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负责分发 客户端自己做负载决策| 特性 | 服务端 (Nginx) | 客户端 (LoadBalancer) |
|---|---|---|
| 流量路径 | 请求→Nginx→实例 | 请求→实例（直连） |
| 性能开销 | 多一跳 | 无额外跳转 |
| 配置管理 | 集中配置 | 分散在客户端 |
| 典型场景 | 网关入口 | 微服务内部调用 |
| 实例发现 | 手动配置 upstream | 自动从注册中心拉取 |
微服务架构里，服务端负载均衡常放在最外层（网关入口），内部服务间调用用客户端负载均衡——两者不是替代关系，而是互补。
二、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 默认提供两种策略：
| 策略 | 实现类 | 说明 |
|---|---|---|
| 轮询 (RoundRobin) | RoundRobinLoadBalancer | 依次轮转，默认策略 |
| 随机 (Random) | RandomLoadBalancer | 随机选一个实例 |
默认就是轮询，如果你就是想要随机的，加个配置即可：
@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 帮你挡掉了所有复杂性。但当你的服务出现流量倾斜、某些节点负载过高时，就该优化负载均衡策略了。
