Serverless App Engine:Implement end-to-end canary release based on a cloud-native API gateway

Terms

• Cloud-native API gateway: A next-generation gateway product that is compatible with the Kubernetes (K8s) Ingress standard. It combines the features of traditional API gateways, traffic gateways, microservice gateways, and security gateways. It supports multiple service discovery methods, such as Container Service for Kubernetes (ACK) and Nacos, and various authentication methods to quickly build a security layer. For more information, see What is a cloud-native API gateway?.

• Lane: A set of isolated environments for applications of the same version. Only request traffic that meets the traffic shaping and routing rules is routed to the tagged applications in the corresponding lane. An application can belong to multiple lanes, and a lane can contain multiple applications. The relationship between applications and lanes is many-to-many.

• Lane group: A collection of lanes. Lane groups are mainly used to distinguish between different teams or scenarios.

• Baseline environment: Untagged applications belong to the baseline environment. This environment serves as a fallback for other environments.

Scenarios

This topic uses a simulated call chain to demonstrate how to implement an end-to-end canary release based on a cloud-native API gateway without modifying business code. You only need to set traffic rules for the ingress application. The traffic tag is then passed through the call chain to subsequent applications. During the invocation process, traffic that meets the rules is routed to the corresponding canary application. If a canary application does not exist, the traffic is automatically routed to the baseline application.

The test applications are as follows:

Test application: end-to-end-canary-release-demo.zip. This file contains three backend applications, A, B, and C. These backend applications can be used for both baseline and canary deployments.

The following figure shows how traffic is distributed.

Normal traffic call chain:

API service gateway -> Application sae-a -> Application sae-b -> Application sae-c.

Tagged traffic call chain:

• t=g1 traffic: API service gateway -> Application sae-a-a1 -> Application sae-b -> Application sae-c-c1.

• t=g2 traffic: API service gateway -> Application sae-a-a2 -> Application sae-b-b2 -> Application sae-c-c2.

Prerequisites

• You have activated the Professional or Enterprise Edition of Microservice Engine (MSE) microservice governance. For more information, see Activate MSE microservice governance.

• You have created a cloud-native API gateway instance. For more information, see Create a gateway instance.

• You have created an MSE Nacos instance and a namespace. For more information, see Create an instance and Create a namespace.

Limits

• End-to-end canary release is applicable only to microservice applications that are created on or after November 8, 2023.

• The end-to-end canary release feature is supported only in the new version of the console.

• The end-to-end canary release feature integrates the tag-based routing feature of MSE microservice governance. This feature is different from the tag-based routing feature of MSE cloud-native gateways. Therefore, we recommend that you do not configure both canary release and tag-based routing rules for applications that are part of an end-to-end canary release.

  Limits and values

  Limit	Limit	Remarks
  Gateway service source type	MSE Nacos and K8s Service	End-to-end canary release based on a cloud-native API gateway currently supports only MSE Nacos and K8s Service as sources.
  Cloud-native API gateway version	2.0.1 or later	For versions earlier than 2.0.1, you must manually upgrade the database engine version on the Instances page of the cloud-native API gateway console.
  Spring Cloud version	Spring Cloud Edgware or later	None.
  Dubbo version	2.5.3 to 2.7.8	Dubbo 3.0 and later are in canary release. If you require this feature, submit a ticket to contact MSE technical support.
  Client type	Resttemplate Spring Cloud OpenFeign	None.
  JDK version for Java applications	JDK 6, 7, and 8 are supported.	JDK 11 is in canary release. If you require this feature, submit a ticket to contact MSE technical support.
  Load balancing type	Ribbon 2.0.x or later LoadBalancer 3.0.x or later	None.
  Spring Cloud Gateway version	Spring Cloud Gateway 2.1.0.RELEASE or later	None.

1. Deploy baseline applications and enable microservice governance for them

2. Deploy canary applications

Deploy canary applications based on the baseline applications:

• The baseline application sae-a has two canary applications: sae-a-a1 and sae-a-a2.

• The baseline application sae-b has one canary application: sae-b-b2.

• The baseline application sae-c has two canary applications: sae-c-c1 and sae-c-c2.

Perform the following steps:

1. On the application list page, click the icon in the row of the baseline application, and then click Create Canary Application.

   Note

   You cannot create a canary application if microservice governance is not enabled for the baseline application. For information about how to enable the feature, see Enable microservice governance for the baseline applications.

2. On the Basic Information wizard page, configure the following information, and then click Next: Advanced Settings.

   1. In the Basic Information Settings section, set the canary Application Name and select a method to deploy the canary application. For more information, see Deploy an application.

      Note

      • The Namespace of the canary application is automatically inherited from the baseline application. You do not need to change it.

      • The Application Deployment Method is also automatically inherited from the baseline application. In this example, you do not need to upload the code package again. However, in a production environment, adjust the configuration as needed.

   2. In the Canary Tag section, set the tag Value. For the tag configuration in this example, see Scenarios.

      

   3. In the Capacity Settings section, configure the single-instance specifications and the number of instances.

3. On the Advanced Settings wizard page, configure related features as needed. For more information, see Advanced configurations.

   Note

   The service discovery feature of the canary application is automatically inherited from the baseline application. You do not need to change it.

4. Click Create Application.

3. Create a cloud-native API Gateway route

1. In SAE Gateway Routing, select a region and namespace from the top menu bar, and then click Create Gateway Route.

2. On the Create Route page, create a cloud-native API gateway route. This topic describes only the key steps. For detailed configuration instructions, see Configure a cloud-native API Gateway routing rule for an SAE application.

   Note

   The configurations in this topic are for demonstration purposes only. In a production environment, adjust the configurations as needed.

   1. Set Gateway Type to Cloud-native API Gateway.

   2. For Gateway Instance, select the gateway instance that you created.

   3. Set Path to Prefix and enter /.

   4. Set Service Source to MSE Nacos.

   5. For MSE Nacos Instance and MSE Nacos Namespace, select the same MSE Nacos instance and namespace as the baseline application.

      

   6. Set Scenario to Single Service.

   7. For Backend Services, set Application Name to sae-a, Service Name to sc-A, Terms of Service to HTTP, and Service Port to 20001.

3. Click Save.

4. Create a lane group and lanes

5. Verify the results

# Test command
curl 8.130.XX.XX/a
# Test result
A[192.168.XX.XX][config=base] -> B[192.168.XX.XX] -> C[192.168.XX.XX]
A${tag}[192.168.XX.XX][config=base] -> B[192.168.XX.XX] -> C${tag}[192.168.XX.XX]