All Products
Search

This Product

    Microservices Engine:Implement an end-to-end canary release based on self-managed Spring Cloud or Zuul gateways

    Document Center

    Microservices Engine:Implement an end-to-end canary release based on self-managed Spring Cloud or Zuul gateways

    Last Updated:Oct 17, 2024

    Spring Cloud and Zuul gateways are two types of API gateways that are commonly used in the microservices architecture. The gateways can implement features such as route forwarding and filter processing. You can configure routing rules to route requests to a canary version to verify and test the canary version. Microservices Engine (MSE) provides the end-to-end canary release capability that allows you to implement end-to-end traffic throttling without the need to modify your business code. This topic describes how to implement an end-to-end canary release based on Spring Cloud or Zuul gateways.

    Prerequisites

    Background information

    This topic uses a simulated call process to describe how to implement an end-to-end canary release for microservice applications by using MSE. To implement an end-to-end canary release, you need only to configure canary traffic rules for an ingress application without application code modifications. This way, traffic that meets the specified traffic rules is directly passed through to the canary versions based on version tags. When an application is being called, traffic that meets canary traffic rules is preferentially routed to the canary version of the application. If an application has no canary version, traffic is routed to the base version or the stable version of the application.

    In this example, the following business applications are deployed: spring-cloud-gateway, spring-cloud-a, spring-cloud-b, and spring-cloud-c. The nacos-server application is deployed as a registry. Business applications are called in the following order: spring-cloud-gateway -> spring-cloud-a -> spring-cloud-b -> spring-cloud-c.

    Application calls include Spring Cloud service calls and Dubbo service calls.

    image

    The end-to-end canary release feature provides traffic tagging. The tagged canary traffic is preferentially sent to canary nodes. This helps you perform a canary release in a controllable way and ensures stability.

    The following policies are generally used for an end-to-end canary release:

    • A small percentage of online traffic is tagged and sent to canary nodes.

    • Online traffic is filtered based on specific rules. For example, online traffic of requests with specified headers or cookies is sent to canary nodes.

    This topic describes how to configure the preceding policies to meet different canary release requirements of the microservices architecture.

    Step 1: Enable Microservices Governance for applications

    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.

    Enable Microservices Governance for applications in an ACK namespace

    1. Log on to the MSE console, and select a region in the top navigation bar.

    2. In the left-side navigation pane, choose Microservices Governance > Application Governance.

    3. On the Application list page, click ACK Application Access.

    4. In the ACK Application Access dialog box, configure the parameters and click OK.

      image

      Parameter

      Description

      Cluster type

      Select ACK Cluster, ACK Serverless Cluster, or ACS Cluster.

      Note

      If you do not grant the ACK cluster or ACK Serverless cluster permissions to call MSE, you need to click please authorize to perform authorization.

      Cluster Name/ID

      Select the Cluster Name/ID for which Microservices Governance is enabled. You can use keywords to search for cluster names or IDs.

      ack-onepilot

      View the status of the ack-onepilot component.

      • If the ack-onepilot component is not installed, click Click Install on the right of ack-onepilot. After the installation is complete, the status of the ack-onepilot component is displayed as Installed.

      • If you perform the operation as a RAM user and a message is displayed, indicating that you have no permissions to perform the operation, you can log on to the ACK console to access the desired cluster, and choose Operations > Add-ons. Then, find ack-onepilot and click Install.

      Note

      • In this step, the ack-onepilot component is involved. You can log on to the ACK console to access the destination cluster, and choose Operations > Add-ons to view the component details.

      • After the ack-onepilot component is installed, the agent is automatically injected. In this case, the startup time of the application may be increased by up to 10s.

      Access Type

      Select Namespace Access.

      ACK Cluster Namespace

      Select an ACK Cluster Namespace.

      Microservices Governance Namespace

      Select the Microservices Governance Namespace. Then, redeploy existing applications or create applications in the associated microservice namespace. This way, Microservices Governance is enabled for the applications.

    Enable Microservices Governance for an application

    1. Log on to the MSE console, and select a region in the top navigation bar.

    2. In the left-side navigation pane, choose Microservices Governance > Application Governance.

    3. On the Application list page, click ACK Application Access.

    4. In the ACK Application Access dialog box, configure the parameters and click OK.

      image

      Parameter

      Description

      Cluster type

      Select ACK Cluster, ACK Serverless Cluster, or ACS Cluster.

      Note

      If you do not grant the ACK cluster or ACK Serverless cluster permissions to call MSE, you need to click please authorize to perform authorization.

      Cluster Name/ID

      Select the Cluster Name/ID for which Microservices Governance is enabled. You can use keywords to search for cluster names or IDs.

      ack-onepilot

      Displays the status of the ack-onepilot component.

      • If the ack-onepilot component is not installed, click Click Install on the right of ack-onepilot. After the installation is complete, the status of the ack-onepilot component is displayed as Installed.

      • If you perform the operation as a RAM user and a message is displayed, indicating that you have no permissions to perform the operation, you can log on to the ACK console to access the desired cluster, and choose Operations > Add-ons. Then, find ack-onepilot and click Install.

      Note

      • In this step, the ack-onepilot component is involved. You can log on to the ACK console to access the destination cluster, and choose Operations > Add-ons to view the component details.

      • After the ack-onepilot component is installed, the agent is automatically injected. In this case, the startup time of the application may be increased by up to 10s.

      Access Type

      Select Single Application Access.

      Access Procedure

      Perform the following steps:

      Step 1: Go to the ACK console, and click the cluster name. In the left-side navigation pane of the page that appears, choose Workloads > Deployments. Then, select the namespace to which the application belongs.

      Step 2: Click the name of the connected application. On the page that appears, click View in YAML.

      Step 3: Edit the labels field in the following format and click Update. 

      spec:
  template:
    metadata:
      labels:
        # The on value indicates that Microservices Governance is enabled. The on value must be enclosed in double quotation marks (").
        msePilotAutoEnable: "on"
        # The MSE microservice namespace where your application resides. If the namespace that you specify does not exist, a namespace with the specified name is automatically created.
        mseNamespace: 202401
        # The actual name of the application for which Microservices Governance is enabled. The name must be enclosed in double quotation marks (").
        msePilotCreateAppName: "your-deployment-name"

    Step 2: Deploy the applications for simulation

    1. Log on to the ACK console. In the left-side navigation pane, click Clusters.

    2. On the Clusters page, find the cluster that you want to manage and click its name. In the left-side pane, choose Workloads > Deployments.

    3. On the Deployments page, select a namespace, and click Create from YAML.

      In this example, the nacos-server application is deployed as a registry, and spring-cloud-gateway, spring-cloud-a, spring-cloud-b, and spring-cloud-c are deployed as business applications. You can obtain the source code of this demo from alibabacloud-microservice-demo.

      • Yet Another Markup Language (YAML) code for the nacos-server application

        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

      • YAML code for the spring-cloud-c application

        Show YAML code

        # Source: mse-simple-demo/templates/spring-cloud-c-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c
