8、深夜，一个“优化”搞挂了系统... 面试官：讲讲如何设计一个不“赌命”的发布系统？

Corey2026/1/3大约 10 分钟面试题面试题

来源：8、深夜，一个“优化”搞挂了系统... 面试官：讲讲如何设计一个不“赌命”的发布系统？

凌晨一点，P0 故障告警。你刚上线的新版推荐算法，因为一个隐藏的并发问题，搞挂了整个首页。

紧急回滚后，你一身冷汗地复盘：如果新功能只推送给千分之一的用户，这场 P0 事故本可避免。这种把每次发布都变成一场“赌上职业生涯”的经历，是所有工程师的噩梦，也是系统设计必须解决的核心痛点。

在面试中，当面试官看似随意地问出“如何设计一个灰度发布系统？”时，他其实是在考察你是否具备终结这种噩梦的架构能力。他想知道，你是否能设计一个系统，让发布从一场“豪赌”变成一次“精准的科学实验”。

“用 Nginx 按 IP 分点流量？”

如果你这么回答，那这次面试可能就止步于此了。因为面试官真正关心的是一系列更棘手的现实问题：

场景一：外科手术式的精准发布
“业务想让上海地区、用着鸿蒙系统、App 版本是 10.5 的新注册用户，看到新的UI界面。你的流量策略怎么定？每次都去改服务器配置吗？”
场景二：微服务下的“幽灵漂移”
“一个被灰度命中的请求，要依次经过 A、B、C 三个服务，其中B到C还是异步调用。如何保证它在每一层都准确地被新版本处理，而不是在服务 B ‘漂移’到了老版本？”
场景三：用数据说话的 A/B 对比
“我想同时上线‘算法A’和‘算法B’，用真实用户的点击率来决定哪个更好。这和灰度发布是一回事吗？你的系统如何支持这种‘赛马’机制？”

这些问题的背后，直指一个核心冲突：业务对“灵活创新”的渴求，与分布式系统对“稳定可靠”的铁律之间的永恒矛盾。

面试官真正要考察的，是你能否设计一个平台级、可复用的解决方案，来优雅地化解这个矛盾。所以，问题的本质是：

如何设计一个支持动态规则、全链路流量隔离、并能与业务指标结合的通用灰度发布与 A/B 测试平台？

要完美解答，我们需要像剥洋葱一样，层层递进。

第一层：给流量打上“身份标签”—— 流量染色

要实现精细化控制，我们不能再依赖粗糙的 IP，而是要给流量一个明确的“身份”，我们称之为“灰度标记” (Gray Tag)。为请求打上这个标记的过程，就是“流量染色” (Traffic Dyeing)。

问：这个“身份”从哪里来？

答：在请求的最入口，通常是 API 网关。网关层会根据当前用户的属性（如 UserID、地理位置、设备型号）和平台预设的灰度规则，动态地为这个请求生成一个“灰度标记”。

问：标记放在哪里才能一路传递下去？

答：放在一个能贯穿整个调用链路的“信使”身上。一个完整的微服务系统包含同步调用和异步调用，所以标记的传递也需要覆盖这两种场景。

HTTP 调用：这是最经典、最通用的方式。将标记放在 HTTP Header 中，例如 x-gray-version: v2.1。
RPC 调用（如 Dubbo/gRPC）：几乎所有的 RPC 框架都提供了类似 HTTP Header 的机制，用于传递链路信息，通常被称为 Attachment 或 Metadata。
消息队列（如 RabbitMQ/RocketMQ）：对于异步解耦的场景，灰度标记的传递同样重要。我们可以在发送消息时，将标记作为消息的一个属性（Property）或头部（Header）附加到消息体之外。

通过覆盖这三种主流通信方式，我们才能确保灰度标记在复杂的微服务拓扑中不丢失。

第二层：让“标签”一路通行 —— 全链路灰度

给流量染上色只是第一步，更关键的是要让整条链路上的所有微服务都能“认出”这个颜色，并把它导向正确的实例或逻辑。这需要对不同的通信组件进行扩展。

场景一：HTTP 调用（以 Spring Cloud Gateway + Feign 为例）

