searchusermenu
  • 发布文章
  • 消息中心
点赞
收藏
评论
分享
原创

发布系统之灰度⼦系统设计初探

2023-06-27 06:51:17
72
0
  1. 背景

why:为什么要进行灰度发布?
ans: 互联网服务变动频繁,需要实现新老版本的平滑过度,减小新版本可能引入的bug对系统带来的负影响;并降低对测试的依赖,实现对部分用户、逻辑的局部测试,以便业务决策与技术回滚。

how: 如何进行灰度发布?
ans:将新版本发布到集群中少数实例上,并路由小部分流量到该小集群中,经过较长时间观察,确定无服务崩溃、监控告警以及客户投诉的情况下,滚动发布扩大灰度范围,最终将所有用户流量切换到新版本。

what:一个灰度系统是由哪些部分组成的?
ans:从功能上看,各灰度系统都要包含:灰度策略设置、流量打标、流量路由3种能力。

本文关注在不同需求场景下,灰度系统具体落地的技术设计。

  1. 主要挑战
  • 灰度方案选型
  • 灰度策略中止
  1. 原理分析

1.灰度系统基本组成:
从系统结构上看,一个典型的灰度系统需要实现:1.可以供业务/开发人员进行配置的灰度策略设置模块;2. 并把配置后的策略下发到loadbalance、gateway以及rpc通信的服务注册中心;3. 打标后的流量下发到各流量转发中间件,按照既定策略进行层层转发;4. 对应新/老系统数据统一回收到监控系统进行灰度效果比对; 

2.灰度配置策略:
配置策略属性:

  • 基于流量属性:如ip、网络分区等
  • 基于业务属性:如用户id、用户性别、设备id、染色tag等
  • 多条件混合配置:如ip%10==1的female用户
    属性的传输方式与实际的通信协议关联,如http/https协议中的header、cookie、GET/POST参数,或者是rpc协议中的config、tag、invoke参数。

配置下发策略:

  • 百分比下发,如从ip流量的10%-100%
  • 黑白名单

配置策略逻辑可以实现在:

  • 应用层,优点是灵活快速,缺点是灰度逻辑与业务逻辑耦合,在大型系统中可控性差
  • 流量调度层,优点是代码侵入性小、策略变更便捷,缺点是灵活度相对较低,且构建成本高

3.各种服务架构下的流量打标与分发

  • 单体服务的分布式架构:即单体分层服务分布式对外提供服务,无内部rpc调用链,可根据业务场景选择在C端(h5或APP等大前端)/S端打标。当涉及h5页面灰度升级时,前端从灰度系统中获取当前资源版本号,动态决定当前请求的前端资源版本;当涉及APP版本灰度时,一般会根据渠道、设备、或者用户信息,提醒命中策略的用户主动升级到灰度版本;服务端灰度时则根据兼容性,选择负载均衡层直接路由或接口多版本灰度,具体实现可以选择nginx+lua或基于redis的独立服务等,一种常见的服务端灰度时序图如下: 
  • 在分析主要挑战时,因为灰度策略调整导致的同一用户的策略变化导致的灰度不一致是我们主要要解决的问题,行业一般选择多版本方式解决上述问题,保证返回结果与当前请求携带的版本号一致,保证在更新通知同步到整个集群前,灰度环境依旧可用,一种变更的服务端灰度策略时序图如下:

 

  • 微服务的分布式架构:目前行业实现微服务架构的方式主要有应用层方案(如dubbo、spring cloud),不可变基础设施方案(k8s),服务网格方案(lstio)。在微服务架构的灰度系统中,核心关注的是对全链路的灰度策略实现,由于各种架构下的服务治理方式不同:应用层方案依赖服务注册中心,基础设施方案依赖描述资源 Deployment 中的 Pod 模板添加标签,服务网格方案依赖控制面打标与下发到边车过滤。以dubbo的染色路由标签为例,具体实现方式如下图: 

 

  1. 行业案例

首先是网络上公开的单体服务灰度案例,基本围绕接入层负载均衡组件进行配置和处理,常见的方案有:

  1. redis+lua从redis上读取配置,直接进行流量分发;
  2. 下发配置到配置中心,再由独立灰度服务组件提供过滤删选能力,服务入口处实现流量分发。

总结网络上公开的tencent cloud北极星灰度系统,阿里MSE灰度,有赞灰度系统,以及weibo路由标签系统,可以总结出:要实现微服务灰度,需结合具体的微服务框架实现,方案比对表如下:

