🚀 我们把前端灰度发布做成了一套“中台能力”
从分支混乱到多版本并行，我们踩过的坑，比代码还多。
一、真正的痛点，不在代码
很多人以为前端灰度很简单：
不就是加个 Header 吗？
但当你团队规模变大，需求并行增多，你会发现真正的问题是：
❌ 测试环境代码永远不纯
两个 feature 同时要上测试：
featureA
featureB
上线时间不同，但都要进测试环境。
于是只能：
merge A + merge B → 发布
测试同学测的是“未来版本”。
上线风险指数级放大。
❌ 分支模型越来越复杂
- 临时合并分支
- 防污染分支
- 测试专用分支
- 预发布临时分支
Git 结构越来越怪。
❌ SSR 根本做不了灰度
SPA 静态资源还能目录隔离。
但 SSR？
- 多 Docker 实例
- 动态 IP
- 服务注册发现
- 负载均衡
复杂度直接上一个量级。
二、我们抽象出了 4 个核心能力
我们没有做“一个灰度方案”。
我们做的是一套：
前端灰度发布中台能力
包含四层：
- 访问分流模型
- 资源隔离模型
- 构建标识注入模型
- 服务注册发现模型
三、SPA 灰度设计
核心思想：资源目录隔离
4
目录结构：
/project/
/prod/
/default/
/featureA/
/featureB/
访问流程：
Client
↓
Header: fe-grayVersion=featureA
↓
Gateway
↓
拼接目录
↓
返回对应 index.html
关键构建代码：
publicPath: `${saFeUrl}/${pkg.name}/${resEnv}${feGrayVersion}`
✔ 多版本可长期共存
✔ 不依赖 Git 合并
✔ 不需要多域名
四、真正的难点：SSR 灰度
SPA 解决的是“文件隔离”。
SSR 解决的是“服务隔离”。
SSR 架构模型
4
核心组件：
- 服务注册：Nacos
- 网关转发
- 加权轮询负载均衡
- 健康探针
流程
Client
↓
Header: fe-grayVersion
↓
Gateway
↓
订阅 Nacos
↓
根据 metadata.feGrayVersion 过滤实例
↓
负载均衡
↓
Proxy
每个灰度版本：
- 一个 Docker 镜像
- 一个注册实例
- 一个 metadata 标识
我们实现的负载均衡算法
平滑加权轮询：
currentWeight += weight
选最大
减去 totalWeight
这是工业级算法。
五、DevOps 才是关键一环
灰度不是运行时问题。
而是构建问题。
构建流程：
DevOps 开启灰度
↓
注入 devops.json
↓
合并 env-cmdrc
↓
注入环境变量
↓
构建
部署规则：
| 灰度开关 | 部署路径 |
|---|---|
| 关闭 | /prod |
| 开启 | /prod/default |
| 指定版本 | /prod/featureA |
六、灰度上线后，发生了什么？
✔ 多版本真正并行
featureA
featureB
default
prod
长期共存。
✔ 分支模型大幅简化
测试不再依赖 merge。
✔ SSR 首次支持灰度
很多公司只做了 SPA 灰度。
SSR 是我们最大的技术挑战。
七、未来升级方向
下一步准备做：
- 流量比例灰度（10% → 100%）
- 用户 ID 稳定灰度
- 自动异常回滚
- 灰度 + AB 实验融合
结论
灰度发布不是一个发布技巧，而是一种架构能力。
当你的系统支持：
- 多版本并行
- 动态分流
- 自动回滚
- 无侵入扩展
它就不再是一个“发布方案”，
而是一套真正的：
前端发布中台能力。
