一、 一次"全量发布"引发的生产事故
聊灰度发布之前，先讲一个真实的故障。

某个周四下午，我们合并了一个"优化订单查询性能"的分支。代码review通过了，单元测试通过了，预发布环境也验证过了。按流程，下午3点开始全量发布。

发布后10分钟，监控大屏突然飘红：

订单查询接口RT从80ms飙升到3.2秒

错误率从0.01%上升到8.7%

紧接着用户开始反馈"我的订单列表打不开了"

紧急回滚，但回滚本身又花了15分钟。从发现问题到完全恢复，总计37分钟。

事后排查原因：新代码中有一个SQL优化，在预发布环境（数据量10万条）执行计划正常，但生产环境（数据量5000万条）触发了MySQL优化器的"索引选择错误"，走了全表扫描。

这个事故让我们深刻意识到一个事实：预发布环境永远不可能和生产环境完全一致。 数据量不同、流量特征不同、并发模式不同——在预发布环境"验证通过"的代码，到了生产环境依然可能出问题。

我们需要一种能力：让新代码先对一小部分真实用户生效，观察无误后再逐步扩大范围。 这就是灰度发布的核心价值。

二、 灰度发布的本质与价值
2.1 什么是灰度发布？
灰度发布（Gray Release，也称金丝雀发布）是指：将新版本只部署到部分机器/只对部分用户开放，逐步扩大范围，最终全量上线。

其核心思想可以用一句话概括：“先让1%的用户当’炮灰’，而不是让100%的用户一起’踩雷’。”

2.2 灰度发布的价值
价值维度 说明
风险可控 新版本只影响小部分用户，问题影响面有限
快速回滚 只需将灰度流量切回，不需要重新部署
真实验证 用生产环境的真实流量验证，比预发布环境可靠得多
业务验证 不只是技术验证，还可以验证新功能是否被用户接受
用户感知 大促前可以让内部员工或种子用户先体验
2.3 全链路灰度 vs 单层灰度
真正的灰度发布需要全链路支持：

text
用户请求
↓
[网关层] → 灰度路由（根据header/cookie/用户ID）
↓
[服务A] → 灰度实例（版本v2）
↓
[服务B] → 灰度实例（版本v2）
↓
[数据库] → 灰度数据（通过字段/影子表隔离）
↓
[MQ] → 灰度Topic（消费时隔离）
如果在网关层做了灰度路由，但服务A调用服务B时又回到了旧版本，就会出现"流量断裂"——用户明明进入了灰度链路，但部分请求却走到了旧版本服务上。

三、 技术选型：网关层灰度路由的实现方案
灰度路由是灰度发布的"入口控制点"，主流有三种实现方案：

方案 实现方式 优点 缺点
Nginx + Lua OpenResty，自定义路由逻辑 性能高、无额外组件 逻辑复杂时维护困难
Spring Cloud Gateway 自定义GlobalFilter 与Spring生态集成好 仅限Java技术栈
Kong/APISIX 插件式灰度路由 功能丰富、可视化配置 额外运维组件
我们选用了Spring Cloud Gateway + 自定义GlobalFilter的方案，主要是考虑到技术栈统一和定制灵活性。

3.1 灰度路由的核心逻辑
java
@Component
public class GrayRouteFilter implements GlobalFilter, Ordered {

@Autowired
private GrayRuleService grayRuleService;

@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
    ServerHttpRequest request = exchange.getRequest();
    
    // 1. 获取灰度标识（从多个来源）
    String grayTag = extractGrayTag(request);
    
    if (StringUtils.isNotBlank(grayTag)) {
        // 2. 注入灰度标签到请求头，传递到下游服务
        ServerHttpRequest mutatedRequest = request.mutate()
            .header("X-Gray-Tag", grayTag)
            .header("X-Gray-Version", "v2")
            .build();
        
        ServerWebExchange mutatedExchange = exchange.mutate()
            .request(mutatedRequest)
            .build();
        
        return chain.filter(mutatedExchange);
    }
    
    return chain.filter(exchange);
}

private String extractGrayTag(ServerHttpRequest request) {
    // 优先级1：从请求头获取（手动指定，用于测试）
    String headerTag = request.getHeaders().getFirst("X-Gray-Tag");
    if (StringUtils.isNotBlank(headerTag)) {
        return headerTag;
    }
    
    // 优先级2：从Cookie获取（用于用户级灰度）
    String cookieTag = getCookieValue(request, "gray_tag");
    if (StringUtils.isNotBlank(cookieTag)) {
        return cookieTag;
    }
    
    // 优先级3：根据用户ID计算灰度比例
    String userId = request.getHeaders().getFirst("X-User-Id");
    if (StringUtils.isNotBlank(userId)) {
        GrayRule rule = grayRuleService.getActiveRule("default");
        if (rule != null && shouldGray(userId, rule.getGrayRatio())) {
            return "gray-v2";
        }
    }
    
    return null;
}

