Microservices Engine:Routing modes

Single-service routing

The cloud-native gateway forwards requests to a backend service based on routing rules. For more information about how to configure services for the cloud-native gateway, see Add a service.

The gateway matches requests based on routing rules that you configured. For example:

• The gateway forwards all requests that match the /user routing rule to the user service.

• The gateway forwards all requests that match the /order routing rule to the order service.

Percentage-based routing

The cloud-native gateway forwards requests to multiple backend services. Traffic is distributed to the backend services based on the weight that you configured for each service. You can use multi-service routing in the following scenarios:

• Registry change

  As your business grows, new technology is continually integrated and you may need to perform registry changes. To ensure business continuity when you perform a registry change, a replica of the service is deployed. The replica uses the new registry. The original service and the original registry are retained. Traffic is gradually diverted from the original service to the new service. After you have verified the stability of the new service, the gateway can forward all incoming traffic to the new service. The service migration process supports rollback. You can roll back traffic to the original service if the new service does not meet your requirements.

  The following figure shows an example of changing the service registry. In this example, the user service in the application system switches from Nacos to the built-in CoreDNS for Kubernetes. You must use CoreDNS together with the service resources.

  

• O&M system change

  Traditionally, most services are deployed on virtual machines such as Alibaba Cloud Elastic Compute Service (ECS) instances. In recent years, Kubernetes has emerged as an alternative deployment solution that features simplified O&M and high elasticity. More and more enterprises are migrating their services to Kubernetes-based management platforms, such as Alibaba Cloud Container Service for Kubernetes (ACK). To ensure seamless service migration, a replica of the service can be deployed on a Kubernetes cluster and registered with a new name in the registry. In this case, two services with identical features exist in the registry: one deployed and running on an ECS instance, and the other on a Kubernetes cluster. Traffic is diverted from the service on the ECS instance to the service on the Kubernetes cluster. During the migration, you can adjust the percentage of diverted traffic and even roll back all traffic to the service on the ECS instance.

  The following figure shows an example of changing the O&M system. In the application system with Nacos as the registry, the user service is migrated from the ECS instance to the ACK platform.

  

Tag-based routing

The cloud-native gateway forwards requests to different versions of the same or different services. Traffic is distributed based on the weight that you configured for each service version. For more information about how to configure service versions for a cloud-native gateway, see Manage service versions. You can use tag-based routing in the following scenarios:

• Canary release

  New versions of a service are released frequently across the development lifecycle. You can use the canary release policy to roll out service upgrades while ensuring service stability and continuity. In a canary release, a small amount of traffic is first diverted to the service of the new version for verification. If the result meets expectations, the remaining traffic is then gradually migrated to the new-version service.

  For example, service discovery is performed on the user service deployed on the ACK cluster in the following application system. The service currently runs the v1 version, and the new version v2 is planned to be released and launched. You can perform a canary release based on one of the following items:

  • Percentages

    Tag-based routing is used to forward /user requests to the user service v1. You can add the user service v2 on the service management page in the Microservices Engine (MSE) console, and then add the user service v2 to destination services for tag-based routing. You can configure a weight to determine the percentage of traffic forwarded to the user service v2.

    

  • Tags

    Tag-based routing is used to forward /user requests to the user service v1. You can add a /user route and configure a tag indicating that this route is used for a canary release. For example, the tag can be the stage header with the gray value. The route is used to forward requests with such headers to the user service v2.

    

• Tag-based routing

  In a production environment, multiple versions of a service may exist in parallel for an extended period of time, and the service features and applicable requests vary with versions. For example, when the same API operation is called, requests with different header values are forwarded to different versions of the service. Tag-based routing is also used in the scenario where multiple development environments (test, staging, and production) coexist. Tags are used to distinguish requests intended for services in different environments.

  For example, in the following application system, service discovery is performed on three versions of the user service deployed on the ACK cluster. The service versions correspond to the test, staging, and production environments, respectively. For /user requests:

  • If the value of the stage header is test, traffic is forwarded to the user service in the test environment.

  • If the value of the stage header is pre, traffic is forwarded to the user service in the staging environment.

  • If the value of the stage header is online, traffic is forwarded to the user service in the production environment.

  

• High-availability deployment

  To ensure service availability, identical services may be deployed on multiple Kubernetes clusters. You can manage all service instances by cluster based on the cluster metadata on the nodes. You can also adjust the weightage to distribute traffic to clusters. When a cluster fails, you can set the traffic distribution weight to 0 for the cluster, and all traffic is then forwarded to other clusters.

  For example, in the following application system, service discovery is performed on the user service deployed on ACK clusters A and B. For the /user requests, 80% traffic is forwarded to the user service deployed on cluster A, and 20% traffic is forwarded to the user service deployed on cluster B.

  

Mock routing

Mock routing is typically used for debugging. You can configure a fixed response for a route to verify whether requests are properly forwarded. This helps frontend and backend development to proceed in parallel and accelerates development iteration.

For example, in the following application system, when the backend user service is not completed, a fixed response is configured for API operations of the user service. The frontend developers can then test and debug the routing process. When the backend user service is completed, you can change the value of the Type parameter from Mock to the user service, and then the frontend and backend personnel can perform joint debugging.

Redirection

The cloud-native gateway can redirect requests to another domain name or path. Redirection is often used in scenarios of domain name transfer and API changes.

For example, the current service domain name is old.example.com and the current path is /test. The cloud-native gateway redirects a request from old.example.com/test to new.example.com/dev.