分布式中灰度方案实践

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
简介: 将版本的分支号加载到服务的元数据信息中,再结合服务名称或者IP地址,来实现对服务列表的多维度过滤,可以支撑大部分轻量级灰度策略的实现。
让请求在导航的服务节上点执行;

一、背景简介

分布式系统中会存在这样的开发场景,不同需求可能涉及到对同一个服务的开发,那么该服务在研发期间就会存在多个版本并行的状态,为了保持不同版本之间的隔离性,验收需要将请求路由到指定版本号的服务上处理;

01.png

假设存在三个服务:A、B、C,且服务B和C都存在多个版本,那么让请求按照即定的路由规则执行,即可保证研发期间的验收是版本间隔离的,并且可以实现灰度部署的策略;

二、负载策略

在微服务系统架构中,请求在服务间转发时会执行负载的策略,尤其当服务存在多版本号的集群模式时,很显然常规的轮询、权重、随机等策略无法满足需求;进行路由规则的自定义设计和开发是常见方式;

经典应用场景:在请求发起时,可以通过Header、Cookie、Parameter等不同的方式,携带路由规则的方式与参数执行匹配逻辑,从而将请求路由到指定版本的服务;

默认主分支路由

02.png

通常来说请求会在主干分支上执行,或者其他分支路由规则不匹配,也可以通过标识配置,判断是否由主分支兜底,甚至是存活的任意服务兜底;

存活的服务中可能存在多个版本,但是主分支Master是否存活是服务健康与否的基本标志,常规应用中路由规则如果不匹配,会由Master服务进行兜底;

版本号统一路由

03.png

请求通过携带分支号进行统一版本路由是常用的轻量级方案,即如果请求携带的是2.0.0的分支,则在路由时优先匹配相关版本的服务,不匹配时由Master服务处理即可;

服务定制化路由

04.png

在请求或配置中指定各个服务的路由分支号,也是常见的匹配方案,如上图在请求时指定服务B由1.0.0分支执行,服务C由3.0.0分支执行,其余服务在主干分支执行;

路由规则可以看做是对可用服务的匹配筛选,如果筛选出来的服务存在集群部署时,还要去执行相应的负载均衡策略,例如上图中当服务C的3.0.0分支是集群时,路由匹配到该版本后,再通过负载均衡的策略选中其中一个服务处理请求;

三、灰度部署

当负载均衡的策略可以按照定制化开发的规则执行时,那服务的灰度发布就会容易很多,在不影响现有服务的情况下发布新版本,同时将请求按照规则分流,完成对新服务的验收后,替换掉旧版本即可;

05.png

分布式系统中子服务的拆分非常多,版本开发通常只会涉及其中部分子服务,通过灰度模式将相关服务部署到线上,并且不会影响主干的服务,只有开启特定的配置才会将请求分流到灰度服务;

流程细节

  • 1、做好路由配置和管理,请求默认在主干服务执行;
  • 2、部署版本涉及的相关服务,灰度层面默认不会处理请求;
  • 3、验收阶段基于配置,将指定规则的请求路由到灰度层;
  • 4、常用规则:携带分支号、灰度用户群、比例分流、IP等;
  • 5、完成灰度服务验收后,将相关服务标记为主干服务;
  • 6、将旧的主干服务下线后,即本次上线流程完整结束;
  • 7、若发现灰度服务验收失败,撤掉灰度层或修改都可以;

灰度发布的模式即依赖于自定义的路由规则,以及服务在负载均衡时权重比例倾斜,这些都可以在配置中心管理,在测试时动态修改即可;

在这种模式下,灰度服务的上线或者下线几乎是没有明显感知的,如果是相对简单的流程,由测试人员验收灰度层服务即可,如果是复杂的流程,放开一定比例的用户流量,流程观察没有问题后完成升级;

四、实践方案

1、流程设计

06.png

在灰度方案落地实践的过程中,通常客户端会携带路由规则的标识,从而将请求发送到指定服务,在规则无法正常匹配的时候,由主干服务处理,对于一些核心的开关标识在配置中心统一维护;

2、路由标识

标识获取

通常情况下,路由的标识是在请求头中携带的,这样比较方便统一管理,常用的传递格式如下:

  • 版本号统一路由:routeId:2.0.0,即所有请求优先在2.0.0分支执行;
  • 服务定制化路由:serverC:3.0.0,请求服务C时优先在3.0.0分支执行;

在微服务的组件中获取请求头的方式很多,比如Gateway网关中的路由过滤器,或者服务中的拦截器,都可以获取请求的相关参数信息,从而执行路由规则;

标识管理

自定义路由规则需要客户端标识,虽然获取请求中的标识并不复杂,但是将标识传递到路由规则中就涉及到上下文参数管理:

07.png

  • 写阶段:在过滤或拦截中获取路由标识,写入上下文容器;
  • 读阶段:路由时从容器中读取标识,基于配置信息执行规则;

