Service Mesh (ASM) provides a feature of swimlanes in permissive mode that allows users to deploy multiple partial environments for a full version. However, ASM does not support message queuing protocols in certain scenarios where a trace contains a message queue. To ensure that traffic tags can be delivered in a message queue , adaptation process is necessary. This topic describes how to integrate message queues with the swimlanes in permissive mode.
Prerequisites
Make sure that the message queue and application deployment meet the following requirements:
Message queue
You can specify custom metadata in a message.
A consumer can consume only the messages that have specific characteristics.
Application deployment
In the message queue from which messages are actively pulled by a consumer, the consumer cannot detect the service discovery information related to the swimlane. To consume messages as expected, you must deploy valid consumers and producers in a swimlane as follows:
Valid deployment: Deploy a producer or a consumer in a swimlane or neither.
Invalid deployment: Deploy a producer or a consumer in a swimlane.
Solution
A producer in a message queue writes swimlane tags to messages
The swimlane tag for a request in a trace must remain unchanged even after the request passes through a message queue. In this way, a consumer can consume messages sent by an application in the swimlane and restore the tags carried in the messages to the requests sent to the upstream service. For example, when the producer application APP-B writes the tags into a message queue, the producer must specify both the swimlane where the application resides and the swimlane tags of the request received from the downstream service in the messages, and the consumer must specify the swimlane where the application resides in the tag-filtering condition fields.
Swimlane where the application resides: This serves as the filter key. A swimlane where an application resides is characteristed by the tag of its workload . You can obtain the swimlane where an application resides by exposing the value of an environment variable tag to the application.
Swimlane tags of the request received from the downstream service: After the traffic passes through the ASM ingress gateway, the requests sent by the gateway contain swimlane tags and can be routed to specified swimlane by using the mesh proxy. ASM passes the tags to end-to-end HTTPS through the request header
x-asm-prefer-tag.
A consumer in a message queue consumes messages in the swimlane where an application resides
To enable a consumer to consume messages in a specified message queue, the consumer must subscribe to the filter key of the swimlane where an application resides.
A producer and a consumer are deployed in swimlane v1 and v2: a producer and a consumer are deployed in both swimlanes v1 and v2. APP-C(v1) can consume the message with the filter key v1. This means that APP-C(v1) only consume the message produced by APP-B(v1). APP-C(v2) can consume the message with the filter key v2. This means that APP-C(v2) only consume the message produced by APP-B(v2).
Neither producer or consumer is deployed in swimlane v2: a producer and a consumer are deployed in the swimlane v1, while only APP-A(v2) and APP-D(v2) are deployed in the swimlane v2. The request received by APP-A(v2) is routed to APP-B(v1) in the swimlane in permissive mode because the APP-B(v2) is not deployed. After a message is sent to APP-B(v1) from APP-A(v1) or APP-A(v2), the system specifies the filter key as the swimlane tag before the message is consumed by APP-C(v1). After the message is consumed by App-Cv1, APP-C(v1) removes the tag of swimlane v1 carried in the messages. In this way, when messages are sent to APP-D, the messages tagged with swimlane v2 can be routed to APP-D(v2).
A consumer application writes the swimlane tag carried in a message to the request sent to the downstream service
If a message is required to be routed to other applications after a consumer application consumes the message, the consumer application needs to write the swimlane tag carried in the message to the request sent to other application. In this way, ASM mesh proxy can route request to different applications based on the tag.
After the preceding configuration is complete, the consumer application adds the request header x-asm-prefer-tag to the request to be sent and specifies the header value as the swimlane tag carried in the messages that are consumed from the message queue. ASM mesh proxy routes the request with the request header x-asm-prefer-tag to the specified swimlane.