Cloud-native Gateway of Microservices Engine (MSE) is a managed service that works as an ingress and provides enormous traffic management capabilities. Cloud-native Gateway supports a variety of service discovery methods by using tools such as Container Service for Kubernetes (ACK), Nacos, Elastic Compute Service (ECS), and Domain Name System (DNS) and delivers a unified solution to support service versions and implement canary release. This topic describes how to implement different service release strategies by using two service discovery mechanisms: ACK and Nacos.

Prerequisites

ACK

In this example, the native service discovery method of ACK is used. This method registers the backend service with CoreDNS by using declarative service APIs. The backend service provides an API operation used to query the current version. The request path is /version and the current version is v1. Cloud-native Gateway is integrated with ACK so that it can obtain service information from ACK clusters in real time. This makes it easier for Cloud-native Gateway to expose the backend service to external users.

Figure 1. Business architecture
Business architecture based on the ACK service discovery method

Application deployment

  1. In the ACK console, deploy the following applications. The current application version is v1.

    For more information about how to deploy an application, see Create a stateless application by using a Deployment. 

    apiVersion: v1
kind: Service
metadata:
  name: httpbin
spec:
  ports:
  - port: 8080
    protocol: TCP
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      containers:
      - image: specialyang/spring-cloud-httpbin-k8s:v1
        imagePullPolicy: Always
        name: spring-cloud-httpbin-k8s
        ports:
        - containerPort: 8080
  2. In the MSE console, choose Cloud-native Gateway > Gateways in the left-side navigation pane. Find the gateway that you want to manage. On the gateway details page, choose Services > Sources in the left-side navigation pane and add an ACK Container service source.
  3. In the MSE console, choose Cloud-native Gateway > Gateways in the left-side navigation pane. Find the gateway that you want to manage. On the gateway details page, choose Services > Services in the left-side navigation pane and import the httpbin service that you want to expose to Cloud-native Gateway.

    For more information about how to add a service to a cloud-native gateway, see Add a service.

  4. Add the v1 version to the httpbin service.

    For more information about how to add a service version to a cloud-native gateway, see Manage service versions.

    Note You must filter v1 nodes based on the tag for v1. Currently, only v1 is deployed. Therefore, v1 nodes take up 100% of instance nodes.
  5. On the Routes page, create a route for the service to expose the service to external users. The route of the API operation used to expose the httpbin service is /version. The request is forwarded to the v1 version of the httpbin service.

    For more information about how to configure a route for a cloud-native gateway, see Create a routing rule.

  6. Run the following command to send a test request:
    for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done
    Command output:
    version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1

Blue-green deployment

In a blue-green deployment, the new version of a service must take up the same amount of resources as the current version. After a blue-green deployment is complete, the traffic is switched over to the new version.

Figure 2. Blue-green deployment based on the ACK service discovery method
Blue-green deployment based on the ACK service discovery method
  1. Deploy the v2 version for the httpbin service by using declarative API resources of ACK. The number of replicas is three. 
    apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin-v2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: httpbin
      version: v2
  template:
    metadata:
      labels:
        app: httpbin
        version: v2
    spec:
      containers:
      - image: specialyang/spring-cloud-httpbin-k8s:v2
        imagePullPolicy: Always
        name: spring-cloud-httpbin-k8s
        ports:
        - containerPort: 8080
  2. Add the v2 version to the httpbin service.

    For more information about how to add a service version to a cloud-native gateway, see Manage service versions.

    Note You must filter v2 nodes based on the tag for v2. Currently, the number of v1 nodes is the same as the number of v2 nodes in an instance. Therefore, v1 and v2 nodes each take up 50% of instance nodes.
  3. To switch traffic from v1 to v2 in a blue-green deployment, you need only to modify the service in the created route.

    For more information about how to modify a route for a cloud-native gateway, see Modify a routing rule.

  4. Run the following command to send a test request:
    for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done
    Command output:
    version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2

Traffic that accesses API resources by using the /version request path has been switched from v1 to v2.

A/B testing

A/B testing routes traffic to the new version of a service based on the metadata of a user request. In other words, A/B testing dynamically routes traffic based on request content. In this example, the new version can be accessed only by requests whose User-Agent value is Android, and other requests are sent to the original version.

