reviews 三个版本的差异与灰度价值

先回到 bookinfo 的调用拓扑。产品页面服务调用评论服务，评论服务调用评分服务。评论服务的三个版本并非功能完备度递进，而是故意制造的视觉差异：一个版本返回文字评论但不调用评分服务，因此页面上评分区空白；另一个版本调用了评分服务但前端模板渲染成某种颜色的星形；第三个版本同样调用评分服务但渲染成另一种颜色的星形。这种设定的巧妙之处在于，一旦流量在三个版本间分配，用户无需看后台日志，只要看星星颜色就知道请求落到了哪个版本。

灰度的本质不是部署一个新版本，而是让一部分流量先见到新版本，其余流量暂留旧版本，观察稳定性后再逐步扩大范围。评论服务的多版本并存正好提供了观察样本——你可以让一小部分随机流量进新版看是否引发报错，也可以让特定测试账号的流量固定进新版，其他人仍看旧版的空白评分。这种细粒度控制是传统副本扩缩容做不到的，因为扩缩容只能按实例数粗调，无法按请求内容或权重精确分发。

子集划分：把标签变成可寻址分组

灰度发布的第一步不是写路由，而是告诉网格评论服务有哪些版本、每个版本对应哪些 Pod。这件事由子集划分规则完成。

子集划分规则挂在评论服务名下，里面定义子集列表。每个子集有一个名字和一组标签选择器。网格控制面会把这组标签与容器集群中 Pod 的标签做匹配，凡是带了特定标签的 Pod 自动归入对应的子集。自此，控制面下发给 Sidecar 的集群配置里，评论服务不是一个扁平的端点池，而是拆成多个端点池，每个池绑定一个子集名。

这里有个容易混淆的点：子集划分规则只负责分组，不负责怎么分流量。它相当于给后端划了多条车道，但哪辆车进哪条车道由路由规则决定。没有子集划分规则时，路由规则里写子集名会报未知子集错误；反过来只有子集划分规则没有路由规则，流量仍按默认轮询打散到所有评论服务的 Pod，灰度不生效。

子集还可以挂载更细的流量策略，比如给新版子集单独设连接池上限或异常点检测阈值。这意味着灰度版本如果资源较脆弱，可以在子集级别限流，不影响旧版的生产流量。

权重灰度：从零到一百的渐进

权重灰度是最常见的金丝雀路径。在网格控制台或命令行下发一个评论服务的路由规则，里面写多个目的地，每个目的地指向评论服务加上子集名，再附带权重字段。

例如初始态全部权重给旧版，页面永远空白星星。切灰时改成旧版占绝大部分、新版占极小部分，约十分之一的刷新会看到新颜色星星；观察一段时间指标平稳后逐步调整权重比例，最后全部给新版，完成全量。整个过程新旧版本的 Pod 副本数可以完全独立伸缩，互不干扰——这是网格切流相比副本替换式发布的最大优势：新版本实例不够可以单独扩容新版，旧版本不用动。

权重是概率性的，代理按权重做随机分发，不是严格按请求计数轮流。因此在低流量下可能出现连续多次都命中旧版的抽样偏差，排障时不要以刷新几次没见到新版本就断定配置没生效，而应看 Sidecar 统计或网格可观测面板里的实际分发比例。

请求头灰度：按身份而不是按概率切流

纯权重灰度对内部测试员不友好——测试员自己刷新多次可能一次都没撞上新版。请求头灰度解决的是指定的人必须看到新版本的问题。

路由规则的匹配条件可以匹配 HTTP 请求头。例如匹配某个特定用户时，路由到新版子集；其余请求走默认路由到旧版或按权重分配。这样测试员用特定账号登录永远看到新颜色星星，真实用户仍看旧版，互不干扰。除了用户名，也可以匹配自定义的请求头，实现带标记的流量进灰度、其余不动。

请求头匹配按顺序求值，第一条命中即停止。因此写规则时要把最具体的匹配放前面，兜底规则放最后。在网格控制台的基于请求内容灰度页签里，本质就是生成这段匹配逻辑，只是把声明式文件抽象成了表单。

这种模式的工程价值在于：灰度不是放一部分陌生流量去冒险，而是让已知身份的内部人员先承担新版本。配合后端打点，可以精确比对测试账号的报错率与大众流量的报错率，隔离变量。

渐进节奏与观测闭环

灰度不是一次配完就走人。评论服务多版本灰度的典型节奏是：先用请求头灰度给内部账号验证功能正确性；再放少量权重灰度验证性能与错误率；指标平稳后逐步提升权重比例；最后全量接管并下线旧版。

观测对象有三个层面。业务层看页面里星星颜色分布是否符合权重预期；服务层看新版的延迟和错误率、下游服务调用成功率；网格层看 Sidecar 的路由命中统计。网格的可观测面板会把路由规则实际生效的权重、各子集端点健康度直接画出来，比登进 Pod 抓包轻量得多。

一旦新版在少量权重时出现下游调用超时飙升，可以不动旧版流量，直接把权重回退到零或删除路由规则恢复默认路由——回滚是秒级的控制面下发，不需要重建 Pod。这是灰度发布相比全量替换的核心安全垫。

多版本共存的边界与误区

评论服务多版本灰度有几个边界开发工程师常踩。

其一是子集标签必须和部署配置的 Pod 模板标签严格一致。若子集划分规则写了一个标签但部署打的是另一个标签，子集为空，路由到新版会返回错误。网格控制台创建灰度版本时会自动补标签，但手写声明式文件容易在这对不上。

其二是权重总和必须完整。写不完整的权重会报校验错误，代理也不会按直觉归一化。

其三是路由规则与子集划分规则是两套资源，删路由规则只去掉流量分发规则，子集定义还在；下次再建路由规则可直接复用。反过来只建子集划分规则不建路由规则，流量不走灰度。

其四是加密传输开启时，新旧版本之间的互信由网格统一签发证书，不存在新版本要单独配证书的问题，这是 Sidecar 模式相比软件开发工具包治理的隐性收益。

结语

bookinfo 的评论服务多版本灰度，表面看是让新颜色星星慢慢取代旧颜色星星的演示，背后是一条完整的服务网格治理链路：子集划分规则把标签映射成可寻址分组，路由规则按权重或请求头把流量导流到分组，Sidecar 在数据面无声执行，控制面秒级下发让灰度可逆可观测。在天翼云容器与网格托管能力上跑这套机制，开发者不需要自己运维控制面，但仍要理解权重与请求头两种灰度的适用边界——权重解决按比例放量，请求头解决按身份放人。把评论服务的星星颜色当成最直观的断言，灰度发布就从黑盒运维变成了可肉眼验收的工程动作。