路由方式概述_微服务引擎(MSE)-阿里云帮助中心

目前，云原生网关支持多种路由方式，包括单服务、多服务、标签路由、服务Mock和重定向。

单服务路由

在该模式下，可以将请求转发到后端某个具体的服务。关于云原生网关服务的设置，请参见管理服务。

网关根据配置的路由规则进行匹配，例如：

匹配/user路由规则的请求，转发到用户服务。
匹配/order路由规则的请求，转发到订单服务。

多服务路由

在该模式下，可以将请求转发到后端多个不同的服务，流量按照配置的权重进行分流。您可以在以下场景中选择多服务类型：

不同的注册中心
在业务发展过程中，内部架构对于注册中心的选型可能随着新技术的迭代而进行更换。在注册中心选型迁移的过程中，为了保证流量无损，平滑稳定的升级，一般会冗余部署服务并将服务的注册中心更换为新的注册中心，同时保留旧服务和旧注册中心。之后逐步将流量从旧服务分流到新服务，这个过程一般耗时较久，待新服务稳定后，就可以将流量全部转发到采用新注册中心的服务。同时，要支持可回滚，一旦新服务的状态不符合预期，您可以随时将流量回滚到旧服务。
例如，以下应用系统中的用户服务原来使用的是Nacos中心，现在希望将注册中心切换到K8s内置的CoreDNS方案（需结合Service资源一起使用）。
不同的运维体系
传统的业务服务大多数部署在虚拟机上，例如阿里云ECS。随着易运维、高弹性的K8s技术的兴起，越来越多的业务开始将业务逐步迁移至K8s运维平台，例如阿里云ACK。为了保证迁移过程中流量无损，一般会在K8s集群上冗余部署服务，以新的服务名注册到注册中心上。此时，注册中心会出现两个功能相同的服务，ECS上部署运行的用户服务以及K8s上部署运行的用户服务。之后逐步将流量从ECS上的服务分流到K8s上的服务，期间可以随时调整流量权重和回滚。
例如，以下应用系统中的以Nacos作为注册中心的用户服务，希望将ECS上的用户服务迁移至阿里云ACK平台。

标签路由

在该模式下，可以将请求转发到相同或不同服务的不同版本，流量按照配置的权重进行分流。关于云原生网关服务版本的设置，请参见管理服务版本。您可以在以下场景中选择多服务类型：

金丝雀发布
在服务持续迭代发展过程中，频繁存在服务新版本发布上线的需求，为了确保流量在服务升级过程中平稳无损，开发者经常会使用金丝雀发布手段来将小部分流量分发到新版本进行验证，验证符合预期后，逐步将流量从老版本完全迁移至新版本。
例如，以下应用系统中以K8s容器服务作为服务发现的用户服务，服务的当前版本为v1，现在服务的新版本v2要发布上线。有两种方式可以进行金丝雀发布：
- 按比例
  现有的路由/user，目标服务类型为标签路由，转发至用户服务v1版本。在服务管理中为用户服务添加v2版本，之后在当前路由的标签路由中新增一个目标服务（用户服务v2版本），您可以配置权重来决定转发至v2版本的流量比例。
- 按内容
  现有的路由/user，目标服务类型为标签路由，转发至用户服务v1版本。新增一条路由/user，添加灰度标识，例如Header名为stage，Header值为gray，转发至用户服务v2版本。
标签路由
在实际业务中，有的服务本身长期存在多个版本，各个版本之间功能也有差异，分别应用于有特定信息的请求。例如对于同一个API，带有某个Header值的请求必须访问服务的某个版本。另一个场景是多套开发环境（测试、预发和生产），利用服务版本可以根据请求的信息来决定分发到哪个开发环境。
例如，以下应用系统中以K8s容器服务作为服务发现的用户服务，有三套开发环境（test、pre和online）。对于/user的请求设置如下：
- Header stage的值为test，流量转发至用户服务的测试版本。
- Header stage的值为pre，流量转发至用户服务的预发版本。
- Header stage的值为online，流量转发至用户服务的正式版本。
高可用部署
为了保证服务的可用性，服务可以部署在不同的K8s集群中，我们可以根据节点上与集群相关的元数据信息对服务所有实例按集群维度进行版本管理，并且可以调整分发到各个集群（各个服务版本）的流量权重。当某个集群出现故障时，设置分发到该集群的流量权重为0，即可达到流量切换目的。
例如，以下应用系统中以K8s容器服务作为服务发现的用户服务，部署在两个不同的ACK集群中，集群A和集群B。对于/user的路由请求流量，希望80%的流量转发至集群A中部署的用户服务，20%的流量转发至集群B中部署的用户服务。