spec:
  replicas: 1
  selector:
    matchLabels:
      app: spring-cloud-c
  template:
    metadata:
      labels:
        msePilotAutoEnable: "on"
        msePilotCreateAppName: "spring-cloud-c"
        app: "spring-cloud-c"
    spec:
      containers:
        - name: spring-cloud-c
          image: "registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1"
          imagePullPolicy: Always
          env:
            - name: nacos.host
              value: "nacos-server"
            - name: nacos.namespace
              value: "public"
          resources:
            requests:
              cpu: 1
              memory: 2Gi
            limits:
              cpu: 1
              memory: 2Gi
          ports:
          - name: http-port
            containerPort: 20003
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - podAffinityTerm:
                topologyKey: failure-domain.beta.kubernetes.io/zone
              weight: 50
            - podAffinityTerm:
                topologyKey: kubernetes.io/hostname
              weight: 100

      • YAML code for the spring-cloud-b application

        Show YAML code

        # Source: mse-simple-demo/templates/spring-cloud-b-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-b
spec:
  replicas: 1
  selector:
    matchLabels:
      app: spring-cloud-b
  template:
    metadata:
      labels:
        msePilotAutoEnable: "on"
        msePilotCreateAppName: "spring-cloud-b"
        app: "spring-cloud-b"
    spec:
      containers:
        - name: spring-cloud-b
          image: "registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-b:3.0.1"
          imagePullPolicy: Always
          env:
            - name: nacos.host
              value: "nacos-server"
            - name: nacos.namespace
              value: "public"
          resources:
            requests:
              cpu: 1
              memory: 2Gi
            limits:
              cpu: 1
              memory: 2Gi
          ports:
            - name: http-port
              containerPort: 20002
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - podAffinityTerm:
                topologyKey: failure-domain.beta.kubernetes.io/zone
              weight: 50
            - podAffinityTerm:
                topologyKey: kubernetes.io/hostname
              weight: 100

      • YAML code for the spring-cloud-a application

        Show YAML code

        # Source: mse-simple-demo/templates/spring-cloud-a-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a
