1、【RibbonAutoConfiguration】类之所以成为配置类，是因为被【@Configuration】注解，而【@Configuration】本身又是被【@Component】注解的，所以该配置类最终会被实例化为一个配置向Bean。
2、其存在一个属性【configurations】，是一个List集合，类型为【RibbonClientSpecification】。在该配置类实例化时会被注入【BeanFactory】中所有【RibbonClientSpecification】类型的【BeanDefinition】，其实这些【BeanDefinition】都是一些配置了，用于定义各【RibbonClient】特有的配置，此外还有一些默认的【RibbonClient】配置。
3、调试过程中，通过负载均衡客户端【loadBalancerClient】调用Eureka客户端应用【user】时，发现属性【configurations】已经存在图中的三个配置项，第一个是为应用【user】特别指定的配置，后两个是默认的配置，并且第二个对应的配置类为空。
4、这三个RibbonClient配置的类型均为【RibbonClientSpecification】，后两个的【name】属性以【default】开头，所以是Client的默认配置，第一个的【name】属性为user，对应为自定义的特殊配种。但它们的【configuration】属性分别为三个配置类【com.mq.cloud.movie.ribbon.RibbonConfiguration】、空、【org.springframework.cloud.netflix.ribbon.eureka.EurekaRibbonClientConfiguration】。
5、那这三个配置类是如何与一个名字结合形成【RibbonClientSpecification】实例，并进入【BeanFactory】的Bean定义集合中的呢？
这是因为它们曾作为【@RibbonClients】的【defaultConfiguration】属性或【@RibbonClient】的【configuration】属性出现在某个配置类上。
这两个类都被【@Import(RibbonClientConfigurationRegistrar.class)】注解过。
而Bean定义注册类【RibbonClientConfigurationRegistrar】会将【@RibbonClients】中指定的默认全局配置【defaultConfiguration】和【@RibbonClient】中与Client名字一起指定的配置【configuration】组建成【RibbonClientSpecification】实例，并注入到【BeanFactory】的Bean定义集合中。
6、自定义的应用客户端配置类本身是在扫描时被排除的类，但它被应用在另一个自定义配置类的【@RibbonClient】中，并且在启动类的包路径下， 所以被扫描到Bean定义集合中。
另外两个默认配置是SpringBoot的配置加载规则，从引用包内的【spring.factories】文件开始加载并注入到Bean定义集合中。
下面这一个是没有指定具体配置类的空【@RibbonClients】。
7、通过对配置类的注解递归调用【collectImports】获取其所有的Bean定义导入注册器类。
然后将其实例化的Bean定义导入注册器加入配置类的【importBeanDefinitionRegistrars】属性。这一阶段只是解析配置类并获取注册器，在真正实例化配置类Bean时才会使用这些注册器来生成要导入的实例Bean并注入到【BeanFactory】。
