「SpringCloud原理」Ribbon核心组件以及运行原理万字源码剖析
大家好，本文我将继续来剖析SpringCloud中负载均衡组件Ribbon的源码。本来我是打算接着OpenFeign动态代理生成文章直接讲Feign是如何整合Ribbon的，但是文章写了一半发现，如果不把Ribbon好好讲清楚，那么有些Ribbon的细节理解起来就很困难，所以我还是打算单独写一篇文章来剖析Ribbon的源码，这样在讲Feign整合Ribbon的时候，我就不再赘述这些细节了。好了，话不多说，直接进入主题。
这是个很简单的东西，就是服务实例数据的封装，里面封装了服务实例的ip和端口之类的，一个服务有很多台机器，那就有很多个Server对象。
ServerList是个接口，泛型是Server，提供了两个方法，都是获取服务实例列表的，这两个方法其实在很多实现类中实现是一样的，没什么区别。这个接口很重要，因为这个接口就是Ribbon获取服务数据的来源接口，Ribbon进行负载均衡的服务列表就是通过这个接口来的，那么可以想一想是不是只要实现这个接口就可以给Ribbon提供服务数据了？事实的确如此，在SpringCloud中，eureka、nacos等注册中心都实现了这个接口，都将注册中心的服务实例数据提供给Ribbon，供Ribbon来进行负载均衡。
通过名字也可以知道，是用来更新服务注册表的数据，他有唯一的实现，就是PollingServerListUpdater，这个类有一个核心的方法，就是start，我们来看一下start的实现。
通过这段方法我们可以看出，首先通过isActive.compareAndSet(false, true)来保证这个方法只会被调用一下，然后封装了一个Runnable，这个Runnable干了一件核心的事，就是调用传入的updateAction的doUpdate方法，然后将Runnable扔到了带定时调度功能的线程池，经过initialDelayMs（默认1s）时间后，会调用一次，之后都是每隔refreshIntervalMs（默认30s）调用一次Runnable的run方法，也就是调用updateAction的doUpdate方法。
所以这个类的核心作用就是每隔30s会调用一次传入的updateAction的doUpdate方法的实现，记住这个结论。
IRule是负责负载均衡的算法的，也就是真正实现负载均衡获取一个服务实例就是这个接口的实现。比如说实现类RandomRule，就是从一堆服务实例中随机选取一个服务实例。
就是一个配置接口，有个默认的实现DefaultClientConfigImpl，通过这个可以获取到一些配置Ribbon的一些配置。
这个接口的作用，对外主要提供了获取服务实例列表和选择服务实例的功能。虽然对外主要提供获取服务的功能，但是在实现的时候，主要是用来协调上面提到的各个核心组件的，使得他们能够协调工作，从而实现对外提供获取服务实例的功能。
这个接口的实现有好几个实现类，但是我讲两个比较重要的。
BaseLoadBalancer
核心属性
allServerList：缓存了所有的服务实例数据
upServerList：缓存了能够使用的服务实例数据。
rule：负载均衡算法组件，默认是RoundRobinRule
核心方法
setRule：这个方法是设置负载均衡算法的，并将当前这个ILoadBalancer对象设置给IRule，从这可以得出一个结论，IRule进行负载均衡的服务实例列表是通过ILoadBalancer获取的，也就是 IRule 和 ILoadBalancer相互引用。setRule(rule)一般是在构造对象的时候会调用。
chooseServer：就是选择一个服务实例，是委派给IRule的choose方法来实现服务实例的选择。
BaseLoadBalancer这个实现类总体来说，已经实现了ILoadBalancer的功能的，所以这个已经基本满足使用了。
说完BaseLoadBalancer这个实现类，接下来说一下DynamicServerListLoadBalancer实现类。DynamicServerListLoadBalancer继承自BaseLoadBalancer，DynamicServerListLoadBalancer主要是对BaseLoadBalancer功能进行扩展。
DynamicServerListLoadBalancer
成员变量
serverListImpl：上面说过，通过这个接口获取服务列表
filter:起到过滤的作用，一般不care
updateAction：是个匿名内部类，实现了doUpdate方法，会调用updateListOfServers方法
serverListUpdater：上面说到过，默认就是唯一的实现类PollingServerListUpdater，也就是每个30s就会调用传入的updateAction的doUpdate方法。
这不是巧了么，serverListUpdater的start方法需要一个updateAction，刚刚好成员变量有个updateAction的匿名内部类的实现，所以serverListUpdater的start方法传入的updateAction的实现其实就是这个匿名内部类。
那么哪里调用了serverListUpdater的start方法传入了updateAction呢？是在构造的时候调用的，具体的调用链路是调用 restOfInit - enableAndInitLearnNewServersFeature()，这里就不贴源码了
所以，其实DynamicServerListLoadBalancer在构造完成之后，默认每隔30s中，就会调用updateAction的匿名内部类的doUpdate方法，从而会调用updateListOfServers。所以我们来看一看 updateListOfServers 方法干了什么。
这个方法实现很简单，就是通过调用 ServerList 的getUpdatedListOfServers获取到一批服务实例数据，然后过滤一下，最后调用updateAllServerList方法，进入updateAllServerList方法。
其实很简单，就是调用每个服务实例的setAlive方法，将isAliveFlag设置成true，然后调用setServersList。setServersList这个方法的主要作用是将服务实例更新到内部的缓存中，也就是上面提到的allServerList和upServerList，这里就不贴源码了。
其实分析完updateListOfServers方法之后，再结合上面源码的分析，我们可以清楚的得出一个结论，那就是默认每隔30s都会重新通过ServerList组件获取到服务实例数据，然后更新到BaseLoadBalancer缓存中，IRule的负载均衡所需的服务实例数据，就是这个内部缓存。
从DynamicServerListLoadBalancer的命名也可以看出，他相对于父类BaseLoadBalancer而言，提供了动态更新内部服务实例列表的功能。
为了便于大家记忆，我画一张图来描述这些组件的关系以及是如何运作的。
说完一些核心的组件，以及他们跟ILoadBalancer的关系之后，接下来就来分析一下，ILoadBalancer是在ribbon中是如何使用的。
ILoadBalancer是一个可以获取到服务实例数据的组件，那么服务实例跟什么有关，那么肯定是跟请求有关，所以在Ribbon中有这么一个抽象类，AbstractLoadBalancerAwareClient，这个是用来执行请求的，我们来看一下这个类的构造。
通过上面可以看出，在构造的时候需要传入一个ILoadBalancer。
AbstractLoadBalancerAwareClient中有一个方法executeWithLoadBalancer，这个是用来执行传入的请求，以负载均衡的方式。
这个方法构建了一个LoadBalancerCommand，随后调用了submit方法，传入了一个匿名内部类，这个匿名内部类中有这么一行代码很重要。
这行代码是根据给定的一个Server重构了URI，这是什么意思呢？举个例子，在OpenFeign那一篇文章我说过，会根据服务名拼接出类似 http:// ServerA 的地址，那时是没有服务器的ip地址的，只有服务名，假设请求的地址是 http:// ServerA/api/sayHello ，那么reconstructURIWithServer干的一件事就是将ServerA服务名替换成真正的服务所在的机器的ip和端口，假设ServerA所在的一台机器（Server里面封装了某台机器的ip和端口）是192.168.1.101:8088，那么重构后的地址就变成 http:// 192.168.1.101:8088/api/ sayHello ，这样就能发送http请求到ServerA服务所对应的一台服务器了。
之后根据新的地址，调用这个类中的execute方法来执行请求，execute方法是个抽象方法，也就是交给子类实现，子类就可以通过实现这个方法，来发送http请求，实现rpc调用。
那么这台Server是从获取的呢？其实猜猜也知道，肯定是通过ILoadBalancer获取的，因为submit方法比较长，这里我直接贴出submit方法中核心的一部分代码
就是通过selectServer来选择一个Server的，selectServer我就不翻源码了，其实最终还是调用ILoadBalancer的方法chooseServer方法来获取一个服务，之后就会调用上面的说的匿名内部类的方法，重构URI，然后再交由子类的execut方法来实现发送http请求。
所以，通过对AbstractLoadBalancerAwareClient的executeWithLoadBalancer方法，我们可以知道，这个抽象类的主要作用就是通过负载均衡算法，找到一个合适的Server，然后将你传入的请求路径 http:// ServerA/api/sayHello 重新构建成类似 http:// 192.168.1.101:8088/api/ sayHello 这样，之后调用子类实现的execut方法，来发送http请求，就是这么简单。
到这里其实Ribbon核心组件和执行原理我就已经说的差不多了，再来画一张图总结一下
说完了Ribbon的一些核心组件和执行原理之后，我们再来看一下在SpringCloud环境下，这些组件到底是用的哪些实现，毕竟有写时接口，有的是抽象类。
Ribbon的自动装配类：RibbonAutoConfiguration，我拎出了核心的源码
RibbonAutoConfiguration配置类上有个@RibbonClients注解，接下来讲解一下这个注解的作用
SpringClientFactory是不是感觉跟OpenFeign中的FeignContext很像，其实两个的作用是一样的，SpringClientFactory也继承了NamedContextFactory，实现了配置隔离，同时也在构造方法中传入了每个容器默认的配置类RibbonClientConfiguration。至于什么是配置隔离，我在OpenFeign那篇文章说过，不清楚的小伙伴可以后台回复feign01即可获得文章链接。
配置优先级问题
优先级最低的就是FeignContext和SpringClientFactory构造时传入的配置类
至于优先级怎么来的，其实是在NamedContextFactory中createContext方法中构建AnnotationConfigApplicationContext时按照配置的优先级一个一个传进去的。
RibbonClientConfiguration提供的默认的bean
接下来我们看一下RibbonClientConfiguration都提供了哪些默认的bean
配置类对应的bean，这里设置了ConnectTimeout和ReadTimeout都是1s中。
IRule，默认是ZoneAvoidanceRule，这个Rule带有过滤的功能，过滤哪些不可用的分区的服务（这个过滤可以不用care），过滤成功之后，继续采用线性轮询的方式从过滤结果中选择一个出来。至于这个propertiesFactory，可以不用管，这个是默认读配置文件的中的配置，一般不设置，后面看到都不用care。
至于为什么容器选择NacosServerList而不是ConfigurationBasedServerList，主要是因为NacosRibbonClientConfiguration这个配置类是通过@RibbonClients导入的，也就是比SpringClientFactory导入的RibbonClientConfiguration配置类优先级高。
ServerListUpdater，就是我们剖析的PollingServerListUpdater，默认30s更新一次BaseLoadBalancer内部服务的缓存。
那么在springcloud中，上图就可以加上注册中心。
三、总结
本文剖析了Ribbon这个负载均衡组件中的一些核心组件的源码，并且将这些组件之间的关系一一描述清楚，同时也剖析了在发送请求的时候是如何通过ILoadBalancer获取到一个服务实例，重构URI的过程。希望本篇文章能够让你知道Ribbon是如何工作的。
Spring Cloud 常用组件梳理
业务场景:
创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付”
扣减相应的商品库存
通知仓储中心，进行发货
给用户的这次购物增加相应的积分
针对上述流程，我们需要有订单服务、库存服务、仓储服务、积分服务。整个流程的大体思路如下：
用户针对一个订单完成支付之后，就会去找订单服务，更新订单状态
订单服务调用库存服务，完成相应功能
订单服务调用仓储服务，完成相应功能
订单服务调用积分服务，完成相应功能
至此，整个支付订单的业务流程结束
一、Spring cloud组件
1、Spring Cloud核心组件：Eureka 注册中心
2、Spring Cloud核心组件：Feign 调用
3、Spring Cloud核心组件：Ribbon 负载均衡
4、Spring Cloud核心组件：Hystrix 熔断器 错误降级 防止雪崩
5、Spring Cloud核心组件：Zuul 网关 各端请求 统一处理
SpringCloud组件之Ribbon深入
在上一节 SpringCloud组件之Ribbon 中，实现了一个Ribbon的Helloword,使用的是Spring Eureka 和Spring Ribbon结合使用，并且使用Ribbon的默认轮询注册清单的负载均衡策略。
Ribbon参数配置通常有两种方式：全局配置和知道客户端配置
通用格式：ribbon.key=value
key：表示参数名称
value：表示参数值
例如：全局配置Ribbon创建连接的超时时间
针对指定的服务进行配置 通用格式 client.ribbon.key=value
key：表示参数名称
value：表示参数值
client：表示客户端服务的名称
例如：我们调用的Rest请求时是 ，现在我们来为服务hello-service服务指定他的实例清单（和注册中心中的服务清单一样）
下面将单独使用Spring Ribbon组件来介绍几种Ribbon负载均衡策略，单独使用Ribbon组件，不结合Eureka组件的不同之处在于，不能根据服务名称自动从Eureka的注册中心获取一个服务的实例清单，必须手动在配置文件中添加服务实例清单。
RandomRule策略：该策略实现了从服务实例清单中 随机选择 一个服务实例，作为请求服务对象。
首先创建一个SpringBoot的服务。
pom.xml
application.yaml
LoadBalanceController类
LoadBalanceMain类
启动main，在浏览器中输入 ，多次请求，可以看到页面呈现不同的请求路径。而且这些请求都是随机出现，查看后台打印
RoundRobinRule：该策略实现了按照 线性轮询 的方式一次轮询服务清单上的每个服务实例。
结合上面的例子，修改两个部分，一个是application.yaml中
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule
一个是LoadBalanceMain 中 修改ribbonRule()的返回值
RetryRule：该策略具备重试机制的实例选择功能，在给定时间内能够得到选择到具体的服务实例就返回，当超过时间还有没选到就返回null，参数maxRetryMillis控制这个超时时间。
WeightedResponseTimeRule：该策略是对RoundRobinRule的扩展，增加了根据实例的响应时间来计算权重，并从权重中选择对应的实例。该策略实现主要有三个核心内容
定时任务
WeightedResponseTimeRule策略在初始化的时候会启动一个定时任务，默认每隔30秒计算一次每个服务实例的权重
权重计算
累计所有实例的响应时间，得到总的totalResponseTime，然后为实例清单中的每个实例逐个计算权重，计算公式为
weightSoFar = weightSoFar + totalResponseTime - 该实例的平均响应时间
weightSoFar 起始为零
例子
有A，B，C，D四个实例，他们的平均响应时间是10,40,80,100，
计算总的响应时间10+40+80+100 =230
计算各个实例的权重
A: 230-10=220
B:220+(230-40)=410
C:410+(230-80)=560
D:560+(230-100)=690;
计算各个实例的权重区间
A:[0,220]
B:(220,410]
C:(410,560]
D:(560,690)
实例选择
WeightedResponseTimeRule策略会在[0,最大权重值)之间随机选取一个数，然后在看这个数落在哪个实例的权重区间内，接着WeightedResponseTimeRule就会去选择该实例。
ClientConfigEnableRoundRobinRule：该策略一般不直接使用，有些高级的策略会继承该类，完成一些高级的策略，ClientConfigEnableRoundRobinRule策略默认使用
RoundRibinRule的线性轮询机制
BestAvailableRule策略继承ClientConfigEnableRoundRobinRule，通过遍历负载均衡中维护的所有服务实例，会过滤掉故障实例，并找出并发数请求数最小的实例，所以该策略的特性就是选出最空闲的实例
PredicateBasedRule策略继承ClientConfigEnableRoundRobinRule，该策略主要特性是“先过滤，在轮询”，也就是先过滤掉一些实例，得到过滤后的实例清单，然后轮询该实例清单，PredicateBasedRule中“过滤”功能没有实现，需要继承它的类完成，也就是说不同继承PredicateBasedRule的类有不同的“过滤特性”
AvailabilityFilteringRule策略继承PredicateBasedRule策略的“先过滤，在轮询”特性，
AvailabilityFilteringRule策略的过滤特性是
1：是否故障，即断路器是否生效已断开
2：实例的并发请求数大于阈值，默认2的32次方减一，该阈值可以通过
clientName.nameSpace.ActiveConnectionsLimit来设置，只要满足其中一个那么就会过滤掉
SpringCloudAlibaba(一)：概述与重要组件
前一篇提到了我们为什么要替换PHP语言采用Java语言。而Java语言的框架选型上来说有太多的选择，常见的有Dubbo，SpringCloud等。我们选择了SpringCloudAlibaba。替换PHP语言到SpringCloudAlibaba是个大工程，主要是业务迁移部分。讨论之初我也确认过是否迁移原有的业务，得到的明确答复是 迁移 。 那么这么来说也就简单了，复杂的就是工期问题了。
SpringCloud Alibaba是Alibaba结合自身的微服务实践开源的一套微服务全家桶 ，在SpringCloud项目中进行孵化并且毕业。既然是SpringCloud的项目那么阿里云其实包含其商业化的产品。 例如Nacos在阿里云就有其商业化的版本 MSE 。 同时SpringCloud Alibaba的相关组件是经历过双十一大促考验的产品。稳定性较高。
SpringCloud Alibaba是SpringCloud的子项目，其实很多相关的文章都提到了SpringCloud Alibaba与SpringCloud的关系，其中有很多的论点都比较有意思。大家可以去搜索一下。
SpringCloud Alibaba是依赖SpringCloud相关的标准实现的一套微服务的架构。结合阿里巴巴的相关实践与阿里云的相关服务实现的一些组件得以更快的实现相关产品业务。
Nacos实现了服务的配置中心与服务注册发现的功能，Nacos可以通过可视化的配置降低相关的学习与维护成本，实现动态的配置管理与分环境的配置中心控制。 同时Nacos提供了基于http/RCP的服务注册与发现功能。
Sentinel是面向分布式微服务架构的轻量级高可用的流控组件，以流量作为切入点，从流量控制，熔断降级，系统负载保护等维度帮助用户保证服务的稳定性。常用与实现限流、熔断降级等策略。
RocketMQ基于Java的高性能、高吞吐量的消息队列，在SpringCloud Alibaba生态用于实现消息驱动的业务开发，常见的消息队列有Kafka、RocketMQ、RabbitMQ等，相关的比较文档可以自行去翻阅。
既然是微服务的产品，那么肯定会用到分布式事物。Seata就是阿里巴巴开源的一个高性能分布式事物的解决方案。
Dubbo已经在圈内很火了,SpringCloud Alibaba基于上面提到的Nacos服务注册中心也同样整合了Dubbo。
SpringCloud Alibaba还有一些其他的组件选择，例如schedulerX、SMS、OSS等。但是由于其主要是阿里云的商业化产品就不再过多的进行介绍。集成其商业化产品时才能用到。
SpringCloud Alibaba是基于SpringCloud标准由阿里巴巴实现的微服务全家桶，可插拔的方式实现组件的替换，在某些场景中我们需要的组件可以自由进行选择。例如需要分布式链路跟踪我们可以增加sleuth组件用于实现分布式链路跟踪业务等。
很多人提到SpringCloudAlibaba的商业问题，记得当年SpringCloudAlibaba推出第一版的时候我也评论了...卖产品全家桶。不可否认是有那么一些，但是其实它本身的很多组件又不一定非要选择商业版本。这个可以自由进行选择。
SpringCloud微服务组件介绍
Spring Cloud是一系列框架的有序集合（框架集），他利用Spring Boot的开发便利性巧妙的简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。
SpringCloud利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等，它们都可以用SpringBoot的开发风格做到一键启动和部署。
SpringCloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包
下面是Spring Cloud的整体架构图：
注册中心可以说是微服务架构中的“通讯录”，他记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其他服务时，就在这里找到对应服务的地址，进行调用。
注册中心的主要作用
Ribbon是Netflix发布的一个负载均衡，有助于控制HTTP和TCP客户端行为。在Spring Cloud中，Eureka一般配合Ribbon进行使用，Ribbon提供了客户端负载均衡的功能，Ribbon利用从Eureka中读取到的服务信息，在调用服务节点提供的服务时，会合理的进行负载。
在Spring Cloud中可以将注册中心和Ribbon配合使用，Ribbon自动的从注册中心中获取服务提供者的列表信息，并基于内置的负载均衡算法，请求服务。
Ribbon原理
几种负载均衡策略：
Hystrix是Netflix开源的一款容错框架，包含常用的容错方法。在高并发访问下，系统所依赖的服务的稳定性对系统的影响非常大，依赖有很多不可控的因素，比如网络连接变慢，资源突然繁忙，暂时不可用，服务脱机等。Hystrix利用熔断、线程池隔离、信号量隔离、降级回退等方法来处理依赖隔离，使系统变得高可用。
Hystrix主要提供了以下几种容错方法：
Spring Cloud Gateway是Spring官方推出的服务网关的实现框架，相对于服务网关的概念有点类似于传统的反向代理服务器（如nginx），但反向代理一般都只是做业务无关的转发请求，而服务网关与服务的整合程度更高，可以看作也是整个服务体系的组成部分，通过过滤器等组件可以在网关中集成一些业务处理的操作（比如权限认证等）。
核心功能：
Spring Cloud Stream是一个用来为微服务应用构建消息驱动能力的框架。
特点：
屏蔽底层 MQ 实现细节，Spring Cloud Stream 的 API 是统一的。如果从 Kafka 切到 RocketMQ，可以直接修改配置。
与 Spring 生态整合更加方便。Spring Cloud Data Flow的流计算都是基于 Spring Cloud Stream；Spring Cloud Bus 消息总线内部也是用的 Spring Cloud Stream。
配置中心功能：
分布式链路追踪，就是将一次分布式请求还原成调用链路，进行日志记录，性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时，请求具体到达哪台机器上、每个服务节点的请求状态等等。
分布式链路追踪方案：