spec:
  replicas: 1
  selector:
    matchLabels:
      app: spring-cloud-a
  template:
    metadata:
      labels:
        msePilotAutoEnable: "on"
        msePilotCreateAppName: "spring-cloud-a"
        app: "spring-cloud-a"
    spec:
      containers:
        - name: spring-cloud-a
          image: "registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1"
          imagePullPolicy: Always
          env:
            - name: nacos.host
              value: "nacos-server"
            - name: nacos.namespace
              value: "public"
          resources:
            requests:
              cpu: 1
              memory: 2Gi
            limits:
              cpu: 1
              memory: 2Gi
          ports:
            - name: http-port
              containerPort: 20001
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - podAffinityTerm:
                topologyKey: failure-domain.beta.kubernetes.io/zone
              weight: 50
            - podAffinityTerm:
                topologyKey: kubernetes.io/hostname
              weight: 100

      • YAML code for the spring-cloud-gateway application

        Show YAML code

        # Source: mse-simple-demo/templates/spring-cloud-gateway-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-gateway
spec:
  replicas: 1
  selector:
    matchLabels:
      app: spring-cloud-gateway
  template:
    metadata:
      labels:
        msePilotAutoEnable: "on"
        msePilotCreateAppName: "spring-cloud-gateway"
        app: spring-cloud-gateway
    spec:
      containers:
        - image: "registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-gateway:3.0.1"
          imagePullPolicy: Always
          env:
            - name: nacos.host
              value: "nacos-server"
            - name: nacos.namespace
              value: "public"
            - name: enable.auto
              value: "true"
            - name: enable.rpc.invoke
              value: "true"
            - name: enable.sql
              value: "false"
            - name: enable.sentinel.demo.flow
              value: "true"
          name: "spring-cloud-gateway"
          resources:
            requests:
              cpu: 1
              memory: 2Gi
            limits:
              cpu: 1
              memory: 2Gi
          ports:
            - containerPort: 20000
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - podAffinityTerm:
                topologyKey: failure-domain.beta.kubernetes.io/zone
              weight: 50
            - podAffinityTerm:
                topologyKey: kubernetes.io/hostname
              weight: 100
---
# Source: mse-simple-demo/templates/spring-cloud-gateway-service.yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: slb.s1.small
    service.beta.kubernetes.io/alicloud-loadbalancer-address-type: internet
  name: spring-cloud-gateway-slb
