微服务发布与灰度：蓝绿部署/金丝雀发布/灰度发布，流量路由与版本管理

提出问题

上线一个微服务新版本，最怕什么？怕改出线上事故，回滚还回不去。单体架构下，新版本上线就是替换整个 war 包，大不了回滚。但微服务架构下，几十个服务各自独立部署，版本号遍布各处，一条新功能可能涉及 3-5 个服务同时发布。如果还像单体一样"全部替换"，某个服务出问题就会拖垮整条调用链。

2023 年某电商大促前一天，团队把订单服务的优惠券计算逻辑从 O(n²) 优化到 O(n)，全量替换上线。结果新版本在极端高并发下抛了 NPE，回滚时发现蓝绿环境已经回收了旧版本，回滚花了 37 分钟，损失 GMV 约 1200 万。这就是没做灰度、没留蓝绿环境的代价。

另一个更隐蔽的案例：2024 年某金融科技公司做金丝雀灰度，5% 流量切到新版本后，错误率、延迟指标都正常。但新版本的一个 bug 是"对特定用户群体（企业商户）的结算逻辑算错了一位小数"，而金丝雀流量恰好 5% 的随机用户没覆盖到企业商户。灰度上线 3 天后才发现，涉及 3000 多家商户多结算了 240 万。教训：金丝雀的流量比例抽样不等于用户维度覆盖，关键业务场景必须做灰度流量定向覆盖。

面试官看一眼就过的回答 vs 加分的回答：

面试官问："你们公司怎么做灰度发布？"

一般回答："我们用了金丝雀发布，先放 5% 流量，观察没问题再全量。"

加分回答："我们根据场景选策略。核心支付链路用蓝绿部署，两套环境双倍资源但回滚秒级。通用业务用金丝雀，按 1%→5%→10%→50%→100% 逐步放量，每阶段 5-15 分钟观察窗口，Prometheus 按 error_rate 和 p99 自动门禁。用户维度灰度用流量染色，Dubbo 拦截器透传 X-Canary-Tag，OpenTelemetry Baggage 全链路携带。多服务灰度时维护版本兼容矩阵，不允许跨版本调用。数据库 Schema 变更必须向后兼容——先 ADD COLUMN 再改代码最后清理，索引变更单独发布不跟灰度代码走。"

面试官问"怎么做灰度发布"时，不只是考你背出蓝绿和金丝雀的定义，而是想听你对风险控制粒度的判断——什么时候用蓝绿，什么时候用金丝雀，灰度期间的流量染色怎么透传，数据库 Schema 不兼容怎么办，多集群跨区域灰度怎么做。这些才是生产上踩过的坑。

分析问题

三种发布策略的适用场景和成本

蓝绿部署（Blue-Green Deployment） 维护两套完整环境。蓝环境跑当前版本，绿环境部署新版本，验证通过后把流量从蓝切到绿。切换瞬间完成，回滚也只需要切回蓝环境。代价是资源翻倍——两套环境意味着 2x 的机器成本，适合交易、支付、用户认证这类核心链路。如果公司预算有限，也可以通过 K8s 的 Namespace 隔离实现"逻辑蓝绿"，同一套集群靠标签和路由规则切换。

蓝绿部署的隐藏陷阱：你以为是"切流量"，其实是"切数据库"。如果新版本同时改了数据库 Schema，切到绿环境后一旦回滚，绿环境写入的数据蓝环境读不了。2023 年某支付公司做蓝绿部署，绿环境新增了一个 payment_risk_level 字段，上线后发现有 bug 回滚，但绿环境已经写入了 10 万条带该字段的数据。回滚到蓝环境后，蓝环境代码的 SELECT * 查询反序列化失败，最终花了 6 小时修复数据。蓝绿部署必须保持数据库同一份，或者用双写 + 切换开关，否则"回滚"只是流量回滚，数据层面已经不可逆了。

金丝雀发布（Canary Release） 先把新版本部署到少量实例（1-5%），观察一段时间后逐步放大流量比例（10% → 50% → 100%）。每一阶段都设观察窗口（5-15 分钟），配合指标门禁：错误率 < 0.1%、P99 延迟 < 500ms、核心业务指标正常。金丝雀不需要额外的硬件资源，但需要精确的流量路由能力和实时监控。适合大多数业务场景。