这是 Spring Cloud 技术栈中最常见的组合。

1. 入口路由：在 Gateway 中动态选择服务版本

我们可以在 Spring Cloud Gateway 中自定义一个全局过滤器（GlobalFilter），它负责检查请求头，并根据“灰度标记”动态地将请求路由到目标服务的灰度版本。

@Component
public class GrayRoutingFilter implements GlobalFilter, Ordered {
    // 伪代码，仅为演示核心逻辑
    @Override
    public Mono&lt;Void&gt; filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String grayVersion = exchange.getRequest().getHeaders().getFirst("x-gray-version");

        if (StringUtils.hasText(grayVersion)) {
            // 将灰度标记附加到下游请求中，供负载均衡器使用
            exchange.getAttributes().put("gray-version-tag", grayVersion);
        }
        return chain.filter(exchange);
    }
    // ... order setting
}

注意：这里的实现通常配合一个自定义的 LoadBalancer，它会读取 exchange.getAttributes() 中的灰度标记，并据此从 Nacos 等注册中心中筛选出带有相应版本元数据的服务实例。

2. 链路透传：在 Feign 中自动传递 Header

为了让灰度标记在服务间不丢失，我们需要为 Feign 自定义一个请求拦截器（RequestInterceptor），它会自动抓取上游请求的灰度 Header，并附加到所有出站的 Feign 请求上。

@Configuration
public class FeignGrayInterceptor implements RequestInterceptor {
    @Override
    public void apply(RequestTemplate template) {
        // 从当前请求的上下文中获取灰度标记
        ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
        if (attributes != null) {
            HttpServletRequest request = attributes.getRequest();
            String grayVersion = request.getHeader("x-gray-version");
            if (StringUtils.hasText(grayVersion)) {
                // 将灰度标记自动添加到所有出站的 Feign 请求头中
                template.header("x-gray-version", grayVersion);
            }
        }
    }
}

场景二：RPC 调用（以 Dubbo 为例）

Dubbo 强大的 Filter 机制是实现灰度标记透传的关键。

// 在Consumer端Filter中，将灰度标记放入Attachment
// @Activate(group = CommonConstants.CONSUMER)
public class GrayTagConsumerFilter implements Filter {
    public static final String GRAY_TAG_KEY = "gray_version";
    @Override
    public Result invoke(Invoker&lt;?> invoker, Invocation invocation) throws RpcException {
        String grayTag = GrayContextHolder.get(); // GrayContextHolder用于线程内传递标记
        if (StringUtils.isNotBlank(grayTag)) {
            invocation.setAttachment(GRAY_TAG_KEY, grayTag);
        }
        return invoker.invoke(invocation);
    }
}

Provider 端的 Filter 则执行相反的操作：从 Attachment 取出标记，存入 GrayContextHolder，并在调用结束后清理，从而完成一次接力。

场景三：异步调用（以 RocketMQ 为例）

对于消息队列，我们需要在消息发送前“注入”标记，在消息消费前“提取”标记。

// 在消息发送时，将灰度标记放入消息属性
public void send(String topic, Object payload) {
    String grayTag = GrayContextHolder.get();
    Message&lt;?> message = MessageBuilder.withPayload(payload)
            // 将灰度标记作为消息的一个用户属性（Header）
            .setHeaderIfAbsent("gray_version", grayTag)
            .build();
    rocketMQTemplate.send(topic, message);
}

// 在消息消费时，通过AOP从消息属性中恢复灰度标记
@Aspect
@Component
public class GrayRocketMQConsumerAspect {
    @Around("@annotation(org.apache.rocketmq.spring.annotation.RocketMQMessageListener)")
    public Object around(ProceedingJoinPoint joinPoint) throws Throwable {
        // ... 从joinPoint的参数中获取MessageExt ...
        String grayTag = message.getUserProperty("gray_version");
        if (StringUtils.isNotBlank(grayTag)) {
            GrayContextHolder.set(grayTag); // 存入消费者线程上下文
        }
        try {
            return joinPoint.proceed();
        } finally {
            GrayContextHolder.clear(); // 清理上下文
        }
    }
}

