[Application.yml] By custom configure client Ribbon ineffective] [listOfServers

1, according to today SpringCloud Series IX: from Eureka Use Ribbon - blog Park - Taboo night 153 introduced by [] application.yml custom client configuration Ribbon, found that the configuration of [listOfServers] does not work.

2, tracing a long time because the original is not strictly follow the steps to do the article caused the main reason is because there is no will depend [spring-cloud-starter-netflix-eureka-client] removed.

3, why not rely on this configuration will lead to the failure of it? Because Ribbon for each client, according to the Spring context will be generated for a way to Spring context execution environment. This process will generate the desired configuration by Bean class file postprocessor and configuration, including the configuration class [by] the @Bean RibbonClientConfiguration Method] [ribbonLoadBalancer acquired load balancer.

clip_image001

4, when generating the load balancer to perform the method, the client requires exclusive Spring BeanFactory [] provides various parameters according to the desired Bean definitions, including the [ServerList <Server>] [serverList type parameter].

clip_image002

5、问题就出现在这个参数的获取上,在配置类【RibbonClientConfiguration】和【EurekaRibbonClientConfiguration】中均定义了获取该参数实例的@Bean方法【ribbonServerList】,并且都被【@ConditionalOnMissingBean】注解。这两者在上下文环境即配置文件中未指定参数【NIWSServerListClassName】的值时将会返回不同的默认类型。【RibbonClientConfiguration】返回的是从参数【listOfServers】获取服务器列表的【ConfigurationBasedServerList】,而【EurekaRibbonClientConfiguration】返回的是从Eureka服务端获取服务器列表的【DomainExtractingServerList】。

clip_image003

clip_image004

clip_image005

clip_image006

6、那为什么配置类【EurekaRibbonClientConfiguration】会优先于【RibbonClientConfiguration】呢?这是由于每个客户端的专有Spring上下文是由【SpringClientFactory】生成的,而它是有由两个配置属性【configurations】和【defaultConfigType】,都是用来指定配置类。其中【configurations】是在应用启动时由配置类【RibbonAutoConfiguration】通过@Bean方法【springClientFactory】从全局Spring上下文中获取的,也就是通过注解【@RibbonClients】和【@RibbonClient】指定的Ribbon配置。

Although specified in the initialization [] [SpringClientFactory defaultConfigType] for configuration class [RibbonClientConfiguration], but in the application of these two properties to create a client-specific Spring context, the priority attribute [configurations] in [defaultConfigType], which also determines [a] RibbonClientConfiguration inside @Bean method [ribbonServerList] can not form a defined join [Bean] BeanFactory definition of a set of Bean, that is invalid, and thus can not be instantiated as parameters involved] [ribbonLoadBalancer created.

clip_image007

clip_image008

clip_image009

7, how to solve that problem] [listOfServers it? The simplest is to remove the dependency [spring-cloud-starter-netflix-eureka-client], without removing the dependent parameters can be specified in the configuration file is [] [NIWSServerListClassName com.netflix.loadbalancer. ConfigurationBasedServerList]. In addition to these two methods there is a way to achieve, is to keep EurekaRibbonClientConfiguration configuration class [] to take effect. Although this configuration can not be set class itself, but by the configuration class [@RibbonClients] [RibbonEurekaAutoConfiguration] which was introduced enabling switch may be provided. Just set the properties [ribbon.eureka.enabled] is false, to prevent its entry into force of the Spring context.

clip_image010

clip_image011

8, in tracking this issue also found another situation, that is the custom rule will define a] [ILoadBalancer type of property. In fact, this property is initialized does not matter, because when instance, the property will be replaced with real] [BaseLoadBalancer instance, inside and outside and will replace it twice in its initialization parameters as an example of a true [BaseLoadBalancer].

clip_image012

clip_image013

clip_image014

Guess you like

Origin www.cnblogs.com/StarkBrothers/p/12173252.html