Online scenario: Perform an end-to-end canary release by using self-managed Spring Cloud or Zuul gateways - Serverless App Engine

This topic describes how to perform an end-to-end canary release for Serverless App Engine (SAE) applications by using self-managed Spring Cloud or Zuul gateways. You can perform end-to-end traffic shaping without the need to modify business code.

Preparations

The following section describes how to use an Application Load Balancer (ALB) instance as an ingress gateway to perform end-to-end canary release. In this example, an application architecture consists of an ALB ingress gateway and a backend microservices framework (Spring Cloud). Backend service calls involve the following microservices applications: a shopping cart (Application A), a transaction center (Application B), and an inventory center (Application C). You can use a client or HTML to access backend services that are registered by using a Nacos registry.

Deploy SAE demo applications

Download the demo package.
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.
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 Spring Cloud or Zuul gateways

You can access applications by forwarding requests from the same domain name but different URLs. For more information, see Configure gateway routing for an application by using a CLB instance.

Perform an end-to-end canary release by adding specific headers to requests

The domain names of some clients cannot be changed. You can associate the www.base.com domain name with a route and add specific headers. This way, you can route specific requests to the canary release environment. In the following figure, a request is routed to canary release environments after the x-mse-tag:gray header is added to the request.

Warning

The x-mse-tag header is suitable for only the scenario described in this topic. Do not use this header in other scenarios. For example, do not use the x-mse-tag header when you configure canary release rules for applications. For more information, see Manage canary release rules for Java applications.

dg_implement_end_to_end_canary_release_by_using_self-managed_spring _cloud_or_zuul_gateways

Verify the results.

Check whether the traffic that is destined for www.base.com is routed to the baseline environment.
- Run the following curl command:
```
curl -H"Host:www.base.com" http://106.14.XX.XX/a
```
- Command output:
```
A[172.18.XX.XX] -> B[172.18.XX.XX] -> C[172.18.XX.XX]
```
To route a request to canary release environments, add the x-mse-tag:gray header to the request.
- Run the following curl command:
```
curl -H"Host:www.base.com"  -H"x-mse-tag:gray" http://106.14.XX.XX/a
```
- Command output:
```
Agray[172.18.XX.XX] -> Bgray[172.18.XX.XX] -> Cgray[172.18.XX.XX]%
```
  The preceding output indicates that the Classic Load Balancer (CLB) Ingress controller routes the request to the canary release environment of Application A.