SpringCloudLoadBalancer权重灰度路由实现方法

Spring Cloud 默认的 RoundRobinLoadBalancer 因完全忽略请求头、实例元数据（如版本号、灰度标签）和权重配置，无法支撑精细化灰度发布；本文深入剖析其局限性，并手把手教你通过重写 `choose(Request)` 方法实现业务感知的权重灰度路由——包括安全提取 `X-Gray-Tag` 等请求头、动态匹配 Nacos 中的元数据标签、基于 `weight` 字段构建累积权重数组并高效完成加权随机选择，同时强调必须配套自定义 `ServiceInstanceListSupplier` 进行上游实例预过滤，否则所有灰度逻辑将形同虚设，最后提醒务必统一各服务的元数据字段命名并做上线前 schema 校验，确保灰度策略在真实生产环境中稳定、准确、可落地。

为什么默认的 RoundRobinLoadBalancer 不适合灰度发布

因为它的选择逻辑只看实例健康状态和注册顺序，完全不感知元数据、版本号或权重配置。当你在 Nacos 里给实例打了 version=v2 和 weight=30，它照样轮询分发，不会把 30% 的流量导向 v2 实例。

真正起作用的是 ReactorServiceInstanceLoadBalancer 接口的实现类，而 Spring Cloud 默认只提供 RoundRobinLoadBalancer 和 RandomLoadBalancer 这两个基础实现 —— 它们不读请求头，也不查元数据，更不支持动态权重计算。

如何让 choose() 方法读取请求头并匹配元数据

关键在于重写 choose(Request request) 方法时，从 request 中提取上下文信息（比如 X-Gray-Tag 或 user-type），再遍历 ServiceInstance 列表做匹配。

• 用 RequestDataContext 提取原始 HTTP 请求：如果是在网关或 Feign 调用中，request 实际是 DefaultRequest，其 context 字段可能包含 ServerWebExchange 或 ClientRequest
• 安全提取 header：不要直接强转，先用 Optional.ofNullable(request.getContext()).map(...) 防 NPE
• 元数据匹配建议用 instance.getMetadata().get("version") 而非硬编码 key，避免不同服务字段不一致

示例片段：

String grayTag = Optional.ofNullable(request.getContext())
    .map(ctx -> (ServerWebExchange) ctx)
    .map(exchange -> exchange.getRequest().getHeaders().getFirst("X-Gray-Tag"))
    .orElse(null);
List candidates = instances.stream()
.filter(i -> Objects.equals(i.getMetadata().get("gray-tag"), grayTag))
.collect(Collectors.toList());

如何实现基于 weight 字段的加权随机路由

单纯过滤出带指定标签的实例还不够 —— 灰度场景常需按比例分配流量，比如 v2 实例权重设为 20，v1 设为 80，整体按 2:8 分流。这需要把元数据中的 weight 解析为整数，并做加权随机选择。

• weight 必须是正整数，且所有同服务实例的 weight 值之和应 > 0，否则 fallback 到 round-robin
• 不要用 Math.random() * sum 线性扫描，对实例数多的集群性能差；改用别名法（Alias Method）或预构建累积权重数组 + 二分查找
• 注意 Nacos/K8s 注册时 weight 是字符串，需 Integer.parseInt(metadata.get("weight")) 并捕获 NumberFormatException

简单可行的累积权重方案：

List weights = instances.stream()
    .map(i -> Integer.parseInt(i.getMetadata().getOrDefault("weight", "1")))
    .collect(Collectors.toList());
int total = weights.stream().mapToInt(Integer::intValue).sum();
int r = ThreadLocalRandom.current().nextInt(total);
int cursor = 0;
for (int i = 0; i 
为什么必须手动注册 ServiceInstanceListSupplier
Spring Boot 自动装配的 ServiceInstanceListSupplier 默认只返回全量健康实例，不支持按元数据过滤。如果你只重写了 ReactorServiceInstanceLoadBalancer，但没替换掉上游的实例供给源，那 choose() 拿到的还是所有实例，过滤逻辑就白写了。
必须声明一个 @Bean 类型为 ServiceInstanceListSupplier，且 @ConditionalOnBean(ReactorServiceInstanceLoadBalancer.class) 控制生效时机
推荐继承 DiscoveryClientServiceInstanceListSupplier，重写 get() 方法，在返回前对 ServiceInstance 列表做预过滤（例如排除 env=dev 的本地实例）
若使用 Nacos，注意 NacosServiceInstanceListSupplier 默认不刷新元数据变更，需配合 @Scheduled 或监听 com.alibaba.nacos.api.naming.listener.Event
漏掉这步，你写的灰度逻辑永远只在“理论上”生效。
最易被忽略的是权重归一化与元数据一致性校验：不同服务可能把权重存在 weight、traffic-weight 或 canary-ratio 字段，而你的负载均衡器若只认一个 key，就会在部分服务上失效。上线前务必用真实 Nacos 实例跑一遍元数据 schema 校验。
本篇关于《SpringCloudLoadBalancer权重灰度路由实现方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！