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

背景

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

可以的。

有两种方式，一种是直接指定url：

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

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

此时应该怎么配置呢？前面的文章提到了，可以像下面这样配置：

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这个选项，就会发现，调用报错了。

原因分析

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

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

很明显，是因为我们的服务实例里面的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

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

nacos中获取到的serviceInstance

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

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

此时自然就不会报错了。

静态ip时获取到的serviceInstance

在获取服务实例时，入口是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的，所以在前面的场景中才会报错。

解决办法一

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

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

我们搜了下这个选项：

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

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

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

@LoadBalancerClients(defaultConfiguration = NacosLoadBalancerClientConfiguration.class)

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

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

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

这个办法的缺点：

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

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

解决办法二

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

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

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

总结

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

参考

官网有类似bug：

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