Implement an end-to-end canary release based on MSE cloud-native gateways - Microservices Engine

In microservices scenarios, calls among applications are random. If a new version is available for the Spring Cloud application or Dubbo application that you deploy, traffic that has specified characteristics may not be routed to the destination version of the application. To resolve the issue, you can use the end-to-end canary release feature provided by Microservices Engine (MSE) to implement end-to-end traffic throttling without the need to modify your business code. When you use the end-to-end canary release feature, you can create lanes and use them as independent runtime environments to isolate application versions. You can configure lane rules to route traffic that matches the rules to the destination version of the application. This topic describes how to configure an MSE cloud-native gateway to implement an end-to-end canary release.

Implementation process

Limits

The end-to-end canary release feature is integrated with the tag-based routing feature provided by Microservices Governance. If you want 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.

Item	Requirement	Description
Gateway service source type	ACK clusters or MSE Nacos instances	The end-to-end canary release based on MSE cloud-native gateways supports ACK clusters or MSE Nacos instances as service sources.
MSE cloud-native gateway version	1.2.13 or later	If you use a version earlier than 1.2.13, you must upgrade the version to 1.2.13 or later. For more information, see Upgrade an MSE cloud-native gateway.
Spring Cloud version	Spring Cloud Edgware or later	None.
Dubbo version	2.5.3 to 2.7.8	The feature support of applications in Dubbo 3.0 or later is in a canary release. To use the end-to-end canary release feature for applications in Dubbo 3.0 or later, submit a ticket to contact MSE technical support.
Client type	ResttemplateSpring Cloud OpenFeign	None.
JDK version	JDK 1.6, 1.7, or 1.8	The feature support of applications that run JDK 1.11 is in a canary release. If you want to implement an end-to-end canary release for these applications, submit a ticket to contact MSE technical support.
Load balancer 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.
Spring Cloud Zuul version	1.3.x	None.

Sample scenario

This topic provides an example on how to implement an end-to-end canary release from an MSE cloud-native gateway to microservice applications in the order placement scenarios of the e-commerce industry. In this example, the application architecture consists of an MSE cloud-native gateway and a backend microservices architecture (Spring Cloud). Backend service calls involve three applications: a transaction center (Application A), a commodity center (Application B), and an inventory center (Application C). Client-based or HTML-based access to backend applications is supported. An MSE Nacos instance is used for service discovery among the applications.

After a customer places an order, traffic flows into the MSE cloud-native gateway. Then, the MSE cloud-native gateway calls the transaction center (Application A), the transaction center (Application A) calls the commodity center (Application B), and then the commodity center (Application B) calls the inventory center (Application C). The following call process is used: Customer > MSE cloud-native gateway > Application A > Application B > Application C.

New features need to be released along with business iteration. In this example, new versions are released for Application A and Application C. Before the new versions are officially released for Application A and Application C, you must test the new versions on the two applications by using a canary release. After the new versions are proven to be stable, you can release the versions for the applications.

The end-to-end canary release feature is implemented based on MSE cloud-native gateways and Microservices Governance. You can implement an end-to-end canary release from a 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 the versions of multiple applications by using a canary release at the same time. If an application does not have a canary version, traffic is automatically routed to the base version of the application.

使用场景

Terms

MSE cloud-native gateway: a next-generation gateway that is compatible with Kubernetes Ingress. MSE cloud-native gateways support service discovery based on multiple sources such as Container Service for Kubernetes (ACK) and Nacos instances. MSE cloud-native gateways also support multiple logon authentication methods to provide security protection.
Lane: an isolated environment that is defined for applications of the same version. Only requests that match specific routing rules can be routed to the tagged applications 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.
Base environment: .an environment in which untagged applications run. Base environments provide disaster recovery for other environments.

Preparations

Create an ACK cluster

For more information about how to create an ACK cluster, see Create an ACK dedicated cluster or Create an ACK managed cluster.

Enable MSE Microservices Governance for applications

Important

Make sure that the version of the MSE Java agent is 3.2.3 or later. Otherwise, your business may be adversely affected.

On the Microservice Governance tab, activate Microservices Governance Professional Edition.
Enable Microservices Governance for microservice applications in the Container Service for Kubernetes (ACK) cluster. You can select an appropriate method based on your business requirements. For more information, see Enable Microservices Governance for microservice applications in an ACK cluster.

Create an MSE cloud-native gateway

For more information, see Create an MSE cloud-native gateway.

Associate the cloud-native gateway with a service source

For more information, see Add a service source.

Note

