当前位置：主页 > java教程 > SpringCloud LoadBalancer负载均衡器

详解SpringCloud LoadBalancer 新一代负载均衡器

发布：2023-03-11 17:00:01 59

本站精选了一篇相关的编程文章，网友袁南晴根据主题投稿了本篇教程内容，涉及到SpringCloud LoadBalancer负载均衡器、SpringCloud LoadBalancer、SpringCloud LoadBalancer负载均衡器相关内容，已被968网友关注，下面的电子资料对本篇知识点有更加详尽的解释。

SpringCloud LoadBalancer负载均衡器

前言

工作中使用 OpenFeign 进行跨服务调用，最近发现线上经常会遇到请求失败。

java.net.ConnectException: Connection refused: connect

通过排查我们发现不是接口超时，而是有时候会请求到已经下线的服务导致报错。这多发生在服务提供者系统部署的时候，因为系统部署的时候会调用 Spring 容器的 shutdown() 方法， Eureka Server 那里能够及时的剔除下线服务，但是我们上一篇文章中已经知道 readOnlyCacheMap 和 readWriteCacheMap 同步间隔是 30S，Client 端拉取实例信息的间隔也是 30S，这就导致 Eureka Client 端存储的实例信息数据在一个临界时间范围内都是脏数据。

调整 Eureka 参数

既然由于 Eureka 本身的设计导致会存在服务实例信息延迟更新，那么我们尝试去修改几个参数来降低延迟

Client 端设置服务拉取间隔3S， eureka.client.registry-fetch-interval-seconds = 3
Server 端设置读写缓存同步间隔 3S，eureka.server.response-cache-update-interval-ms=3000

这样设置之后经过一段时间的观察发现情况有所改善，但还是存在这个问题，而且并没有改善多少。

LoadBalancer 如何获取实例信息

在 Eureka 和 OpenFeign 的文章中都有提到，OpenFeign 进行远程调用的时候会通过负载均衡器选取一个实例发起 Http 请求。我们 SpringCloud 版本是 2020，已经移除了 ribbon，使用的是 LoadBalancer。

通过 debug OpenFeign 调用的源码发现它是从 DiscoveryClientServiceInstanceListSupplier的构造方法获取实例信息集合 List<ServiceInstance> 的，内部调用到 CachingServiceInstanceListSupplier 构造方法，重点看 CacheFlux.lookup()

public CachingServiceInstanceListSupplier(ServiceInstanceListSupplier delegate, CacheManager cacheManager) {
   super(delegate);
   this.serviceInstances = CacheFlux.lookup(key -> {
      // TODO: configurable cache name
      Cache cache = cacheManager.getCache(SERVICE_INSTANCE_CACHE_NAME);
      if (cache == null) {
         if (log.isErrorEnabled()) {
            log.error("Unable to find cache: " + SERVICE_INSTANCE_CACHE_NAME);
         }
         return Mono.empty();
      }
      List<ServiceInstance> list = cache.get(key, List.class);
      if (list == null || list.isEmpty()) {
         return Mono.empty();
      }
      return Flux.just(list).materialize().collectList();
   }, delegate.getServiceId()).onCacheMissResume(delegate.get().take(1))
         .andWriteWith((key, signals) -> Flux.fromIterable(signals).dematerialize().doOnNext(instances -> {
            Cache cache = cacheManager.getCache(SERVICE_INSTANCE_CACHE_NAME);
            if (cache == null) {
               if (log.isErrorEnabled()) {
                  log.error("Unable to find cache for writing: " + SERVICE_INSTANCE_CACHE_NAME);
               }
            }
            else {
               cache.put(key, instances);
            }
         }).then());
}

这里先去查缓存，缓存有就直接返回，缓存没有就去 CompositeDiscoveryClient.getInstances() 查询。查询完毕之后会回调到 CacheFlux.lookup(param,param2) 第二个参数的代码块，将结果放进缓存。

@Override
public List<ServiceInstance> getInstances(String serviceId) {
   if (this.discoveryClients != null) {
      for (DiscoveryClient discoveryClient : this.discoveryClients) {
         List<ServiceInstance> instances = discoveryClient.getInstances(serviceId);
         if (instances != null && !instances.isEmpty()) {
            return instances;
         }
      }
   }
   return Collections.emptyList();
}

重点看这个方法，由于我们使用的是 Eureka 作为注册中心。所以这里会调用 EurekaDiscoveryClient 的getInstances()，最终我们发现底层其实就是从 DiscoveryClient.localRegionApps 获取的服务实例信息。

现在我们清楚了，OpenFeign 调用时，负载均衡策略还不是从 DiscoveryClient.localRegionApps 直接拿的实例信息，是自己缓存了一份。这样一来，不仅要计算 Eureka 本身的延迟，还要算上缓存时间。

SpringCloud 中有很多内存缓存的实现，这里我们选择的是 Caffine

<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <version>3.0.5</version>
</dependency>

引入依赖即可自动配置，从 LoadBalancerCacheProperties 中我们能够发现默认的缓存时间是 35S，所以要解决我们的问题还需要降低缓存时间，也可以直接不使用内存缓存，每次都从 EurekaClient 拉取过来的实例信息读取即可。

通过上面的分析我们可以发现使用 OpenFeign 内部调用是无法根治这个问题的，因为 Eureka 的延迟是无法根治的，只能说在维持机器性能等各方面的前提下尽可能的缩短数据同步定时任务的时间间隔。所以我们可以换个角度，让调用失败的请求进行重试。

LoadBalancer 的两种负载均衡策略

通过源码调试，发现它有两种负载均衡策略 RoundRobinLoadBalancer、RandomLoadBalancer，轮询和随机，默认的策略是轮询

LoadBalancerClientConfiguration 类