private boolean shouldGray(String userId, int grayRatio) {
    // 使用一致性哈希，保证同一个用户每次路由结果一致
    int hash = Math.abs(userId.hashCode()) % 100;
    return hash < grayRatio;
}

}
3.2 灰度规则的动态配置
灰度规则应该支持动态调整，无需重启网关：

java
// 灰度规则实体
@Data
public class GrayRule {
private String ruleId;
private String serviceName;
private String grayVersion; // v2
private int grayRatio; // 0-100，灰度比例
private List whitelist; // 白名单用户ID
private List blacklist; // 黑名单用户ID
private String condition; // 条件表达式（如 “city=Beijing”）
private boolean enabled;
private LocalDateTime createTime;
private LocalDateTime updateTime;
}

// 规则刷新监听器
@Component
public class GrayRuleRefresher {

@Scheduled(fixedDelay = 10000) // 每10秒刷新一次
public void refreshRules() {
    List<GrayRule> rules = grayRuleService.loadAllEnabled();
    localRuleCache.clear();
    localRuleCache.putAll(rules);
    log.info("灰度规则已刷新，共{}条有效规则", rules.size());
}

}
四、 全链路灰度：服务间的灰度流量传递
网关层做了灰度路由还不够——服务A调用服务B时，灰度标签必须继续传递，否则流量就"断了"。

4.1 灰度上下文传递（ThreadLocal + Feign拦截器）
java
// 灰度上下文
public class GrayContext {
private static final ThreadLocal grayTagHolder = new ThreadLocal<>();
private static final ThreadLocal grayVersionHolder = new ThreadLocal<>();

public static void setGrayTag(String tag) {
    grayTagHolder.set(tag);
}

public static String getGrayTag() {
    return grayTagHolder.get();
}

public static void clear() {
    grayTagHolder.remove();
    grayVersionHolder.remove();
}

}

// Feign请求拦截器：将灰度标签传递给下游服务
@Component
public class GrayFeignInterceptor implements RequestInterceptor {

@Override
public void apply(RequestTemplate template) {
    String grayTag = GrayContext.getGrayTag();
    if (StringUtils.isNotBlank(grayTag)) {
        template.header("X-Gray-Tag", grayTag);
        template.header("X-Gray-Version", "v2");
    }
}

}

// RestTemplate拦截器（用于非Feign的HTTP调用）
@Component
public class GrayRestTemplateInterceptor implements ClientHttpRequestInterceptor {

@Override
public ClientHttpResponse intercept(HttpRequest request, byte[] body, 
                                     ClientHttpRequestExecution execution) throws IOException {
    String grayTag = GrayContext.getGrayTag();
    if (StringUtils.isNotBlank(grayTag)) {
        request.getHeaders().add("X-Gray-Tag", grayTag);
        request.getHeaders().add("X-Gray-Version", "v2");
    }
    return execution.execute(request, body);
}

}
4.2 网关到服务的完整链路
text
[网关层]
├─ 解析灰度规则 → 生成 grayTag
├─ 注入请求头 X-Gray-Tag
└─ 将请求路由到 服务A-v2（灰度实例）
↓
[服务A]（v2）
├─ 接收请求头 X-Gray-Tag
├─ 存入 GrayContext（ThreadLocal）
├─ 执行业务逻辑
└─ 调用服务B（通过Feign）
├─ GrayFeignInterceptor 自动注入 X-Gray-Tag
↓
[服务B]（v2）
├─ 接收请求头 X-Gray-Tag
├─ 存入 GrayContext（ThreadLocal）
└─ 执行业务逻辑
↓
[数据库]
└─ 根据 grayTag 判断是否写入影子表
五、 数据库层面的灰度：影子表与数据隔离
灰度发布的"最后一公里"是数据层。如果灰度流量写入了生产数据，而新版本有BUG导致数据污染，后果同样严重。

5.1 影子表方案
影子表（Shadow Table）是业界最常用的数据库灰度隔离方案：

text
生产表：t_order
影子表：t_order_shadow（结构与生产表完全一致）
写入策略：

灰度流量 → 写入 t_order_shadow

正常流量 → 写入 t_order

读取策略：

灰度流量 → 查询 t_order_shadow

正常流量 → 查询 t_order

