云端应用灰度发布的实例分组策略，重点不是简单挑几台机器，而是让新旧版本可识别、流量可控制、异常可回退。分组时先确定实例边界，再决定哪些请求进入新版本，并为每组设置独立的观察和退出条件。
先按版本和职责划分实例
最基本的做法是把旧版本与新版本部署成可区分的实例组。以 Kubernetes 为例，可以用两个 Deployment 分别运行稳定版和候选版，并通过标签标记应用名、版本、环境等属性。这样既能单独扩缩容，也方便查看日志和指标。
如果应用由多个服务组成，应按服务职责分别灰度，不要把无关组件一并换版。比如只改了订单查询接口，就先控制该服务的候选实例；数据库结构变更、消息格式变化等有兼容性影响的改动，则要先确认新旧版本能否并行工作。
选择分组维度：流量入口优先，实例属性辅助
按请求分流，适合验证真实用户流量
金丝雀发布通常先让少量请求进入候选版本，再逐步扩大范围。入口层或服务网格可以按权重分配流量，但 Kubernetes Service 的标签选择本身不提供按百分比加权的路由能力，具体做法取决于所用 Ingress 控制器或流量管理组件。
灰度比例应结合流量规模和风险调整。常见做法是从少量流量开始，观察错误率、延迟和关键业务指标，再分阶段提高比例；低流量服务需要更长观察时间，否则样本不足，不能仅凭短暂无报错判断安全。
按用户或实例属性分组，适合保持体验一致
对于有登录态的应用，可依据用户标识、租户或请求头进行标签路由，使同一用户在一段时间内尽量落到同一版本。按可用区、节点类型或容量分组，则适合检查新版本是否只在特定运行环境出现异常。不要把用户身份、地域等敏感信息直接写进不受控的日志或标签。
可执行的分组与放量步骤
- 列出实例和依赖：确认应用服务、实例数、入口规则、会话状态及数据库或消息队列兼容要求。
- 给版本加标识：为稳定版和候选版设置清晰标签，检查服务选择器只匹配预期实例，避免新旧版本被意外混在同一组。
- 设定流量规则：先选择内部测试、指定用户或小比例请求等入口。记录规则的生效范围，并确认未命中灰度条件的请求仍走稳定版。
- 分阶段观察：每次调整后检查错误率、响应时间、资源使用和核心业务结果。观察时长应覆盖业务高峰或主要请求周期，不能只按固定分钟数判断。
- 扩大或回滚：指标稳定且样本足够时再增加流量；若错误明显上升、关键操作失败或依赖出现不兼容，先将候选版流量切回稳定版，再排查原因。
分组时容易忽略的边界
只按实例数量分组，不等于按流量分组：不同实例的请求量可能差异很大。若存在本地会话、缓存或长连接，切换流量还可能造成用户状态不一致。发布前应确认会话共享或粘性策略，并让候选组具备足够容量，避免少量实例承受过高负载。
同时保留旧版本的可运行实例和配置，但要明确回滚是否涉及数据库变更。应用代码可以切回，不代表不可逆的数据结构修改也能自动恢复。将灰度比例、标签路由和回滚条件记录在同一发布方案中，云端应用灰度发布的实例分组策略才真正具备可执行性。
常见问题
实例组应该按机器还是按版本创建？
通常先按版本区分，再结合节点、可用区等属性细分；机器归属是运行位置，版本才是灰度控制的核心。
能否只挑一台实例做灰度？
可以用于初步验证，但单实例可能无法代表其他节点环境，也容易形成容量瓶颈。正式放量前应确认样本和承载能力足够。
没有流量管理组件怎么办？
可先采用指定测试用户或独立测试入口验证；若要按请求比例稳定分流，需要检查现有入口是否支持相应路由能力。
什么情况应立即停止放量？
关键请求失败、错误率持续升高、延迟明显恶化或数据兼容异常时，应暂停扩量并按预案回滚。