This topic describes how to perform environment isolation in Serverless App Engine (SAE) based on Message Queue for Apache RocketMQ. You can perform traffic control in an asynchronous manner without the need to modify business code.

Background information

dg_rocket_mq_workflow
  • Supported versions of Message Queue for Apache RocketMQ: 4.2.0 and later.
  • The pull and push modes are supported.
  • You must configure the enablePropertyFilter=true setting on your server and then restart the server.

Preparations

Deploy SAE demo applications

  1. Download the demo package.
  2. Deploy backbone applications.
    Deploy the following backbone applications: Application A, Application B, and Application C. For more information, see Host Spring Cloud applications to SAE.
  3. Deploy the following canary release applications: Application A-gray, Application B-gray, and Application C-gray. Add -Dalicloud.service.tag=gray to the startup command to distinguish the canary release applications with the backbone applications.
Note If you want to use a non-SAE built-in service registry when you deploy an application, you must add the following startup parameters: -Dnacos.use.endpoint.parsing.rule=false -Dnacos.use.cloud.namespace.parsing=false.

Deploy RocketMQ

  • Canary release takes effect on messages only when you enable the RocketMQ-based canary release feature for both the producers and consumers of the messages. Only RocketMQ messages support the canary release feature. RocketMQ messages include Apache RocketMQ messages and Message Queue for Apache RocketMQ messages.
    • If you use Apache RocketMQ messages, the versions of RocketMQ Server and RocketMQ Client must be 4.5.0 or later. For more information, see Apache RocketMQ.
    • If you use Message Queue for Apache RocketMQ messages, you must use the Enterprise Platinum Edition of Message Queue for Apache RocketMQ and ons-client 1.8.0.Final or later. For more information, see Overview
  • After you enable the RocketMQ-based canary release feature, SAE modifies the consumer groups of messages. In this example, the tag of a consumer group named group1 is gray. After you enable the RocketMQ-based canary release feature, the consumer group is renamed as group1_gray. If you use Message Queue for Apache RocketMQ messages, make sure that you create a consumer group in advance.
  • By default, SAE uses SQL-92 to filter messages. If you use Apache RocketMQ, you must enable SQL-92 filtering on the server side by setting enablePropertyFilter to true in the broker.conf file.

Step 1: Enable the RocketMQ-based canary release feature for applications

The spring-cloud-c and spring-cloud-a applications in the demo are respectively the producer and consumer of messages. You can add the startup parameter setting -Dprofiler.micro.service.mq.gray.enable=true in SAE to enable the RocketMQ-based canary release feature for the applications.

Note After you enable or disable the RocketMQ-based canary release feature for an application, you must redeploy the application in the SAE console to validate the change.

Step 2: Ingest traffic and perform verification

The following figure shows the structure of this demo. Application calls involve Spring Cloud service calls and Dubbo service calls. Spring Cloud and Dubbo are the two most commonly used microservices frameworks in the market. spring-cloud-c produces RocketMQ messages for spring-cloud-a. When the messages are consumed by spring-cloud-a, new calls are initiated. The following figure shows the basic and standard use of Spring Cloud, Dubbo, and RocketMQ.

dg_implement_end_to_end_canary_release_via_rocket_mq

Before you deploy the applications, we recommend that you understand the call process in the demo. In the call process, spring-cloud-zuul receives a request from /A/dubbo and forwards the request to spring-cloud-a. Then, spring-cloud-a accesses spring-cloud-b by using the Dubbo protocol, and spring-cloud-b accesses spring-cloud-c in the same manner. After spring-cloud-c receives the request, a message is produced and the environment tag and IP address of spring-cloud-c are returned. spring-cloud-a consumes produced messages and calls spring-cloud-b by using the Spring Cloud protocol at the same time. Then, spring-cloud-b calls spring-cloud-c in the same manner and displays results in logs. 

# When you access /A/dubbo,
# the return value is A[10.25.xx.xx] -> B[10.25.xx.xx] -> C[10.25.xx.xx].
# At the same time, spring-cloud-a receives the message and returns the following log:
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]

Log on to the SAE console to view the logs of spring-cloud-a and verify configurations. The baseline environment can consume messages that are produced from the canary release and baseline environments. The Spring Cloud calls from the canary release or baseline environment are routed to the downstream canary release or baseline environment. For more information, see View real-time logs.