5.2 MyBatis拦截器实现影子表切换
java
@Intercepts({
@Signature(type = StatementHandler.class, method = “prepare”,
args = {Connection.class, Integer.class})
})
public class ShadowTableInterceptor implements Interceptor {

private static final Set<String> SHADOW_TABLES = new HashSet<>(
    Arrays.asList("t_order", "t_order_item", "t_cart", "t_coupon_usage")
);

@Override
public Object intercept(Invocation invocation) throws Throwable {
    String grayTag = GrayContext.getGrayTag();
    
    // 非灰度流量，直接放行
    if (StringUtils.isBlank(grayTag) || !grayTag.startsWith("gray")) {
        return invocation.proceed();
    }
    
    StatementHandler handler = (StatementHandler) invocation.getTarget();
    BoundSql boundSql = handler.getBoundSql();
    String sql = boundSql.getSql();
    String lowerSql = sql.toLowerCase();
    
    // 检查SQL中是否包含影子表相关表
    for (String table : SHADOW_TABLES) {
        if (lowerSql.contains(table)) {
            String shadowSql = sql.replaceAll(table, table + "_shadow");
            
            // 反射修改SQL
            Field field = boundSql.getClass().getDeclaredField("sql");
            field.setAccessible(true);
            field.set(boundSql, shadowSql);
            break;
        }
    }
    
    return invocation.proceed();
}

}
5.3 影子数据的自动清理
灰度测试完成后，影子表中的数据需要定期清理，避免积累过多：

java
@Component
public class ShadowDataCleaner {

@Scheduled(cron = "0 0 4 * * ?") // 每天凌晨4点执行
public void cleanShadowTables() {
    LocalDateTime threshold = LocalDateTime.now().minusDays(7);
    
    for (String table : SHADOW_TABLES) {
        String shadowTable = table + "_shadow";
        jdbcTemplate.execute(
            String.format("DELETE FROM %s WHERE create_time < '%s'", 
                          shadowTable, threshold)
        );
    }
}

}
六、 AB实验平台：灰度发布的"升级版"
灰度发布是"新老版本之间的切换"，AB实验是"多个版本之间的比较"。两者在技术实现上有很高的共通性。

6.1 灰度发布 vs AB实验
维度 灰度发布 AB实验
核心目标 验证新版本是否稳定 验证哪个方案效果更好
流量分配 逐步扩大（1%→10%→50%→100%） 固定比例（如50%对50%）
持续时间 小时级到天级 天级到周级
成功标准 错误率不上升、性能不下降 CTR/CVR/GMV等业务指标提升
技术实现 基本相同（流量路由 + 分流） 基本相同
可回滚 是 否（实验结束后才能确定胜负）
6.2 AB实验的核心架构
text
[用户请求]
↓
[分流层] → 根据实验配置，将用户分配到不同组
├── 对照组（A组）：使用老版本UI
└── 实验组（B组）：使用新版本UI
↓
[业务层] → 处理业务逻辑，记录实验标签
↓
[数据层] → 业务数据 + 实验标签（用于后续分析）
↓
[分析层] → 对比两组指标，计算统计显著性
6.3 AB实验的分流实现
java
@Service
public class ExperimentService {

private static final Map<String, ExperimentConfig> experiments = new ConcurrentHashMap<>();

// 注册实验
public void registerExperiment(ExperimentConfig config) {
    experiments.put(config.getExperimentKey(), config);
}

// 获取实验分组
public String getVariant(String experimentKey, String userId) {
    ExperimentConfig config = experiments.get(experimentKey);
    if (config == null || !config.isEnabled()) {
        return "default"; // 实验关闭，全部走默认
    }
    
    // 使用一致性哈希分流，保证同一用户每次结果一致
    int hash = Math.abs((experimentKey + "_" + userId).hashCode()) % 100;
    
    int accumulated = 0;
    for (Variant variant : config.getVariants()) {
        accumulated += variant.getTrafficRatio();
        if (hash < accumulated) {
            return variant.getVariantKey();
        }
    }
    
    return config.getDefaultVariant();
}

}

// 实验配置实体
@Data
public class ExperimentConfig {
private String experimentKey; // “homepage_layout_test”
private String experimentName; // “首页布局AB实验”
private List variants; // [A组 50%, B组 50%]
private String defaultVariant; // “A”
private boolean enabled;
private LocalDateTime startTime;
private LocalDateTime endTime;
}

@Data
public class Variant {
private String variantKey; // “A” 或 “B”
private int trafficRatio; // 50
private Map<String, Object> config; // 具体配置参数
}
6.4 AB实验的前端接入
前端页面需要根据分流结果展示不同的UI：

