​**简介：**帮助应用发布版本过程中更精细化，提高了发布过程中的稳定性。服务转移⾄请求链路上进行流量控制，有效保证了多个亲密关系的服务顺利安全发布以及服务多版本并⾏开发，进⼀步促进业务的快速发展。

作者：

十眠｜微服务引擎 MSE 研发工程师

扬少｜微服务引擎 MSE 研发工程师

本文摘选自《微服务治理技术白皮书》，该白皮书历经半年多筹备，长达 379 页。希望通过本书，能对高效解决云原生架构下的微服务治理难题，起到一点点作用，电子版免费下载地址：developer.aliyun.com/ebook/7565

单体架构下的服务发布

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

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

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

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

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

微服务架构下的服务发布

在分布式微服务架构中，应⽤中被拆分出来的⼦服务都是独⽴部署、运⾏和迭代的。单个服务新版本上线时，我们再也不需要对应⽤整体进⾏发版，只需关注每个微服务⾃身的发布流程即可，如下：

​为了验证服务 Cart 的新版本，流量在整个调⽤链路上能够通过某种⽅式有选择的路由到 Cart 的灰度版本，这属于微服务治理领域中流量治理问题。常⻅的治理策略包括基于 Provider 和基于 Consumer 的⽅式。

1. 基于 Provider 的治理策略。配置 Cart 的流量流⼊规则，User 路由到 Cart 时使⽤ Cart 的流量流⼊规则。
2. 基于 Consumer 的治理策略。配置 User 的流量流出规则， User 路由到 Cart 时使⽤ User 的流量流出规则。

此外，使⽤这些治理策略时可以结合上⾯介绍的蓝绿发布和灰度发布⽅案来实施真正的服务级别的版本发布。

什么是全链路灰度

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

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

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

全链路灰度的解决方案

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

物理环境隔离

物理环境隔离，顾名思义，通过增加机器的⽅式来搭建真正意义上的流量隔离。

​这种⽅案需要为要灰度的服务搭建⼀套⽹络隔离、资源独⽴的环境，在其中部署服务的灰度版本。由于与正式环境隔离，正式环境中的其他服务⽆法访问到需要灰度的服务，所以需要在灰度环境中冗余部署这些线上服务，以便整个调⽤链路正常进⾏流量转发。此外，注册中⼼等⼀些其他依赖的中间件组件也 需要冗余部署在灰度环境中，保证微服务之间的可⻅性问题，确保获取的节点 IP 地址只属于当前的⽹络环境。

这个⽅案⼀般⽤于企业的测试、预发开发环境的搭建，对于线上灰度发布引流的场景来说其灵活性不够。况且，微服务多版本的存在在微服务架构中是家常便饭，需要为这些业务场景采⽤堆机器的⽅式来 维护多套灰度环境。如果您的应⽤数⽬过多的情况下，会造成运维、机器成本过⼤，成本和代价远超收益；如果应⽤数⽬很⼩，就两三个应⽤，这个⽅式还是很⽅便的，可以接受的。

逻辑环境隔离

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

​上图可以很好展示这种方案的效果，我们用不同的颜色来表示不同版本的灰度流量，可以看出无论是微服务网关还是微服务本身都需要识别流量，根据治理规则做出动态决策。当服务版本发生变化时，这个调用链路的转发也会实时改变。相比于利用机器搭建的灰度环境，这种方案不仅可以节省大量的机器成本和运维人力，而且可以帮助开发者实时快速的对线上流量进行精细化的全链路控制。

那么全链路灰度具体是如何实现呢？通过上⾯的讨论，我们需要解决以下问题：

1.链路上各个组件和服务能够根据请求流量特征进⾏动态路由。

2.需要对服务下的所有节点进⾏分组，能够区分版本。

3.需要对流量进⾏灰度标识、版本标识。

4.需要识别出不同版本的灰度流量。

接下来，会介绍解决上述问题需要⽤到的技术。

标签路由

标签路由通过对服务下所有节点按照标签名和标签值不同进⾏分组，使得订阅该服务节点信息的服务消费端可以按需访问该服务的某个分组，即所有节点的⼀个⼦集。服务消费端可以使⽤服务提供者节点上的任何标签信息，根据所选标签的实际含义，消费端可以将标签路由应⽤到更多的业务场景中。

​节点打标

