• Feign源码解析7:nacos loadbalancer不支持静态ip的负载均衡


    背景#

    在feign中,一般是通过eureka、nacos等获取服务实例,但有时候调用一些服务时,人家给的是ip或域名,我们这时候还能用Feign这一套吗?

    可以的。

    有两种方式,一种是直接指定url:

    image-20240121151018163

    这种是服务端自己会保证高可用、负载均衡那些。

    但也可能对方给了多个url(一般不会这样,但是在app场景下,为了极致的高可用,可能会配置多个服务端地址),此时就需要咱们在客户端配置多个url,并且进行负载均衡。

    此时应该怎么配置呢?前面的文章提到了,可以像下面这样配置:

    Copy
    spring: application: discovery: client: simple: instances: echo-service-provider: - uri: http://1.1.1.1:8082 metadata: my: instance1 - uri: http://2.2.2.2:8082 metadata: my: instance2

    但是,这第二种方式下,如果你同时使用了nacos,且打开了spring.cloud.loadbalancer.nacos.enabled=true这个选项,就会发现,调用报错了。

    image-20240121151628850

    原因分析#

    从上面的错误堆栈可以看到,在执行Double.parseDouble的时候抛了空指针异常,为啥还涉及什么浮点数呢?

    我们定位到报错的地方,原来是获取服务实例的权重值的时候,报错了:

    image-20240121151853048

    很明显,是因为我们的服务实例里面的metadata字段,没有nacos.weight这个属性,所以是null,自然就空指针了。

    这里的服务实例是ServiceInstance,这是个通用接口,定义在spring-cloud-commons中的,按理说,你作为一种实现,是需要考虑到传入的ServiceInstance不一定就有这个属性,比如可能是Eureka管理的。但是上面报错的地方又强制假设这个地方一定是metadata拥有nacos.weight。

    这块就是个兼容性bug,看了下最新版本,也还是未修复:

    https://github.com/alibaba/spring-cloud-alibaba/blob/2022.x/spring-cloud-alibaba-starters/spring-cloud-starter-alibaba-nacos-discovery/src/main/java/com/alibaba/cloud/nacos/balancer/NacosBalancer.java#L58

    image-20240121152632222

    接下来,我们看下,那如果是从nacos获取到的serviceInstance,是不是就没有这个问题?为啥配置静态ip地址的时候,就有这个问题。

    nacos中获取到的serviceInstance#

    咱们先把前面的静态ip配置去掉,改为从nacos获取。

    image-20240121153456819

    从上图看到,此时实例类型是com.alibaba.cloud.nacos.NacosServiceInstance:

    image-20240121153542584

    此时自然就不会报错了。

    静态ip时获取到的serviceInstance#

    image-20240121153910030

    在获取服务实例时,入口是org.springframework.cloud.client.discovery.composite.CompositeDiscoveryClient#getInstances,它内部聚合了两个discoveryClient,第一个是simpleDiscoveryClient,这个就是从静态ip获取服务实例,可以看到其order是-1,所以它排在了第一位;第二个是nacosDiscoveryClient,由于它的order值是0,所以排序靠后。

    从simpleDiscoveryClient中获取到的serviceInstance的类型就是org.springframework.cloud.client.DefaultServiceInstance,它内部自然是没有配置nacos相关的metadata的,所以在前面的场景中才会报错。

    image-20240121153833435

    解决办法一#

    既然nacos这个loadbalancer不兼容静态ip这种org.springframework.cloud.client.DefaultServiceInstance,那我不使用nacos的loadbalancer不就可以了。

    是的,只要你不打开spring.cloud.loadbalancer.nacos.enabled=true这个选项,就不会用到nacos的这个loadbalancer。

    我们搜了下这个选项:

    image-20240121154722753

    这被弄成了一个条件注解。这个条件用于以下的自动装配类:

    image-20240121154806179

    image-20240121154854657

    在之前的文章里,我们提到了,每个feign服务只要url没指定,就默认是走负载均衡,就会有一个loadbalancerClient。

    每个loadbalancerClient都是通过一个spring容器来的,每个服务都有一个自己的用于创建loadbalancer的spring容器(比如这里的echo-service,就有一个自己的用于创建loadbalancer的spring容器)。这个容器里面默认有啥内容呢?

    Copy
    @LoadBalancerClients(defaultConfiguration = NacosLoadBalancerClientConfiguration.class)

    这里的NacosLoadBalancerClientConfiguration.class就会被作为各个spring容器的默认配置类。

    image-20240121155450960

    这里就会自动配置一个NacosLoadBalancer,一旦有了这个bean,spring-cloud-loadbalancer里的默认配置,就不会生效了:

    image-20240121155754346

    最终获取bean的时候,就拿到了nacos的这个NacosLoadBalancer类型的bean,进行负载均衡。

    image-20240121160127329

    这个办法的缺点:

    这个选项是全局的,不能针对某一个服务来单独开启,这个选项一旦关了,那么其他的走nacos的服务,也就没法用nacosLoadBalancer了。

    所以,我们想到了如下的方法。

    解决办法二#

    我们上面提到,这个nacosLoadBalancer被自动装配进去的,那么,破解自动装配的办法就是你自己定义一个这种类型的bean,它就不会再自动装配了。

    image-20240121162841370

    image-20240121162914911

    这样的话,echo-service-provider的spring容器创建时,就会优先把这个配置class注册到容器里:

    image-20240121163142851

    这种办法的优势是,可以在spring.cloud.loadbalancer.nacos.enabled=true开启的情况下,解决本文的问题。就是,nacos的依然可以用nacosLoadBalancer来负载均衡;静态ip的服务,就可以用轮询这种loadbalancer。

    总结#

    这个feign写得差不多了,后面写点别的。如果后续需要补充这块,再说。

    参考#

    官网有类似bug:

    https://github.com/alibaba/spring-cloud-alibaba/issues/3346




  • 相关阅读:
    oracle的正则表达式(regular expression)
    自动化测试教程(20)了解PageObject模式
    Linux系统编程·环境变量
    关于Python的局部变量和全局变量使用介绍
    《机械设计基础》题库
    基于后端和爬虫创建的代理ip池
    JUC并发编程——单例模式(基于狂神说的学习笔记)
    关于匿名内部类
    linux-任务计划和日志管理
    SpringMVC入门指南
  • 原文地址:https://www.cnblogs.com/grey-wolf/p/17978012