微服务发布策略面试题：灰度、金丝雀、蓝绿与回滚
本页只放面试标准回答、追问点和原理跳转。完整原理、流程图、配置 Demo 和 Runbook 见微服务发布策略。
高频问题
| 问题 | 标准回答 | 原理页 |
|---|---|---|
| 滚动发布、蓝绿发布、金丝雀和灰度有什么区别 | 滚动发布是分批替换实例；蓝绿是保留两套完整环境并切流；金丝雀是先放极少量流量验证；灰度是按用户、租户、地域、标签等规则让指定人群进入新版本。它们解决的问题不同，可以组合使用。 | 发布策略全景 |
| 一次灰度请求完整链路怎么走 | Gateway先基于可信身份生成灰度标签并路由，服务间通过Feign拦截器或RPC Filter透传标签；注册中心提供带metadata的实例列表，LoadBalancer按version、zone、weight过滤并选择实例，底层HTTP/RPC客户端发出真实请求，最后按版本观测成功率和P99。 | 灰度调用链 |
| Feign、Nacos和LoadBalancer在灰度里分别做什么 | Feign生成客户端代理和请求模板；Nacos保存服务实例、健康状态和metadata；LoadBalancer在调用方本地拿到实例快照后过滤和选择目标实例；真正发请求的是底层HTTP Client。 | LoadBalancer灰度 |
| 怎么保证本地服务列表是最新的 | 不能保证任意瞬间绝对最新，只能保证最终收敛并缩短传播窗口。注册中心更新、客户端推送或拉取、本地快照替换、LoadBalancer选址和连接池释放都是异步过程。生产上靠订阅推送、定期刷新、Readiness摘流、优雅停机、健康过滤、短超时、有限重试和连接池最大存活时间降低旧列表风险。 | 本地列表新鲜度 |
| 如果调到了旧服务怎么办 | 先用Trace和日志确认目标ip、版本、routeId和时间，再查注册中心事实、调用方本地实例快照、LoadBalancer候选列表、HTTP连接池和灰度标签。只读请求可按兼容策略容忍短窗口；写请求不能简单重放到新版本，必须用幂等号查询业务事实，再补偿或对账。 | 调到旧服务Runbook |
| Gateway能不能直接相信客户端传来的X-Gray-Tag | 不能。外部客户端可以伪造Header。生产上应由Gateway认证后根据用户、租户或灰度平台规则生成可信标签，并覆盖或清理客户端同名Header。 | Gateway灰度 |
| 灰度实例为空怎么办 | 先区分读写场景。只读查询可以按策略回退稳定版本；写请求直接回退可能造成语义不一致或重复执行。应告警并保留明确错误，同时排查实例metadata、健康状态、zone和规则。 | 实例过滤边界 |
| 为什么配置5%灰度实际不是5% | 权重是概率或局部策略，不是全局精确配额。样本太小、HTTP/2长连接、调用方本地LB、zone过滤、sticky、重试和慢实例都会导致实际流量偏差。判断要看版本维度QPS、连接数、并发、P95/P99和业务请求数。 | 权重不精确 |
| 灰度发布要观察哪些指标 | 至少看版本维度QPS、错误率、P95/P99、业务成功率、重试次数、熔断限流降级、线程池、连接池、慢SQL、锁等待、MQ Lag和Trace。技术200不代表业务成功。 | 观察指标 |
| 回滚是不是把镜像改回旧版本 | 不是。代码回滚只停止新代码继续接流量，不能自动回滚数据库字段、数据语义、MQ Offset、外部支付短信库存副作用、配置中心和缓存结构。回滚要先切流、排空连接、处理副作用并对账。 | 回滚边界 |
| 数据库变更怎样支持灰度和回滚 | 使用Expand-Migrate-Contract：先新增兼容字段或表，发布双写/兼容读，回填并校验，灰度切读，确认旧版本退出后再删除旧字段。不要在一次发布里同时删字段、改代码和切流。 | 数据兼容 |
| MQ事件发布怎样保证新旧版本兼容 | 事件要有eventId、eventType、schemaVersion和业务版本；新增字段可选，消费者忽略未知字段，已发布字段语义不能改变。上线前用历史消息样本回放验证，避免延迟消息和灾备重放打挂新消费者。 | MQ事件兼容 |
| Service Mesh灰度和应用内灰度怎么选 | Mesh适合统一的语言无关流量治理，如权重、Header路由、mTLS和遥测；应用内灰度适合强业务语义，如租户、订单类型、权限和数据策略。复杂系统常组合使用，但要明确唯一规则来源，避免双重路由冲突。 | Service Mesh灰度 |
| 回滚后为什么还有v2流量 | 可能是Gateway、Envoy或客户端本地缓存未刷新，HTTP/2/gRPC连接复用，已有请求未完成，异步消息由v2生产后仍在消费，或者配置开关未回滚。应停止新流量、观察连接排空、必要时摘除v2实例并处理副作用。 | 回滚Runbook |
场景题：医疗采集新解析器怎样灰度
先按医院租户灰度，不按随机用户灰度。新解析器先镜像解析并记录新旧结果差异，不直接入主表；差异率和P99达标后，小范围医院切读新结果。所有入库记录保留原始报文、解析版本和字段差异，出问题时先切回旧解析器，再根据审计记录修正受影响数据。
场景题：订单库存新逻辑怎样灰度
写请求灰度要特别谨慎。新旧版本必须共享幂等表、订单状态机和库存冻结记录；v2超时不能自动回退v1重新扣减，而应返回处理中并通过订单号查询事实。灰度时观察库存冻结成功率、重复请求、补偿率、订单最终成功率和下游P99。
项目回答模板
我们把发布当成一条闭环链路处理：发布前先做API、数据库和事件兼容检查；入口由Gateway根据可信用户和租户生成灰度标签；服务间通过Feign拦截器或RPC Filter透传；LoadBalancer按注册中心metadata过滤版本实例；灰度期间按版本看QPS、错误率、P99、业务成功率、重试和资源池；达到门禁再逐步放量。回滚时先切断新流量，再处理配置、缓存、消息和外部副作用，最后通过业务对账确认恢复。
本章小结
发布策略面试不能只背“蓝绿两套环境、灰度小流量”。高质量回答必须讲清调用链位置、标签可信性、实例过滤、数据兼容、观测门禁和回滚副作用。