发布系统：发布架构设计与实现

「滚动 / 蓝绿 / 金丝雀 / 灰度发布的架构设计与实现总览」。

用统一的架构视角来讲：流量在哪切、版本如何共存、如何回滚、如何落地实现。

一、统一架构抽象（先立模型）

无论哪种发布方式，本质都是 4 层结构：

┌─────────────────────────┐
│        用户流量          │
└──────────┬──────────────┘
           │
┌──────────▼──────────────┐
│  流量控制层               │ ← 关键
│  (LB / Ingress / GW)    │
└──────────┬──────────────┘
           │
┌──────────▼──────────────┐
│  应用运行层              │
│  (多版本实例共存)         │
└──────────┬──────────────┘
           │
┌──────────▼──────────────┐
│  数据与依赖层             │
│  (DB / Cache / MQ)      │
└─────────────────────────┘

👉 区别只在：

是否多版本共存
流量如何切
切流是否原子
回滚成本

二、滚动发布（Rolling）——最基础实现

架构设计

LB
 │
 ├─ Pod v1
 ├─ Pod v1
 ├─ Pod v2   ← 新版本逐步替换
 └─ Pod v1

关键特征

无多版本流量控制
版本通过“实例替换”完成
对用户透明

实现方式

Kubernetes

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1

核心实现点

readinessProbe 控制接流量
优雅关闭（SIGTERM）
滚动节奏控制

回滚

重新 rollout 到旧版本
成本：中等（需要时间）

三、蓝绿发布（Blue-Green）——双环境切流

架构设计

            LB
             │
     ┌───────┴────────┐
     │                │
 蓝环境 v1        绿环境 v2

关键特征

两套完整环境
一次切流
单一版本对外服务

实现方式

K8S 示例

两个 Deployment：app-blue / app-green
一个 Service
切换 Service selector 或 Ingress backend

回滚

秒级切回
风险极低

四、金丝雀发布（Canary）——小流量试运行

架构设计

                 LB / Gateway
                        │
        ┌───────────────┴───────────────┐
        │                               │
  Stable v1 (95%)                Canary v2 (5%)

关键特征

多版本并存
按流量比例
实时观察

实现方式

网关层

Nginx upstream 权重
Ingress annotations

Service Mesh（高级）

Istio VirtualService
精细到请求级别

回滚

权重 -> 0
极快

五、灰度发布（Gray）——策略总称（最灵活）

架构设计（策略化）

        Gateway
           │
   ┌───────┼────────┐
   │       │        │
用户A   用户B    用户C
 v2      v1       v2

核心特征

规则驱动
用户维度
长期多版本

实现方式

1️⃣ 网关规则

Header / Cookie / UID
地域 / IP

2️⃣ 应用内 Feature Toggle

配置中心
动态开关

3️⃣ Service Mesh

标签路由
多条件组合

回滚

规则撤销
无需回滚代码

六、四种发布方式对比（架构视角）

维度	滚动	蓝绿	金丝雀	灰度
多版本共存	❌	❌	✅	✅
流量控制	❌	原子	比例	规则
回滚速度	中	秒级	快	极快
实现复杂度	低	中	高	最高
成本	低	高	中	中

七、统一的发布系统设计（推荐架构）

Git
 ↓
CI/CD
 ↓
制品库
 ↓
部署层（K8S / VM）
 ↓
流量治理（Ingress / Gateway / Mesh）
 ↓
监控 & 自动回滚

发布策略 = 参数化配置

八、数据库 & 状态设计（最容易翻车）

所有发布方式 必须满足：

向前兼容
两阶段发布
禁止破坏性变更
数据迁移独立执行

九、自动回滚设计（高级）

触发条件：

错误率 ↑
延迟 ↑
核心业务指标 ↓

实现：

Prometheus + Alertmanager
CI/CD 回滚钩子
Service Mesh 动态权重

十、选型决策树（非常实用）

是否允许双环境？
 ├─ 是 -> 蓝绿
 └─ 否
    ├─ 是否支持精细流量？
    │    ├─ 是 -> 金丝雀 / 灰度
    │    └─ 否 -> 滚动

总结（给架构设计用）

滚动解决“不停机”

蓝绿解决“可回滚”

金丝雀解决“先验证”

灰度解决“可控风险”