公司名

系统名

适用服务架构

灰度方案

支持灰度策略

灰度核心组件

应用场景

阿里云

ALB灰度

单体服务

nginx+lua分流

7层协议http header/cookie/服务器组

ALB负载均衡

仅在服务入口处进行流量分发的场景

阿里云

基于ASM灰度

k8s为基础设施

kubectl使用RollingUpdate策略

ASM网关标签

Iostio+yaml文件

基于阿里云k8s部署的微服务集群

阿里云

基于MSE灰度

应用层微服务架构(可选dubbo/spring cloud)

路由标识

自定义流量标识tag

服务发现组件

使用应用层微服务架构的集群

Ucloud

serviceMesh灰度系统

基于serviceMesh的微服务

Istio+Envoy边车

账号、http、grpc协议

服务发现组件

使用serviceMesh运维的微服务集群

weibo

alchemy

单体服务

nginx+lua+redis

7层协议header/cookie/params

7层负载均衡

仅在服务入口处进行流量分发的场景

  1. 结论
  1. 在灰度方案上,技术选型取决于系统整体的服务架构,共同点是在流量分发组件上进行基础改造:单体分层服务关注入口lb,应用层微服务关注入口gatway与服务发现组件,基础设施微服务关注控制面deploy,service mesh微服务关注配置下发与sidecar;
  2. 在灰度过程中出现线上错误,直接回滚会导致已灰度用户错误,因此所有灰度系统都需要增加灰度中止能力,即已灰度的特征流量仍保持在灰度环境中,所有新增特征流量不再进入灰度环境;
  3. 灰度操作本身的高效依托于灰度监控的完整,因此结合灰度系统搭建,提供核心参数比对的监控系统也需要及时构建;
  1. 参考

如何设计可靠的灰度方案
深入剖析全链路灰度内幕
使用ALB实现灰度发布
基于ASM实现全链路灰度发布
微服务引擎MSE
灰度发布GrayRelease/Dark launch详解

 

 

0条评论
作者已关闭评论
范****平
3文章数
0粉丝数
范****平
3 文章 | 0 粉丝
范****平
3文章数
0粉丝数
范****平
3 文章 | 0 粉丝
原创

发布系统之灰度⼦系统设计初探

2023-06-27 06:51:17
72
0
  1. 背景

why:为什么要进行灰度发布?
ans: 互联网服务变动频繁,需要实现新老版本的平滑过度,减小新版本可能引入的bug对系统带来的负影响;并降低对测试的依赖,实现对部分用户、逻辑的局部测试,以便业务决策与技术回滚。

how: 如何进行灰度发布?
ans:将新版本发布到集群中少数实例上,并路由小部分流量到该小集群中,经过较长时间观察,确定无服务崩溃、监控告警以及客户投诉的情况下,滚动发布扩大灰度范围,最终将所有用户流量切换到新版本。

what:一个灰度系统是由哪些部分组成的?
ans:从功能上看,各灰度系统都要包含:灰度策略设置、流量打标、流量路由3种能力。

本文关注在不同需求场景下,灰度系统具体落地的技术设计。

  1. 主要挑战
  • 灰度方案选型
  • 灰度策略中止
  1. 原理分析

1.灰度系统基本组成:
从系统结构上看,一个典型的灰度系统需要实现:1.可以供业务/开发人员进行配置的灰度策略设置模块;2. 并把配置后的策略下发到loadbalance、gateway以及rpc通信的服务注册中心;3. 打标后的流量下发到各流量转发中间件,按照既定策略进行层层转发;4. 对应新/老系统数据统一回收到监控系统进行灰度效果比对; 

2.灰度配置策略:
配置策略属性:

  • 基于流量属性:如ip、网络分区等
  • 基于业务属性:如用户id、用户性别、设备id、染色tag等
  • 多条件混合配置:如ip%10==1的female用户
    属性的传输方式与实际的通信协议关联,如http/https协议中的header、cookie、GET/POST参数,或者是rpc协议中的config、tag、invoke参数。

配置下发策略:

  • 百分比下发,如从ip流量的10%-100%
  • 黑白名单

配置策略逻辑可以实现在:

  • 应用层,优点是灵活快速,缺点是灰度逻辑与业务逻辑耦合,在大型系统中可控性差
  • 流量调度层,优点是代码侵入性小、策略变更便捷,缺点是灵活度相对较低,且构建成本高