金丝雀的流量比例陷阱：1% 的流量并不代表 1% 的风险。如果新版本只影响特定用户（如 VIP 用户、企业商户），1% 的随机流量可能完全覆盖不到这些用户。正确做法是：金丝雀的流量路由策略必须按业务维度分层——先压 1% 随机流量观察系统稳定性，再压 5% 核心用户流量观察业务逻辑正确性，最后放量到 100%。

灰度发布（Gray Release） 是金丝雀的精细化版本，按用户组划分流量——VIP 用户先体验、内部白名单用户先体验、或者按用户 ID 取模、地域、设备类型等维度分配。灰度发布通常配合流量染色机制：网关层为灰度请求注入特殊 HTTP Header（如 X-Canary-Tag: v1.2.4），该 Header 在服务间调用时透传，下游服务据此选择执行灰度逻辑还是稳定逻辑。

面试追问：三种策略怎么选？

面试官：你们公司预算有限，做不了蓝绿，金丝雀又怕抽样偏差，怎么选？ 加分回答：金丝雀 + 定向流量。不需要 2x 资源，但需要对关键用户做定向——比如先让内部 QA 团队走灰度（白名单），然后放 1-5% 随机流量测系统稳定性，最后放 5-10% 的核心付费用户测业务逻辑。如果业务节奏急，可以金丝雀+蓝绿混合：核心链路用蓝绿，非核心链路用金丝雀。全链路蓝绿的公司，要么很有钱，要么业务容错率极低（支付、交易）。

三种策略对比表

维度	蓝绿部署	金丝雀发布	灰度发布
资源成本	2x（两套完整环境）	无额外成本（共享集群）	无额外成本（共享集群）
回滚速度	秒级（切回流量）	分钟级（缩容 canary 实例）	分钟级（改路由规则）
风险暴露面	全量一次暴露	渐进暴露，逐步放大	按用户维度可控
流量控制粒度	全部/无	按比例（1%-100%）	按用户属性（ID/地域/设备）
适合场景	核心链路、不可逆变更	通用业务迭代	内测/定向体验/AB测试
监控要求	低（切换后对比）	极高（实时门槛）	高（需染色透传）
数据库兼容性要求	高（共库或双写）	中（必须向后兼容）	中（必须向后兼容）
多集群支持	好（每集群一套）	需要跨集群路由	需要跨集群路由
典型回滚耗时	秒级（DNS/负载均衡切流量）	分钟级（缩容canary+扩容stable）	分钟级（改路由规则+灰度下线）
运维复杂度	低（切流量即可）	中（监控+门槛+自动扩缩）	高（流量染色+透传+版本管理）
适合公司规模	大厂/核心链路	中小厂/通用业务	中大型/精细化运营

流量路由的三种实现方式

第一种：Kubernetes + Service Mesh（Istio）。通过 Istio 的 VirtualService 和 DestinationRule 实现精细化的灰度路由。以下是一个基于 Header 的灰度路由配置：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-svc
spec:
  hosts:
  - order-svc
  http:
  - match:
    - headers:
        x-canary-tag:
          exact: "v1.2.4"
    route:
    - destination:
        host: order-svc
        subset: canary
      weight: 100
  - route:
    - destination:
        host: order-svc
        subset: stable
      weight: 100
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: order-svc
spec:
  host: order-svc
  subsets:
  - name: stable
    labels:
      version: v1.2.3
  - name: canary
    labels:
      version: v1.2.4

Istio 灰度路由的坑：VirtualService 的 match 规则是按顺序匹配的，第一条匹配到了就不再往下走。如果 x-canary-tag 头的值不是 v1.2.4 而是 v1.2.4-dev 或其他版本号，会直接走到稳定版本。实际生产中，建议在 match 中加一个兜底规则：如果灰度 Header 存在但版本号不匹配，也要路由到 canary 子集，否则灰度用户会"出灰度"——比如一个灰度用户先后调用两个接口，因为 Header 版本号溢出，第二个接口走了稳定版本，导致数据不一致。

# 改进版：灰度 Header 存在即走灰度子集
http:
- match:
  - headers:
      x-canary-tag:
        regex: ".*"
  route:
  - destination:
      host: order-svc
      subset: canary
    weight: 100

面试追问：Istio 灰度路由的性能开销？

