【音频】微服务治理技术解决方案-全链路灰度|学习笔记

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
简介: 快速学习【音频】微服务治理技术解决方案-全链路灰度

开发者学堂课程【微服务治理技术进阶【音频】微服务治理技术解决方案-全链路灰度】学习笔记,与课程紧密联系,让用户快速学习知识。  

课程地址:https://developer.aliyun.com/learning/course/1033/detail/15134


【音频】微服务治理技术解决方案-全链路灰度


内容介绍:

一、微服务架构下的服务发布

二、全链路灰度

三、标签路由

微服务治理技术解决方案有很多,例如无损发布、全链路灰度、限流降级等,本次播客摘自《微服务治理技术白皮书》的第三章第2节《微服务全链路灰度解决方案》将对全链路灰度解决方案做详细的介绍。首先,我们先看一下在单体架构中,如何对应用中某个服务模块进行新版本发布。应用中的Cart服务模块有新版本迭代。

由于 Cart 服务是应用的一部分,所以新版本上线时需要对整个应用进行编译、打包以及部署。服务级别发布问题变成了应用级别的发布问题,我们需要对应用的新版本而不是服务来实施有效的发布策略。目前,业界已经有非常成熟的服务发布方案,例如蓝绿发布和灰度发布。蓝绿发布需要对服务的新版本进行冗余部署,一般新版本的机器规格和数量与旧版本保持一致,相当于该服务有两套完全相同的部署环境,只不过此时只有旧版本在对外提供服务,新版本作为热备,当服务进行版本升级时,我们只需将流量全部切换到新版本即可,旧版本作为热备。我们的例子使用蓝绿发布的示意图,流量切换基于四层代理的流量网关即可完成。在蓝绿发布中,由于存在流量整体切换,所以需要按照原服务占用的机器规模为新版本克隆一套环境,相当于要求原来1倍的机器资源。

灰度发布的核心思想是根据请求内容或者请求流量的比例将线上流量的一小部分转发至新版本,待灰度验证通过后,逐步调大新版本的请求流量,是一种循序渐进的发布方式。我们的例子使用灰度发布的示意图,基于内容或比例的流量控制需要借助于一个七层代理的微服务网关来完成。

其中,Traffic Routing 是基于内容的灰度方式,比如请求中含有头部 stag=gray 的流量路由到应用 v2 版本; TrafficShifting 是基于比例的灰度方式,以无差别的方式对线上流量按比重进行分流。相比蓝绿发布,灰度发布在机器资源成本以及流量控制能力上更胜一筹,但缺点就是发布周期过长,对运维基础设施要求较高。


一、微服务架构下的服务发布

在分布式微服务架构中,应用中被拆分出来的子服务都是独立部署、运行和迭代的。单个服务新版本上线时,我们再也不需要对应用整体进行发版,只需关注每个微服务自身的发布流程即可,如下,为了验证服务 Cart 的新版本,流量在整个调用链路上能够通过某种方式有选择的路由到 Cart 的灰度版本,这属于微服务治理领域中流量治理问题。常见的治理策略包括基于 Provider 和基于 Consumer 的方式。

·基于 Provider 的治理策略。配置 Cart 的流量流入规则,User 路由到Cart 时使用Cant 的流量流入规则。

·基于 Consumer 的治理策略。配置 User 的流量流出规则,User 路由到 Cart 时使用 User 的流量流出规则。

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


二、全链路灰度

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

上一小节提出的两种治理策略,我们需要额外配置服务 Order 的治理规则,确保来自灰度环境的服务 Cart 的流量转发至服务 Order 的灰度版本。这样的做法看似符合正常的操作逻辑,但在真实业务场景中,业务的微服务规模和数量远超我们的例子,其中一条请求链路可能经过数十个微服务,新功能发布时也可能会涉及到多个微服务同时变更并且业务的服务之间依赖错综复杂,频繁的服务发布、以及服务多版本并行开发导致流量治理规则日益膨胀,给整个系统的维护性和稳定性带来了不利因素。对于以上的问题,开发者结合实际业务场景和生产实践经验,提出了一种端到端的灰度发布方案,即全链路灰度,全链路灰度治理策略主要专注干整个调用链,它不关心链路上经过具体哪些微服务,流量控制视角从服务转移至请求链路上,仅需要少量的治理规则即可构建出从网关到整个后端服务的多个流量隔离环境,有效保证了多个亲密关系的服务顺利安全发布以及服务多版本并行开发,进一步促进业务的快速发展。

1、全链路灰度的解决方案

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

2、物理环境隔离

