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

背景

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

可以的。

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

image-20240121151018163

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

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

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

代码语言:javascript
复制
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容器)。这个容器里面默认有啥内容呢?

代码语言:javascript
复制
@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写得差不多了,后面写点别的。如果后续需要补充这块,再说。