全链路灰度的挑战、实现思路与解决方案

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 全链路灰度的挑战、实现思路与解决方案

作者:ZadigX


微服务架构下的灰度发布挑战


在传统的单体应用架构中,灰度发布相对简单。只需要在服务的流量入口处进行分流,通过使用 K8s Service 或各种类型的网关即可实现。然而,微服务架构引入了新的复杂性,服务之间的依赖关系错综复杂。有时候,某个功能的发布可能依赖于多个服务,要求灰度流量在整个调用链中准确路由到灰度版本的服务。传统的单个服务流量入口设置分流的做法无法满足这一需求。为了解决微服务架构下的灰度发布问题,全链路灰度发布引入了泳道(Lane)的概念。泳道将灰度视角从单个服务扩展到整个请求的调用链上,确保流量能够精确地在一组指定规则的服务之间流动,就像在预先设置好的泳道中一样。全链路灰度发布方案专为微服务架构设计,旨在应对微服务架构下的灰度发布挑战。


全链路灰度发布的实现思路


全链路灰度发布的核心在于流量泳道概念的实现,而泳道正如上文所说,是对满足指定规则的流量定下一个活动范围,它有以下两种实现思路:


第一种思路:完整环境隔离

泳道实现的主要难点在于,流量在服务间调用的过程中如何路由到正确的服务版本,但有一个简单的实现思路可以规避这个问题:复制一个包含所有微服务的完整环境,将需要灰度的服务替换为灰度版本。然后只需要在两个环境的流量入口处通过网关对流量进行规则分流,由于两套环境间存在网络隔离,灰度环境天然成为了一个灰度流量泳道。



然而,对于服务数量较多的微服务项目来说,这种方法会浪费资源,因为在灰度环境中创建非灰度服务会消耗额外的资源。如果要同时灰度多个版本,就需要创建多套完整环境,进一步增加了资源的浪费。


第二种思路:服务流量路由



若能赋予每个服务路由流量的能力,泳道的设置就可以共用正常服务从而充分利用资源,多版本的全链路灰度发布也可以同时在同一个环境中进行。具体而言,需要两个能力:全链路流量路由和全链路数据透传。


全链路流量路由

流量路由指的是服务本身发送流量时,可以根据指定规则将其路由到正确的目的地,例如带有灰度标的流量应该优先发往灰度版本的服务,全链路流量路由则要求每个服务都具备这种能力。


全链路流量路由目前有两种主流实现:

  1. 基于 Istio:采用 Istio 这个开源 Service Mesh 组件,通过在每个服务的容器中部署 Envoy 透明代理,拦截服务之间的网络通信并按指定规则转发,从而实现了全链路流量路由,无需对现有代码进行修改。
  2. 基于服务发现组件:通过支持为服务设置元数据的服务注册中心,如 Nacos,可以标记服务实例的特征,例如灰度版本。每个服务可以通过注册中心获取其他服务实例的版本信息,并通过修改代码逻辑或 Java Agent 实现流量路由。


全链路数据透传

为了实现全链路灰度发布,流量路由规则基于流量染色标记,因此需要将染色标记传递到整个请求链路中,即实现全链路数据透传能力。简单的数据透传可以基于原生的 HTTP Header、Query Parameters 等资源来实现,但在复杂的微服务场景下,应该使用 Tracing Baggage 机制。Tracing Baggage 是分布式链路跟踪工具提供的一种能力,可以携带用户自定义的键值对,主流的跟踪工具如 Skywalking 和 OpenTelemetry 都支持该功能。使用分布式链路追踪框架可以方便地进行日志记录和问题排查,特别适用于灰度发布场景下的需求。


企业发布现状的痛点分析


目前企业在选择和实施发布策略时面临以下困境:


1. 从传统部署模式转变为云原生模式后,缺乏相关能力的人才进行技术架构改造,使得企业在发布策略方面难以入手。

2. 已经找到适合产品现状的发布策略,但缺乏自动化平台或工具的支持,仍然依赖手工逐步执行,可能导致流程遗漏或人工操作失误,造成生产事故。

