一、背景简介
分布式系统中会存在这样的开发场景，不同需求可能涉及到对同一个服务的开发，那么该服务在研发期间就会存在多个版本并行的状态，为了保持不同版本之间的隔离性，验收需要将请求路由到指定版本号的服务上处理；
二、负载策略
在微服务系统架构中，请求在服务间转发时会执行负载的策略，尤其当服务存在多版本号的集群模式时，很显然常规的轮询、权重、随机等策略无法满足需求；进行路由规则的自定义设计和开发是常见方式；
默认主分支路由
存活的服务中可能存在多个版本，但是主分支Master是否存活是服务健康与否的基本标志，常规应用中路由规则如果不匹配，会由Master服务进行兜底；
版本号统一路由
服务定制化路由
路由规则可以看做是对可用服务的匹配筛选，如果筛选出来的服务存在集群部署时，还要去执行相应的负载均衡策略，例如上图中当服务C的分支是集群时，路由匹配到该版本后，再通过负载均衡的策略选中其中一个服务处理请求；
三、灰度部署
流程细节
1、做好路由配置和管理，请求默认在主干服务执行；
2、部署版本涉及的相关服务，灰度层面默认不会处理请求；
3、验收阶段基于配置，将指定规则的请求路由到灰度层；
4、常用规则：携带分支号、灰度用户群、比例分流、IP等；
5、完成灰度服务验收后，将相关服务标记为主干服务；
6、将旧的主干服务下线后，即本次上线流程完整结束；
7、若发现灰度服务验收失败，撤掉灰度层或修改都可以；
在这种模式下，灰度服务的上线或者下线几乎是没有明显感知的，如果是相对简单的流程，由测试人员验收灰度层服务即可，如果是复杂的流程，放开一定比例的用户流量，流程观察没有问题后完成升级；
四、实践方案
1、流程设计
2、路由标识
标识获取
版本号统一路由：routeId:2.0.0，即所有请求优先在分支执行；
服务定制化路由：serverC:3.0.0，请求服务C时优先在分支执行；
在微服务的组件中获取请求头的方式很多，比如Gateway网关中的路由过滤器，或者服务中的拦截器，都可以获取请求的相关参数信息，从而执行路由规则；
标识管理
写阶段：在过滤或拦截中获取路由标识，写入上下文容器；
读阶段：路由时从容器中读取标识，基于配置信息执行规则；
3、服务选中
微服务之间通信时，选中一个服务执行请求的逻辑比较复杂，尤其在灰度模式下涉及到对路由规则的改造，即策略指定的服务优先被选中；
1、从注册中心查询相应服务的可用列表；
2、基于路由规则，匹配符合请求标识的服务；
3、对筛选的结果列表执行负载均衡，选中服务；
在整个路由机制中，会涉及到匹配规则自定义改造，从常规的手段来看，将版本的分支号加载到服务的元数据信息中，再结合服务名称或者IP地址，来实现对服务列表的多维度过滤，可以支撑大部分轻量级灰度策略的实现。
五、参考源码
应用仓库：
https://gitee.com/cicadasmile/butte-flyer-parent
组件封装：
https://gitee.com/cicadasmile/butte-frame-parent