3.各种服务架构下的流量打标与分发

  • 单体服务的分布式架构:即单体分层服务分布式对外提供服务,无内部rpc调用链,可根据业务场景选择在C端(h5或APP等大前端)/S端打标。当涉及h5页面灰度升级时,前端从灰度系统中获取当前资源版本号,动态决定当前请求的前端资源版本;当涉及APP版本灰度时,一般会根据渠道、设备、或者用户信息,提醒命中策略的用户主动升级到灰度版本;服务端灰度时则根据兼容性,选择负载均衡层直接路由或接口多版本灰度,具体实现可以选择nginx+lua或基于redis的独立服务等,一种常见的服务端灰度时序图如下: 
  • 在分析主要挑战时,因为灰度策略调整导致的同一用户的策略变化导致的灰度不一致是我们主要要解决的问题,行业一般选择多版本方式解决上述问题,保证返回结果与当前请求携带的版本号一致,保证在更新通知同步到整个集群前,灰度环境依旧可用,一种变更的服务端灰度策略时序图如下:

 

  • 微服务的分布式架构:目前行业实现微服务架构的方式主要有应用层方案(如dubbo、spring cloud),不可变基础设施方案(k8s),服务网格方案(lstio)。在微服务架构的灰度系统中,核心关注的是对全链路的灰度策略实现,由于各种架构下的服务治理方式不同:应用层方案依赖服务注册中心,基础设施方案依赖描述资源 Deployment 中的 Pod 模板添加标签,服务网格方案依赖控制面打标与下发到边车过滤。以dubbo的染色路由标签为例,具体实现方式如下图: 

 

  1. 行业案例

首先是网络上公开的单体服务灰度案例,基本围绕接入层负载均衡组件进行配置和处理,常见的方案有:

  1. redis+lua从redis上读取配置,直接进行流量分发;
  2. 下发配置到配置中心,再由独立灰度服务组件提供过滤删选能力,服务入口处实现流量分发。

总结网络上公开的tencent cloud北极星灰度系统,阿里MSE灰度,有赞灰度系统,以及weibo路由标签系统,可以总结出:要实现微服务灰度,需结合具体的微服务框架实现,方案比对表如下:

公司名

系统名

适用服务架构

灰度方案

支持灰度策略

灰度核心组件

应用场景

阿里云

ALB灰度

单体服务

nginx+lua分流

7层协议http header/cookie/服务器组

ALB负载均衡

仅在服务入口处进行流量分发的场景

阿里云

基于ASM灰度

k8s为基础设施

kubectl使用RollingUpdate策略

ASM网关标签

Iostio+yaml文件

基于阿里云k8s部署的微服务集群

阿里云

基于MSE灰度

应用层微服务架构(可选dubbo/spring cloud)

路由标识

自定义流量标识tag

服务发现组件

使用应用层微服务架构的集群

Ucloud

serviceMesh灰度系统

基于serviceMesh的微服务

Istio+Envoy边车

账号、http、grpc协议

服务发现组件

使用serviceMesh运维的微服务集群

weibo

alchemy

单体服务

nginx+lua+redis

7层协议header/cookie/params

7层负载均衡

仅在服务入口处进行流量分发的场景

  1. 结论
  1. 在灰度方案上,技术选型取决于系统整体的服务架构,共同点是在流量分发组件上进行基础改造:单体分层服务关注入口lb,应用层微服务关注入口gatway与服务发现组件,基础设施微服务关注控制面deploy,service mesh微服务关注配置下发与sidecar;
  2. 在灰度过程中出现线上错误,直接回滚会导致已灰度用户错误,因此所有灰度系统都需要增加灰度中止能力,即已灰度的特征流量仍保持在灰度环境中,所有新增特征流量不再进入灰度环境;
  3. 灰度操作本身的高效依托于灰度监控的完整,因此结合灰度系统搭建,提供核心参数比对的监控系统也需要及时构建;
  1. 参考

如何设计可靠的灰度方案
深入剖析全链路灰度内幕
使用ALB实现灰度发布
基于ASM实现全链路灰度发布
微服务引擎MSE
灰度发布GrayRelease/Dark launch详解

 

 

文章来自个人专栏
开发实录
3 文章 | 1 订阅
0条评论
作者已关闭评论
作者已关闭评论
0
0