Istio sidecar 每次请求做一次 Envoy 的 match 匹配，开销在 1-3ms（实测）。如果请求链路有 10 个服务，每个服务都走 sidecar，总延迟增加 10-30ms。对于 P99 延迟要求 < 200ms 的核心链路，这个开销不能忽略。解法：非核心链路用 Istio，核心链路用网关层路由（第二种方式），减少 sidecar 跳数。

第二种：网关层 + 注册中心。Spring Cloud Gateway 配合 Nacos，通过 Nacos 元数据标记服务版本，网关层根据请求 Header 路由到对应版本实例。这种方式不需要 Istio，但需要自己实现网关层的路由逻辑。核心代码片段：

// 自定义 GatewayFilter 实现灰度路由
@Component
public class GrayRouteFilter implements GlobalFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        ServerHttpRequest request = exchange.getRequest();
        // 从请求头提取灰度标记
        String canaryTag = request.getHeaders().getFirst("X-Canary-Tag");
        if (canaryTag != null) {
            // 将灰度标记注入请求属性，下游负载均衡器读取
            exchange.getAttributes().put("canaryTag", canaryTag);
        }
        // 从 Nacos 元数据匹配可用实例
        // 例如 nacos 元数据中 version=v1.2.4 的实例标记为 canary
        return chain.filter(exchange.mutate()
            .request(request.mutate()
                .header("X-Canary-Tag", canaryTag != null ? canaryTag : "stable")
                .build())
            .build());
    }
}

Nacos 元数据灰度潜规则：Nacos 的元数据是键值对，但不是所有客户端都支持按元数据过滤。Spring Cloud 2020.x 之前的 Ribbon 负载均衡器不支持 Nacos 元数据路由，需要升级到 Spring Cloud LoadBalancer 或引入 Nacos 的 nacos-discovery-ribbon 扩展。如果还在用 Ribbon + Nacos 的组合，元数据灰度路由根本不会生效，只会按随机策略选实例。

第三种：客户端负载均衡自定义规则。在 Spring Cloud LoadBalancer 中编写自定义路由规则，根据请求中携带的版本信息选择目标实例：

public class CanaryLoadBalancer implements ReactorServiceInstanceLoadBalancer {
    private final String serviceId;
    private final ObjectProvider<ServiceInstanceListSupplier> supplierProvider;

    @Override
    public Mono<Response<ServiceInstance>> choose(Request request) {
        // 从 Request 中提取灰度标记
        RequestDataContext context = (RequestDataContext) request.getContext();
        String canaryTag = context.getClientRequest().getHeaders().getFirst("X-Canary-Tag");
        
        return supplierProvider.getIfAvailable(serviceId)
            .flatMap(supplier -> supplier.get(request))
            .map(instances -> {
                if (canaryTag != null) {
                    // 优先匹配灰度版本实例
                    List<ServiceInstance> canaryInstances = instances.stream()
                        .filter(inst -> canaryTag.equals(inst.getMetadata().get("version")))
                        .collect(Collectors.toList());
                    if (!canaryInstances.isEmpty()) {
                        return Response.of(canaryInstances.get(0));
                    }
                }
                // 降级到稳定版本
                return Response.of(instances.get(0));
            });
    }
}

负载均衡灰度的性能陷阱：每次请求都遍历所有实例过滤元数据，如果实例数量大（几千个），每次请求的 instances.stream().filter(...) 会变成性能瓶颈。实测：5000 个实例的服务，每次过滤耗时约 8-15ms。建议在本地缓存实例列表按版本分组，或者用 Nacos 的 NamingService.selectInstances(serviceName, "version", "v1.2.4", true) 直接在 Nacos 服务端过滤，减少客户端计算。

灰度发布最容易被忽略的坑：数据库兼容性

新版本的代码需要新的数据库字段，但旧版本代码不兼容新字段。灰度期间两套代码同时运行，新版本写入了一个新字段，旧版本批量查询时抛出 SQL 异常，这种情况在业内反复出现。2022 年某支付公司做灰度发布，新增了一个 refund_type 字段，旧版本代码有一个 SELECT * 批量查询 + 自动映射到 Entity，结果新版本写入的 refund_type 值导致旧版本 Entity 反序列化失败，灰度流量只占 5%，却把整个查询链路的 P99 延迟从 50ms 拉到了 3.2s。

