背景
在feign中，一般是通过eureka、nacos等获取服务实例，但有时候调用一些服务时，人家给的是ip或域名，我们这时候还能用Feign这一套吗？
可以的。
有两种方式，一种是直接指定url：
这种是服务端自己会保证高可用、负载均衡那些。
但也可能对方给了多个url（一般不会这样，但是在app场景下，为了极致的高可用，可能会配置多个服务端地址），此时就需要咱们在客户端配置多个url，并且进行负载均衡。
此时应该怎么配置呢？前面的文章提到了，可以像下面这样配置：
yaml
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，看了下最新版本，也还是未修复：
接下来，我们看下，那如果是从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容器）。这个容器里面默认有啥内容呢？
java
@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：