java微服在使用nacos注册中心时，ribbon负载均衡时给部分feign client使用静态serverList

我看很多贴子都是针对eureka环境下做静态ServerList配置，目前国内大部分都用Nacos，所以便研究了一下。

micore-service-x:
  ribbon:
    listOfServers: ip1:port,ip2:port2
    NIWSServerListClassName: com.netflix.loadbalancer.ConfigurationBasedServerList 

micore-service-x: 表示你的微服务名
listOfServers：表示你的微服务实例的’ ip地址+端口’的列表，多个实例用逗号分隔，
NIWSServerListClassName：表示ServerList的类名，这个只能用ConfigurationBasedServerList, 表示使用静态配置的服务列表，而不用动态服务发现。
ConfigurationBasedServerList的核心方法就是derive

我们的ServerList为啥能生效呢？关键就这com.alibaba.cloud.nacos.ribbon.NacosRibbonClientConfiguration#ribbonServerList这个配置类方法，
propertiesFactory.isSet(ServerList.class, config.getClientName())这行代码 会判断Enironment中是否为指定ribbon client配置了相应的ServerList类名。如果配置了，就用你配置的serverlist实现，否则就使用动态的NacosServerList.这里的PropertiesFactory#getClassName会返回Environmen中的clientName.ribbon.NIWSServerListClassName属性值，如果这个属性值存在就实例化这个返回值代表的ServerList类型的一个实例，并且会走完自动注入的bean生命周期。
org.springframework.cloud.netflix.ribbon.PropertiesFactory#get和ApplicationContext.get一样，返回的示例是一个被容器管理的对象，而且这个容器是ApplicationContext的子容器。
有人可能会问静态ServerList有啥用？在真实项目中，大家几乎都是用动态服务发现的，谁会用这么原始的方案？其实它的作用之一就是方便本地调试，本地微服务A要调用本地微服务B,而微服务B在开发环境已经发布了一套，为了不影响其他人的联调、测试，这个本地微服务B一般会加入-Dspring.cloud.nacos.discovery.register-enabled=false这类参数，让这个本地微服务B不注册到注册中心上去。本地联调时可以服务A中配上服务B的本地地址 listOfServers:localhost:server-b-port