从一起知名线上故障，谈配置灰度发布的重要性

作者：正己

引言

2025 年 6 月 12 日，Google Cloud 经历了一次重大故障，导致 Gmail、YouTube、Google 搜索、Google Cloud API 以及众多依赖其服务的互联网应用出现大规模中断。这次故障从太平洋时间 10:51 开始，直到 18:18 才完全解决，持续了约 7 小时 27 分钟。

根因分析

据 Google Cloud 发布的报告，此次故障产生的根本原因是一个新功能在没有经过充分测试和灰度发布的情况下被直接部署到生产环境，并且处理推送关键配置没有灰度过程。具体来说有以下几个环节：

故障引入：新功能部署

Google Cloud 为 Service Control 系统添加了一个新功能，用于配额策略检查。这个功能在没有经过充分测试和灰度发布的情况下被直接部署到生产环境。

设计缺陷：错误处理不足

新添加的功能缺乏适当的错误处理机制，特别是对于意外的空字段（blank fields）没有进行处理。根据 Reddit 上的信息，代码中存在致命缺陷：无法处理策略数据中的意外空字段。

故障触发：空指针异常

推送新配置，当系统遇到空字段时，代码抛出了空指针异常（null pointer exception），导致 Service Control 实例完全无响应，并进入崩溃循环（crash loop）状态。

连锁反应：全球服务中断

由于推送新配置没有灰度过程，导致配置在全球范围几秒内迅速生效，且 Service Control 是 Google Cloud 的核心组件，负责 API 管理和配额控制，其故障导致了连锁反应，影响了众多依赖 Google Cloud 的服务和应用，造成了全球范围的互联网中断。

配置灰度及常见的实现路径

什么是配置灰度发布

配置灰度发布是一种软件配置变更策略，通过逐步将新的配置参数发布给一部分服务实例或用户，以降低全量发布可能带来的风险。它允许在不影响大多数用户的情况下，验证新配置的有效性和稳定性。

配置灰度的核心思想是在黑（旧配置）与白（新配置）之间，实现平滑过渡的一种发布方式，确保系统稳定性的同时逐步引入新的配置变更。

配置灰度的主要应用场景包括配置参数调整、功能开关切换、系统阈值修改等需要谨慎变更的配置场景，特别适用于高可用性要求的核心业务系统。

配置灰度的常见实现路径

配置灰度发布作为一种降低风险的发布策略，有多种实现路径。根据不同的业务需求和技术架构，可以选择最适合的实现方式。以下是几种常见的配置灰度发布实现路径：

基于标识的灰度发布
- 用户 ID 灰度：根据用户 ID 特征（如尾号）决定是否应用新配置
- IP 地址灰度：基于服务实例 IP 地址进行灰度发布
- 设备特征灰度：根据设备类型（如 iOS/Android）进行灰度
基于规则的灰度发布
- 白名单/黑名单：通过维护特定名单控制配置应用范围
- 标签灰度：给服务实例添加标签，根据标签决定配置版本
- 业务规则灰度：基于业务场景或特定条件进行灰度
基于流量的灰度发布
- 比例灰度：按照一定比例的流量应用新配置
- 区域灰度：根据地理位置或区域进行灰度发布
- 时间窗口灰度：在特定时间段内进行灰度发布
基于架构的灰度发布
- 服务网格灰度：利用服务网格技术控制配置分发
- 网关灰度：在 API 网关层面实现配置灰度
- 配置中心灰度：通过配置中心直接控制配置分发

业务做配置灰度有哪些方案

基于注册配置中心的配置灰度发布能力

目前业界主流的配置中心有 Nacos、Apollo、Disconf、ETCD 等，其中支持配置灰度发布的主要有 Nacos 和 Apollo。

Nacos 目前支持两种灰度方式，基于 IP 灰度和基于标签灰度，支持某个版本的配置只对某些监听者生效。此外，用户还可在 Nacos 标签灰度的基础上扩展 SPI，以贴合自己的业务场景，比如实现设置多值标签、自定义应用标签 SPI、多版本并行灰度等。

Apollo 的配置灰度发布能力相对简单一些，仅支持基于 IP 的灰度能力，也能基于注册配置中心的能力做二次开发扩展自定义配置灰度发布。

基于注册配置中心的能力做二次开发扩展自定义配置灰度发布