spec:
  ports:
    - port: 80
      protocol: TCP
      targetPort: 20000
  selector:
    app: spring-cloud-gateway
  type: LoadBalancer

      Run the following command to query the deployment result:

      kubectl get svc,deploy

      Expected output:

      NAME                               TYPE           CLUSTER-IP   EXTERNAL-IP  PORT(S)             AGE
service/kubernetes                 ClusterIP      172.16.x.x   <none>       443/TCP             23h
service/nacos-server               ClusterIP      172.16.x.x   <none>       8848/TCP,9848/TCP   94s
service/spring-cloud-gateway-slb   LoadBalancer   172.16.x.x   8.130.x.x    80:32641/TCP        57s

NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nacos-server           1/1     1            1           94s
deployment.apps/spring-cloud-a         1/1     1            1           66s
deployment.apps/spring-cloud-b         1/1     1            1           74s
deployment.apps/spring-cloud-c         1/1     1            1           83s
deployment.apps/spring-cloud-gateway   1/1     1            1           57s

    Step 3: Deploy canary versions for spring-cloud-c and spring-cloud-a

    1. Log on to the ACK console. Use the following YAML code to deploy the canary version of the spring-cloud-c application.

      Show YAML code

      # Source: mse-simple-demo/templates/spring-cloud-c-gray-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-c-gray
spec:
  replicas: 1
  selector:
    matchLabels:
      app: spring-cloud-c-gray
      version: gray
  template:
    metadata:
      labels:
        msePilotAutoEnable: "on"
        msePilotCreateAppName: "spring-cloud-c"
        alicloud.service.tag: gray
        app: "spring-cloud-c-gray"
        version: gray
    spec:
      containers:
        - name: spring-cloud-c
          image: "registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1"
          imagePullPolicy: Always
          env:
            - name: nacos.host
              value: "nacos-server"
            - name: nacos.namespace
              value: "public"
          resources:
            requests:
              cpu: 1
              memory: 2Gi
            limits:
              cpu: 1
              memory: 2Gi
          ports:
            - name: http-port
              containerPort: 20002
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - podAffinityTerm:
                topologyKey: failure-domain.beta.kubernetes.io/zone
              weight: 50
            - podAffinityTerm:
                topologyKey: kubernetes.io/hostname
              weight: 100

    2. Use the following YAML code to deploy the canary version of the spring-cloud-a application.

      Show YAML code

      # Source: mse-simple-demo/templates/spring-cloud-a-gray-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-cloud-a-gray
