灰度发布在Java项目中核心是“按条件路由流量”，通过配置中心驱动的动态开关和规则引擎实现运行时控制，支持用户ID哈希、请求头标识等路由策略，并在网关或RPC层统一拦截，配套日志打标、全链路追踪与快速回滚机制。
灰度发布在Java项目中核心是“按条件路由流量”，不靠改代码重启，而是通过可动态控制的开关 + 规则引擎实现。关键在于把“谁能看到新版本”这件事从硬编码里抽出来，变成配置可调、运行时生效的能力。
灰度开关：用配置中心驱动的动态开关
灰度开关不是简单的if (isGray)，而是基于外部配置实时感知状态。推荐用Nacos、Apollo或Spring Cloud Config做开关托管：
- 定义开关名如
feature.user-service.v2.enabled，值为true/false，支持按环境（dev/test/prod）隔离 - Java侧用
@Value("${feature.user-service.v2.enabled:false}")或监听配置变更事件（如Apollo的@ApolloConfigChangeListener）自动刷新内存状态 - 避免直接读文件或写死
static boolean——那样改了要重启，失去灰度意义
灰度路由：按用户/设备/请求特征分发流量
开关只是“开或关”，真正决定“谁走新逻辑”的是路由规则。常见策略有：
-
用户ID哈希分流：取
userId % 100，设定0–9（10%）走新服务，其余走老服务；适合后端接口，稳定且可追溯 -
请求头标识识别：检查Header中是否有
X-Gray-Version: v2或X-Test-User: true，方便测试人员或内部账号手动触发 - 设备指纹/地域/IP段：结合风控或日志系统提取客户端信息，在网关层（如Spring Cloud Gateway）或Feign拦截器中做判断
流量控制：在网关或RPC层统一拦截与降级
灰度不是全量切流，必须可控、可观测、可回滚。建议在统一入口做控制：
立即学习“Java免费学习笔记（深入）”；
- 在Spring Cloud Gateway中写
GlobalFilter，解析请求并根据灰度规则设置ServerWebExchange属性，下游服务通过该属性决定执行路径 - 使用Sentinel或自定义Dubbo/Feign拦截器，在调用前注入灰度上下文（如
GrayContextHolder.setVersion("v2")），服务内通过ThreadLocal读取 - 配合监控埋点：对灰度流量打标（如
metric_name{gray="true"}），实时看QPS、错误率、RT，异常时5秒内关闭开关
配套保障：日志、链路、回滚三件套
没有可观测性，灰度就是黑盒。必须同步落地：
- 所有关键日志加
[gray:v2]前缀，ELK中可快速过滤灰度请求全链路 - 用SkyWalking或Pinpoint确保TraceId贯穿灰度调用链，便于排查v2逻辑中的慢SQL或空指针
- 回滚不是删代码，而是把开关置为
false+ 清空本地缓存（如有）+ 观察1分钟监控无抖动，即完成
基本上就这些。灰度不是高深架构，本质是“把决策逻辑外置+让执行路径可切换”。只要开关可配、路由可算、流量可拦、问题可查，就能稳稳落地。