解决原则：向后兼容 Schema 变更。分三步走：

1. 先加字段（ADD COLUMN），旧版本忽略新字段，新版本读写新字段
2. 灰度期间新版本写新字段，旧版本读旧字段，两套代码同时运行
3. 灰度结束后清理旧版本中的旧字段逻辑，最终统一为新字段

-- 第一步：灰度前，新增字段，设置默认值
ALTER TABLE `order` ADD COLUMN `promotion_id` VARCHAR(32) DEFAULT NULL COMMENT '活动ID，灰度期新版本使用';

-- 第二步：新旧版本共存期间，新版本写入 promotion_id，旧版本忽略
-- 第三步：灰度结束后，删除旧版本中不相关的临时字段处理逻辑

数据库变更的另一个坑：索引变更。灰度期间新增了索引，新版本跑索引查询飞快，但旧版本没有索引同样能跑——看似没问题。但回滚时如果同时删索引，新版本写入的数据量可能已经把索引撑到很大，重建索引需要很长时间。真实案例：2024 年某电商在灰度期间对订单表加了联合索引，灰度 3 天后回滚，回滚时把索引 DROP 了。结果第二天灰度重新上线，重建索引花了 47 分钟，期间订单查询全部走全表扫描，数据库 CPU 冲到 95%。索引变更最好单独发布，不跟随灰度代码一起走。

如果新版本的行为不可逆（例如图片存储格式从 JPEG 改 WebP、订单状态机新增状态），灰度期间必须确保新旧版本都能处理对方的数据，或者灰度期间不做数据写入。回滚的原子性不是"把流量切回旧版本"就完了——新版本写入的数据，旧版本代码可能无法处理。

金丝雀发布的完整流程（含指标门禁）

          ┌─────────────────────────────────────┐
          │           流量入口（网关/Ingress）      │
          └──────────┬──────────────────────────┘
                     │
          ┌──────────▼──────────┐
          │   流量分类器          │
          │  (基于权重/Header)    │
          └──────┬──────┬───────┘
                 │      │
          ┌──────▼──┐ ┌▼───────┐
          │ 稳定版本  │ │ 金丝雀   │
          │ v1.2.3  │ │ v1.2.4  │
          │ 95% 流量 │ │ 5% 流量  │
          └─────────┘ └─────────┘
                 │           │
          ┌──────▼───────────▼───────┐
          │    指标对比引擎            │
          │  (Prometheus/Grafana)     │
          │  错误率 P99 业务指标        │
          └──────┬───────────────────┘
                 │
          ┌──────▼───────────────────┐
          │  决策网关                  │
          │  ┌──────────────────────┐ │
          │  │ 全部通过 → 放量到 10%  │ │
          │  │ 指标异常 → 回滚金丝雀   │ │
          │  └──────────────────────┘ │
          └──────────────────────────┘

指标门禁的典型配置（Prometheus 告警规则）：

groups:
- name: canary-gate
  rules:
  - alert: CanaryErrorRateHigh
    expr: |
      (sum(rate(http_requests_total{version="v1.2.4", status=~"5.."}[5m]))
       / sum(rate(http_requests_total{version="v1.2.4"}[5m])))
      > 0.001
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "金丝雀错误率超过 0.1%"
  - alert: CanaryLatencyHigh
    expr: |
      histogram_quantile(0.99,
        rate(http_request_duration_seconds_bucket{version="v1.2.4"}[5m]))
      > 0.5
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "金丝雀 P99 延迟超过 500ms"

指标门禁的隐藏缺陷：Prometheus 的 rate() 函数在 5m 窗口内计算，意味着指标异常要等 5 分钟才能触发告警。如果金丝雀流量只有 1%，5 分钟内可能只有几十个请求，统计意义不大。建议缩短金丝雀观察窗口到 1-2 分钟，配合 increase() 函数看绝对值而非百分比：

# 金丝雀低流量场景的告警规则
- alert: CanaryAny5xxError
  expr: increase(http_requests_total{version="v1.2.4", status=~"5.."}[2m]) > 0
  for: 30s
  labels:
    severity: critical
  annotations:
    summary: "金丝雀版本出现 5xx 错误"

金丝雀放量速度的实践经验：