javascript
// 前端AB实验接入
async function getExperimentVariant(experimentKey) {
const response = await fetch(‘/api/exp/variant’, {
method: ‘POST’,
headers: { ‘Content-Type’: ‘application/json’ },
body: JSON.stringify({ experimentKey })
});
const data = await response.json();
return data.variant; // “A” 或 “B”
}

// 根据分组渲染不同的UI
async function renderHomePage() {
const variant = await getExperimentVariant(‘homepage_layout_test’);

if (variant === 'B') {
    // 新版本首页布局
    renderNewHomePage();
    // 埋点记录实验分组
    track('exp_view', { experiment: 'homepage_layout_test', variant: 'B' });
} else {
    // 老版本首页布局（A组或默认）
    renderOldHomePage();
    track('exp_view', { experiment: 'homepage_layout_test', variant: 'A' });
}

}
6.5 AB实验结果分析
实验结束后，需要对比两组数据，判断差异是否具有统计显著性：

sql
– 对比两组的关键指标
SELECT
variant,
COUNT(DISTINCT user_id) AS user_count,
AVG(ctr) AS avg_ctr,
AVG(conversion_rate) AS avg_cvr,
AVG(gmv_per_user) AS avg_gmv
FROM experiment_log
WHERE experiment_key = ‘homepage_layout_test’
AND event_date BETWEEN ‘2024-01-01’ AND ‘2024-01-07’
GROUP BY variant;
python

计算统计显著性

from scipy import stats
import numpy as np

def calculate_significance(group_a, group_b):
# t检验
t_stat, p_value = stats.ttest_ind(group_a, group_b)

# 计算效应量（Cohen's d）
mean_diff = np.mean(group_a) - np.mean(group_b)
pooled_std = np.sqrt((np.var(group_a) + np.var(group_b)) / 2)
cohen_d = mean_diff / pooled_std

return {
    'p_value': p_value,
    'significant': p_value < 0.05,
    'cohen_d': cohen_d,
    'lift': (np.mean(group_a) / np.mean(group_b) - 1) * 100
}

七、 踩坑实录
坑1：灰度用户选择不一致
现象：一个用户首次访问走了灰度版本，刷新页面后走了正常版本。用户体验混乱。

根因：灰度路由时没有使用"一致性哈希"，每次请求独立判断。

解决方案：

java
// 错误：每次随机判断
if (new Random().nextInt(100) < grayRatio) { … }

// 正确：基于用户ID的一致性哈希
int hash = Math.abs(userId.hashCode()) % 100;
if (hash < grayRatio) { … }
坑2：灰度实例的缓存污染
现象：灰度版本更新了缓存中的数据格式，但Redis中的老数据未被清理，导致灰度服务读取到了老格式数据，解析失败。

解决方案：

灰度实例使用独立的缓存Key前缀：gray:${originalKey}

或者在切换版本时主动清理相关缓存

坑3：AB实验的"新奇效应"
现象：新版本上线初期CTR明显高于老版本，但一周后差距消失。

根因：用户对新事物的"新鲜感"导致短期数据虚高。

解决方案：

AB实验至少运行7-14天，排除新奇效应

分析日度趋势，确认提升是否持续

引入留存指标，而不仅仅是"首次点击率"

坑4：实验组之间的干扰
现象：两个实验同时运行，用户同时出现在两个实验中，结果无法归因。

根因：实验流量重叠。

解决方案：

使用分层实验（Layer）：不同实验使用不同的哈希盐值

确保同一层级的实验互斥

八、 总结
灰度发布和AB实验平台的核心能力可以归纳为三个层面：

能力层 关键技术 核心目标
流量路由 一致性哈希、网关过滤、Header传递 精准可控的流量分配
全链路传递 ThreadLocal、Feign拦截器、RestTemplate拦截器 灰度标签不丢失、不断裂
数据隔离 影子表、独立缓存前缀 灰度数据不污染生产数据
三条核心原则：

一致性哈希是分流的基石：确保同一用户/同一请求每次路由结果一致，避免用户"跳来跳去"的糟糕体验。

全链路灰度是分流的保障：网关层灰度了，服务层、数据层也要灰度。任意一层"断裂"都会导致不可预测的问题。

数据隔离是灰度的底线：灰度版本产生的数据必须与生产数据隔离，否则一旦回滚，数据污染将不可逆。

文末思考：

灰度发布和AB实验的本质区别在于"目标不同"——前者是为了"稳妥上线"，后者是为了"科学决策"。建议团队先建立灰度能力，再在此基础上构建AB实验平台，两者共享流量路由和全链路传递的基础设施，可以复用大量代码。