Alibaba Cloud Service Mesh:Use traffic lanes in permissive mode to manage end-to-end traffic

Feature introduction

Traffic lanes in permissive mode allow you to flexibly isolate application versions. Traffic is routed to different lanes based on request routing headers and E2E pass-through request headers. 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. This feature ensures the integrity of traces and simplifies traffic management.

The following section provides more information about traffic lanes in permissive mode.

Pass-through modes of trace context

To use traffic lanes in permissive mode, applications must support pass-through of trace context. This means that the applications must have the following characteristics: All requests in the same trace have the same request header.

Traffic lanes in permissive mode support common pass-through modes of trace context for applications. You can configure traffic lanes in permissive mode based on your business requirements.

Scenario 1: Pass through trace IDs

A trace ID request header is a request header that has the following characteristics:

• The content of the request header can be transparently transmitted throughout the entire trace.

• The content of the request header varies for each trace.

A trace ID is generally used to uniquely identify a complete trace, and its content is a random string. If your application is connected to a tracing system, your application may have the ability to pass through trace IDs. Some common tracing standards define unique trace ID request headers, such as x-b3-trace-id and x-datadog-trace-id.

Scenario 2: Pass through custom request headers

Applications may use code to implement pass-through of some request headers with service information, such as version and environment. Such request headers are commonly used to identify the version and environment of traces. To use traffic lanes in permissive mode in this scenario, you can only use pass-through custom request headers as request routing headers.

Scenario 3: Pass through Baggage headers

Baggage is a standardized mechanism developed by OpenTelemetry to propagate context information across processes in traces of a distributed system. To do this, you can add an HTTP header named Baggage to HTTP headers. The value of a Baggage header is in the key-value pair format. You can use Baggage headers to transfer context data such as tenant ID, trace ID, and security credential. This way, you can use the tracing analysis and log association features without the need to modify code. Example:

baggage: userId=alice,serverNode=DF%2028,isProduction=false

Baggage is a standardized mechanism proposed by the OpenTelemetry community for transparently transmitting trace context. Therefore, we also recommend that you configure traffic lanes in permissive mode based on this mechanism.

Request routing header

Typically, traffic lanes in permissive mode use request routing headers to label request traces. You can specify any request routing header as long as it does not conflict with the existing service-related request headers of the application. Based on the trace context pass-through mode you select, traffic lanes in permissive mode ensure that each request in the trace contains a request routing header whose value is the lane name. For example, if you set the Routing Request Header parameter to x-asm-prefer-tag during lane group creation, when a request is sent to a service in the s1 lane, subsequent requests in the trace always contain the x-asm-prefer-tag: s1 request header. Based on the lane tag information in request headers, traffic lanes can isolate different versions of an application.

If you set the Pass-through Mode of Trace Context parameter to Pass Through Custom Header, you must set the request routing header to the custom request header that will be passed through.

Scenario description

Traffic lanes in permissive mode allow you to isolate application versions in multiple ways. In the examples in the following scenarios, you will learn how to route traffic to lanes by using three different pass-through request headers and how to configure and use custom virtual services to route traffic for traffic lanes in permissive mode.

• Preparations for using traffic lanes in permissive mode to manage end-to-end traffic

• Scenario 1: Pass through trace IDs in traces

• Scenario 2: Pass through custom request headers in traces

• Scenario 3: Pass through Baggage headers in traces

• Use custom virtual services to route traffic for traffic lanes in permissive mode

References

• Traffic lanes have two modes: strict and permissive. For more information about the descriptions and differences between the two modes, see Overview of traffic lanes.

• If you want to use traffic lanes in permissive mode to manage E2E traffic in scenarios where request routing headers are the same as E2E pass-through request headers, see Scenario 2: Pass through custom request headers in traces.

• You can configure traffic lanes by specifying virtual services and destination rules. You can also use these rules to configure traffic shifting, which routes traffic to a version with a lower priority or an application with specific characteristics when the destination version or application is unavailable. For more information, see Use traffic rules to configure traffic lanes and traffic shifting.

• Request routing rules of traffic lanes include matching rules for request headers and request paths. You can create custom virtual services to define more complex matching rules or create custom request routes. For more information, see Use custom virtual services to route traffic for traffic lanes in permissive mode.