介绍：帮助应用版本发布流程更加精细化，提高发布流程的稳定性。将服务转移到请求环节进行流控，有效保证了多个贴心服务的顺利安全发布和服务多版本的并行开发，进一步促进了业务的快速发展。作者：十眠｜微服务引擎MSE研发工程师杨少｜微服务引擎MSE研发工程师希望通过这本书，能为高效解决云原生架构下的微服务治理问题起到一点作用。电子版可以在https://developer.aliyun.com/免费下载...单体架构下的服务发布首先我们来看看如何在应用中发布一个服务模块的新版本单体架构。如下图，应用中的Cart服务模块有了新版本迭代：由于Cart服务是应用的一部分，新版本上线时需要对整个应用进行编译、打包、部署。服务级别的发布问题变成了应用级别的发布问题，我们需要对新版本的应用实施有效的发布策略，而不是服务。目前业界已经有非常成熟的服务发布方案，比如蓝绿发布、灰度发布等。蓝绿发布需要冗余部署新版本的服务。一般而言，新版本的机器规格和数量与旧版本一致，也就是说该服务有两个相同的部署环境，只是只有旧版本对外提供服务，而新版本是作为热备使用。当服务版本升级时，我们只需要将所有流量切换到新版本，旧版本作为双机热备。我们的例子使用蓝绿发布图如下，基于四层代理的流量网关即可完成流量切换。蓝绿发布时，由于流量的整体切换，需要根据原服务占用的机器规模，为新版本克隆一个环境，相当于需要原先两倍的机器资源。灰度发布的核心思想是根据请求内容或者请求流量的比例，将一小部分在线流量转发到新版本。灰度验证通过后，逐步增加新版本的请求流量。发布方式。我们的例子使用灰度发布的示意图如下。基于内容或者基于比例的流量控制需要借助七层代理微服务网关来完成。其中，TrafficRouting是一种基于内容的灰度方法。例如请求中包含headerstag=gray的流量被路由到v2版本的应用；TrafficShifting是一种基于比例的灰度方法，以一种无所谓的方式，根据比重来划分线上的流量。与蓝绿发布相比，灰度发布在机器资源成本和流量控制能力上具有优势，但缺点是发布周期过长，对运维基础设施要求较高。微服务架构下的服务发布在分布式微服务架构中，拆分出应用的子服务独立部署、运行、迭代。当单个服务上线新版本时，我们不再需要将应用整体发布，只需要关注每个微服务本身的发布过程，如下：serviceCart，整个Links调用的流量可以通过某种方式选择性的路由到灰色版本的Cart，属于微服务治理领域的流量治理问题。常见的治理策略包括基于提供者和基于消费者的方法。基于提供商的治理策略。配置Cart的流量流入规则，当用户被路由到Cart时使用Cart的流量流入规则。基于消费者的治理策略。配置User的流量流出规则，路由到Cart时使用User的流量流出规则。此外，在使用这些治理策略时，可以结合上述蓝绿发布和灰度发布方案，实现真正的服务级发布。什么是全链路灰度？继续考虑上面微服务系统中发布服务Cart的场景。如果此时服务Order也需要发布新版本，由于这个新功能涉及到服务Cart和Order的共同变化，因此需要开启灰度流量通过Cart和Order的灰度版本同时进行灰度验证。如下图所示：根据上一节提出的两种治理策略，我们需要额外配置serviceorder的治理规则，保证灰度环境下来自serviceCart的流量转发到灰度版本服务订单。这种做法看似符合正常的操作逻辑，但在真实的业务场景中，业务中微服务的规模和数量远远超过我们的例子，一个请求链路可能会经过数十个微服务。还可能涉及到多个微服务同时变更，业务服务之间的依赖错综复杂，频繁的服务发布，服务的多版本并行开发导致流量治理规则越来越膨胀，影响整个系统的可维护性和稳定性.带来的不利。针对以上问题，开发者结合实际业务场景和生产实践经验，提出了端到端的灰度发布方案，即全链路灰度。全链路灰度治理策略主要针对整个调用链。它不关心链接上的特定微服务。流量控制视角从服务转移到请求链接。只需要少量的治理规则，构建从网关到整个后端服务的多重流量隔离环境，有效保证多个紧密关联的服务的顺利安全发布和服务的多版本并行开发，进一步促进业务的快速发展。全链路灰度解决方案如何在实际业务场景中快速落地全链路灰度？目前主要有两种解决方案，物理环境隔离和逻辑环境隔离。物理环境隔离物理环境隔离，顾名思义，就是通过增加机器来构建真正的流量隔离。该方案需要为待灰度服务构建一个网络隔离、资源无关的环境，并在其中部署该服务的灰度版本。由于与正式环境的隔离，正式环境中的其他服务无法访问需要灰度的服务，因此需要在灰度环境中对这些在线服务进行冗余部署，使整个调用链路能够正常转发流量。此外，注册中心等其他一些依赖的中间件组件也需要在灰度环境中冗余部署，以保证微服务之间的可见性，保证获取的节点IP地址只属于当前网络环境。该方案一般用于企业测试和预发布开发环境的搭建。对于线上灰度发布引流场景不够灵活。而且微服务多版本的存在在微服务架构中司空见惯，对于这些业务场景需要使用堆机来维护多套灰度环境。如果你的应用太多，运维和机器成本就会太高，成本和成本远远超过收益；如果申请数量不多，只有两三个申请，这种方法还是很方便的，可以接受。逻辑环境隔离另一种解决方案是构建逻辑环境隔离。我们只需要部署服务的灰度版本。识别灰度流量，动态转发给对应服务的灰度版本。如下图所示：上图可以很好的展示这个方案的效果。我们使用不同的颜色来表示不同版本的灰度流量。可以看出，无论是微服务网关还是微服务本身，都需要对流量进行识别，并按照治理规则进行。做出动态决策。当服务版本发生变化时，该调用链接的转发也会实时变化。与机器搭建的灰度环境相比，该方案不仅可以节省大量的机器成本和运维人力，还可以帮助开发者实时快速地对线上流量进行细粒度的全链路管控。那么全链路灰度是如何实现的呢？通过以上讨论，我们需要解决以下问题：1、链路上的各个组件和服务可以根据请求流量的特点进行动态路由。2.需要将服务下的所有节点进行分组，才能区分版本。3、需要对流量进行灰度识别和版本识别。4.需要识别不同版本的灰度流量。下面介绍解决上述问题所需要的技术。标签路由标签路由根据标签名称和标签值对服务下的所有节点进行分组，使订阅服务节点信息的服务消费者可以按需访问服务的某一组，即所有节点的子集。服务消费者可以使用服务提供者节点上的任何标签信息。消费者可以根据所选标签的实际含义，将标签路由应用到更多的业务场景中。节点标记那么如何给服务节点添加不同的标签呢？在当今炙手可热的云原生技术的推动下，大多数企业都在积极踏上容器转型之旅。这里我以一个容器化应用为例，介绍在使用KubernetesService作为服务发现和使用流行的Nacos注册中心两种场景下如何标记服务工作负载节点。在使用KubernetesService作为服务发现的业务系统中，服务提供者通过向ApiServer提交Service资源完成服务暴露，服务消费者监听与Service资源关联的Endpoint资源，并从Endpoint获取关联的业务Pod资源resource，读取上面的Labels数据，作为节点的元数据信息。因此，我们只需要在业务应用描述资源Deployment中为Pod模板中的节点添加标签即可。在使用Nacos作为服务发现的业务系统中，一般需要业务根据自己使用的微服务框架来决定标记方式。如果Java应用使用了SpringCloud微服务开发框架，我们可以在业务容器中添加相应的环境变量来完成打标签的操作。比如我们要给节点添加一个版本灰度标签，那么在业务容器中添加spring.cloud.nacos.discovery.metadata.version=gray，这样框架就会给节点添加一个标签verison=gray当它向Nacos注册时。流量着色请求链路上的组件如何识别不同的灰度流量？答案是流量着色，对请求流量添加不同的灰度标记，方便区分。我们可以在请求的源头对流量进行着色，前端在发起请求时根据用户信息或者平台信息对流量进行标记。如果前端做不到，我们也可以在微服务网关上为匹配特定路由规则的请求动态添加流量标识。另外，当流量流经链路中的灰度节点时，如果请求信息中不包含灰度标识，则需要自动着色，以便流量在后续流中优先访问灰度版本的服务过程。分布式链路跟踪还有一个很重要的问题就是如何保证灰度标识一直在链路中传递？如果请求的源被染色，那么当请求经过网关时，网关会作为代理将请求转发给ingress服务，除非开发者在网关的路由策略中实现了请求内容修改策略。然后请求流量会从入口服务调用下一个微服务，根据业务代码的逻辑会形成一个新的调用请求，那么我们如何在这个新的调用请求中添加灰度标识，这样我们就可以传递链接怎么样？从单体架构演进到分布式微服务架构，服务之间的调用从同一个线程中的方法调用变成了本地进程中的服务调用远程进程中的服务，而远程服务可能以多副本的形式部署，所以一个请求流经的节点是不可预测和不确定的，每一跳的调用都可能因为网络故障或服务故障而出错。分布式链路跟踪技术详细记录了大规模分布式系统中的请求调用链路。核心思想是通过一个全局唯一的traceid记录请求链路经过的节点，每个spanid以及耗时的请求，traceid需要跨链路传递。借助分布式链接跟踪的思想，我们还可以传递一些自定义的信息，比如灰度标识。业界常见的分布式链路跟踪产品都支持链路传输用户自定义数据。数据处理流程如下图所示：逻辑环境隔离首先需要支持动态路由。对于SpringCloud和Dubbo开发框架，可以实现出口流量的自定义过滤器，在过滤器中完成流量识别和标签路由。同时，需要利用分布式链路跟踪技术完成流量识别链路传输和自动流量着色。此外，还需要引入一个集中的流量管理平台，方便各业务线的开发者定义自己的全链路灰度规则。如下图所示：一般来说，实现全链路灰度的能力在成本和技术复杂度上都比较高，后续的维护和扩容成本非常高，但确实提高了发布过程中的应用稳定性以更精细的方式处理。原文链接本文为阿里云原创内容，未经许可不得转载。
