我看很多贴子都是针对eureka环境下做静态ServerList配置,目前国内大部分都用Nacos,所以便研究了一下。
micore-service-x:ribbon:listOfServers: ip1:port,ip2:port2NIWSServerListClassName: 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