Cloud-native gateways support multiple routing modes, including single-service routing, multi-service routing, tag-based routing, mock routing, and redirection.
Single-service routing
The cloud-native gateway forwards all requests of a specific type to a backend service based on routing rules. For more information about configuring services for the cloud-native gateway, see Add services.
The gateway matches a service and requests of a specific type 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.
Multi-service routing
The cloud-native gateway forwards requests of a specific type to multiple backend services. Traffic is distributed to the 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 one. 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 functions 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 proportion 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 of a specific type to services of different versions. Traffic is distributed based on the weight that you configured for each service version. For more information about how to manage service versions for the 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 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 use the following methods to perform canary release:
Routing based on traffic distribution proportions
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 proportion of traffic forwarded to the user service v2.
Routing based on 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 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 functions 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 set 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 set when API operations of the user service are called. 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
A 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.
The following figure shows an example of redirection. The cloud-native gateway forwards requests whose service domain name is old.example.com and path is /test to new.example.com/dev.