对于业务复杂的用户，有复杂的灰度场景，可能需要基于配置中心的基本能力做二次开发。比如阿里巴巴集团基于 Nacos 开发了基于单元/机房的灰度、基于用户 ID 的灰度等功能。

业务自研产品支持配置灰度发布

对于少数业务非常复杂的用户，市场上的配置中心无法满足需求，则需要自研相关方案，比如运行环境很特殊的场景。

对于大多数用户来说，方案一采用 Nacos 或 Apollo 基本能满足配置灰度的需求。少部分用户可能需要基于配置中心做二次开发，建议在 Nacos 的标签灰度之上开发更复杂的方案。

如何基于 Nacos 实现配置灰度

Nacos 配置灰度介绍

Nacos 作为一个动态服务发现、配置管理和服务管理平台，提供了强大的配置灰度发布功能，帮助开发者安全地进行配置变更。本节将介绍 Nacos 配置灰度发布的基本概念、功能特性和使用场景。

Nacos 配置灰度发布的核心功能

基于 IP 的灰度发布：通过指定服务实例的 IP 地址，将新配置仅推送到特定的服务实例，其余实例保持原有配置不变。
基于应用标签的灰度发布：通过为服务实例添加标签，根据标签属性决定配置的推送范围，支持更灵活的灰度策略。
命名空间隔离：利用 Nacos 的命名空间(Namespace)机制，创建独立的灰度环境，与生产环境完全隔离。
配置标识区分：通过在 dataId 或 group 中添加特定标识，区分灰度配置和正式配置，便于管理和追踪。

图1：配置发布流程图

使用 MSE Nacos 进行配置灰度发布

上一节讲述了 Nacos 配置灰度的核心能力，本节讲述基于 IP 的灰度发布和基于标签灰度的具体用法。

基于 IP 的灰度发布

基于 IP 的灰度发布是一种基础的灰度方式，可以通过选择 IP 地址列表来确定需要灰度的机器，在一些小型业务系统中，这种方式可以满足灰度的需求，能够大大降低配置推送的风险，减少因配置出错导致的故障。

mse.console.aliyun.com/

在目标配置的操作列单击编辑。在编辑配置面板，发布方式选择基于 IP 灰度发布。

单击应用节点 IP 输入框，在 IP 地址列表中选择待灰度推送的 IP 地址。您也可以选择手动输入 IP 地址，手动输入支持 IP 地址补全。

修改完配置后，单击发布灰度。在配置内容对比对话框中确认当前正式版本内容和本次发布内容，然后单击发布。

基于标签的灰度发布

为了解决基于 IP 灰度的局限性，MSE Nacos 对灰度发布进行了功能升级，支持了自定义标签灰度的能力，结合原先的 IP 灰度，可以给业务提供更加灵活更加易用的灰度发布能力，为业务稳定性保驾护航。

自定义标签灰度允许应用侧根据其实际场景给不同的节点设置不同的标签，比如给节点设置应用，机房，环境等标签，比如在阿里集团内部，同一个应用在线下环境中有不同的项目开发分支，就给对应的开发分支部署的节点打上项目分支的标签，借助标签灰度的能力实现不同的项目环境下发不同的配置内容。

在 MSE Nacos 2.2.3.3 及以上版本中，支持基于应用标签灰度的方式进行灰度发布，您可以在客户端对应用节点进行标签设置并针对标签进行灰度发布。

1. 客户端设置应用标签

通过以下方式设置应用的标签，应用标签为 key-value 格式。可以通过 properties，JVM 参数和环境变量三种方式指定。相同 key 的情况下，默认优先级：properties > JVM 参数 > env 环境变量，nacos.config.gray.label 是 Nacos 内置的默认配置灰度标签。

typescript 复制代码

//1.properties形式传入
Properties properties = new Properties();
properties.put(PropertyKeyConst.SERVER_ADDR, "your endpoint");
properties.put("project.name", "your app name");
properties.put("nacos.config.gray.label","yourgrayname");
//2.JVM参数设置
设置启动参数-Dnacos.config.gray.label=yourgrayname
//3.env环境变量指定
设置环境变量 nacos_config_gray_label=yourgrayname
 String dataId = "gray_test_dataid";
 String group = "test-group";
 configService.addListener(dataId, group, new Listener() {
        @Override
        public Executor getExecutor() {
            return null;
        }
        @Override
        public void receiveConfigInfo(String configInfo) {
            System.out.println("receiveConfig:" + configInfo);
        }
 });

2. 服务端发布标签灰度