3. 仅实现了服务级别的灰度能力,逐个发布服务耗时长,导致发布过程缓慢,验证效果不佳。


针对以上问题,ZadigX 提供了灰度发布的解决方案,帮助企业应对这些痛点。


全链路灰度发布的实现方案


主要有 Istio、JavaAgent 等主流方案,基于流量路由的能力,ZadigX 提供了两套通用方案:


阿里云 MSE + ZadigX

阿里云 MSE 为 Java 应用提供了便捷实现全链路灰度的能力。MSE 微服务引擎是基于 Java Agent 实现的无侵入式企业生产级服务治理产品,不需要修改任何一行业务代码,即可拥有不限于全链路灰度的治理能力,并且支持近 5 年内所有的 Spring Boot、Spring Cloud 和 Dubbo。


使用 MSE 进行灰度发布的过程中,ZadigX 可以便捷得创建灰度环境和灰度 K8S 资源、结合发布工作流编排能力,自动为 K8S 资源设置 MSE 所需的资源标记,集成了 MSE API 降低重复工作量。


Istio + Distributed Tracing + ZadigX

Istio 可以无侵入地实现全链路流量路由能力,同时还可以设置基于比例、权重、HTTP Header 等条件的流量路由,但全链路数据透传需要服务本身实现,为此需要服务接入支持 Baggage 的分布式链路追踪框架,若还没接入则会涉及到一定的改造成本。


ZadigX 可以根据指定的灰度任务与灰度标记规则,结合发布工作流编排能力与环境的监测管理能力,自动创建 Istio VirtualService 与 DistinationRule  资源以实现相应的泳道,达到了让开发者轻松进行全链路灰度发布的效果。

相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
相关文章
|
10月前
|
Kubernetes 负载均衡 安全
【服务网格】最佳实践在哪里-1:全链路灰度
作为完全兼容社区Istio的服务网格产品,服务网格ASM针对全链路灰度场景提出了自己的思考,并针对性地设计了对应的流量标签方案,来解决上述全链路灰度实现方案中的痛点问题。
全链路压测常态化方案
压测任务正式开始前,设定并检查压测的SLA阈值,确保压测流量不会导致生产服务负载过高出现异常;
全链路压测常态化方案
|
存储 运维 监控
业务全链路追踪最佳实践|学习笔记
快速学习业务全链路追踪最佳实践
455 0
业务全链路追踪最佳实践|学习笔记
|
运维 Kubernetes Java
【音频】微服务治理技术解决方案-全链路灰度|学习笔记
快速学习【音频】微服务治理技术解决方案-全链路灰度
250 0
|
负载均衡 测试技术 微服务
分布式中灰度方案实践
将版本的分支号加载到服务的元数据信息中,再结合服务名称或者IP地址,来实现对服务列表的多维度过滤,可以支撑大部分轻量级灰度策略的实现。
395 0
分布式中灰度方案实践
|
运维 Cloud Native Dubbo
微服务全链路灰度新能力
微服务体系架构中,服务之间的依赖关系错综复杂,有时某个功能发版依赖多个服务同时升级上线。我们希望可以对这些服务的新版本同时进行小流量灰度验证,这就是微服务架构中特有的全链路灰度场景,通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。
微服务全链路灰度新能力
|
API 开发工具 Android开发
Android推送全链路简析
Android推送全链路简析
496 0
Android推送全链路简析
|
运维 Kubernetes Java
浅析微服务全链路灰度解决方案
帮助应用发布版本过程中更精细化,提高了发布过程中的稳定性。服务转移⾄请求链路上进行流量控制,有效保证了多个亲密关系的服务顺利安全发布以及服务多版本并⾏开发,进⼀步促进业务的快速发展。
浅析微服务全链路灰度解决方案
|
监控 NoSQL 新能源
全链路压测体系建设方案的思考与实践
全链路压测体系建设方案的思考与实践
全链路压测体系建设方案的思考与实践
|
存储 运维 Prometheus
云原生景观:可观察性和分析解决了什么问题?如何解决的?
云原生景观:可观察性和分析解决了什么问题?如何解决的?
153 0
云原生景观:可观察性和分析解决了什么问题?如何解决的?