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.
For more information about the limits of the end-to-end canary release feature on Java applications, see Java frameworks supported by Microservices Governance.
To implement an end-to-end canary release, you must make sure that the version of your MSE cloud-native gateway is 2.0.2 or later. For more information about how to upgrade an MSE cloud-native gateway, see Upgrade an MSE cloud-native gateway.

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 simultaneously test the versions of multiple applications by using a canary release. 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, 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 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 must be deployed in the same virtual private cloud (VPC) as your ACK cluster or MSE Nacos instance.

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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1
        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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-b:3.0.1
        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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1
        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-hangzhou.aliyuncs.com/mse-governance-demo/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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1
        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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-b:3.0.1
        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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1
        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. In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the created cloud-native gateway. In the left-side navigation pane, click Routes. On the Routes page, click the Services tab. Then, click Add Service. For more information, see Add a service.
- 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.
On the Routes page, click the Routes tab. On the Routes tab, click Add Route to create a route for sc-a or sc-A and use the route to expose the service. For more information, see Create a route.
Parameter
Description
Path
Select Prefix from the matching condition drop-down list and enter /a in the path field.
Route Point
Select Single Service.
Backend Service
Select sc-A.

Case 2: Expose an existing service

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

Log on to the MSE console. In the left-side navigation pane, choose Cloud-native Gateway > Gateways. On the Gateways page, click the name of the created cloud-native gateway. On the Routes page, click the Routes tab. On the Routes tab, modify an existing route and use the route to expose the service.

Parameter	Description
Path	Select Prefix from the matching condition drop-down list and enter /a in the path field.
Route Point	Select Single Service.
Backend Service	Select sc-A.

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 value of the Ingress IP Address parameter of the Server Load Balancer (SLB) instance.
Use a cURL command to test the traffic of base versions. The test result shows that traffic passes through the base versions of Application A, Application B, and Application C. The following sample code provides an example of the configuration:
```
# 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 passes 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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1
        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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1
        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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1
        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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1
        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
Lane Group Name	Enter a name for the lane group.
Ingress Type	Select MSE Cloud-native Gateway.
Ingress Gateway	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 a lane group, click the icon.

Step 3: Create a lane for the canary environment

Note

When you use the end-to-end canary release feature, you need to add a tag to canary application nodes to distinguish the nodes from other nodes. In the container environment, you need to add alicloud.service.tag: ${tag} to spec.template.metadata.labels. In the Elastic Compute Service (ECS) environment, you need to add the Java startup parameter -Dalicloud.service.tag=${tag}.
MSE supports the following lane routing modes if you select MSE Cloud-native Gateway for Ingress Type when you create the related lane group.
- Routing by request content: If the request content can be used to identify canary nodes, we recommend that you use this lane routing mode. If the request content cannot be used to identify canary nodes, we also strongly recommend that you add such identifiers by using system modifications to achieve a better canary release effect. For example, you can use this mode to ensure that canary requests are passed through to the same environment.
- Routing by percentage: If the request content cannot be used to identify canary nodes and the legacy system cannot be modified, you can use this mode. However, if you use this mode, requests from the same source may be routed to the application nodes in different lanes. As a result, canary requests may be passed through to different environments.
The lane routing mode must be the same for lanes in a lane group. You can modify the lane routing mode only when you create the first lane in a 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 Node Tag	Manually add tags to your canary application nodes to distinguish these nodes from other nodes.
Enter lane information	Lane Tag: the tag of the requests that are sent to the application nodes in the lane. Confirm Matching Relationship: allows you to check whether the number of tagged application nodes is as expected.
Configure Routing and Canary Release Rules	Specify the rule for routing requests to application nodes in lanes. Gateway Base Routing: Select the base route test created in Step 1. The base route is a single-service route. Lane Routing Mode (Same in the Lane Group): 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.

Lane routing modes

Canary Release Condition	Effect
Meet All Conditions	Traffic that meets all conditions is routed to the relevant lane.
Meet Any Condition	Traffic that meets one of the following conditions is routed to the relevant lane.

Condition description

Condition	Description
==	The exact match. The condition is met if the traffic value and the condition value are exactly the same.
!=	The not equal match. The condition is met if the traffic value and the condition value are not the same.
in	The inclusive match. The condition is met if the traffic value is included in the specified list.
Percentage	The percentage match. Principle: The condition is met if 'hash(get(key)) % 100 < value'.
Regular expression match	The regular expression match. The condition is met if the traffic value is matched based on the specified regular expression rule.
Prefix match	The prefix match. The condition is met if the specified value is the prefix of the actual value.

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 Node Tag	Manually add tags to your canary application nodes to distinguish these nodes from other nodes.
Enter lane information	Lane Tag: the tag of the requests that are sent to the application nodes in the lane. Confirm Matching Relationship: allows you to check whether the number of tagged application nodes is as expected.
Configure Routing and Canary Release Rules	Specify the rule for routing requests to application nodes in lanes. Gateway Base Routing: Select the base route test created in Step 1. Lane Routing Mode (Same in the Lane Group): Select Routing by Percentage. Flow ratio: Enter 30. Unit: percentage (%).

Note

You can also configure different traffic percentages for each gateway base route. If you enable this feature, you must make sure that the sum of the traffic percentages of the gateway base route configured for all lane groups does not exceed 100%.

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 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 following 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 Routes page of the MSE cloud-native gateway, click the Services tab. On the Services tab, click the name of the service that you want to view. On the page that appears, view the traffic metric data of each service version in the Basic Metrics section.

基础监控

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 Data section, you can view the traffic data of the base version and canary version of the relevant lane.

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