版本发布策略：灰度、金丝雀与蓝绿部署
为什么要关注发布策略
当您上线一个新版本的应用时，最怕的不是"新版本有 Bug"，而是"新版本的 Bug 影响了所有用户"。传统的停服更新——全量发布——一旦出了问题，回滚窗口长、影响面大。
矩尺平台作为流量的入口，天然具备流量调度能力。利用服务器池的权重调节、虚拟组、分发规则等功能，您可以在不改变应用代码、不增加额外组件的前提下，实现精细化的版本发布策略。
三种策略概览
| 策略 | 核心思路 | 切换方式 | 回滚速度 | 适用场景 |
|---|---|---|---|---|
| 灰度发布 | 按条件筛选一小部分用户先体验新版本 | 按规则（IP、Header、Cookie 等） | 修改规则即回滚 | 按用户属性逐步放开 |
| 金丝雀发布 | 按比例将少量流量引向新版本 | 按权重百分比 | 权重调回 0% 即回滚 | 按流量比例验证新版本稳定性 |
| 蓝绿部署 | 准备两套完整环境，一键整体切换 | 全量切换 | 切回旧环境即回滚 | 需要瞬间全量切换的场景 |
三者的核心区别在于流量切换的粒度：灰度是按条件选人，金丝雀是按比例分流，蓝绿是全量切换。
矩尺平台相关能力
在介绍具体配置之前，先梳理矩尺平台中与发布策略相关的功能：
| 平台能力 | 位置 | 作用 | 适用策略 |
|---|---|---|---|
| 节点权重 | 服务器池 → 负载均衡算法选择"加权轮询"或"加权最小连接数" | 在同一个服务器池内，按权重比例将流量分给不同节点。权重 0 的节点不收流量 | 金丝雀（同池内新旧节点配不同权重） |
| 虚拟组 | 服务器池 → 开启"虚拟组" | 将节点分组，组间按权重分配流量。节点故障时该组权重自动下调，其余组承接流量 | 金丝雀（同池内新旧节点分成两组） |
| 分发规则 | SLB 本地负载 → 分发规则 | 按 URL、Host、Header、Cookie、源 IP 等条件匹配请求，转发到不同服务器池 | 灰度（按条件分流到不同池） |
| 分发策略 | 分发规则中绑定 | 定义具体的匹配条件（来源 IP、Cookie 值、Header 值等） | 灰度 |
| 优先级分组 | 服务器池 → 节点优先级 | 高优先级节点可用时，低优先级节点不收流量 | 蓝绿（备环境设为低优先级，切换时提升） |
| 温暖上线 | 服务器池 → 节点配置 | 节点上线后流量逐步增加，避免瞬时冲击 | 金丝雀的补充（新节点上线时平滑过渡） |
策略一：灰度发布（按条件筛选用户）
原理
灰度发布的核心是按条件筛选用户——比如让内网 IP 段的用户、或者 Cookie 中带有 test=true 的用户先访问新版本，其余用户继续使用旧版本。
配置方式：分发规则 + 两个服务器池
准备两个服务器池：
app-v1-pool：旧版本服务器（节点运行 v1 版本）app-v2-pool：新版本服务器（节点运行 v2 版本）
在虚拟服务中创建以下分发规则：
规则 1（高优先级）：
分发策略：源地址 = 10.0.0.0/8（内网IP段）
处理方式：HTTP代理 → app-v2-pool
说明：内网用户访问新版本 v2
默认分发规则：
处理方式：HTTP代理 → app-v1-pool
说明：其余所有用户继续使用旧版本 v1灰度用户的选择方式
分发策略支持多种匹配条件，您可以灵活定义灰度范围：
- 源地址：指定公司内网 IP 段、特定城市 IP
- Cookie：前端给部分用户种上
canary=true的 Cookie - Header：客户端请求带
X-Version: v2的自定义 Header - URL 参数：URL 中带有
?version=v2参数
灰度放量过程
阶段 1：仅内网 IP → v2
阶段 2：内网 IP + 带有 Cookie canary=true 的用户 → v2
阶段 3：内网 IP + 所有带有指定 Header 的用户 → v2
阶段 4：全量切换到 v2（修改默认分发规则的目标服务器池）每个阶段只需修改分发策略中的匹配条件，无需重启服务或修改应用。
策略二：金丝雀发布（按比例分流）
原理
金丝雀发布的核心是按比例将一小部分流量引向新版本，比如新版本只承载 10% 的流量。观察一段时间（如几小时）确认无异常后，逐步增加新版本的比例，直到 100%。
配置方式一：同池内权重调节（最简单）
在同一个服务器池中，将新旧版本的节点放在一起，通过节点权重控制比例：
适用前提：使用加权轮询或加权最小连接数算法。
服务器池：app-pool
├── 节点 N1（v1 旧版）：权重 = 90
├── 节点 N2（v1 旧版）：权重 = 90
├── 节点 N3（v2 新版）：权重 = 10
└── 节点 N4（v2 新版）：权重 = 10
新版本流量占比 = (10 + 10) / (90 + 90 + 10 + 10) = 10%放量过程：
| 阶段 | N1(v1) | N2(v1) | N3(v2) | N4(v2) | v2 流量占比 |
|---|---|---|---|---|---|
| 金丝雀验证 | 90 | 90 | 10 | 10 | 10% |
| 扩大验证 | 70 | 70 | 30 | 30 | 30% |
| 半数切换 | 50 | 50 | 50 | 50 | 50% |
| 全量上线 | 0 | 0 | 50 | 50 | 100%（旧节点可下线） |
修改权重后即时生效，无需变更执行。
配置方式二：虚拟组（推荐）
如果新旧版本各有多个节点，用虚拟组管理更方便——按组调权重，组内节点权重自动均分。
在服务器池中开启"虚拟组"，创建两个组：
虚拟组 A（旧版）：权重 90%，组内节点 N1, N2
虚拟组 B（新版）：权重 10%，组内节点 N3, N4放量过程： 逐步调整虚拟组 B 的权重：10% → 30% → 50% → 100%。
虚拟组的优势：
- 批量调权重：修改组权重即可，不用逐个节点修改
- 故障自动调整：如果新版组中有节点宕机，该组权重自动下调，不会让剩余的单个新版节点承载过多流量
配置方式三：分发规则 + 两个服务器池（与灰度结合）
将灰度与金丝雀结合：建立两个服务器池，用分发规则按比例引导。但矩尺分发规则本身不支持百分比分流，因此纯百分比场景建议使用方式一或方式二。
温暖上线的配合
金丝雀发布中，新节点刚上线时可以开启温暖上线，让新节点的流量在"温暖时间"内从 0 缓慢增长到目标权重对应的量，避免冷启动的新节点被突然涌入的流量打垮。
策略三：蓝绿部署（两套环境全量切换）
原理
蓝绿部署的核心是准备两套完整的环境：
- 蓝色环境：当前正在运行的生产环境（旧版本）
- 绿色环境：与蓝色环境完全对等的另一套环境（新版本），已部署并通过测试
切换时，将 100% 的流量从蓝色瞬间切到绿色。如果绿色出问题，瞬间切回蓝色。
配置方式一：分发规则切换服务器池（推荐）
准备两个独立的服务器池：
blue-pool（旧版 v1）：N1, N2, N3
green-pool（新版 v2）：N4, N5, N6虚拟服务的默认分发规则指向当前活跃的环境：
切换前：
默认分发规则 → HTTP代理 → blue-pool
（所有流量走蓝色旧版）
切换后：
默认分发规则 → HTTP代理 → green-pool
（所有流量走绿色新版）操作步骤：
- 部署绿色环境（
green-pool中的 N4、N5、N6）并完成健康检查 - 在虚拟服务的默认分发规则中，将服务器池从
blue-pool修改为green-pool - 执行变更
- 观察绿色环境运行状态（通过监控分析页面确认无异常）
- 确认稳定后，蓝色环境可以保留一段时间作为回滚备选，或直接下线
回滚： 将默认分发规则的服务器池改回 blue-pool，变更执行即可。回滚时间 = 修改配置 + 变更执行的时间（通常 1 分钟以内）。
配置方式二：优先级分组切换
在同一服务器池中，使用优先级分组实现蓝绿切换：
服务器池：app-pool
├── 高优先级组：green 节点（初始不可用或设为低优先级）
└── 低优先级组：blue 节点（正在处理流量）切换时，将 green 节点提升为高优先级，同时降低 blue 节点优先级或直接下线 blue 节点。
此方式适合节点数量较少的场景。节点数量多时，推荐使用方式一（两个独立服务器池），管理更清晰。
三种策略对比与选型建议
| 决策因素 | 推荐策略 | 原因 |
|---|---|---|
| 需要按用户属性精细控制（如只让 VIP 用户体验新版） | 灰度发布 | 分发策略支持多种匹配条件 |
| 只想验证新版本的稳定性，不关心具体谁访问 | 金丝雀发布 | 按比例分流最简单 |
| 新老版本差异大、不兼容，需要整体切换 | 蓝绿部署 | 两套完整环境隔离 |
| 后端节点资源有限，不能同时跑两套环境 | 金丝雀（同池权重） | 只需增加少量节点 |
| 需要频繁发布、快速回滚 | 蓝绿部署 | 一键切换，回滚最快 |
| 需要观察新版本在真实流量下的表现 | 金丝雀发布 | 按比例逐步放量，风险可控 |
组合使用
在实际项目中，三种策略可以组合使用。例如：
第一阶段（灰度）：内网用户先访问绿色环境 → 人工验证功能
第二阶段（金丝雀）：放开 10% 公网流量到绿色环境 → 监控指标对比
第三阶段（蓝绿）：确认无误后全量切换到绿色环境 → 蓝色环境保留 1 天后下线注意事项
- 会话保持的影响：如果虚拟服务开启了会话保持（如基于 Cookie），同一个用户的请求会被持续分配到同一台服务器。在金丝雀发布中，这意味着某个用户一旦被分配到新版或旧版，后续请求会一直在同一版本上。这不是 Bug，但需要了解。
- 数据库兼容性：蓝绿部署要求新旧版本同时连接同一数据库，因此数据库表结构的变更必须是向后兼容的（新增列可以有默认值，删除列不能在切换前执行）。
- 权重生效时机：修改节点权重或虚拟组权重后即时生效（无需变更执行），但已建立的 TCP 长连接不会断开重连。
- 监控对比：在灰度/金丝雀期间，建议同时观察新旧版本节点的监控图表（吞吐量、错误率、响应时延），对比确认新版本是否引入了性能退化。
- 免费版限制：虚拟组功能和温暖上线功能仅商业版支持。免费版可通过节点权重 + 分发规则实现基本的金丝雀和灰度发布。
服务器池的权重和虚拟组配置详见 服务器池用户手册，分发规则与策略的配置详见 分发规则匹配逻辑详解。