The end-to-end canary release based on MSE cloud-native gateways supports ACK clusters or MSE Nacos instances as service sources.
The MSE cloud-native gateway and ACK cluster or MSE Nacos instance must be deployed in the same virtual private cloud (VPC).

1. Build a base environment for business applications

Step 1: Deploy the base versions of backend applications

Log on to the ACK console.
In the left-side navigation pane, click Clusters. Then, click the name of the cluster that you want to manage.
In the left-side navigation pane, choose Workloads > Deployments.
In the upper part of the page, select the namespace of the cluster, and click Create from YAML.

Deploy the base versions of backend applications

Use an MSE Nacos instance as the service source

Copy the following Yet Another Markup Language (YAML) code to deploy the base versions of Application A, Application B, and Application C.

Note

Replace {nacos server address} in the code with the internal endpoint of the MSE Nacos instance and remove the curly braces {}.

Show YAML code

# YAML code for the base version of Application A
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-a
  template:
    metadata:
      labels:
        app: spring-cloud-a
        msePilotCreateAppName: spring-cloud-a
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-a
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-a:1.0.0
        imagePullPolicy: Always
        ports:
          - containerPort: 20001
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 30
          periodSeconds: 60
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: {nacos server address}
        - name: dubbo.registry.address
          value: 'nacos://{nacos server address}:8848'
---
# YAML code for the base version of Application B
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-b
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-b
  template:
    metadata:
      labels:
        app: spring-cloud-b
        msePilotCreateAppName: spring-cloud-b
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-b
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-b:1.0.0
        imagePullPolicy: Always
        ports:
          - containerPort: 20002
        livenessProbe:
          tcpSocket:
            port: 20002
          initialDelaySeconds: 30
          periodSeconds: 60
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: {nacos server address}
        - name: dubbo.registry.address
          value: 'nacos://{nacos server address}:8848'
---
# YAML code for the base version of Application C
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-c
  template:
    metadata:
      labels:
        app: spring-cloud-c
        msePilotCreateAppName: spring-cloud-c
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-c
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-c:1.0.0
        imagePullPolicy: Always
        ports:
          - containerPort: 20003
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 30
          periodSeconds: 60
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: {nacos server address}
        - name: dubbo.registry.address
          value: 'nacos://{nacos server address}:8848'

Use an ACK cluster as the service source

Copy the following YAML code to deploy an MSE Nacos instance as a self-managed service registry.

Show YAML code

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nacos-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nacos-server
  template:
    metadata:
      labels:
        msePilotAutoEnable: "off"
        app: nacos-server
    spec:
      containers:
        - name: nacos-server
          image: 'registry.cn-shanghai.aliyuncs.com/yizhan/nacos-server:v2.1.2'
          env:
            - name: MODE
              value: standalone
            - name: JVM_XMS
              value: 512M
            - name: JVM_XMX
              value: 512M
            - name: JVM_XMN
              value: 256M
          imagePullPolicy: Always
          livenessProbe:
            failureThreshold: 3
            initialDelaySeconds: 15
            periodSeconds: 10
            successThreshold: 1
            tcpSocket:
              port: 8848
            timeoutSeconds: 3
          readinessProbe:
            failureThreshold: 5
            initialDelaySeconds: 15
            periodSeconds: 15
            successThreshold: 1
            tcpSocket:
              port: 8848
            timeoutSeconds: 3
          resources:
            requests:
              cpu: '1'
              memory: 2Gi
      dnsPolicy: ClusterFirst
      restartPolicy: Always

---
apiVersion: v1
kind: Service
metadata:
  name: nacos-server
spec:
  type: ClusterIP
  ports:
    - name: nacos-server-8848-8848
      port: 8848
      protocol: TCP
      targetPort: 8848
    - name: nacos-server-9848-9848
      port: 9848
      protocol: TCP
      targetPort: 9848
  selector:
    app: nacos-server

Copy the following YAML code to deploy the base versions of Application A, Application B, and Application C.

Show YAML code

# YAML code for the base version of Application A
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-a
  template:
    metadata:
      labels:
        app: spring-cloud-a
        msePilotCreateAppName: spring-cloud-a
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-a
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-a:1.0.0
        imagePullPolicy: Always
        ports:
          - containerPort: 20001
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 30
          periodSeconds: 60
        # Access the self-managed Nacos instance by using the Nacos service.
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: nacos-server
        - name: dubbo.registry.address
          value: 'nacos://nacos-server:8848'
