LoadBalancer负载均衡：集群高可用调用优化

LoadBalancer负载均衡：集群高可用调用优化

一个服务三个节点，请求来了该打给谁？你总不能闭着眼睛随机点一个吧——那叫"非洲大草原式负载均衡"。今天聊聊 SpringCloud 官方的 LoadBalancer，让你的请求分配得明明白白。

一、负载均衡到底在均衡什么

假设你的product-service部署了 3 个节点，每天被调用 10 万次。如果没有负载均衡，所有请求可能全打到节点 A 上——节点 A CPU 飙到 99%，节点 B 和 C 闲得发慌。这就是典型的流量分配不均。

负载均衡解决三个问题：

• 分摊压力：请求分散到多个节点，避免单点过热
• 提高可用性：某个节点挂了，自动切换到健康的节点
• 横向扩展：流量涨了就加节点，负载均衡自动把新节点纳入调度

1.1 客户端 vs 服务端负载均衡

服务端负载均衡 (Nginx)： 客户端负载均衡 (LoadBalancer)： Client → Nginx ┬→ Server A Client ─── 拉取实例列表 ──→ 注册中心 ├→ Server B │ └→ Server C ├─ 选节点A → 直连 ├─ 选节点B → 直连 └─ 选节点C → 直连 请求先到Nginx 请求直接打到后端，省去一层转发 Nginx负责分发 客户端自己做负载决策

微服务架构里，服务端负载均衡常放在最外层（网关入口），内部服务间调用用客户端负载均衡——两者不是替代关系，而是互补。

二、LoadBalancer 替代 Ribbon

Ribbon 曾是 SpringCloud 标配的客户端负载均衡组件，但 Netflix 在 2018 年宣布其进入维护模式（不再加新功能）。SpringCloud 官方推出了 Spring Cloud LoadBalancer 作为替代。

为什么要换？

• Ribbon 已停更，Bug 不会再修
• Ribbon 基于阻塞式 HTTP 客户端，不适配 WebFlux 响应式场景
• LoadBalancer 原生支持 Spring Reactor，响应式友好

2.1 依赖引入

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-loadbalancer</artifactId></dependency>

无需额外注解，LoadBalancer 会自动配置。如果你同时引入了 Feign 或 SpringCloud Gateway，LoadBalancer 会自动整合。

2.2 LoadBalancer 整合 Nacos

┌──────────────────────────────────────────────┐ │ Nacos 注册中心 │ │ product-service: [192.168.1.10, .11, .12] │ └──────────────────────────────────────────────┘ ↑ 注册 ↓ 定时拉取（30s间隔） ┌─────────────────┐ ┌─────────────────────┐ │ product-service │ │ order-service │ │ (3个实例) │ │ ┌─────────────────┐ │ │ │←───│ │ LoadBalancer │ │ │ │ 调用│ │ ↓ 选一个实例 │ │ └─────────────────┘ │ │ 直连调用 │ │ │ └─────────────────┘ │ └─────────────────────┘

关键点：LoadBalancer 从 Nacos 获取的是服务实例列表的快照缓存，默认每 30 秒刷新一次。这意味着新实例上线最多 30 秒后才能被调用方感知——如果你的服务扩缩容很频繁，需要调小刷新间隔。

三、负载均衡策略

3.1 内置策略

LoadBalancer 默认提供两种策略：

默认就是轮询，如果你就是想要随机的，加个配置即可：

@ConfigurationpublicclassLoadBalancerConfig{@BeanpublicReactorLoadBalancer<ServiceInstance>randomLoadBalancer(Environmentenvironment,LoadBalancerClientFactoryloadBalancerClientFactory){Stringname=environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);returnnewRandomLoadBalancer(loadBalancerClientFactory.getLazyProvider(name,ServiceInstanceListSupplier.class),name);}}

3.2 自定义策略：基于权重的负载均衡

生产环境中，很可能不是所有节点配置相同——8 核 16G 的机器和 4 核 8G 的机器，分配的流量应该不一样。我们来写一个权重负载均衡：

