Service Mesh (ASM) allows you to isolate a version or certain features of an application into an independent runtime environment (known as lane). Then, you can configure lane rules to route requests that meet the rules to the destination version or features of the application. This topic describes the concepts and use scenarios of traffic lanes, and traffic lanes in both strict and permissive modes.
Feature description
Canary release allows you to incrementally roll out new services or versions. For example, if you want to release a new version, you can first direct a portion of traffic to the version to test its functionality, and then increase traffic after the functionality is verified.
When services call each other, you may need to isolate environments and perform traffic shaping for the end-to-end service call chain when you perform a canary release. In other words, you must make sure that canary release traffic is sent to only the canary release versions of the services in the corresponding call chain. This way, different call chains are isolated from each other.
Such call chains that consist of different services with the same version or certain features are called traffic lanes. By using traffic lanes, you need to configure only a few rules to build isolated environments for traffic from the gateway to services. Traffic lanes facilitate the release of multiple services and parallel development of multiple versions of a service.
Traffic lanes have two modes: strict and permissive. The following section describes these two modes of traffic lanes in detail.
Traffic lanes in strict mode
In strict mode, each traffic lane contains all services in relevant call chains. This mode has no requirements for your application. You need to only configure traffic lanes to implement end-to-end traffic management. For more information, see Use traffic lanes in strict mode to manage end-to-end traffic.
Traffic lanes in permissive mode
In permissive mode, you need to only create a baseline lane that contains all services in relevant call chains. Other lanes are not required to contain all services in relevant call chains. When services in a lane call each other, if the service to be called does not exist in the lane, requests are forwarded to the same service in the baseline lane. When the service to be called becomes available in the lane, requests are forwarded back to the desired service in the lane. When you use traffic lanes in permissive mode, your application must add headers that can be transparently transmitted throughout the corresponding call chains in requests and such headers have different values. These request headers are called the end-to-end (E2E) pass-through request headers. For more information, see Scenario 1: Request routing headers are different from E2E pass-through request headers and Scenario 2: Request routing headers are the same as E2E pass-through request headers.
Comparison between the strict mode and the permissive mode
Traffic lane mode | Benefit | Limit | Use scenario |
Strict mode | No requirements are imposed on your applications. | Each traffic lane must contain all services in relevant call chains. | This mode is applicable to the scenario where you perform canary releases for all services in a call chain. When you perform canary releases for all services in a call chain, the strict mode has lower requirements on your applications compared with the permissive mode. |
Permissive mode | It is required that your application must add E2E pass-through request headers in requests and such headers have different values. | You must ensure that a baseline lane contains all services in relevant call chains and that service requests in other lanes can be forwarded to the baseline lane. | When E2E pass-through request headers are used, traffic lanes in permissive mode can be used in more scenarios. For example, when only new versions of some services in a call chain are released, you can use traffic lanes in permissive mode to test these new versions. |