放量阶段	流量比例	观察窗口	重点检查指标	典型风险
阶段 1	1%	5 分钟	5xx 错误率、JVM Full GC 次数	代码异常（NPE、OOM）
阶段 2	5%	10 分钟	P99 延迟、数据库连接池使用率	性能退化（慢 SQL、死锁）
阶段 3	10%	10 分钟	业务指标（下单成功率、支付成功率）	业务逻辑错误
阶段 4	50%	15 分钟	内容不一致、缓存命中率	数据一致性问题
阶段 5	100%	30 分钟	全链路指标漂移	规模效应（连接池、IO 瓶颈）

为什么 50%→100% 的观察窗口要最长？ 因为流量翻倍后，系统的非线性效应才暴露出来。典型案例：数据库连接池在线程池满后排队，50% 流量时连接池用了 60%，看起来正常；到 100% 时连接池冲到了 95%，请求排队时间从 10ms 跳到 200ms，P99 暴涨。50% 以上风险不是线性放大的，而是指数级放大。

流量染色透传的完整链路

灰度发布的难点不在于"怎么切流量"，而在于"灰度标志怎么跨服务透传"。一个请求经过网关 → 订单服务 → 库存服务 → 支付服务，如果只在网关层打灰度标记，下游服务感知不到，新的灰度逻辑在下游就不会执行。

透传方案一：ThreadLocal + RPC 拦截器

// 灰度上下文持有者
public class GrayContext {
    private static final ThreadLocal<String> CANARY_TAG = new ThreadLocal<>();
    
    public static void setTag(String tag) { CANARY_TAG.set(tag); }
    public static String getTag() { return CANARY_TAG.get(); }
    public static void clear() { CANARY_TAG.remove(); }
}

// Dubbo 消费者拦截器：透传灰度标记
@Activate(group = "consumer")
public class GrayContextFilter implements Filter {
    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        String tag = GrayContext.getTag();
        if (tag != null) {
            invocation.getAttachments().put("x-canary-tag", tag);
        }
        return invoker.invoke(invocation);
    }
}

// Dubbo 提供者拦截器：恢复灰度标记
@Activate(group = "provider")
public class GrayProviderFilter implements Filter {
    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        String tag = invocation.getAttachments().get("x-canary-tag");
        if (tag != null) {
            GrayContext.setTag(tag);
        }
        try {
            return invoker.invoke(invocation);
        } finally {
            GrayContext.clear();
        }
    }
}

ThreadLocal 透传的坑：用了虚拟线程（Project Loom）后，虚拟线程可以被 JVM 挂起和恢复，ThreadLocal 不再可靠。虚拟线程被挂起后，灰度标记会丢失。2024 年 Spring Boot 3.2 + 虚拟线程的项目中，灰度标记在 Dubbo 调用时随机丢失，导致灰度流量间歇性"出灰度"。解决方案：虚拟线程场景下用 ScopedValue（Java 21+）替代 ThreadLocal，或者改用 OpenTelemetry Baggage 透传，因为 Baggage 是绑定在 Trace 上下文中的，不依赖当前线程。

面试追问：为什么不用 ThreadLocal 透传灰度标记？

加分回答：ThreadLocal 在虚拟线程下不可靠。虚拟线程是 JVM 管理的轻量级线程，被 park 时 ThreadLocal 数据会丢失。我们踩过这个坑——灰度流量在调用链上随机丢失灰度标记，查了两天才发现是虚拟线程挂起导致的。最终方案：网关层把灰度标记写入 OpenTelemetry Baggage，全链路自动透传，不需要手动拦截器，而且 Baggage 绑定在 TraceContext 上，不依赖当前线程。如果项目还没上 OpenTelemetry，至少用 MDC（Mapped Diagnostic Context）传递，它也是线程安全的。

透传方案二：OpenTelemetry Baggage。灰度标签写入 OpenTelemetry Baggage，全链路自动透传，不需要手动实现拦截器：

// 在网关层设置灰度 Baggage
Span span = Span.current();
span.setAttribute("canary.tag", "v1.2.4");
Baggage.current().toBuilder()
    .put("canary.tag", "v1.2.4")
    .build()
    .makeCurrent();

// 下游服务读取 Baggage（自动传透，无需额外代码）
String canaryTag = Baggage.current().getEntryValue("canary.tag");