---
# YAML code for the base version of Application B
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-b
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-b
  template:
    metadata:
      labels:
        app: spring-cloud-b
        msePilotCreateAppName: spring-cloud-b
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-b
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-b:1.0.0
        imagePullPolicy: Always
        ports:
          - containerPort: 20002
        livenessProbe:
          tcpSocket:
            port: 20002
          initialDelaySeconds: 30
          periodSeconds: 60
        # Access the self-managed Nacos instance by using the Nacos service.
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: nacos-server
        - name: dubbo.registry.address
          value: 'nacos://nacos-server:8848'
---
# YAML code for the base version of Application C
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-c
  template:
    metadata:
      labels:
        app: spring-cloud-c
        msePilotCreateAppName: spring-cloud-c
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-c
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-c:1.0.0
        imagePullPolicy: Always
        ports:
          - containerPort: 20003
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 30
          periodSeconds: 60
        # Access the self-managed Nacos instance by using the Nacos service.
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: nacos-server
        - name: dubbo.registry.address
          value: 'nacos://nacos-server:8848'

Copy the following YAML code to create a service for Application A that works as an ingress application.

Show YAML code

# Expose Application A.
apiVersion: v1
kind: Service
metadata:
  name: sc-a
  namespace: default
spec:
  ports:
    - port: 20001
      protocol: TCP
      targetPort: 20001
  selector:
    app: spring-cloud-a
  type: ClusterIP

Step 2: Use the MSE cloud-native gateway to expose Application A

Case 1: Expose a new service

If you have not added Application A to the cloud-native gateway, perform the following steps to expose Application A:

Log on to the MSE console. On the Services tab of the Routes page, click Add Service. In the Add Service panel, configure the following settings:
- Use an ACK cluster as the service source
  - Service Source: Select Container Service.
  - Namespace: Select default.
  - Services: Select sc-a.
- Use an MSE Nacos instance as the service source
  - Service Source: Select MSE Nacos.
  - Namespace: Select public.
  - Services: Select sc-A.
For more information about how to add a service, see Add a service.
On the Services tab, find the service sc-a or sc-A and click Policies in the Actions column.
Check whether the Service version of the sc-a or sc-A service meets the following conditions:
- Version Name is set to base.
- Tag Name is set to opensergo.io/canary.
- Tag Value is left empty.
In normal cases, the preceding base version is added for the imported Nacos instance or ACK cluster by default, and the number of Number of instances of the base version is greater than 0.
On the Route Settings tab, click Add Route to create a route for sc-a or sc-A.
- In the Request Information step, specify Routing Rule Name and Domain Name, and select Prefix matching from the Match Rule drop-down list. Retain the default settings of other parameters.
- In the Destination Service step, configure the following settings:
  - Select Label routing for Destination Service.
  - Select sc-a or sc-A from the Service drop-down list, and select base from the Version drop-down list.
  - Select Configure Fallback Service and select Version from the No Limits drop-down list. This way, the sc-A service is highly available.

Case 2: Expose an existing service

For imported services, you can perform the following steps to expose Application A:

On the Services page, find the service that you want to view and click Policies in the Actions column to view service information.
In normal cases, the service version that meets the following conditions does not exist: Version Name is base, Tag Name is opensergo.io/canary, and Tag Value is empty.
Redeploy the sc-A service.
In the Service Version section of the service details page, click Add Version, configure the parameters, and then click the icon in the Actions column to save the settings. Then, check whether the number of application instances that run the base version is greater than 0.
- Set Version Name to base.
- Set Tag Name to opensergo.io/canary.
- Leave Tag Value empty.
On the Route Settings page, modify an existing route and use the route to expose the sc-A service.
- In the Request Information step, select Prefix matching from the Match Rule drop-down list, and retain the default settings of other parameters.
- In the Destination Service step, configure the following settings:
  - Select Label routing for Destination Service.
  - Select sc-A from the Service drop-down list and select base from the Version drop-down list.
  - Select Configure Fallback Service and select Version from the No Limits drop-down list. This way, the sc-A service is highly available.

Step 3: Test the traffic of base versions

Log on to the MSE console. In the top navigation bar, select a region.
In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the gateway.
In the left-side navigation pane, click Overview.
On the Gateway Ingress tab, view the Ingress IP Address of the Server Load Balancer (SLB) instance.
Use a cURL command to test the traffic of base versions. The test result shows that the traffic passes through the base versions of Application A, Application B, and Application C. Sample code:
```
# Test command
curl x.x.1.1/a

# Test result
A[10.0.3.178][config=base] -> B[10.0.3.195] -> C[10.0.3.201]%
```
In the test result, the names of Application B and Application C are not followed by a version number. The test result indicates that traffic is passed through the base versions of the two applications.

