全链路灰度

什么是全链路灰度

单体架构下的服务发布

⾸先，我们先看⼀下在单体架构中，如何对应⽤中某个服务模块进⾏新版本发布。如下图，应⽤中的 Cart 服务模块有新版本迭代：

由于 Cart 服务是应⽤的⼀部分，所以新版本上线时需要对整个应⽤进⾏编译、打包以及部署。服务级别发布问题变成了应⽤级别的发布问题，我们需要对应⽤的新版本⽽不是服务来实施有效的发布策略。

⽬前，业界已经有⾮常成熟的服务发布⽅案，例如蓝绿发布和灰度发布。蓝绿发布需要对服务的新版本进⾏冗余部署，⼀般新版本的机器规格和数量与旧版本保持⼀致，相当于该服务有两套完全相同的部署环境，只不过此时只有旧版本在对外提供服务，新版本作为热备。当服务进⾏版本升级时，我们只需将流量全部切换到新版本即可，旧版本作为热备。我们的例⼦使⽤蓝绿发布的示意图如下，流量切换基于四层代理的流量⽹关即可完成。

在蓝绿发布中，由于存在流量整体切换，所以需要按照原服务占⽤的机器规模为新版本克隆⼀套环境，相当于要求原来 1 倍的机器资源。灰度发布的核⼼思想是根据请求内容或者请求流量的⽐例将线上流量的⼀⼩部分转发⾄新版本，待灰度验证通过后，逐步调⼤新版本的请求流量，是⼀种循序渐进的发布⽅式。我们的例⼦使⽤灰度发布的示意图如下，基于内容或⽐例的流量控制需要借助于⼀个七层代理的微服务⽹关来完成。

其中，Traffic Routing 是基于内容的灰度⽅式，⽐如请求中含有头部 stag=gray 的流量路由到应⽤v2 版本；Traffic Shifting 是基于⽐例的灰度⽅式，以⽆差别的⽅式对线上流量按⽐重进⾏分流。相⽐蓝绿发布，灰度发布在机器资源成本以及流量控制能⼒上更胜⼀筹，但缺点就是发布周期过⻓，对运维基础设施要求较⾼。

全链路灰度

继续考虑上⾯微服务体系中对服务 Cart 进⾏发布的场景，如果此时服务 Order 也需要发布新版本，由于本次新功能涉及到服务 Cart 和 Order 的共同变动，所以要求在灰度验证时能够使得灰度流量同时经过服务 Cart 和 Order 的灰度版本。如下图：

按照上⼀⼩节提出的两种治理策略，我们需要额外配置服务 Order 的治理规则，确保来⾃灰度环境的服务 Cart 的流量转发⾄服务 Order 的灰度版本。这样的做法看似符合正常的操作逻辑，但在真实业务场景中，业务的微服务规模和数量远超我们的例⼦，其中⼀条请求链路可能经过数⼗个微服务，新功能发布时也可能会涉及到多个微服务同时变更，并且业务的服务之间依赖错综复杂，频繁的服务发布、以及服务多版本并⾏开发导致流量治理规则⽇益膨胀，给整个系统的维护性和稳定性带来了不利因素。

对于以上的问题，开发者结合实际业务场景和⽣产实践经验，提出了⼀种端到端的灰度发布⽅案，即全链路灰度。全链路灰度治理策略主要专注于整个调⽤链，它不关⼼链路上经过具体哪些微服务，流量控制视⻆从服务转移⾄请求链路上，仅需要少量的治理规则即可构建出从⽹关到整个后端服务的多个流量隔离环境，有效保证了多个亲密关系的服务顺利安全发布以及服务多版本并⾏开发，进⼀步促进业务的快速发展

全链路灰度的解决⽅案

如何在实际业务场景中去快速落地全链路灰度呢？⽬前，主要有两种解决思路，基于物理环境隔离和基于逻辑环境隔离。

物理环境隔离

逻辑环境隔离

另⼀种⽅案是构建逻辑上的环境隔离，我们只需部署服务的灰度版本，流量在调⽤链路上流转时，由流经的⽹关、各个中间件以及各个微服务来识别灰度流量，并动态转发⾄对应服务的灰度版本。如下图：

上图可以很好展示这种方案的效果，我们用不同的颜色来表示不同版本的灰度流量，可以看出无论是微服务网关还是微服务本身都需要识别流量，根据治理规则做出动态决策。当服务版本发生变化时，这个调用链路的转发也会实时改变。相比于利用机器搭建的灰度环境，这种方案不仅可以节省大量的机器成本和运维人力，而且可以帮助开发者实时快速的对线上流量进行精细化的全链路控制。
那么全链路灰度具体是如何实现呢？通过上⾯的讨论，我们需要解决以下问题：
1.链路上各个组件和服务能够根据请求流量特征进⾏动态路由。
2.需要对服务下的所有节点进⾏分组，能够区分版本。
3.需要对流量进⾏灰度标识、版本标识。
4.需要识别出不同版本的灰度流量。
接下来，会介绍解决上述问题需要⽤到的技术。