4. 蓝绿发布在门户中的整体架构:前端负载均衡器、后端服务组、配置中心、健康检查模块的协作关系
在发布工程自助门户中,蓝绿发布并非孤立的功能模块,而是由前端负载均衡器、后端服务组、配置中心和健康检查模块四个核心组件紧密协作构成的闭环系统。理解它们之间的数据流与控制流,是设计可靠发布流程的基础。
4.1 核心组件职责矩阵
下表梳理了每个组件在蓝绿发布生命周期中的核心职责与关键交互对象:
| 组件 | 核心职责 | 关键交互对象 | 状态持久化位置 |
|---|---|---|---|
| 前端负载均衡器 | 流量分发、蓝绿组切换、会话保持 | 后端服务组、健康检查模块 | 负载均衡器自身配置 / API Gateway |
| 后端服务组 | 运行应用实例、暴露健康端点、上报状态 | 健康检查模块、配置中心 | 服务注册中心 / K8s Endpoint |
| 配置中心 | 存储发布策略、版本标签、开关配置 | 门户后端、负载均衡器、服务组 | Etcd / Nacos / Consul |
| 健康检查模块 | 探活、指标采集、熔断决策、结果上报 | 后端服务组、负载均衡器、配置中心 | 内存状态 + 配置中心持久化 |
4.2 协作关系架构图
下图展示了蓝绿发布在门户中的完整协作拓扑,重点突出流量切换与验证阶段的数据流向:
4.3 流量切换与验证的协作流程
一次完整的蓝绿发布流量切换,遵循以下五步协作流程:
- 配置下发:门户后端将新版本标签、路由权重(如蓝:绿 = 90:10)写入配置中心。
- 策略生效:负载均衡器监听配置中心变更,实时更新路由表,开始按权重分发流量。
- 健康检查:健康检查模块以固定间隔(如 5s)对蓝绿两组所有实例执行 HTTP/TCP 探活。
- 熔断反馈:若绿组错误率超过阈值(如 5%),健康检查模块向负载均衡器发送熔断信号,自动将绿组权重降为 0。
- 切换确认:验证通过后,门户触发全量切换,负载均衡器将 100% 流量导向绿组,蓝组进入待销毁状态。
关键设计原则:健康检查模块与负载均衡器之间采用异步事件驱动通信,避免同步阻塞。健康检查结果先写入配置中心,负载均衡器通过 Watch 机制感知变化,确保切换过程不丢失请求。
4.4 组件间接口契约
为保证协作的标准化,各组件之间定义了明确的接口契约:
| 交互方向 | 协议 / 接口 | 数据格式 | 超时 / 重试策略 |
|---|---|---|---|
| 负载均衡器 → 服务组 | HTTP / gRPC | 标准请求/响应 | 5s 超时,2 次重试 |
| 服务组 → 健康检查 | HTTP GET /health | JSON: {"status":"UP","version":"v2.4.0"} | 3s 超时,不重试 |
| 健康检查 → 配置中心 | gRPC Stream / HTTP PUT | JSON: {"group":"green","healthy":false,"reason":"high_error_rate"} | 2s 超时,3 次重试 |
| 配置中心 → 负载均衡器 | Watch / Long Polling | 配置变更事件 | 30s 长连接保活 |
4.5 典型异常场景与协作处理
下表总结了三种常见异常场景下,各组件的协作处理方式:
| 异常场景 | 健康检查模块行为 | 负载均衡器行为 | 配置中心行为 |
|---|---|---|---|
| 绿组实例批量故障 | 检测到 /health 返回 503,上报熔断事件 | 收到熔断信号,将绿组权重降为 0,流量全量切回蓝组 | 持久化熔断状态,触发告警通知 |
| 配置中心短暂不可用 | 使用本地缓存策略,继续按上次配置探活 | 保持当前路由表不变,等待配置中心恢复 | 恢复后推送全量配置快照 |
| 蓝组缩容导致容量不足 | 检测到蓝组实例数低于最小阈值,发出容量告警 | 自动降低蓝组权重,避免过载 | 记录容量事件,触发弹性伸缩流程 |
生产建议:在配置中心与负载均衡器之间引入本地缓存层,可有效防止配置中心抖动导致的路由表频繁变更。推荐使用
etcd + confd 或 Nacos + Spring Cloud Gateway 的组合方案。
4.6 协作关系时序图
下图以时间轴形式展示一次完整的蓝绿发布流量切换与验证的协作过程:
时序关键点:在 T2 到 T3 阶段,健康检查模块必须完成至少 3 次连续成功探活,才能向负载均衡器发送“验证通过”信号。这可以避免因网络抖动导致的误判。