2. Build a canary environment for business applications

In this example, new versions need to be released for Application A and Application C due to the release of new features. You need to use the end-to-end canary release feature to test the canary versions of Application A and Application C.

Step 1: Deploy canary versions of backend applications

Log on to the ACK console.
In the left-side navigation pane, click Clusters. Then, click the name of the cluster that you want to manage.
In the left-side navigation pane, choose Workloads > Deployments.
In the upper part of the page, select the namespace of the cluster, and click Create from YAML.

Use the following YAML code to deploy the canary versions of Application A and Application C.

Use an MSE Nacos instance as the service source

Note

Replace {nacos server address} in the code with the internal endpoint of the MSE Nacos instance and remove the curly braces {}.

Show YAML code

# YAML code for the canary version of Application A
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a-gray
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-a-gray
  template:
    metadata:
      labels:
        alicloud.service.tag: gray
        app: spring-cloud-a-gray
        msePilotCreateAppName: spring-cloud-a
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-a
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-a:1.0.0
        imagePullPolicy: Always
        ports:
          - containerPort: 20001
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 30
          periodSeconds: 60
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: {nacos server address}
        - name: dubbo.registry.address
          value: 'nacos://{nacos server address}:8848'
---
# YAML code for the canary version of Application C
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c-gray
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-c-gray
  template:
    metadata:
      labels:
        alicloud.service.tag: gray
        app: spring-cloud-c-gray
        msePilotCreateAppName: spring-cloud-c
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-c
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-c:1.0.0
        imagePullPolicy: Always
        ports:
          - containerPort: 20003
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 30
          periodSeconds: 60
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: {nacos server address}
        - name: dubbo.registry.address
          value: 'nacos://{nacos server address}:8848'

Use an ACK cluster as the service source

Show YAML code

# YAML code for the canary version of Application A
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a-gray
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-a
  template:
    metadata:
      labels:
        alicloud.service.tag: gray
        app: spring-cloud-a
        msePilotCreateAppName: spring-cloud-a
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-a
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-a:1.0.0
        imagePullPolicy: Always
        ports:
          - containerPort: 20001
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 30
          periodSeconds: 60
        # Access the self-managed Nacos instance by using the Nacos service.
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: nacos-server
        - name: dubbo.registry.address
          value: 'nacos://nacos-server:8848'

---
# YAML code for the canary version of Application C
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c-gray
  namespace: default
spec:
  selector:
    matchLabels:
      app: spring-cloud-c
  template:
    metadata:
      labels:
        alicloud.service.tag: gray
        app: spring-cloud-c
        msePilotCreateAppName: spring-cloud-c
        msePilotAutoEnable: 'on'
    spec:
      containers:
      - name: spring-cloud-c
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-c:1.0.0
        imagePullPolicy: Always
        ports:
          - containerPort: 20003
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 30
          periodSeconds: 60
        # Access the self-managed Nacos instance by using the Nacos service.
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: nacos-server
        - name: dubbo.registry.address
          value: 'nacos://nacos-server:8848'

Step 2: Create a lane group for the canary environment

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.
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
Name of Lane Group	Enter a name for the lane group.
Entry Type	Select MSE Cloud-native Gateway.
Lane Group Traffic Entry	Select the destination cloud-native gateway.
Lane Group Application	Select spring-cloud-a, spring-cloud-b, and spring-cloud-c.

创建泳道组.png

After the lane group is created, you can view the lane group in the Lane Group section of the Full link grayscale page. To modify the information about the lane group, click the icon.

Step 3: Create a lane for the canary environment

Note

If you use a cloud-native gateway as an ingress for end-to-end canary release, MSE supports two types of lane routing modes.
- Routing by request content: Set content matching conditions to route the requests that meet the conditions to the versions in the lane.
- Routing by percentage: Set a percentage value to route a percentage of requests to the versions in the lane. Requests initiated by the same client may be routed to versions in different lanes. This results in an inconsistent user experience.
The base routing mode or lane routing mode of a gateway must be the same in a lane group. You can adjust the base routing mode or lane routing mode of a gateway only when you create the first lane in the lane group.

In the lower part of the Full link grayscale page, click Click to create the first shunt Lane. If a lane is available in the microservice namespace that you select, click Create swim lanes.

In the Create swim lanes dialog box, configure the parameters and click OK.

Create a lane that uses routing by request content

Parameter

Description

Add Application

After the lane tag is selected, the lane name is automatically displayed and the applications that belong to the lane are added.

Routing rules

Configure the conditions of the routing rule.

