版本发布策略：灰度、金丝雀与蓝绿部署

为什么要关注发布策略

当您上线一个新版本的应用时，最怕的不是"新版本有 Bug"，而是"新版本的 Bug 影响了所有用户"。传统的停服更新——全量发布——一旦出了问题，回滚窗口长、影响面大。

矩尺平台作为流量的入口，天然具备流量调度能力。利用服务器池的权重调节、虚拟组、分发规则等功能，您可以在不改变应用代码、不增加额外组件的前提下，实现精细化的版本发布策略。

三种策略概览

策略	核心思路	切换方式	回退操作	适用场景
灰度发布	按条件筛选一小部分用户先体验新版本	按规则（IP、Header、Cookie 等）	恢复原匹配条件并验证	按用户属性逐步放开
金丝雀发布	将少量流量引向新版本	按相对权重	新版权重归零并验证新请求	按流量比例验证新版本稳定性
蓝绿部署	准备两套完整环境，切换请求去向	更换目标池	切回旧环境并验证	需要整体切换业务入口的场景

三者的核心区别在于流量切换的粒度：灰度是按条件选人，金丝雀是按比例分流，蓝绿是全量切换。

矩尺平台相关能力

在介绍具体配置之前，先梳理矩尺平台中与发布策略相关的功能：

平台能力	位置	作用	适用策略
节点权重	服务器池 → 负载均衡算法选择"加权轮询"或"加权最小连接数"	在同一个服务器池内，按权重比例将流量分给不同节点。权重 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（旧版）：优先级 100，权重 90，组内节点 N1, N2
虚拟组 B（新版）：优先级 100，权重 10，组内节点 N3, N4

放量过程： 同时调整 A/B 的相对权重，例如 90/10 → 70/30 → 50/50 → 0/100。输入的是权重数值，不带百分号；只增加 B 而不调整 A，不能据此认定新版比例就是输入数值对应的百分比。

虚拟组的优势：

• 批量调权重：修改组权重即可，不用逐个节点修改
• 故障后重新分配：节点健康状态会影响实际分配；仍应核对剩余节点容量，不能保证其不会过载

配置方式三：分发规则 + 两个服务器池（与灰度结合）

分发规则用于按条件选择服务器池，本身不提供百分比分流。可先用规则确定灰度人群，再在目标池内用节点或虚拟组权重分配；只需要比例分流时使用方式一或方式二。

温暖上线的配合

金丝雀发布中，新节点刚上线时可以开启温暖上线，让新节点的流量在"温暖时间"内从 0 缓慢增长到目标权重对应的量，避免冷启动的新节点被突然涌入的流量打垮。

策略三：蓝绿部署（两套环境全量切换）

原理

蓝绿部署的核心是准备两套完整的环境：

• 蓝色环境：当前正在运行的生产环境（旧版本）
• 绿色环境：与蓝色环境完全对等的另一套环境（新版本），已部署并通过测试

切换后，让新请求使用绿色环境；异常时将分发规则改回蓝色。已有连接和会话保持可能影响实际切换边界，不能承诺所有请求瞬间迁移。

配置方式一：分发规则切换服务器池（推荐）

准备两个独立的服务器池：

blue-pool（旧版 v1）：N1, N2, N3
green-pool（新版 v2）：N4, N5, N6

虚拟服务的默认分发规则指向当前活跃的环境：

切换前：
  默认分发规则 → HTTP代理 → blue-pool
  （所有流量走蓝色旧版）

切换后：
  默认分发规则 → HTTP代理 → green-pool
  （所有流量走绿色新版）

操作步骤：

1. 部署绿色环境（green-pool 中的 N4、N5、N6）并完成健康检查
2. 在虚拟服务的默认分发规则中，将服务器池从 blue-pool 修改为 green-pool
3. 执行变更
4. 观察绿色环境运行状态（通过监控分析页面确认无异常）
5. 确认稳定后，蓝色环境可以保留一段时间作为回滚备选，或直接下线

回滚： 将实际命中规则的服务器池改回 blue-pool，保存并执行变更，再确认新请求回到旧版。回滚耗时应按配置生效、连接状态和业务恢复实测，不承诺固定完成时间。

配置方式二：优先级分组切换

在同一服务器池中，使用优先级分组实现蓝绿切换：

服务器池：app-pool
  ├── 高优先级组：green 节点（初始不可用或设为低优先级）
  └── 低优先级组：blue 节点（正在处理流量）

