All checks were successful
Publish to Confluence / confluence (push) Successful in 41s
95 lines
2.2 KiB
Markdown
95 lines
2.2 KiB
Markdown
<!-- Space: qifu -->
|
||
<!-- Parent: 后端技术&知识&规范 -->
|
||
<!-- Parent: 技术方案 -->
|
||
<!-- Parent: 基建 -->
|
||
<!-- Parent: 02-技术方案 -->
|
||
<!-- Title: 20250401-全链路灰度方案 -->
|
||
|
||
<!-- Macro: :anchor\((.*)\):
|
||
Template: ac:anchor
|
||
Anchor: ${1} -->
|
||
<!-- Macro: \!\[.*\]\((.+)\)\<\!\-\- width=(.*) \-\-\>
|
||
Template: ac:image
|
||
Url: ${1}
|
||
Width: ${2} -->
|
||
<!-- Macro: \<\!\-\- :toc: \-\-\>
|
||
Template: ac:toc
|
||
Printable: 'false'
|
||
MinLevel: 2
|
||
MaxLevel: 4 -->
|
||
<!-- Include: 杂项/声明文件.md -->
|
||
|
||
<!-- :toc: -->
|
||
|
||
# 全链路灰度方案
|
||
|
||
## 一、现状
|
||
|
||
### 业务背景
|
||
|
||
现有平台多项目多团队同时进行时,各个团队之间的服务发布互相干扰,无法实现有效的测试隔离
|
||
|
||
## 二、需求
|
||
|
||
### 业务需求
|
||
|
||
开发泳道管理,支持多项目、多任务并行开发互不干扰
|
||
|
||
## 三、设计目标
|
||
|
||
### 实现的功能
|
||
|
||
- 灰度服务发布
|
||
- 流量灰度路由
|
||
- 全链路灰度(定时任务、MQ、Redis、RDB 暂时不持支)
|
||
|
||
## 四、方案对比
|
||
### 方案一、Spring Cloud + Nacos + 负载均衡器实现全链路灰度发布
|
||
https://zhuanlan.zhihu.com/p/29869400585
|
||
|
||
#### 优点
|
||
- 实现流程不是很复杂
|
||
- 支持响应式编程,灵活性高
|
||
|
||
#### 缺点
|
||
- 需要代码实现
|
||
|
||
### 方案二、Istio 灰度方案
|
||
https://www.kubesphere.io/zh/docs/v3.3/pluggable-components/service-mesh/
|
||
https://istio.io/latest/zh/docs/overview/what-is-istio/
|
||
|
||
#### 优点
|
||
- 云原生
|
||
- 无关技术语言
|
||
- 扩展性好
|
||
- 大团队维护
|
||
|
||
#### 缺点
|
||
- 维护成本
|
||
|
||
## 五、方案选择
|
||
基于一下几个需求
|
||
- 实现灰度发布
|
||
- 运维人员只有一个
|
||
- 暂时没有过多的流量治理需求
|
||
- 技术栈只有java
|
||
|
||
所以建议先使用方案一、后续运维团队增加,流量治理需求增加,运维人员熟悉 istio 后再做迁移部署
|
||
|
||
## 六、实施步骤
|
||
### 一、核心包扩展灰度链路包
|
||
- 快速集成
|
||
- 无需改动业务代码
|
||
- 后续上 Istio 后可以快速下架
|
||
|
||
### 二、业务集成
|
||
- 业务引入灰度链路包
|
||
|
||
### 三、Pipeline 添加对应的灰度参数
|
||
- jenkins 添加对应的灰度 pipeline
|
||
- 灰度 pipeline 添加对应的参数
|
||
|
||
### 四、部署测试
|
||
|
||
### 五、运维人员开始熟悉 Istio
|