算命手机网站开发,福田瑞沃前四后四车价格,中英文双语网站 滑动切换,做网站标题居中代码简介#xff1a;帮助应用发布版本过程中更精细化#xff0c;提高了发布过程中的稳定性。服务转移⾄请求链路上进行流量控制#xff0c;有效保证了多个亲密关系的服务顺利安全发布以及服务多版本并⾏开发#xff0c;进⼀步促进业务的快速发展。
作者#xff1a;
十眠帮助应用发布版本过程中更精细化提高了发布过程中的稳定性。服务转移⾄请求链路上进行流量控制有效保证了多个亲密关系的服务顺利安全发布以及服务多版本并⾏开发进⼀步促进业务的快速发展。
作者
十眠微服务引擎 MSE 研发工程师
扬少微服务引擎 MSE 研发工程师
本文摘选自《微服务治理技术白皮书》该白皮书历经半年多筹备长达 379 页。希望通过本书能对高效解决云原生架构下的微服务治理难题起到一点点作用电子版免费下载地址
微服务治理技术白皮书-藏经阁-阿里云开发者社区
单体架构下的服务发布
⾸先我们先看⼀下在单体架构中如何对应⽤中某个服务模块进⾏新版本发布。如下图应⽤中的 Cart 服务模块有新版本迭代 由于 Cart 服务是应⽤的⼀部分所以新版本上线时需要对整个应⽤进⾏编译、打包以及部署。服务级别发布问题变成了应⽤级别的发布问题我们需要对应⽤的新版本⽽不是服务来实施有效的发布策略。
⽬前业界已经有⾮常成熟的服务发布⽅案例如蓝绿发布和灰度发布。蓝绿发布需要对服务的新版本进⾏冗余部署⼀般新版本的机器规格和数量与旧版本保持⼀致相当于该服务有两套完全相同的部署环境只不过此时只有旧版本在对外提供服务新版本作为热备。当服务进⾏版本升级时我们只需将流量全部切换到新版本即可旧版本作为热备。我们的例⼦使⽤蓝绿发布的示意图如下流量切换基于四层代理的流量⽹关即可完成。 在蓝绿发布中由于存在流量整体切换所以需要按照原服务占⽤的机器规模为新版本克隆⼀套环境相当于要求原来 1 倍的机器资源。灰度发布的核⼼思想是根据请求内容或者请求流量的⽐例将线上流量的⼀⼩部分转发⾄新版本待灰度验证通过后逐步调⼤新版本的请求流量是⼀种循序渐进的发布⽅式。我们的例⼦使⽤灰度发布的示意图如下基于内容或⽐例的流量控制需要借助于⼀个七层代理的微服务⽹关来完成。 其中Traffic Routing 是基于内容的灰度⽅式⽐如请求中含有头部 staggray 的流量路由到应⽤ v2 版本Traffic Shifting 是基于⽐例的灰度⽅式以⽆差别的⽅式对线上流量按⽐重进⾏分流。相⽐蓝绿发布灰度发布在机器资源成本以及流量控制能⼒上更胜⼀筹但缺点就是发布周期过⻓对运维基础设施要求较⾼。
微服务架构下的服务发布
在分布式微服务架构中应⽤中被拆分出来的⼦服务都是独⽴部署、运⾏和迭代的。单个服务新版本上线时我们再也不需要对应⽤整体进⾏发版只需关注每个微服务⾃身的发布流程即可如下 为了验证服务 Cart 的新版本流量在整个调⽤链路上能够通过某种⽅式有选择的路由到 Cart 的灰度版本这属于微服务治理领域中流量治理问题。常⻅的治理策略包括基于 Provider 和基于 Consumer 的⽅式。
基于 Provider 的治理策略。配置 Cart 的流量流⼊规则User 路由到 Cart 时使⽤ Cart 的流量流⼊规则。基于 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.versiongray这样框架向 Nacos 注册该节点时会为其添加⼀个标签verisongray。 流量染色
请求链路上各个组件如何识别出不同的灰度流量答案就是流量染⾊为请求流量添加不同灰度标识来⽅便区分。我们可以在请求的源头上对流量进⾏染⾊前端在发起请求时根据⽤户信息或者平台信息的不同对流量进⾏打标。如果前端⽆法做到我们也可以在微服务⽹关上对匹配特定路由规则的请求动态 添加流量标识。此外流量在链路中流经灰度节点时如果请求信息中不含有灰度标识需要⾃动为其染⾊接下来流量就可以在后续的流转过程中优先访问服务的灰度版本。
分布式链路追踪
还有⼀个很重要的问题是如何保证灰度标识能够在链路中⼀直传递下去呢如果在请求源头染⾊那么请求经过⽹关时⽹关作为代理会将请求原封不动的转发给⼊⼝服务除⾮开发者在⽹关的路由策略中实施请求内容修改策略。接着请求流量会从⼊⼝服务开始调⽤下⼀个微服务会根据业务代码逻辑形成新的调⽤请求那么我们如何将灰度标识添加到这个新的调⽤请求从⽽可以在链路中传递下去呢
从单体架构演进到分布式微服务架构服务之间调⽤从同⼀个线程中⽅法调⽤变为从本地进程的服务调⽤远端进程中服务并且远端服务可能以多副本形式部署以⾄于⼀条请求流经的节点是不可预知的、不确定的⽽且其中每⼀跳的调⽤都有可能因为⽹络故障或服务故障⽽出错。分布式链路追踪技术对⼤型分布式系统中请求调⽤链路进⾏详细记录核⼼思想就是通过⼀个全局唯⼀的 traceid 和每⼀条的 spanid 来记录请求链路所经过的节点以及请求耗时其中 traceid 是需要整个链路传递的。
借助于分布式链路追踪思想我们也可以传递⼀些⾃定义信息⽐如灰度标识。业界常⻅的分布式链路追踪产品都⽀持链路传递⽤户⾃定义的数据其数据处理流程如下图所示 逻辑环境隔离
⾸先需要⽀持动态路由功能对于 Spring Cloud、Dubbo 开发框架可以对出⼝流量实现⾃定义 Filter在该 Filter 中完成流量识别以及标签路由。同时需要借助分布式链路追踪技术完成流量标识链路传递以及流量⾃动染⾊。此外需要引⼊⼀个中⼼化的流量治理平台⽅便各个业务线的开发者定义⾃⼰的全链路灰度规则。如下图所示 总体上看实现全链路灰度的能⼒⽆论是成本还是技术复杂度都是⽐较⾼的以及后期的维护、扩展都是⾮常⼤的成本但确实更精细化的提高了发布过程中的应用稳定性。
原文链接
本文为阿里云原创内容未经允许不得转载。