Figure 3. A/B testing based on the ACK service discovery method
A/B testing based on the ACK service discovery method
  1. Create two routes to v1 and v2 of the httpbin service.
    • Requests that match the /version path are routed to the v1 version.
    • Requests that match the /version path and contain Android in the User-Agent header are routed to the v2 version.
    Note The version-v2 route must be added with a request header that is used for matching.
  2. Run the following command to send a test request that does not contain Android in the User-Agent header:
    curl ${GATEWAY_EXTERNAL_IP}/version
    Command output:
    version: v1
  3. Run the following command to send a test request that contains Android in the User-Agent header:
    curl -H "User-Agent: Mozilla/5.0 (Linux; Android 4.0.3)" ${GATEWAY_EXTERNAL_IP}/version
    Command output:
    version: v2

Requests are distributed to different service versions based on operating systems from which the requests are sent.

Canary release

Canary release allows a small amount of traffic to be routed to the new version of a service. After the new version is verified, more traffic is gradually routed to the new version until eventually all traffic is routed to the new version. In the process, the new version is scaled up and the original version is scaled down to achieve maximum resource utilization.

Figure 4. Canary release based on the ACK service discovery method
Canary release based on the ACK service discovery method
  1. In a canary release, the number of replicas in the new version does not need to be consistent with that in the original version. The only requirement is that resources in the new version must be sufficient to handle canary traffic to the version. In this case, the number of replicas in the new version is set to 1. You can view node distribution of versions in the Service Version section of the Services page.
  2. Create a route to forward traffic to the new and original versions of the service based on node weights.

    In the process, you must configure the v1 and v2 versions for the httpbin service and specify the weights based on which traffic is routed.

  3. Run the following command to send a test request:
    for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done
    Command output:
    version: v1
version: v1
version: v1
version: v1
version: v1
version: v2
version: v1
version: v2
version: v1
version: v1

Two out of ten requests access the v2 version. This traffic distribution ratio is the expected ratio.

Note In actual business scenarios, you can increase the traffic weights for the new version after the version is verified. When you increase the traffic weights, you must scale up the new version and scale down the original version.

Nacos

In this example, the backend service provides an API operation used to query the current version. The request path is /version and the current version is v1. Cloud-native Gateway is integrated with MSE Nacos to obtain service information from MSE Nacos instances in real time. This makes it easier for Cloud-native Gateway to expose the backend service to external users.

Figure 5. Business architecture
Business architecture based on the Nacos service discovery method

Application deployment

  1. In the ACK console, deploy the following applications and connect the applications to Nacos. The current application version is v1.

    For more information about how to deploy an application, see Create a stateless application by using a Deployment.

    Note
    • The ${NACOS_SERVER_ADDRESS} variable in the YAML file must be replaced with the address of your MSE Nacos instance. If your MSE Nacos instance shares the same VPC as the gateway, the internal domain name of the instance can be used. Otherwise, a public domain name is needed.
    • In ACK, label data in pods can be considered as node metadata. In Nacos, node metadata is determined by the data used when a service is registered. In the Spring Cloud framework, you can use the spring.cloud.nacos.discovery.metadata.xxx environment variable to add metadata for a node. In this example, the version types are used to distinguish nodes that have different versions. In this case, set spring.cloud.nacos.discovery.metadata.version to v1 for applications. 
    apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: httpbin
  template:
    metadata:
      labels:
        app: httpbin
    spec:
      containers:
      - image: specialyang/spring-cloud-httpbin-nacos:v1
        imagePullPolicy: Always
        name: spring-cloud-httpbin-nacos
        ports:
        - containerPort: 8080
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: ${NACOS_SERVER_ADDRESS} 
        - name: spring.cloud.nacos.discovery.metadata.version
          value: v1
  2. In the MSE console, choose Cloud-native Gateway > Gateways in the left-side navigation pane. Find the gateway that you want to manage. On the gateway details page, choose Services > Sources in the left-side navigation pane and add an MSE Nacos service source.
  3. In the MSE console, choose Cloud-native Gateway > Gateways in the left-side navigation pane. Find the gateway that you want to manage. On the gateway details page, choose Services > Services in the left-side navigation pane, import the httpbin service that you want to expose to Cloud-native Gateway, and then select MSE Nacos as the service source.

    For more information about how to add a service to a cloud-native gateway, see Add a service.

  4. Add the v1 version to the httpbin service.
    Note You must filter v1 nodes based on the tag for v1. Currently, only v1 is deployed. Therefore, v1 nodes take up 100% of instance nodes.
  5. On the Routes page, create a route for the service to expose the service to external users. The route of the API operation used to expose the httpbin service is /version. The request is forwarded to the v1 version of the httpbin service.

    For more information about how to configure a route for a cloud-native gateway, see Create a routing rule.

  6. Run the following command to send a test request:
    for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done
    Command output:
    version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1