请求从进入网关开始,在服务间通信时会涉及负载均衡的策略,在过滤或拦截器中将标识写到上下文容器,执行路由规则需要读取上下文容器,如果标识不存在则默认选择主干服务执行请求;

3、服务选中

微服务之间通信时,选中一个服务执行请求的逻辑比较复杂,尤其在灰度模式下涉及到对路由规则的改造,即策略指定的服务优先被选中;

08.png

  • 1、从注册中心查询相应服务的可用列表;
  • 2、基于路由规则,匹配符合请求标识的服务;
  • 3、对筛选的结果列表执行负载均衡,选中服务;

在整个路由机制中,会涉及到匹配规则自定义改造,从常规的手段来看,将版本的分支号加载到服务的元数据信息中,再结合服务名称或者IP地址,来实现对服务列表的多维度过滤,可以支撑大部分轻量级灰度策略的实现。

五、参考源码

应用仓库:
https://gitee.com/cicadasmile/butte-flyer-parent

组件封装:
https://gitee.com/cicadasmile/butte-frame-parent
相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
22天前
|
消息中间件 架构师 数据库
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
45岁资深架构师尼恩分享了一篇关于分布式事务的文章,详细解析了如何在10Wqps高并发场景下实现分布式事务。文章从传统单体架构到微服务架构下分布式事务的需求背景出发,介绍了Seata这一开源分布式事务解决方案及其AT和TCC两种模式。随后,文章深入探讨了经典ebay本地消息表方案,以及如何使用RocketMQ消息队列替代数据库表来提高性能和可靠性。尼恩还分享了如何结合延迟消息进行事务数据的定时对账,确保最终一致性。最后,尼恩强调了高端面试中需要准备“高大上”的答案,并提供了多个技术领域的深度学习资料,帮助读者提升技术水平,顺利通过面试。
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
|
16天前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力,支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业,ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战,实现云上云下统一管理,提升业务效率与稳定性。
|
18天前
|
消息中间件 SQL 中间件
大厂都在用的分布式事务方案,Seata+RocketMQ带你打破10万QPS瓶颈
分布式事务涉及跨多个数据库或服务的操作,确保数据一致性。本地事务通过数据库直接支持ACID特性,而分布式事务则需解决跨服务协调难、高并发压力及性能与一致性权衡等问题。常见的解决方案包括两阶段提交(2PC)、Seata提供的AT和TCC模式、以及基于消息队列的最终一致性方案。这些方法各有优劣,适用于不同业务场景,选择合适的方案需综合考虑业务需求、系统规模和技术团队能力。
133 7
|
23天前
|
机器学习/深度学习 存储 运维
分布式机器学习系统:设计原理、优化策略与实践经验
本文详细探讨了分布式机器学习系统的发展现状与挑战,重点分析了数据并行、模型并行等核心训练范式,以及参数服务器、优化器等关键组件的设计与实现。文章还深入讨论了混合精度训练、梯度累积、ZeRO优化器等高级特性,旨在提供一套全面的技术解决方案,以应对超大规模模型训练中的计算、存储及通信挑战。
57 4
|
26天前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
57 8
|
24天前
|
缓存 NoSQL Java
Spring Boot中的分布式缓存方案
Spring Boot提供了简便的方式来集成和使用分布式缓存。通过Redis和Memcached等缓存方案,可以显著提升应用的性能和扩展性。合理配置和优化缓存策略,可以有效避免常见的缓存问题,保证系统的稳定性和高效运行。
43 3
|
29天前
|
NoSQL 安全 PHP
hyperf-wise-locksmith,一个高效的PHP分布式锁方案
`hyperf-wise-locksmith` 是 Hyperf 框架下的互斥锁库,支持文件锁、分布式锁、红锁及协程锁,有效防止分布式环境下的竞争条件。本文介绍了其安装、特性和应用场景,如在线支付系统的余额扣减,确保操作的原子性。
30 4
|
1月前
|
NoSQL 算法 关系型数据库
分布式 ID 详解 ( 5大分布式 ID 生成方案 )
本文详解分布式全局唯一ID及其5种实现方案,关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
分布式 ID 详解 ( 5大分布式 ID 生成方案 )
|
2月前
|
存储 缓存 NoSQL
分布式架构下 Session 共享的方案
【10月更文挑战第15天】在实际应用中,需要根据具体的业务需求、系统架构和性能要求等因素,选择合适的 Session 共享方案。同时,还需要不断地进行优化和调整,以确保系统的稳定性和可靠性。
|
3月前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
3年前的云栖大会,我们发布分布式云容器平台ACK One,随着3年的发展,很高兴看到ACK One在混合云,分布式云领域帮助到越来越多的客户,今天给大家汇报下ACK One 3年来的发展演进,以及如何帮助客户解决分布式领域多云多集群管理的挑战。
阿里云容器服务 ACK One 分布式云容器企业落地实践

热门文章

最新文章