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 替代 RibbonRibbon 曾是 SpringCloud 标配的客户端负载均衡组件但 Netflix 在 2018 年宣布其进入维护模式不再加新功能。SpringCloud 官方推出了 Spring Cloud LoadBalancer 作为替代。为什么要换Ribbon 已停更Bug 不会再修Ribbon 基于阻塞式 HTTP 客户端不适配 WebFlux 响应式场景LoadBalancer 原生支持 Spring Reactor响应式友好2.1 依赖引入dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-loadbalancer/artifactId/dependency无需额外注解LoadBalancer 会自动配置。如果你同时引入了 Feign 或 SpringCloud GatewayLoadBalancer 会自动整合。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{BeanpublicReactorLoadBalancerServiceInstancerandomLoadBalancer(Environmentenvironment,LoadBalancerClientFactoryloadBalancerClientFactory){Stringnameenvironment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);returnnewRandomLoadBalancer(loadBalancerClientFactory.getLazyProvider(name,ServiceInstanceListSupplier.class),name);}}3.2 自定义策略基于权重的负载均衡生产环境中很可能不是所有节点配置相同——8 核 16G 的机器和 4 核 8G 的机器分配的流量应该不一样。我们来写一个权重负载均衡Slf4jpublicclassWeightedLoadBalancerimplementsReactorServiceInstanceLoadBalancer{privatefinalObjectProviderServiceInstanceListSupplierserviceInstanceListSupplierProvider;privatefinalStringserviceId;publicWeightedLoadBalancer(ObjectProviderServiceInstanceListSuppliersupplierProvider,StringserviceId){this.serviceInstanceListSupplierProvidersupplierProvider;this.serviceIdserviceId;}OverridepublicMonoResponseServiceInstancechoose(Requestrequest){ServiceInstanceListSuppliersupplierserviceInstanceListSupplierProvider.getIfAvailable();returnsupplier.get(request).next().map(instances-{ServiceInstancechosenchooseByWeight(instances);if(chosennull){returnnewEmptyResponse();}log.debug(权重策略选中: {}:{},chosen.getHost(),chosen.getPort());returnnewDefaultResponse(chosen);});}privateServiceInstancechooseByWeight(ListServiceInstanceinstances){if(instances.isEmpty())returnnull;// 从 Nacos 元数据中读取权重默认 1inttotalWeightinstances.stream().mapToInt(i-Integer.parseInt(i.getMetadata().getOrDefault(weight,1))).sum();if(totalWeight0){// 没有权重配置时回退到轮询returninstances.get(ThreadLocalRandom.current().nextInt(instances.size()));}// 按权重随机intoffsetThreadLocalRandom.current().nextInt(totalWeight);for(ServiceInstanceinstance:instances){intweightInteger.parseInt(instance.getMetadata().getOrDefault(weight,1));offset-weight;if(offset0){returninstance;}}returninstances.get(0);}}配置这个自定义策略ConfigurationpublicclassWeightedLoadBalancerConfig{BeanpublicReactorLoadBalancerServiceInstanceweightedLoadBalancer(Environmentenvironment,LoadBalancerClientFactoryfactory){Stringnameenvironment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);returnnewWeightedLoadBalancer(factory.getLazyProvider(name,ServiceInstanceListSupplier.class),name);}}然后在 Nacos 配置实例元数据weight3权重越高被选中的概率越大。这下你那台 16 核机器的weight设成 34 核机器设成 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 帮你挡掉了所有复杂性。但当你的服务出现流量倾斜、某些节点负载过高时就该优化负载均衡策略了。