多集群/跨区域的灰度发布方案

当服务部署在多个地域（北京、上海、新加坡）或多个 K8s 集群时，灰度发布不能只在一个集群做。常见做法：

方案一：按地域独立灰度。每个地域的集群独立部署灰度实例，灰度流量只在本地域内路由。优点是灰度影响范围小，一个地域出问题不影响其他地域。缺点是灰度管理复杂，需要同步所有地域的灰度状态。

方案二：全局灰度 + 地域路由。在全局流量入口（如 Global Load Balancer）做灰度判断，按用户 ID 取模决定灰度组，然后根据灰度组将流量路由到对应地域的灰度集群。核心逻辑：

# 全局灰度路由规则示意
# 用户 ID 模 100 < 5 → 灰度组，路由到北京灰度集群
# 用户 ID 模 100 >= 5 → 稳定组，路由到北京/上海稳定集群

方案三：K8s 多集群服务网格。Istio 支持跨集群的 VirtualService，通过 MeshNetworking 配置跨集群路由。但配置复杂度高，实际生产中用得不多，大部分公司还是按地域独立做灰度。

多集群灰度的坑：用户从北京集群灰度到了上海集群，结果上海集群的灰度实例还没部署，用户降级到稳定版本——"灰度出城"了。解决办法：全局灰度路由必须在每个集群都部署灰度实例，或者在灰度期间限制流量只路由到已部署灰度实例的集群。

灰度发布自动化流程设计

一个完整的灰度发布流程应该包含以下步骤，且每一步都应该自动化：

1. 健康检查准入 → 新版本镜像扫描通过（漏洞、合规）
2. 部署灰度实例 → 自动注入灰度标签（version: v1.2.4）
3. 流量引入 → 1% 流量 → 观察 5 分钟 → 自动指标比对
4. 放量 10% → 观察 10 分钟 → 自动指标比对
5. 放量 50% → 观察 15 分钟 → 自动指标比对
6. 全量 100% → 观察 30 分钟 → 标记灰度完成
7. 清理旧版本实例 → 缩容旧版本，保留回滚能力 24 小时

自动化流程中的关键决策点：

• 指标比对用什么阈值？不是固定值，而是相对值：新版本 vs 旧版本的指标变化率。例如新版本错误率比旧版本高 50% 就算异常。
• 谁有权限叫停？一般是自动叫停 + 人工确认。自动叫停触发后，灰度实例自动缩容到 0，旧版本恢复全量流量。
• 放量速度怎么控制？从 1% 到 10% 可以快（5 分钟），从 10% 到 50% 要慢（10-15 分钟），从 50% 到 100% 最慢（15-30 分钟），因为后半段流量放大后可能出现"规模效应"的问题（如数据库连接池不够、缓存击穿等）。

面试常见追问

Q：灰度期间发现旧版本实例报错，怎么排查是灰度流量导致的？ A：通过日志聚合。灰度流量携带 X-Canary-Tag，在日志输出时统一打印，配合 ELK 按 x-canary-tag: v1.2.4 过滤。另一种方案是 OpenTelemetry TraceId 关联，灰度请求的 Trace 打上 canary=true 标签，在 Jaeger/Zipkin 中一键筛选。更细节的是：如果灰度流量调用了旧版本实例（下游服务没有灰度版本），旧版本实例的日志中也会出现 X-Canary-Tag 头，可以通过日志反查——搜索灰度主 TraceId 就能找到所有被影响的调用链。

Q：如果灰度服务 A 调用了下游服务 B，但 B 没有灰度版本，怎么办？ A：分三种情况。如果 B 的行为不依赖灰度逻辑（只读数据、无状态计算），直接调稳定版本，A 的灰度逻辑在 A 自身完成。如果 B 的行为需要配合灰度逻辑（比如 B 也要根据灰度标记走不同分支），那 B 必须也部署灰度版本，否则灰度逻辑在下游断层。如果 B 是第三方服务（不可控），只能在 A 层做数据隔离，比如灰度期间的中间结果存到临时表，不写入正式表。

Q：灰度期间数据库 Schema 变更，怎么保证回滚后数据不丢失？ A：回滚只是切回流量，不撤回数据变更。如果新字段已有数据，旧版本代码必须能处理（要么忽略，要么有默认值兜底）。不可逆的 Schema 变更（如删除列、修改列类型）必须分两步发布：先发布代码兼容新 Schema，再执行 Schema 变更。如果非要一次性完成，必须用蓝绿部署，回滚时连同数据一起回滚到快照。

