客户端负载均衡之 Ribbon
Ribbon 简介
Ribbon 是一个基于 HTTP 和 TCP 的客户端负载均衡器， 主要提供客户侧的软件负载均衡算法， 运行在消费者端。 客户端负载均衡是当浏览器向后台发出请求的时候，客户端会向 Eureka Server 读取注册到服务器的可用服务信息列表，然后根据设定的负载均衡策略，抉择出向哪台服务器发送请求。 在客户端就进行负载均衡算法分配。Ribbon 客户端组件提供一系列完善的配置选项，比如连接超时、重试、重试算法等。下面是用到的一些负载均衡策略：
- 随机策略---随机选择 server
- 轮询策略---轮询选择， 轮询 index，选择 index 对应位置的 Server
- 重试策略--在一个配置时间段内当选择 Server 不成功，则一直尝试使用 subRule 的方式选择一个可用的server 最低并发策略--逐个考察 server，如果 server 断路器打开，则忽略，再选择其中并发链接最低的 server可用过滤策略--过滤掉一直失败并被标记为 circuit tripped 的 server，过滤掉那些高并发链接的 server （active connections 超过配置的阈值）或者使用一个 AvailabilityPredicate 来包含过滤 server 的逻 辑，其实就就是检查 status 里记录的各个 Server 的运行状态
- 响应时间加权重策略--根据 server 的响应时间分配权重，响应时间越长，权重越低，被选择到的概率也就越低。响应时间越短，权重越高，被选中的概率越高，这个策略很贴切，综合了各种因素，比如：网 络，磁盘，io 等，都直接影响响应时间
- 区域权重策略--综合判断 server 所在区域的性能，和 server 的可用性，轮询选择 server 并且判断一个AWS Zone 的运行性能是否可用，剔除不可用的 Zone 中的所有 server。
互动： 举个列子说明 ribbon
比如我们设计了一个秒杀系统，但是为了整个系统的 高可用 ，我们需要将这个系统做一个集群，而这个时候我们消费者就可以拥有多个秒杀系统的调用途径了，如下图：
如果这个时候我们没有进行一些 均衡操作 ，如果我们对秒杀系统1进行大量的调用，而另外两个基本不请求，就会导致秒杀系统 1 崩溃，而另外两个就变成了傀儡，那么我们为什么还要做集群，我们高可用体现的意义又在哪呢？
所以 Ribbon 出现了，注意我们上面加粗的几个字——运行在消费者端 。指的是，Ribbon 是运行在消费者端的负载均衡器，如下图。
其工作原理就是 Consumer 端获取到了所有的服务列表之后，在其内部使用负载均衡算法 ，进行对多个系统的调用。
Ribbon 的功能
- 易于与服务发现组件（比如 Eureka）集成
- 使用 Archaius 完成运行时配置
- 使用 JMX 暴露运维指标，使用 Servo 发布
- 多种可插拔的序列化选择
- 异步和批处理操作
- 自动 SLA 框架
- 系统管理/指标控制台
Ribbon 和 nginx 对比分析
区别：
Ribbon 实现的是客户端负载均衡，它可以在客户端经过一系列算法来均衡调用服务。Ribbon 工作时分两步：
- 第一步：从 Eureka Server 中获取服务注册信息列表，它优先选择在同一个 Zone 且负载较少的Server。
- 第二步：根据用户指定的策略，在从 Server 取到的服务注册列表中选择一个地址，其中 Ribbon 提供了多种策略，例如轮询、随机等。
Nginx 是服务器端负载均衡，所有请求统一交给 nginx，由 nginx 实现负载均衡请求转发，属于服务器端负载均衡。