物理环境隔离,顾名思义,通过增加机器的方式来搭建真正意义上的流量隔离。这种方案需要为要灰度的服务搭建一套网络隔离、资源独立的环境,在其中部署服务的灰度版本。

由于与正式环境隔离,正式环境中的其他服务无法访问到需要灰度的服务,所以需要在灰度环境中冗余部署这些线上服务,以便整个调用链路正常进行流量转发。此外,注册中心等一些其他依赖的中间件组件也需要冗余部署在灰度环境中,保证微服务之间的可见性问题,确保获取的节点 IP 地址只属于当前的网络环境。这个方案一般用于企业的测试、预发开发环境的搭建,对于线上灰度发布引流的场景来说其灵活性不够。况目,微服务多版本的存在在微服务架构中是家常便饭,需要为这些业务场景采用堆机器的方式来维护多套灰度环境。如果您的应用数目过多的情况下,会造成运维、机器成本过大,成本和代价远超收益:如果应用数目很小,就两三个应用,这个方式还是很方便的,可以接受的。

3、逻辑环境隔离

另一种方案是构建逻辑上的环境隔离,我们只需部署服务的灰度版本,流量在调用链路上流转时,由流经的网关、各个中间件以及各个微服务来识别灰度流量,并动态转发至对应服务的灰度版本。图可以很好展示这种方案的效果,我们用不同的颜色来表示不同版本的灰度流量,可以看出无论是微服务网关还是微服务本身都需要识别流量,根据治理规则做出动态决策。当服务版本发生变化时,这个调用链路的转发也会实时改变。相比于利用机器搭建的灰度环境,这种方案不仅可以节省大量的机器成本和运维人力,而且可以帮助开发者实时快速的对线上流量进行精细化的全链路控制。全链路灰度具体是如何实现,通过讨论,需要解决以下问题:

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

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

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

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

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


三、标签路由

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

1、节点打标

如何给服务节点添加不同的标签,在如今火热的云原生技术推动下,大多数业务都在积极进行容器化改造之旅。这里以容器化的应用为例,介绍在使用 Kubernetes Service 作为服务发现和使用比较流行的 Nacos 注册中心这两种场景下如何对服务 Workload 进行节点打标。在使用 Kubernetes Service 作为服务发现的业务系统中,服务提供者通过向 ApiServer 提交 Service 资源完成服务暴露,服务消费端监听与该 Service 资源下关联的 Endpoint 资源,从 Endpoint 资源中获取关联的业务 Pod 资源,读取上面的 Labels 数据并作为该节点的元

数据信息。所以只要在业务应用描述资源 Deployment 中的 Pod 模板中为节点添加标签即可。在使用 Nacos 作为服务发现的业务系统中,一般需要业务根据其使用的微服务框架来决定打标方式。如果 java 应用使用的 Spring Cloud 微服务开发框架,我们可以为业务容器添加对应的环境变量来完成标签的添加操作。比如希望为节点添加版本灰度标。那么为业务容器添加这样框架向Nacos 注册该节点时会为其添加一个标签 verison=gray。

2、流量染色

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

3、分布式链路追踪

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

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

借助于分布式链路追踪思想,也可以传递一些自定义信息,比如灰度标识。业界常见的分布式链路追踪产品都支持链路传递用户自定义的数据。

4、逻辑环境隔离

首先需要支持动态路由功能,对于 Spring Cloud Dubbo 开发框架,可以对出口流量实现自定义 Filter,在 Filter 中完成流量识别以及标签路由。同时需要借助分布式链路追踪技术完成流量标识链路传递以及流量自动染色。

此外需要引入一个中心化的流量治理平台,方便各个业务线的开发者定义自己的全链路灰度规则。实现全链路灰度的能力,无论是成本还是技术复杂度都是比较高的,以及后期的维护、扩展都是非常大的成本。可以选择阿里云 MSE 服务治理产品,该产品就是一款基于 Java Agent 实现的无侵入式企业生产级服务治理产品,不需要修改任何一行业务代码,即可拥有不限于全链路灰度的治理能力,并且支持近5年内所有的 Spring Boot Spring Cloud 和Dubbo。