切换时调整虚拟组优先级，并确认目标优先级内健康节点总数达到“组中最少健康节点数量”。数字越大，优先级越高；目标等级不满足阈值时会回退到其他符合条件的等级，不能只改优先级就认定新版已承载。

此方式适合节点数量较少的场景。节点数量多时，推荐使用方式一（两个独立服务器池），管理更清晰。

节点上线与维护下线

新节点或故障节点恢复

1. 先确认后端应用已就绪，端口、健康接口及路由可用。
2. 在服务器池中配置节点、健康检查及探测引擎，按业务需要开启温暖上线。
3. 填写恢复时间和温暖时间，保存并处理必要的配置变更。
4. 持续发送可识别后端节点的请求，观察等待、流量爬升和稳定三个阶段。

验证单节点恢复时，保留其他健康节点持续承载。全池均异常后的恢复可能走直接恢复分配的路径，不应假定所有故障恢复都必定等待同样时长。

恢复时间与温暖时间在服务器池的基础信息区域配置，与虚拟组弹框是两个配置区域。恢复时间用于等待，温暖时间用于逐步增加流量，单位都是秒。

例如恢复时间 10 秒、温暖时间 10 秒，健康检查确认恢复后，还需观察等待与爬升过程。这个数值用于说明阶段，不保证从启动应用起恰好 20 秒达到稳定分布。

维护下线与回退

1. 核对其他健康节点能承载业务，并记录当前节点、权重、优先级和健康阈值。
2. 按维护方案关闭目标节点，或调整发布规则、虚拟组权重。
3. 用新请求验证目标节点不再承接预期范围的新业务。
4. 单独观察已有连接、长请求和应用事务；确认影响后再停止后端服务。
5. 恢复时先验证后端就绪，再恢复配置，检查健康状态及流量爬升。

不能把“关闭节点”“权重为 0”“删除节点”视为完全相同的连接处理方式。需要不中断已有业务时，应先在与生产相同的协议和连接模型下验证排空行为。

优先级与健康阈值示例

状态	阈值为 2 时的选择
高优先级有 2 个健康节点	使用高优先级
高优先级仅剩 1 个健康节点，低优先级有 2 个	高优先级不达标，使用低优先级
高优先级恢复到 2 个健康节点	重新优先使用高优先级
所有等级都不达标	不能保证还有可用后端；检查错误响应或保障页面

同一优先级下多个参与候选的组会汇总健康节点数量；权重为 0 的组不计入。将阈值改小可能维持高优先级承载，但也会让更少的节点承担业务，应结合容量评估。

三种策略对比与选型建议

决策因素	推荐策略	原因
需要按用户属性精细控制（如只让 VIP 用户体验新版）	灰度发布	分发策略支持多种匹配条件
只想验证新版本的稳定性，不关心具体谁访问	金丝雀发布	按比例分流最简单
新老版本差异大、不兼容，需要整体切换	蓝绿部署	两套完整环境隔离
后端节点资源有限，不能同时跑两套环境	金丝雀（同池权重）	只需增加少量节点
需要频繁发布、保留明确回退目标	蓝绿部署	旧池保留，异常时可恢复引用并验证
需要观察新版本在真实流量下的表现	金丝雀发布	按比例逐步放量，风险可控

组合使用

在实际项目中，三种策略可以组合使用。例如：

第一阶段（灰度）：内网用户先访问绿色环境 → 人工验证功能
第二阶段（金丝雀）：放开 10% 公网流量到绿色环境 → 监控指标对比
第三阶段（蓝绿）：确认无误后全量切换到绿色环境 → 蓝色环境保留 1 天后下线

注意事项

1. 会话保持的影响：保持策略可能让同一用户继续访问某个节点，从而影响比例与切换结果；节点异常、保持记录过期和池切换也可能改变去向。验证时区分已有会话和新会话，参见会话保持指南。
2. 业务数据兼容性：新旧版本共用数据库时，需确保数据结构和读写方式兼容；使用独立数据库时，还需准备数据同步及回退方案。
3. 权重与连接状态：修改权重后验证新请求的实际分布；不要把权重归零等同于旧连接全部结束，也不要把它当作应用事务完成的证明。
4. 监控对比：在灰度/金丝雀期间，建议同时观察新旧版本节点的监控图表（吞吐量、错误率、响应时延），对比确认新版本是否引入了性能退化。
5. 免费版限制：虚拟组功能和温暖上线功能仅商业版支持。免费版可通过节点权重 + 分发规则实现基本的金丝雀和灰度发布。

---

服务器池的权重和虚拟组配置详见 服务器池用户手册，分发规则与策略的配置详见 分发规则匹配逻辑详解。