基于SpringCloud及Nacos灰度发布方案

发表于 | 分类于 | | 阅读量
字数统计: 1.8k 字 | 阅读时长 ≈ 6 分钟

背景及概述

背景

公司在去年上线了蓝绿发布，大家也摆脱了发版加班的苦恼，在日益业务增长的情况下，服务数和节点数不断增加，由于是蓝绿版本隔离的颗粒为整套环境，成本相对来说比较高，因此本次将设计灰度发布流程来实现降本增效的目的。将版本隔离的颗粒的缩小到某个服务某个节点。

灰度（染色）方案目标如下：

  1. 对测试环境进行逻辑隔离：减少硬件成本消耗、减少部署测试环境人力消耗、减少发布版后同步环境的人力消耗以及沟通成本，提高测试环境的可维护性，提高测试环境的并行项目数，提高测试环境提早暴露问题的可能性。
  2. 平滑上线：可在真实的生产环境做最后的功能测试以及兼容性验证，并且可以通过服务上下线的方式平滑上线及回滚。
  3. 可进行A/BTest：打好公司进行数字化验证产品方案的基础，可以让不同用户体验不同版本，来分析哪个需求更加吸引用户使用。
  4. 多版本并行上线：提高团队整体上线效率，在生产环境无需进行串行化发布等待。
  5. 回收线上蓝绿一半资源：节省成本。
  6. 在健康业务试点并逐步展开，最终形成统一方案输出到全公司业务使用。

功能概述

保证线上系统平稳的情况下，采用尽可能代码侵入性小的方案，进行根据特定参数以及特定规则进行单个服务单个节点的流量分配。

需求点

灰度发布功能清单

非功能性需求

扩展性

通过SpringBoot Starter的方式实现可插拔插件使用，需要使用灰度的时候引入，提取关键版本选择策略及灰度上下文为core包，如后续具体集成其他框架如注册中心只需要新建starter实现服务发现接口即可。

通过适配器模式适配各框架服务实例对象，抽取灰度策略core

可用性

保证每个服务必定有default的环境可用，当服务的所有基线版本不健康需要发送企业微信报警机器人，保证每次请求必定有响应。

性能

所有流量标记通过请求头传递，并维护在线程的Threadlocal中，新增逻辑均为内存操作，不影响原系统性能

可测试性

目前采用记录日志的方式展示整条请求链的版本访问链路，方便测试查看一条请求链分别请求了哪些版本，后续可支持根据requestId进行链路可视化

整体设计

灰度发布整体设计

  • 基线版本：生产环境的最稳定版本，当没有灰度实例的时候默认访问基线版本，因此需要保证每个服务都有基线版本存活，需要做监控，当某个服务所有基线版本不健康的时候需要发送报警通知。
  • 灰度版本：灰度发布版本，根据用户的属性经过负载均衡访问此版本，可用于测试，体验新功能使用。
中间件 是否需要隔离 灰度影响及解决方案
注册中心 ✘ 无需处理，通过项目启动时候注入的元数据进行区分版本
配置中心(需要调研是否支持灰度) ✘ 无需处理，隔离维护性太差，改动老配置场景较少，需要开发考虑兼容性
Redis ✘ 无需处理，隔离维护性太差，大多缓存的Key和业务数据绑定，业务数据和用户数据绑定，灰度目前根据用户维护隔离一定程度上实现了隔离，若非业务数据的配置数据，应当考虑放入配置中心去
Mysql ✘ 无需处理，灰度即线上环境应当保证数据共用
Mongo ✘ 无需处理，灰度即线上环境应当保证数据共用
定时任务 ✘ 保证生产定时任务全部走default版本，定时任务都是以接口的形式写在业务服务中，若有访问灰度的需求，如：需要测试，可配置灰度请求头访问定时任务接口
消息队列 ✘ 通过Mq网络代理服务EventCenter，保证什么环境生产的消息就被什么环境消费，如灰度环境下线即表示已合入基线版本，即访问基线版本即可

存储设计

使用TransmittableThreadLocal技术，保证父子线程间的灰度上线文传递

各模块设计

横向流量泳道图

HTTP流量泳道图

消息队列流量泳道图

消息队列流量泳道图

Event-Center服务

  1. Event-Center服务是一个网络代理服务，仅做调度，代理了MQ的流量，使得开发者无需关注mq的流量归属。正常consumer的逻辑中也会有远程调用。
  2. Event-Center无需关注使用哪种Mq客户端，如Kafka、RocketMq只需要在服务中引入官方的客户端即可消费消息
  3. 加了中间代理层是否会影响性能？会轻微影响性能，但对于异步消息来说，性能不是瓶颈所在。
  4. Event-Center会不会成为消费能力瓶颈？不会，以往的消费者都是绑定在业务进程中，消费能力受制于业务进程的消费者线程数，抽离出独立服务之后为无状态服务，当消费能力不足的时候可以横向扩展。当然如果某个消费者流量过高，如IM服务，可以独立出im-eventcenter服务进行水平扩展
  5. Event-Center保证开发自己调试的时候，不会因业务服务被别人本地启动导致消息丢失，排查半天，一定程度上提高了工作效率。
  6. Event-Center服务消费者调度统一处理，符合单一职责，可以做一些mq逻辑的统一处理，如日志统一打印等额外操作。使得功能更加内聚。
  7. Event-Center并不适用于所有场景，改造成本相对比较大，但也是可以考虑的一种方案

统一规则入口

统一规则入口

CICD

CICD

上线方案

V1 V2为当前蓝绿环境
beta1 beta2 为灰度版本

  1. 生产假设V2为正式环境，保持V2版本流量不变，将灰度改造的项目发至V1环境并且全量发布default基线版本。
  2. 部署APISIX上线，更新upstream为V1的gateway
  3. 测试配置host文件，来测试V1环境的灰度版本，先将default版本基础功能进行回归测试
  4. 发布灰度的bete1版本服务，并配置一些用户到beta1、2、3环境，测试流量走向是否正常
  5. 测试完毕，结合Argo Rollout系统分析，晚上将ELB流量全量切入V1蓝绿环境，此时用户流量全部默认走基线版本，观察情况，蓝绿V2环境作为备份环境，如有大面积问题直接切入V2。若无则上线完毕

上线方案