Microservices Engine (MSE) allows you to implement an end-to-end canary release based on MSE Ingress gateways. This way, you can implement end-to-end traffic throttling without the need to modify your business code. This topic describes how to use MSE Ingress gateways to implement an end-to-end canary release.
Prerequisites
A Container Service for Kubernetes (ACK) cluster is created. For more information, see Create an ACK managed cluster.
Microservices Governance Professional Edition is activated. For more information, see Activate Microservices Governance.
The MSE Ingress Controller component is installed and relevant permissions are granted to the component. For more information, see Manage components and Grant permissions to MSE Ingress Controller.
Limits
The end-to-end canary release feature is integrated with the tag-based routing feature. If you use Microservices Governance to implement the end-to-end canary release feature for your applications, we recommend that you do not configure canary release rules and tag-based routing rules for the applications.
For more information about the Java versions and frameworks supported by end-to-end canary release, see Java frameworks supported by Microservices Governance.
Background information
In microservices scenarios in which you have deployed Spring Cloud applications or Dubbo applications and new versions are available for these applications, traffic is randomly routed to the applications regardless of the versions in use. In this case, the traffic that has specific characteristics may not be routed to the desired version of an application. To resolve the issue, you can use the end-to-end canary release feature to isolate specific versions of an application from other versions and route request traffic that matches specific rules to the desired version of the application. You can create lanes that are equivalent to independent runtime environments to isolate application versions and configure routing rules for MSE Ingress gateways to route traffic.
Scenario
This topic provides an example on how to implement an end-to-end canary release from an MSE Ingress gateway to microservice applications in the order placement scenarios of the e-commerce industry. In this example, an application architecture consists of an MSE Ingress gateway and a backend microservices framework (Spring Cloud). The following backend applications are involved in the backend call process: a transaction center (Application A), a commodity center (Application B), and an inventory center (Application C). You can use a client or an HTML page to access these backend applications that are registered with a Nacos instance.
After the customer places an order, traffic flows into the MSE Ingress gateway and is routed to the transaction center (Application A), the commodity center (Application B), and the inventory center (Application C) in sequence. The following call process is used: Customer -> MSE Ingress gateway -> Application A -> Application B -> Application C.
Features of application versions are updated alongside business iterations. Before a new version is officially released for Application A and Application C, you must test the version on both the applications by using a canary release. After the version is proven to be stable, you can release the version for the applications. To release new features of a version, you must release the version for both Application A and Application C. The end-to-end canary release feature is provided based on MSE Ingress gateways and Microservices Governance. You can implement an end-to-end canary release from an MSE Ingress gateway to multiple backend applications. This way, canary traffic that has specific characteristics can always be routed to the canary versions of applications. This helps you test a version on multiple applications by using a canary release. If an application does not have a canary version, traffic is automatically routed to the base environment of the application.
Terms
Lane
An isolated environment that is defined for applications of the same version. Only traffic that matches specific traffic control rules can be routed to the applications that are marked in a lane. An application can belong to multiple lanes. A lane can contain multiple applications. Applications have a many-to-many relationship with lanes.
Lane group
A collection of lanes. A lane group is used to distinguish between different teams or scenarios.
MSE Ingress gateway
MSE Ingress gateways allow you to manage ingress traffic based on MSE cloud-native gateways. MSE Ingress gateways are compatible with NGINX Ingress gateways and support more than 50 annotations in NGINX Ingress gateways. MSE Ingress gateways support canary releases of multiple service versions at the same time. MSE Ingress gateways provide flexible service governance capabilities and comprehensive security protection. MSE Ingress gateways are suitable for traffic governance in scenarios in which a large number of cloud-native distributed applications are available.
Preparations
Enable Microservices Governance for applications
Activate MSE Microservices Governance Professional Edition.
For more information, see Activate Microservices Governance.
Enable Microservices Governance for applications.
Log on to the MSE console.
In the left-side navigation pane, choose . Find the cluster that you want to manage, and click Manage in the Actions column.
On the cluster details page, find the namespace that you want to manage, and click Activate Microservices Governance in the Operation column. In the message that appears, click OK.
Deploy demo applications
Log on to the ACK console.
In the left-side navigation pane of the ACK console, click Clusters.
On the Clusters page, find the cluster that you want to manage and click the name of the cluster or click Details in the Actions column. The details page of the cluster appears.
In the left-side navigation pane of the details page, choose .
On the Deployments page, select a namespace, and click Create from YAML.
Configure the parameters and click Create.
In this example, a Nacos Server application is deployed to implement service discovery. Applications A, B, and C are deployed. A base version and a canary version are deployed for Applications A and C, and a base version is deployed for Application B.
Deploy the nacos-server application.
Deploy Application A.
YAML code for the base version
YAML code for the canary version
Deploy Application B.
YAML code for the base version
Deploy Application C.
YAML code for the base version
YAML code for the canary version
Configure two Kubernetes services for Application A, which is an ingress application.
Log on to the ACK console.
In the left-side navigation pane of the details page, choose
On the Services page, select a namespace and click Create Resources in YAML. On the Create page, configure the parameters, and click Create.
YAML code for the spring-cloud-a-base service that is deployed for the base version of Application A
YAML code for the spring-cloud-a-gray service that is deployed for the canary version of Application A
Step 1: Create a lane group
Log on to the MSE console, and select a region in the top navigation bar.
In the left-side navigation pane, choose Microservices Governance > Full link grayscale.
On the Full link grayscale page, click Create Lane Group and Lane. If a lane group is available in the microservice namespace that you select, click Create Lane Group.
In the Create Lane Group panel, configure the parameters and click OK.
Parameter
Description
Lane Group Name
Enter a name of the lane group.
Ingress Type
Select Ingress/Self-managed Gateway.
Lane Group Application
Select all related services involved in your ingress application or Ingress gateway.
After the lane group is created, check whether the ingress application and other involved applications are valid. You can view the lane group that you created in the Lane Groups and Involved Applications section on the Full link grayscale page. To change the lane group information, click the icon on the right and modify the information.
Step 2: Create a lane
On the Full link grayscale page, select the region in which the lane group resides in the top navigation bar, and click Create First Split Lane in the lower part.
If a lane is available in the microservice namespace that you select, click Create Lane.
ImportantIf the end-to-end canary release feature is enabled for applications, we recommended that you do not use the canary release and tag-based routing features for these applications.
In the Create Lane panel, configure the parameters and click OK.
ImportantIf your gateway is an Ingress gateway, you must configure Ingress routing rules in the ACK console.
Parameter
Description
Add Node Tag
Configuration method: In the ACK console, add
alicloud.service.tag: ${tag}
tospec.template.metadata.labels
in the YAML file of the application.Add a tag: Add the following key-value pairs to
spec.template.metadata.labels
.msePilotCreateAppName:${AppName}
alicloud.service.tag:{tag}
Lane Name
Enter a name for the lane.
Lane Tag
After the node tag is configured, the tag is displayed in the Lane Tag drop-down list. If you select the tag that you configured from the drop-down list, the tag is automatically added to the applications in the lane.
After you create a lane, you can view or configure the lane information in the Traffic Distribution section on the Full link grayscale page.
Click the icon to view the traffic percentage of the lane.
Click the icon to configure the status of the lane application in the Actions column.
Enable a lane: Click Enable. Traffic is routed based on the configurations of the lane. Traffic is preferentially routed to the application versions that have the lane tag. If the tagged application versions do not exist, traffic is routed to the untagged application versions.
Disable a lane: Click Disable. Traffic of an application in the lane is subsequently routed to the untagged application versions.
Edit information about a lane: Click Edit.
Delete a lane: Click Delete.
Step 3: Configure Ingress rules for base versions
If the service domain name is example.com
and you want to route traffic of requests to access example.com
to only base versions (online versions), you can use the following code to configure Ingress rules for the base versions.
Use the curl command to access example.com
and route traffic to the base versions.
curl -H "host: example.com" http://47.98.xxx.xx/a
The following result is returned:
A[192.168.0.98][config=base] -> B[192.168.0.157] -> C[192.168.0.161]
Step 4: Configure Ingress routing rules for the canary versions
You use a header-based routing rule to distinguish base traffic and canary traffic. You want to route requests with the HTTP header x-user-id: 100
to canary versions for access to example.com
. In this example, requests are preferentially routed to the canary version of each application. If an application has no canary version, requests are routed to the base version of the application. The following code is used to configure an Ingress routing rule for the canary versions.
The preceding code uses annotations to implement the canary release, header configuration, and header control capabilities. For more information about how to use annotations, see Advanced usage of MSE Ingress.
Run the curl command to access example.com
and route requests with the HTTP header x-user-id: 100
to the canary versions.
curl -H "host: example.com" -H "x-user-id: 100" http://47.98.xxx.xx/a
The following result shows that canary traffic is preferentially routed to the canary versions of Applications A and C. For Application B, traffic is routed to the base version because no canary version is available for the application.
Agray[192.168.0.128][config=base] -> B[192.168.0.152] -> Cgray[192.168.0.151]
View the traffic monitoring charts of applications in the MSE console
View the monitoring chart of a single application.
On the Full link grayscale page, click the tab of the lane group whose monitoring information you want to view.
In the Lane Groups and Involved Applications section, click the name of the application whose monitoring information you want to view. The queries per second (QPS) data is displayed in the QPS data section on the right of the page.
View the monitoring charts of all applications in the lane group.
On the Full link grayscale page, click the tab of the lane group whose monitoring information you want to view.
On the right side of the Application QPS Monitoring section, click View Traffic Details to view the traffic monitoring charts of all applications in the lane.