Achieve RocketMQ Canary Release Environment Isolation in SAE - Serverless App Engine - Alibaba Cloud - Serverless App Engine

Serverless App Engine (SAE) integrates with ApsaraMQ for RocketMQ to extend full-link environment isolation to asynchronous message paths — without modifying your business code.

How it works

When the canary release feature is enabled, SAE uses RocketMQ message properties to route messages by environment tag. The tag on each message determines which consumer group receives it:

Environment tag	Consumer group (example)	Messages routed to
(none — baseline)	`group1`	Baseline consumers only
`gray`	`group1_gray`	Canary release consumers only

The baseline environment can consume messages from both environments. Calls triggered by message consumption follow the same routing rules as synchronous traffic — requests from the canary release environment go to canary release downstream services, and baseline requests go to baseline downstream services.

The canary release feature is effective for messages only if it is enabled on both producers and consumers. If only one side enables it, the feature is not effective.

Prerequisites

Before you begin, ensure that you have:

A supported version of Message Queue for Apache RocketMQ. Supported versions: 4.2.0 and later.

RocketMQ variant	Version requirement
Apache RocketMQ (open-source)	RocketMQ Server and RocketMQ Client 4.5.0 or later
ApsaraMQ for RocketMQ (commercial)	Platinum Edition; Ons Client 1.8.0.Final or later. For more information, see the quick start overview.

SQL92 filtering enabled on the broker. Set enablePropertyFilter=true in broker.conf and restart the broker.
Both pull mode and push mode are supported.
After enabling the RocketMQ-based canary release feature, SAE modifies the message consumer groups. For example, if your original consumer group is group1 and your environment tag is gray, SAE renames it to group1_gray after the feature is activated. If you are using ApsaraMQ for RocketMQ, pre-create any consumer groups that the canary release feature will rename before enabling the feature.

Step 1: Deploy the demo applications

Download the demo package.
Deploy the backbone applications — Application A, Application B, and Application C. For details, see Host Spring Cloud applications to SAE.
Deploy the canary release applications — Application A-gray, Application B-gray, and Application C-gray. Add -Dalicloud.service.tag=gray to the startup command of each canary release application to distinguish them from the backbone applications.

If you use a non-SAE built-in service registry, add the following startup parameters to each application: -Dnacos.use.endpoint.parsing.rule=false -Dnacos.use.cloud.namespace.parsing=false.

Step 2: Enable the canary release feature

In the demo, spring-cloud-c is the producer and spring-cloud-a is the consumer. Enable the canary release feature on both by adding the following startup parameter:

-Dprofiler.micro.service.mq.gray.enable=true

Add this parameter to the startup command of both spring-cloud-c and spring-cloud-a, then redeploy each application on the SAE console.

To disable the feature, remove the parameter and redeploy.

Step 3: Verify environment isolation

dg_implement_end_to_end_canary_release_via_rocket_mq

The call chain works as follows:

spring-cloud-zuul receives a request to /A/dubbo and forwards it to spring-cloud-a.
spring-cloud-a calls spring-cloud-b using the Dubbo protocol; spring-cloud-b calls spring-cloud-c.
spring-cloud-c produces a RocketMQ message and returns its environment tag and IP address.
spring-cloud-a consumes the message and simultaneously calls spring-cloud-b using the Spring Cloud protocol; spring-cloud-b calls spring-cloud-c again.
Results appear in the logs.

Send a test request to /A/dubbo. The expected response and log output are:

# Response:
A[10.25.xx.xx] -> B[10.25.xx.xx] -> C[10.25.xx.xx]

# Log on spring-cloud-a after consuming the message:
c.a.mse.demo.service.MqConsumer: topic:TEST_MQ,producer:C[10.25.xx.xx],invoke result:A[10.25.xx.xx] -> B[10.25.xx.xx] -> C[10.25.xx.xx]

To view the logs, log on to the SAE console and open the spring-cloud-a application log.

Confirm that:

Messages produced by a canary release application are only consumed by canary release consumers.
Messages produced by a baseline application are only consumed by baseline consumers.
The baseline environment can also consume messages produced by canary release applications.