通过以上组合设计，无论你的系统是 Spring Cloud 全家桶，还是 Dubbo，亦或两者混合，灰度标记都能像接力棒一样，在整个分布式系统中精准传递。

第三层：从“灰度”到“A/B”—— 数据驱动决策

A/B 测试是灰度发布的“升级版”，它更关心“哪个版本更好”。其本质是并行的、带有业务指标观测的灰度。

问：A/B 和普通灰度核心区别在哪？

答：在于流量分配逻辑和数据回收。

灰度发布：流量是“非此即彼”的，一个用户要么在灰度组，要么不在。目标是验证稳定性。
A/B 测试：流量是“平行对比”的。同一批目标用户会被逻辑上分成不同的小组（A组、B组、对照组），同时体验不同版本的服务。目标是通过数据决策。

问：代码层面如何实现 A/B 逻辑？

答：A/B 测试通常不是在路由层，而是在业务代码内部进行逻辑分流，这需要一个叫“特性开关”(Feature Toggle)或“实验平台”的组件来支持。

@Service
public class RecommendService {
    @Autowired
    private ExperimentClient experimentClient; // A/B 实验平台客户端
    public List&lt;Product&gt; getRecommendations(Long userId) {
        // 向实验平台查询，当前用户命中了哪个实验版本
        String experimentGroup = experimentClient.getGroup("recommend-algo-exp", userId, "control");
        switch (experimentGroup) {
            case "group-A":
                // 用户在实验组 A，调用新算法 A
                log.info("User {} is in group-A", userId);
                return newAlgorithmA(userId);
            case "group-B":
                // 用户在实验组 B，调用新算法 B
                log.info("User {} is in group-B", userId);
                return newAlgorithmB(userId);
            default: // "control"
                // 用户在对照组，调用老算法
                return legacyAlgorithm(userId);
        }
    }
}

这里的 ExperimentClient 内部封装了复杂的哈希和分桶逻辑，能根据 UserID 和实验配置，稳定地将用户划分到不同分组。

第四层：大脑与指挥官 —— 统一管控平台

最后，将所有能力汇聚到一个可视化的管控平台，实现：

规则动态配置：无需改代码、无需重启，像填表格一样创建灰度规则和 A/B 实验。
指标实时监控：对接公司的监控系统（如 Prometheus+Grafana），实时对比灰度版本与老版本的机器性能（CPU、内存）和业务指标（错误率、转化率）。
一键发布与回滚：提供“发布”、“暂停”、“全量”、“回滚”等按钮，让发布过程安全、可控。

总结：如何给面试官一个满意的答案

当面试官再问你这个问题时，你可以这样结构化地回答：

切入痛点：首先说明灰度发布和 A/B 测试是为了解决业务快速迭代与系统稳定性之间的矛盾，避免“发布即赌命”的窘境。
阐述架构：

流量染色：讲解在 API 网关层对流量进行标记。
全链路透传：核心部分！详细阐述灰度标记如何通过 Gateway+Feign 在 HTTP 链路中传递，如何通过 Dubbo Filter 在同步RPC中传递，以及如何通过 AOP+消息属性 在 RocketMQ 异步场景中传递，展现你对混合架构的全面理解。
A/B 测试实现：说明 A/B 测试是灰度的扩展，需要通过独立的实验平台和业务代码内的“特性开关”进行逻辑分流和数据埋点。
管控平台：最后点出需要一个统一的管控平台，实现动态配置、实时监控和一键回滚，赋能业务。

展现经验：主动抛出一些你在实践中会考虑的边界问题，展现你的经验深度。

缓存污染：“为了防止不同版本的用户数据在 Redis 中互相覆盖，缓存 Key 的设计需要加入灰度标记。”
数据库变更：“灰度发布期间，数据库的 Schema 变更必须做到向前和向后兼容，例如只加字段、不删字段，避免新版本写入的数据导致老版本读取失败。”

这样一套组合拳下来，你不仅清晰地展示了技术方案，更重要的是，体现了你作为一名准高级工程师或架构师，对分布式系统复杂性的深刻洞察和驾驭能力。

这，才是面试官真正想要的答案。