Blue-green deployment

In a blue-green deployment, the new version of a service must take up the same amount of resources as the current version. After a blue-green deployment is complete, the traffic is switched over to the new version.

Figure 6. Blue-green deployment based on the Nacos service discovery method
1
  1. Deploy the v2 version for the httpbin service.
    Note The procedure for registering an application with Nacos is the same as that for registering the service with ACK. Set the spring.cloud.nacos.discovery.metadata.version environment variable to v2 for applications. When an application starts, the application is automatically registered with Nacos and carries custom metadata. Cloud-native Gateway can use the metadata to distinguish nodes of different versions. 
    apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin-v2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: httpbin
  template:
    metadata:
      labels:
        app: httpbin
    spec:
      containers:
      - image: specialyang/spring-cloud-httpbin-nacos:v2
        imagePullPolicy: Always
        name: spring-cloud-httpbin-nacos
        ports:
        - containerPort: 8080
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: ${NACOS_SERVER_ADDRESS}
        - name: spring.cloud.nacos.discovery.metadata.version
          value: v2
  2. Add the v2 version to the httpbin service.

    For more information about how to add a service version to a cloud-native gateway, see Manage service versions.

    Note You must filter v2 nodes based on the tag for v2. Currently, the number of v1 nodes is the same as the number of v2 nodes in an instance. Therefore, v1 and v2 nodes each take up 50% of instance nodes.
  3. To switch traffic from v1 to v2 in a blue-green deployment, you need only to modify the service in the created route.

    For more information about how to modify a route for a cloud-native gateway, see Modify a routing rule.

  4. Run the following command to send a test request:
    for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done
    Command output:
    version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2

Traffic that accesses API resources by using the /version request path has been switched from v1 to v2.

A/B testing

A/B testing routes traffic to the new version of a service based on the metadata of a user request. In other words, A/B testing dynamically routes traffic based on request content. In this example, the new version can be accessed only by requests whose User-Agent value is Android, and other requests are sent to the original version.

Figure 7. A/B testing based on the Nacos service discovery method
2
  1. Create two routes to v1 and v2 of the httpbin service.
    • Requests that match the /version path are routed to the v1 version.
    • Requests that match the /version path and contain Android in the User-Agent header are routed to the v2 version.
    Note The version-v2 route must be added with a request header that is used for matching.
  2. Run the following command to send a test request that does not contain Android in the User-Agent header:
    curl ${GATEWAY_EXTERNAL_IP}/version
    Command output:
    version: v1
  3. Run the following command to send a test request that contains Android in the User-Agent header:
    curl -H "User-Agent: Mozilla/5.0 (Linux; Android 4.0.3)" ${GATEWAY_EXTERNAL_IP}/version
    Command output:
    version: v2

Requests are distributed to different service versions based on operating systems from which the requests are sent.

Canary release

Canary release allows a small amount of traffic to be routed to the new version of a service. After the new version is verified, more traffic is gradually routed to the new version until eventually all traffic is routed to the new version. In the process, the new version is scaled up and the original version is scaled down to achieve maximum resource utilization.

Figure 8. Canary release based on the Nacos service discovery method
3
  1. In a canary release, the number of replicas in the new version does not need to be consistent with that in the original version. The only requirement is that resources in the new version must be sufficient to handle canary traffic to the version. In this case, the number of replicas in the new version is set to 1. You can view node distribution of versions in the Service Version section of the Services page.
  2. Create a route to forward traffic to the new and original versions of the service based on node weights.

    In the process, you must configure the v1 and v2 versions for the httpbin service and specify the weights based on which traffic is routed.

  3. Run the following command to send a test request:
    for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done
    Command output:
    version: v1
version: v1
version: v1
version: v1
version: v1
version: v2
version: v1
version: v2
version: v1
version: v1

Two out of ten requests access the v2 version. This traffic distribution ratio is the expected ratio.

Note In actual business scenarios, you can increase the traffic weights for the new version after the version is verified. When you increase the traffic weights, you must scale up the new version and scale down the original version.