那么如何给服务节点添加不同的标签呢？在如今⽕热的云原⽣技术推动下，⼤多数业务都在积极进⾏容器化改造之旅。这⾥，我就以容器化的应⽤为例，介绍在使⽤ Kubernetes Service 作为服务发现和使⽤⽐较流⾏的 Nacos 注册中⼼这两种场景下如何对服务 Workload 进⾏节点打标。

在使⽤ Kubernetes Service 作为服务发现的业务系统中，服务提供者通过向 ApiServer 提交 Service 资源完成服务暴露，服务消费端监听与该 Service 资源下关联的 Endpoint 资源，从 Endpoint 资源中获取关联的业务 Pod 资源，读取上⾯的 Labels 数据并作为该节点的元数据信息。所以，我们只要在业务应⽤描述资源 Deployment 中的 Pod 模板中为节点添加标签即可。

​在使⽤ Nacos 作为服务发现的业务系统中，⼀般是需要业务根据其使⽤的微服务框架来决定打标⽅式。如果 Java 应⽤使⽤的 Spring Cloud 微服务开发框架，我们可以为业务容器添加对应的环境变量来完成标签的添加操作。⽐如我们希望为节点添加版本灰度标，那么为业务容器添加`spring.cloud.nacos.discovery.metadata.version=gray`，这样框架向 Nacos 注册该节点时会为其添加⼀个标签`verison=gray`。

​流量染色

请求链路上各个组件如何识别出不同的灰度流量？答案就是流量染⾊，为请求流量添加不同灰度标识来⽅便区分。我们可以在请求的源头上对流量进⾏染⾊，前端在发起请求时根据⽤户信息或者平台信息的不同对流量进⾏打标。如果前端⽆法做到，我们也可以在微服务⽹关上对匹配特定路由规则的请求动态 添加流量标识。此外，流量在链路中流经灰度节点时，如果请求信息中不含有灰度标识，需要⾃动为其染⾊，接下来流量就可以在后续的流转过程中优先访问服务的灰度版本。

分布式链路追踪

还有⼀个很重要的问题是如何保证灰度标识能够在链路中⼀直传递下去呢？如果在请求源头染⾊，那么请求经过⽹关时，⽹关作为代理会将请求原封不动的转发给⼊⼝服务，除⾮开发者在⽹关的路由策略中实施请求内容修改策略。接着，请求流量会从⼊⼝服务开始调⽤下⼀个微服务，会根据业务代码逻辑形成新的调⽤请求，那么我们如何将灰度标识添加到这个新的调⽤请求，从⽽可以在链路中传递下去呢？

从单体架构演进到分布式微服务架构，服务之间调⽤从同⼀个线程中⽅法调⽤变为从本地进程的服务调⽤远端进程中服务，并且远端服务可能以多副本形式部署，以⾄于⼀条请求流经的节点是不可预知的、不确定的，⽽且其中每⼀跳的调⽤都有可能因为⽹络故障或服务故障⽽出错。分布式链路追踪技术对⼤型分布式系统中请求调⽤链路进⾏详细记录，核⼼思想就是通过⼀个全局唯⼀的 traceid 和每⼀条的 spanid 来记录请求链路所经过的节点以及请求耗时，其中 traceid 是需要整个链路传递的。

借助于分布式链路追踪思想，我们也可以传递⼀些⾃定义信息，⽐如灰度标识。业界常⻅的分布式链路追踪产品都⽀持链路传递⽤户⾃定义的数据，其数据处理流程如下图所示：

​逻辑环境隔离

⾸先，需要⽀持动态路由功能，对于 Spring Cloud、Dubbo 开发框架，可以对出⼝流量实现⾃定义 Filter，在该 Filter 中完成流量识别以及标签路由。同时需要借助分布式链路追踪技术完成流量标识链路传递以及流量⾃动染⾊。此外，需要引⼊⼀个中⼼化的流量治理平台，⽅便各个业务线的开发者定义⾃⼰的全链路灰度规则。如下图所示：

​总体上看，实现全链路灰度的能⼒，⽆论是成本还是技术复杂度都是⽐较⾼的，以及后期的维护、扩展都是⾮常⼤的成本，但确实更精细化的提高了发布过程中的应用稳定性。

原文链接

本文为阿里云原创内容，未经允许不得转载。