浅析微服务全链路灰度解决方案

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 帮助应用发布版本过程中更精细化,提高了发布过程中的稳定性。服务转移⾄请求链路上进行流量控制,有效保证了多个亲密关系的服务顺利安全发布以及服务多版本并⾏开发,进⼀步促进业务的快速发展。

作者:

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

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


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

https://developer.aliyun.com/ebook/7565


1.png

长按二维码直达下载地址


单体架构下的服务发布


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


2.png


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


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


3.png


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


4.png


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


微服务架构下的服务发布


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


5.png


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


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


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


什么是全链路灰度


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


6.png


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


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


全链路灰度的解决方案


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


物理环境隔离


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


7.png


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


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


逻辑环境隔离


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


8.png


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


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


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

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

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

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


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


标签路由


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


9.png


节点打标

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


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


10.png


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


11.png


流量染色

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


分布式链路追踪


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


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


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


12.png


逻辑环境隔离


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


13.png


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


点击此处,前往微服务引擎 MSE 官网查看更多详情!

相关实践学习
分布式链路追踪Skywalking
Skywalking是一个基于分布式跟踪的应用程序性能监控系统,用于从服务和云原生等基础设施中收集、分析、聚合以及可视化数据,提供了一种简便的方式来清晰地观测分布式系统,具有分布式追踪、性能指标分析、应用和服务依赖分析等功能。 分布式追踪系统发展很快,种类繁多,给我们带来很大的方便。但在数据采集过程中,有时需要侵入用户代码,并且不同系统的 API 并不兼容,这就导致了如果希望切换追踪系统,往往会带来较大改动。OpenTracing为了解决不同的分布式追踪系统 API 不兼容的问题,诞生了 OpenTracing 规范。OpenTracing 是一个轻量级的标准化层,它位于应用程序/类库和追踪或日志分析程序之间。Skywalking基于OpenTracing规范开发,具有性能好,支持多语言探针,无侵入性等优势,可以帮助我们准确快速的定位到线上故障和性能瓶颈。 在本套课程中,我们将全面的讲解Skywalking相关的知识。从APM系统、分布式调用链等基础概念的学习加深对Skywalking的理解,从0开始搭建一套完整的Skywalking环境,学会对各类应用进行监控,学习Skywalking常用插件。Skywalking原理章节中,将会对Skywalking使用的agent探针技术进行深度剖析,除此之外还会对OpenTracing规范作整体上的介绍。通过对本套课程的学习,不止能学会如何使用Skywalking,还将对其底层原理和分布式架构有更深的理解。本课程由黑马程序员提供。
相关文章
|
8月前
|
消息中间件 弹性计算 数据可视化
SpringBoot 整合 Elastic Stack 最新版本(7.14.1)分布式日志解决方案,开源微服务全栈项目【有来商城】的日志落地实践
SpringBoot 整合 Elastic Stack 最新版本(7.14.1)分布式日志解决方案,开源微服务全栈项目【有来商城】的日志落地实践
|
1月前
|
数据库 开发者 微服务
浅谈微服务架构中的数据一致性解决方案
在分布式系统的演进过程中,微服务架构因其高度的解耦和独立性成为了众多企业技术栈的首选。然而,微服务架构中的数据一致性管理却是一个棘手的问题,直接关系到系统的稳定性和可靠性。本文将探讨在微服务架构下,如何通过不同的策略和技术手段,有效地解决数据一致性问题。我们将介绍基于事件驱动的一致性模式、分布式事务处理机制以及最终一致性的概念,并分析它们各自的应用场景和优缺点,为开发者提供在设计和实现微服务架构时的参考和指导。
|
2月前
|
传感器 监控 安全
微服务智慧工地信息化解决方案(源码)
智慧工地是指应用智能技术和互联网手段对施工现场进行管理和监控的一种工地管理模式。它利用传感器、监控摄像头、人工智能、大数据等技术,实现对施工现场的实时监测、数据分析和智能决策,以提高工地的安全性、效率和质量。
35 0
|
3月前
|
消息中间件 Kubernetes 监控
一个简化版的微服务解决方案
一个简化版的微服务解决方案
|
3月前
|
NoSQL API Redis
开箱即用!看看人家的微服务权限解决方案,那叫一个优雅
我们将采用Nacos作为注册中心,Gateway作为网关,使用Sa-Token提供的微服务权限解决方案,此方案是基于之前的解决方案改造的
|
3月前
|
监控 前端开发 持续交付
微服务的4个设计原则和19个解决方案
微服务的4个设计原则和19个解决方案
28 0
|
4月前
|
Arthas Java 测试技术
微服务轮子项目(49) -常见JVM内存错误及解决方案
微服务轮子项目(49) -常见JVM内存错误及解决方案
61 0
|
4月前
|
消息中间件 存储 Kafka
微服务轮子项目(07) - 日志解决方案设计
微服务轮子项目(07) - 日志解决方案设计
43 0
|
6月前
|
Web App开发 Cloud Native 数据安全/隐私保护
基于云原生网关实现微服务的多版本线上灰度
一起体验云原生网关开箱即用的微服务多样灰度能力,支持容器服务、Nacos、ZooKeeper、Edas等多种服务发现方式。
114 0
|
6月前
|
Kubernetes Cloud Native Serverless
基于MSE实现微服务的全链路灰度
本场景提供MSE Ingress网关集群和Kubernates集群,部署Demo服务。您将掌握支持Spring Cloud/Dubbo、云原生网关的全链路灰度方案。
423 0

相关产品

  • 云消息队列 MQ
  • 微服务引擎
  • 云消息队列 Kafka 版