Q：灰度期间，新版本的一个 bug 只在特定数据量级下触发，金丝雀流量太小覆盖不到怎么办？ A：这就是金丝雀的"抽样偏差"问题。解法：对灰度流量做定向压测——从灰度环境拉一部分流量到压测工具，模拟真实数据量级。或者在灰度期间开启全量数据比对：新版本和旧版本同时处理同一份请求，但旧版本的结果返回给用户，新版本的结果写入对比表，定时比对差异。这需要 2x 的计算资源，但能在大流量覆盖前发现逻辑不一致。

Q：微服务链路中，多个服务同时灰度发布，灰度版本间怎么保证兼容？ A：多服务灰度必须有一个版本兼容矩阵。比如 A 的 v1.2.4 只能调 B 的 v1.2.4 或 v1.2.3，但调不了 v1.2.2。如果 A 和 B 同时灰度，必须保证 A 的灰度版本和 B 的灰度版本同时部署，且 A 的灰度版本不能调 B 的稳定版本（除非 B 的稳定版本兼容）。实践中，多服务灰度通常用灰度发布平台统一管理，平台维护一个"灰度版本兼容关系表"，不允许跨不兼容的灰度版本调用。

Q：你们公司灰度发布平台怎么设计的？核心模块有哪些？ A：灰度发布平台核心模块包括：① 灰度规则引擎（支持按权重、Header、用户属性、地域等多维度路由）；② 流量染色管理（定义灰度 Header 格式、透传策略）；③ 指标门禁系统（对标金丝雀的 Prometheus 规则，支持自动放量/回滚）；④ 版本兼容矩阵（维护服务间版本依赖关系，灰度时自动检测兼容性）；⑤ 灰度大盘（实时展示灰度流量、实例状态、指标对比）。如果要自己实现，最简 MVP 就是：网关层 + Nacos 元数据 + 自定义 LoadBalancer + ELK 日志过滤，3 个后端开发 2 周可以搭起来。

Q：灰度发布和 AB 测试有什么区别？ A：灰度发布是运维手段，目的是降低发布风险，逐步放量直到全量。AB 测试是产品手段，目的是对比两个版本的效果（如点击率、转化率），可能需要长期运行，且两个版本可能永远不合并。灰度发布的全量是目标，AB 测试的对比是目标。实操中，灰度发布可以复用 AB 测试的流量路由基础设施，但灰度发布的放量逻辑是自动递增的，AB 测试的流量分配是固定的。

总结

灰度发布的关键要点：

• 策略选择：蓝绿部署适合核心链路（资源翻倍，回滚快，注意数据库兼容性）；金丝雀发布适合大多数场景（渐进放量，资源省，注意流量抽样偏差）；灰度发布适合精细化运营（按用户维度分流，复杂但可控）
• 流量染色必须透传：灰度 Header 在跨服务调用时不能丢失，配合 OpenTelemetry Baggage 可将灰度标签带入全链路追踪；虚拟线程场景下避免用 ThreadLocal
• Schema 变更必须向后兼容：先加字段、再改代码、最后清理旧逻辑，这条顺序不能反；索引变更单独发布
• 指标门禁必须设：错误率、延迟、业务指标一票否决，低流量场景用 increase() 而非 rate() 做告警
• 回滚的原子性：评估新版本写入的数据是否可逆，不可逆的变更必须保持新旧兼容，或者用蓝绿部署+快照回滚
• 多集群灰度：按地域独立灰度比全局灰度更可控，灰度放量速度要渐进（1%→10%→50%→100%），每阶段有足够的观察时间
• 面试回答要具体：别只说"用了金丝雀"，要说出策略选择的依据、流量染色怎么透传、数据库兼容性怎么处理、多服务灰度怎么管版本兼容

参考：Istio 官方文档 VirtualService 与 DestinationRule 配置；《Building Microservices》第 8 章 Deployment；Kubernetes 官方文档 Canary Deployments；OpenTelemetry Baggage 规范；Nacos 元数据路由文档；Spring Cloud LoadBalancer 自定义规则文档