consul/website/content/docs/connect/l7-traffic/index.mdx

---
layout: docs
page_title: Service Mesh Traffic Management - Overview
description: >-
  Consul can route, split, and resolve Layer 7 traffic in a service mesh to support workflows like canary testing and blue/green deployments. Learn about the three configuration entry kinds that define L7 traffic management behavior in Consul.
---

-> **1.6.0+:** This feature is available in Consul versions 1.6.0 and newer.

# Service Mesh Traffic Management Overview

Layer 7 traffic management allows operators to divide L7 traffic between
different
[subsets](/consul/docs/connect/config-entries/service-resolver#service-subsets) of
service instances when using service mesh.

There are many ways you may wish to carve up a single datacenter's pool of
services beyond simply returning all healthy instances for load balancing.
Canary testing, A/B tests, blue/green deploys, and soft multi-tenancy
(prod/qa/staging sharing compute resources) all require some mechanism of
carving out portions of the Consul catalog smaller than the level of a single
service and configuring when that subset should receive traffic.

-> **Note:** This feature is not compatible with the
[built-in proxy](/consul/docs/connect/proxies/built-in),
[native proxies](/consul/docs/connect/native),
and some [Envoy proxy escape hatches](/consul/docs/connect/proxies/envoy#escape-hatch-overrides).

## Stages

Service mesh proxy upstreams are discovered using a series of stages: routing,
splitting, and resolution. These stages represent different ways of managing L7
traffic.

![screenshot of L7 traffic visualization in the UI](/img/l7-routing/full.png)

Each stage of this discovery process can be dynamically reconfigured via various
[configuration entries](/consul/docs/agent/config-entries). When a configuration
entry is missing, that stage will fall back on reasonable default behavior.

### Routing

A [`service-router`](/consul/docs/connect/config-entries/service-router) config
entry kind is the first configurable stage.

![screenshot of service router in the UI](/img/l7-routing/Router.png)

A router config entry allows for a user to intercept traffic using L7 criteria
such as path prefixes or http headers, and change behavior such as by sending
traffic to a different service or service subset.

These config entries may only reference `service-splitter` or
`service-resolver` entries.

[Examples](/consul/docs/connect/config-entries/service-router#sample-config-entries)
can be found in the `service-router` documentation.

### Splitting

A [`service-splitter`](/consul/docs/connect/config-entries/service-splitter) config
entry kind is the next stage after routing.

![screenshot of service splitter in the UI](/img/l7-routing/Splitter.png)

A splitter config entry allows for a user to choose to split incoming requests
across different subsets of a single service (like during staged canary
rollouts), or perhaps across different services (like during a v2 rewrite or
other type of codebase migration).

These config entries may only reference `service-splitter` or
`service-resolver` entries.

If one splitter references another splitter the overall effects are flattened
into one effective splitter config entry which reflects the multiplicative
union. For instance:

    splitter[A]:           A_v1=50%, A_v2=50%
    splitter[B]:           A=50%,    B=50%
    ---------------------
    splitter[effective_B]: A_v1=25%, A_v2=25%, B=50%

[Examples](/consul/docs/connect/config-entries/service-splitter#sample-config-entries)
can be found in the `service-splitter` documentation.

### Resolution

A [`service-resolver`](/consul/docs/connect/config-entries/service-resolver) config
entry kind is the last stage.

![screenshot of service resolver in the UI](/img/l7-routing/Resolver.png)

A resolver config entry allows for a user to define which instances of a
service should satisfy discovery requests for the provided name.

Examples of things you can do with resolver config entries:

- Control where to send traffic if all instances of `api` in the current
  datacenter are unhealthy.

- Configure service subsets based on `Service.Meta.version` values.

- Send all traffic for `web` that does not specify a service subset to the
  `version1` subset.

- Send all traffic for `api` to `new-api`.

- Send all traffic for `api` in all datacenters to instances of `api` in `dc2`.

- Create a "virtual service" `api-dc2` that sends traffic to instances of `api`
  in `dc2`. This can be referenced in upstreams or in other config entries.

If no resolver config is defined for a service it is assumed 100% of traffic
flows to the healthy instances of a service with the same name in the current
datacenter/namespace and discovery terminates.

This should feel similar in spirit to various uses of Prepared Queries, but is
not intended to be a drop-in replacement currently.

These config entries may only reference other `service-resolver` entries.

[Examples](/consul/docs/connect/config-entries/service-resolver#sample-config-entries)
can be found in the `service-resolver` documentation.

-> **Note:** `service-resolver` config entries kinds can function at L4 (unlike
`service-router` and `service-splitter` kinds). These can be created for
services of any protocol such as `tcp`.