Select base routes that are created on the gateway: Select the test route that is created in Step 1.
Lane Routing Mode: Select Routing by Request Content.
Conditional list: In the lower part of the Conditions section, click + Add Condition to add a condition.
Configuration details in this example:
- Parameter Type: Set this parameter to Header.
- Parameters: Set this parameter to canary.
- Condition: Set this parameter to Exact Match.
- Value: Set this parameter to gray.

Create a lane that uses routing by percentage

Note

To create a lane that uses routing by percentage, make sure that the ack-onepilot version is 3.0.18 or later and the agent version is 3.2.3 or later.

Parameter

Description

Add Application

After the lane tag is selected, the lane name is automatically displayed and the applications that belong to the lane are added.

Routing rules

Configure the conditions of the routing rule.

Select base routes that are created on the gateway: Select the test route that is created in Step 1.
Lane Routing Mode: Select Routing by Percentage.
Traffic Percentage: Enter 30%.

After the lane is created, you can view the details of the lane in the Flow distribution section of the Full link grayscale page. You can also perform the following operations:

Find the lane and click Enable in the Actions column to make the lane take effect. This way, traffic is routed based on the lane configuration. The traffic that meets the routing rule is preferentially routed to the application version whose tag corresponds to the lane. If the tagged application version does not exist, traffic is routed to the untagged application versions.
Find the lane and click Close in the Actions column to disable the created lane. Application traffic is then routed to the untagged application versions.
Click the icon to view the traffic percentage of the lane.
Click the icon to configure the status of the applications in the lane.

Step 4: Test the traffic of canary versions

Test the lane that uses routing by request content

Use a cURL command to test the canary traffic.

# Test command
curl -H "canary: gray" x.x.x.x/a

# Test result
Agray[10.0.3.177][config=base] -> B[10.0.3.195] -> Cgray[10.0.3.180]

In the test result, the traffic passes through the canary versions of Application A and Application C. Application B does not have the canary version, and therefore traffic is automatically routed to the base version of Application B.

Test the lane that uses routing by percentage

You can execute the following Python script to test the distribution of requests that are routed based on a percentage value. You must install the requests package and replace x.x.x.x with the IP address of the SLB instance that is associated with the cloud-native gateway.

Show the Python script

# pip3 install requests
# python3 traffic.py
import requests


TOTAL_REQUEST = 100
ENTRY_URL = 'http://x.x.x.x/a'

def parse_tag(text:str):
    '''
    A[10.0.23.64][config=base] -> B[10.0.23.65] -> C[10.0.23.61]
    Agray[10.0.23.64][config=base] -> B[10.0.23.65] -> Cgray[10.0.23.61]
    Ablue[10.0.23.64][config=base] -> B[10.0.23.65] -> Cblue[10.0.23.61]
    '''
    print(text)
    app_parts = text.split(' -> ')
    # tag_app: C[10.0.23.61] / Cgray[10.0.23.61]
    tag_app = app_parts[-1]
    
    splits = tag_app.split('[')
    
    # tag_part: C / Cgray
    tag_part = splits[0]
    tag = tag_part[1:]
    return tag if len(tag) > 0 else 'base'

def get_tag(url:str):
    resp = requests.get(url)
    resp.encoding = resp.apparent_encoding
    return parse_tag(resp.text)

def cal_tag_count(url:str, total_request:int):
    count_map = {}
    for i in range(total_request):
        tag = get_tag(url)
        if tag not in count_map:
            count_map[tag] = 1
        else:
            count_map[tag] += 1

    print()
    print('Total Request:', total_request)
    print('Traffic Distribution:', count_map)


if __name__ == '__main__':
    cal_tag_count(ENTRY_URL, TOTAL_REQUEST)

The result indicates that about 30% of requests are routed to the canary environment.

(Optional) 3. Implement observability

If an issue occurs in an application, you can use the observability capability provided in the MSE console to view the abnormal data. This helps you quickly locate the issue.

Observability of cloud-native gateways

On the Services page of the MSE cloud-native gateway, find the service and click Policies in the Actions column. In the Basic Metrics section of the page that appears, view the traffic metric data of each service version.

基础监控

QPS: the queries per second (QPS) of each version of the application.
Errors: the number of error requests of each version of the application.
RT(ms): the response time consumed for each version of the application.

Observability of Microservices Governance

On the Full link grayscale page of MSE Microservices Governance, click the destination application. In the QPS monitoring chart (total) section, you can view the traffic data of the base version and canary version of the relevant lane.

Total: the total QPS of the application.
Abnormal QPS: the number of error requests of the application.
gray: the QPS of the canary version of the application.