spec:
  replicas: 1
  selector:
    matchLabels:
      app: spring-cloud-a-gray
      version: gray
  template:
    metadata:
      labels:
        msePilotAutoEnable: "on"
        msePilotCreateAppName: "spring-cloud-a"
        alicloud.service.tag: gray
        app: "spring-cloud-a-gray"
        version: gray
    spec:
      containers:
        - name: spring-cloud-a
          image: "registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1"
          imagePullPolicy: Always
          env:
            - name: nacos.host
              value: "nacos-server"
            - name: nacos.namespace
              value: "public"
          resources:
            requests:
              cpu: 1
              memory: 2Gi
            limits:
              cpu: 1
              memory: 2Gi
          ports:
            - name: http-port
              containerPort: 20001
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - podAffinityTerm:
                topologyKey: failure-domain.beta.kubernetes.io/zone
              weight: 50
            - podAffinityTerm:
                topologyKey: kubernetes.io/hostname
              weight: 100

    Step 4: Create a lane group for the canary environment

    1. Log on to the MSE console, and select a region in the top navigation bar.

    2. In the left-side navigation pane, choose Microservices Governance > Full link grayscale.

    3. Click Create Lane Group and Lane. If a lane group is available in the microservice space that you select, click + Create Lane Group.

    4. On the Full link grayscale page, 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 Java Microservice Gateway.

      Lane Group Traffic Entry

      Select spring-cloud-gateway.

      Lane Group Application

      Select spring-cloud-a, spring-cloud-b, and spring-cloud-c.

      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 and edit the information.

    Step 5: 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}.

    • If you select Java Microservice Gateway for Ingress Type, MSE supports the following lane routing modes:

      • 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 Path and Lane Routing Mode parameters only when you create the first lane in a lane group.

    1. In the lower part of the Full link grayscale page, click Click to Create First Split Lane. If a lane is available in the microservice space that you select, click Create Lane.

    2. In the Create Lane panel configure the parameters and click OK.

    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.

    • Path: If you leave this parameter empty, all paths are matched.

    • Canary Release Mode: Select Canary Release by Ratio.

    • Flow ratio: Enter 30. Unit: percentage (%).

    Note

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

    Routing by request content

    Parameter

    Description

    Add Node Tag

    Add a tag for canary application nodes to distinguish the nodes from other nodes.

    Enter lane information

    Lane Tag: the tag of the requests that are sent to the application nodes in the lane. In this example, gray is used as the lane tag.

    Confirm Matching Relationship: allows you to check whether the number of tagged application nodes is as expected.

    Configure Routing and Canary Release Rules

    Configure the conditions of the routing rule.

    • Enter a value for the Path parameter. If you do not configure this parameter, all paths are matched.

    • Canary Release Mode: Select Canary Release by Content.

    • Canary Release Condition: Add a rule condition. Select Meet All Conditions.

      In this example, Parameter Type is set to name, and Value is set to xiaoming. Sample configurations:

      • Parameter Type: Select Parameter.

      • Parameter: Enter name.

      • Condition: Select ==.

      • Value: Enter xiaoming.

    Routing by percentage
    Important

    Make sure that the version of the MSE Java agent is 3.2.3 or later. Otherwise, the percentage-based canary release capability is adversely affected.

    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. In this example, gray is used as the lane tag.

    Confirm Matching Relationship: allows you to check whether the number of tagged application nodes is as expected.

    Configure Routing and Canary Release Rules

    Configure the conditions of the routing rule.

    • Path: If you leave this parameter empty, all paths are matched.

    • Canary Release Mode: Select Canary Release by Ratio.

    • Flow ratio: Enter 30%.

    After the lane is created, you can view the details of the lane in the Traffic 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 Disable 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 6: Test traffic routing

    Routing by request content

    1. Run the following curl command to test the traffic routed to the base versions:

      curl 8.130.x.x/A/a
A[192.168.x.x][config=base] -> B[192.168.x.x] -> C[192.168.x.x]
      Note

      In the preceding command, 8.130.x.x is the public IP address that is exposed by the spring-cloud-gateway application.

    2. Run the following curl command to test the traffic routed to the canary versions:

      curl 8.130.x.x/A/a?name=xiaoming
Agray[192.168.x.x][config=base] -> B[192.168.x.x] -> Cgray[192.168.x.x]
      Note

      • If name=xiaoming is carried in a request, the request is passed through to the canary versions.

      • For example, if a request with a canary tag is sent to spring-cloud-a and spring-cloud-c, the request is routed to the canary nodes of the two applications.

      • If the request is sent to spring-cloud-b, the request is still sent to the base node of the application because no canary node is available for this application.

    Routing by percentage

    Use the following Python3 script to test the percentage of traffic that is routed to the canary versions. You must install the requests package before you perform tests. Replace x.x.x.x with the IP address of the ingress Server Load Balancer (SLB) instance that is associated with spring-cloud-gateway. 

    # pip3 install requests
# python3 traffic.py
import requests

TOTAL_REQUEST = 100
ENTRY_URL = 'http://x.x.x.x/A/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 approximately 30% of the traffic is routed to the canary environment.

    image.png

    Step 7: 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.

    Implement observability of Microservices Governance

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

    image

    • Total QPS: the total QPS of the application.

    • Exception QPS: the number of error requests of the application.

    • GrayQPS: the QPS of the canary version of the application.

    References