@Bean
@ConditionalOnMissingBean
public ReactorLoadBalancer<ServiceInstance> reactorServiceInstanceLoadBalancer(Environment environment,
      LoadBalancerClientFactory loadBalancerClientFactory) {
   String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
   return new RoundRobinLoadBalancer(
         loadBalancerClientFactory.getLazyProvider(name, ServiceInstanceListSupplier.class), name);
}

这两种策略都比较简单，没什么好说的。

轮询策略存在的问题

我们可以观察下轮询策略的实现，它有一个原子类型的成员变量，用来记录下一次请求要落到哪一个实例

final AtomicInteger position;

核心逻辑

private Response<ServiceInstance> getInstanceResponse(List<ServiceInstance> instances) {
   if (instances.isEmpty()) {
      if (log.isWarnEnabled()) {
         log.warn("No servers available for service: " + serviceId);
      }
      return new EmptyResponse();
   }
   // TODO: enforce order?
   int pos = Math.abs(this.position.incrementAndGet());
   ServiceInstance instance = instances.get(pos % instances.size());
   return new DefaultResponse(instance);
}

可以看到实现逻辑很简单，用 position 自增，然后实例数量进行求余，达到轮询的效果。乍一看好像没问题，但是它存在这样一种情况。现在我们有两个实例 192.168.1.121、192.168.1.122，这时候两个请求 A、B 过来，A 请求了 121 的，B 请求了 122 的，然后 A 请求失败了触发重试，由于轮询机制 A 重试的实例又回到了 121 ，这样就有问题了，因为还是失败，我们要让重试的请求一定能重试到其他的服务实例。

使用 TraceId 实现自定义负载均衡策略

因为重试的时候是在 OpenFeign 内部重新发起了一次 HTTP 请求，所以 traceId 并没有变，我们可以先从 MDC 上下文获取 traceId，再从缓存中获取 traceId 对应的值，如果没有就随机生成一个数字然后和 RoundRobinLoadBalancer 一样自增求余，如果缓存中已经有了就直接自增求余，这样就一定能重试到不同的实例。

这里我们缓存组件还是使用 Caffeine

private final LoadingCache<String, AtomicInteger> positionCache = Caffeine.newBuilder().expireAfterWrite(1, TimeUnit.MINUTES)
      .build(k -> new AtomicInteger(ThreadLocalRandom.current().nextInt(0, 1000)));

private Response<ServiceInstance> getInstanceResponse(List<ServiceInstance> serviceInstances) {
   if (serviceInstances.isEmpty()) {
      log.warn("No servers available for service: " + serviceId);
      return new EmptyResponse();
   }
   String traceId = MDC.get("traceId");
   if (traceId == null) {
      traceId = UUID.randomUUID().toString();
   }
   AtomicInteger seed = positionCache.get(traceId);
   int s = seed.getAndIncrement();
   int pos = s % serviceInstances.size();
   return new DefaultResponse(serviceInstances.stream()
         .sorted(Comparator.comparing(ServiceInstance::getInstanceId))
         .collect(Collectors.toList()).get(pos));
}

这个方法是从哈希哥那里学到的，他的主页 juejin.cn/user/501033… 。

完了之后声明我们自己的负载均衡器的 Bean

public class FeignLoadBalancerConfiguration {
    @Bean
    public ReactorLoadBalancer<ServiceInstance> reactorServiceInstanceLoadBalancer(ObjectProvider<ServiceInstanceListSupplier> serviceInstanceListSuppliers, Environment environment) {
        String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
        return new RoundRobinRetryDifferentInstanceLoadBalancer(serviceInstanceListSuppliers,name);
    }
}

之后在主启动类上使用 @LoadBalancerClient 指定我们自定义的负载均衡器

@LoadBalancerClient(name = "feign-test-product", configuration = FeignLoadBalancerConfiguration.class)

设置 LoadBalancer Zone

还记得之前 Eureka 我们为了解决本机调用的时候会通过负载均衡调用到开发环境的机器设置了 zone，SpringCloud LoadBalancer 也提供了这个配置，并且从源码中我们可以发现，最终会以 LoadBalancer 设置的为准，如果没有为它设置，那么会使用 Eureka 中的 zone 配置，如果设置了就会覆盖 Eureka 的 zone 设置

EurekaLoadBalancerClientConfiguration.postprocess()

@PostConstruct
public void postprocess() {
   if (!StringUtils.isEmpty(zoneConfig.getZone())) {
      return;
   }
   String zone = getZoneFromEureka();
   if (!StringUtils.isEmpty(zone)) {
      if (LOG.isDebugEnabled()) {
         LOG.debug("Setting the value of '" + LOADBALANCER_ZONE + "' to " + zone);
      }
      zoneConfig.setZone(zone);
   }
}

以上就是详解SpringCloud LoadBalancer 新一代负载均衡器的详细内容，更多关于SpringCloud LoadBalancer负载均衡器的资料请关注码农之家其它相关文章！

上一篇：解决2022.3.1版本中 IDEA中 XML文件提示屎黄色背景的方法
下一篇：浅谈SpringBoot在使用测试的时候是否需要@RunWith

参考资料

网友讨论

最新更新

最近更新

05-29Go语言面试八股文大全
05-29MySQL 8.4中文手册
05-29华为OD机考100题(真题)
05-29Python+OpenCV入门计算机视觉实战项目52讲 v1.0
05-21敏捷软件测试实践指南
05-21编写可维护的JavaScript
05-21Modbus协议
05-21竹林蹊径：深入浅出Windows驱动开发
05-21PCIE规范合集(PCI_Express_Base 1.0/2.1/3.0/4.0/5.0/6.0)
05-21深入理解Rust并发编程

热门资源