@Slf4jpublicclassWeightedLoadBalancerimplementsReactorServiceInstanceLoadBalancer{privatefinalObjectProvider<ServiceInstanceListSupplier>serviceInstanceListSupplierProvider;privatefinalStringserviceId;publicWeightedLoadBalancer(ObjectProvider<ServiceInstanceListSupplier>supplierProvider,StringserviceId){this.serviceInstanceListSupplierProvider=supplierProvider;this.serviceId=serviceId;}@OverridepublicMono<Response<ServiceInstance>>choose(Requestrequest){ServiceInstanceListSuppliersupplier=serviceInstanceListSupplierProvider.getIfAvailable();returnsupplier.get(request).next().map(instances->{ServiceInstancechosen=chooseByWeight(instances);if(chosen==null){returnnewEmptyResponse();}log.debug("权重策略选中: {}:{}",chosen.getHost(),chosen.getPort());returnnewDefaultResponse(chosen);});}privateServiceInstancechooseByWeight(List<ServiceInstance>instances){if(instances.isEmpty())returnnull;// 从 Nacos 元数据中读取权重，默认 1inttotalWeight=instances.stream().mapToInt(i->Integer.parseInt(i.getMetadata().getOrDefault("weight","1"))).sum();if(totalWeight<=0){// 没有权重配置时回退到轮询returninstances.get(ThreadLocalRandom.current().nextInt(instances.size()));}// 按权重随机intoffset=ThreadLocalRandom.current().nextInt(totalWeight);for(ServiceInstanceinstance:instances){intweight=Integer.parseInt(instance.getMetadata().getOrDefault("weight","1"));offset-=weight;if(offset<0){returninstance;}}returninstances.get(0);}}

配置这个自定义策略：

@ConfigurationpublicclassWeightedLoadBalancerConfig{@BeanpublicReactorLoadBalancer<ServiceInstance>weightedLoadBalancer(Environmentenvironment,LoadBalancerClientFactoryfactory){Stringname=environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);returnnewWeightedLoadBalancer(factory.getLazyProvider(name,ServiceInstanceListSupplier.class),name);}}

然后在 Nacos 配置实例元数据：weight=3（权重越高，被选中的概率越大）。这下你那台 16 核机器的weight设成 3，4 核机器设成 1，流量自然分配得更合理。

四、健康检查与缓存机制

LoadBalancer 依赖 Nacos 的健康检查。Nacos 客户端会定时（默认 5 秒）向服务实例发送心跳，如果超时没收到，就标记该实例不健康，下一轮 LoadBalancer 拉取时就不会包含它。

spring:cloud:loadbalancer:cache:enabled:truettl:30s# 缓存过期时间，即多久刷新一次实例列表capacity:1000# 缓存容量nacos:discovery:heartbeat-interval:5s# 心跳间隔

注意：cache.ttl不宜设得太小，否则频繁从 Nacos 拉取会增加注册中心压力；太大则服务上下线感知慢。30 秒是个合理的默认值。

五、与 Feign 的关系

大多数开发者不需要直接操作 LoadBalancer，因为 Feign 已经帮你集成了——引入spring-cloud-starter-loadbalancer后，Feign 会自动走 LoadBalancer 选节点。你在代码里只用关心 Feign 接口怎么写，负载均衡全程在幕后工作。

User Code ↓ 调用 @FeignClient 代理 ↓ 拦截请求 LoadBalancer.choose(serviceName) ↓ 选出一个实例 HttpURL → http://192.168.1.10:8081/api/product/1 ↓ 发起请求 product-service 实例

六、负载均衡策略对比

总结

LoadBalancer 是微服务内部调用的流量调度器，它从 Nacos 感知服务拓扑，按策略选择目标实例。日常开发中你甚至感觉不到它的存在——Feign 帮你挡掉了所有复杂性。但当你的服务出现流量倾斜、某些节点负载过高时，就该优化负载均衡策略了。