相关实践学习
基于OpenTelemetry构建全链路追踪与监控
本实验将带领您快速上手可观测链路OpenTelemetry版,包括部署并接入多语言应用、体验TraceId自动注入至日志以实现调用链与日志的关联查询、以及切换调用链透传协议以满足全链路打通的需求。
分布式链路追踪Skywalking
Skywalking是一个基于分布式跟踪的应用程序性能监控系统,用于从服务和云原生等基础设施中收集、分析、聚合以及可视化数据,提供了一种简便的方式来清晰地观测分布式系统,具有分布式追踪、性能指标分析、应用和服务依赖分析等功能。 分布式追踪系统发展很快,种类繁多,给我们带来很大的方便。但在数据采集过程中,有时需要侵入用户代码,并且不同系统的 API 并不兼容,这就导致了如果希望切换追踪系统,往往会带来较大改动。OpenTracing为了解决不同的分布式追踪系统 API 不兼容的问题,诞生了 OpenTracing 规范。OpenTracing 是一个轻量级的标准化层,它位于应用程序/类库和追踪或日志分析程序之间。Skywalking基于OpenTracing规范开发,具有性能好,支持多语言探针,无侵入性等优势,可以帮助我们准确快速的定位到线上故障和性能瓶颈。 在本套课程中,我们将全面的讲解Skywalking相关的知识。从APM系统、分布式调用链等基础概念的学习加深对Skywalking的理解,从0开始搭建一套完整的Skywalking环境,学会对各类应用进行监控,学习Skywalking常用插件。Skywalking原理章节中,将会对Skywalking使用的agent探针技术进行深度剖析,除此之外还会对OpenTracing规范作整体上的介绍。通过对本套课程的学习,不止能学会如何使用Skywalking,还将对其底层原理和分布式架构有更深的理解。本课程由黑马程序员提供。
相关文章
|
2月前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
30天前
|
监控 JavaScript 数据可视化
建筑施工一体化信息管理平台源码,支持微服务架构,采用Java、Spring Cloud、Vue等技术开发。
智慧工地云平台是专为建筑施工领域打造的一体化信息管理平台,利用大数据、云计算、物联网等技术,实现施工区域各系统数据汇总与可视化管理。平台涵盖人员、设备、物料、环境等关键因素的实时监控与数据分析,提供远程指挥、决策支持等功能,提升工作效率,促进产业信息化发展。系统由PC端、APP移动端及项目、监管、数据屏三大平台组成,支持微服务架构,采用Java、Spring Cloud、Vue等技术开发。
|
2月前
|
Java Nacos Sentinel
Spring Cloud Alibaba:一站式微服务解决方案
Spring Cloud Alibaba(简称SCA) 是一个基于 Spring Cloud 构建的开源微服务框架,专为解决分布式系统中的服务治理、配置管理、服务发现、消息总线等问题而设计。
366 13
Spring Cloud Alibaba:一站式微服务解决方案
|
2月前
|
运维 监控 Java
为何内存不够用?微服务改造启动多个Spring Boot的陷阱与解决方案
本文记录并复盘了生产环境中Spring Boot应用内存占用过高的问题及解决过程。系统上线初期运行正常,但随着业务量上升,多个Spring Boot应用共占用了64G内存中的大部分,导致应用假死。通过jps和jmap工具排查发现,原因是运维人员未设置JVM参数,导致默认配置下每个应用占用近12G内存。最终通过调整JVM参数、优化堆内存大小等措施解决了问题。建议在生产环境中合理设置JVM参数,避免资源浪费和性能问题。
114 3
|
3月前
|
Kubernetes Java 微服务
微服务上下线动态感知实现的技术解析
随着微服务架构的广泛应用,服务的动态管理和监控变得尤为重要。在微服务架构中,服务的上下线是一个常见的操作,如何实时感知这些变化,确保系统的稳定性和可靠性,成为了一个关键技术挑战。本文将深入探讨微服务上下线动态感知的实现方式,从技术基础、场景案例、解决思路和底层原理等多个维度进行阐述,并分别使用Java和Python进行演示介绍。
87 4
|
3月前
|
运维 Kubernetes Docker
深入理解容器化技术及其在微服务架构中的应用
深入理解容器化技术及其在微服务架构中的应用
95 1
|
3月前
|
监控 Java 微服务
从零构建微服务架构:一次深度技术探索之旅####
本文作为一篇深度技术分享,引领读者踏上自底向上搭建微服务架构的征途,旨在通过实战经验剖析,揭示微服务转型背后的技术挑战与解决方案。不同于常规摘要仅概述内容,本文摘要将直接以故事化手法,简述作者从单体应用困境出发,逐步迈向微服务化的心路历程,涵盖关键决策点、技术选型考量及实践收获,激发读者对微服务架构设计与实现的浓厚兴趣。 ####
|
3月前
|
Cloud Native 云计算 Docker
云原生技术的崛起:从容器化到微服务架构
云原生技术的崛起:从容器化到微服务架构
|
3月前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
200 6
|
3月前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
76 1