Ribbon入门

刺骨的言语ヽ痛彻心扉 2023-06-16 04:00 11阅读 0赞

![在这里插入图片描述][20191124140953876.png]

### 文章目录 ###

*  Ribbon简介
 *  Ribbon的负载均衡
 *  Ribbon的负载均衡策略
 *  Ribbon详细学习

# Ribbon简介 #

Ribbon是一个负载均衡组件，具有丰富的负载均衡策略、重试机制、支持多协议的异步与响应式模型、容错、缓存与批处理功能。  
Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Spring Cloud Ribbon虽然只是一个工具类框架，它不像服务注册中心、配置中心、API网关那样需要独立部署，但是它几乎存在于每一个Spring Cloud构建的微服务和基础设施中。因为微服务间的调用，API网关的请求转发等内容，实际上都是通过Ribbon来实现的，包括后续我们将要介绍的Feign，它也是基于Ribbon实现的工具。所以，对Spring Cloud Ribbon的理解和使用，对于我们使用Spring Cloud来构建微服务非常重要。

# Ribbon的负载均衡 #

负载均衡在系统架构中是一个非常重要，并且是不得不去实施的内容。因为负载均衡是对系统的高可用、网络压力的缓解和处理能力扩容的重要手段之一。我们通常所说的负载均衡都指的是服务端负载均衡，其中分为硬件负载均衡和软件负载均衡。硬件负载均衡主要通过在服务器节点之间按照专门用于负载均衡的设备，比如F5等；而软件负载均衡则是通过在服务器上安装一些用于负载均衡功能或模块等软件来完成请求分发工作，比如Nginx等。不论采用硬件负载均衡还是软件负载均衡，只要是服务端都能以类似下图的架构方式构建起来：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMTUxNjU5_size_16_color_FFFFFF_t_70]  
硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备的时候，该设备按某种算法（比如线性轮询、按权重负载、按流量负载等）从维护的可用服务端清单中取出一台服务端端地址，然后进行转发。  
而客户端负载均衡和服务端负载均衡最大的不同点在于上面所提到服务清单所存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端端清单来自于服务注册中心。同服务端负载均衡的架构类似，在客户端负载均衡中也需要心跳去维护服务端清单的健康性，默认会创建针对各个服务治理框架的Ribbon自动化整合配置，比如Eureka中的org.springframework.cloud.netflix.ribbon.eureka.RibbonEurekaAutoConfiguration，Consul中的org.springframework.cloud.consul.discovery.RibbonConsulAutoConfiguration。在实际使用的时候，我们可以通过查看这两个类的实现，以找到它们的配置详情来帮助我们更好地使用它。  
负载均衡分类：

1.  集中式负载均衡：也叫做服务端负载均衡，位于英特网与服务提供者之间，负责把网络请求转发给各个提供单位，典型产品是Ngixn；
2.  进程负载均衡：也叫作客户端负载均衡，位于服务提供者内部，从注册中心的已注册实例库选取实例进行流量导入，整个过程都是在进程间通信。

Ribbon就是典型的客户端负载均衡，它赋予了应用一些支配HTTP与TCP行为的能力，如果没有Ribbon，Spring Cloud构建的服务则无法横向扩展，所以Spring Cloud的Feign和Zuul默认集成了Ribbon。

# Ribbon的负载均衡策略 #

Ribbon有7中可选的负载均衡策略，如下：

*  RomdomRule：随机策略，随机选择 Server；
 *  RoundRobbinRule：轮询策略，按顺序循环选择 Server，该策略是Ribbon默认策略；
 *  RetryRule：重试策略，在一个配置时间段内当选择 server 不成功，则一直尝试选择一个可用的 server；
 *  BestAvailableRule：最低并发策略，逐个考察 server，如果 server 断路器打开，则忽略，再选择其中并发连接最低的 server；
 *  AvailabilityFilteringRule：可用过滤策略，过滤掉一直连接失败并被标记为 circuit tripped 的 server，过滤掉那些高并发连接的 server（active connections 超过配置的阀值）；
 *  ResponseTimeWeightedRule：响应时间加权策略，根据 server 的响应时间分配权重。响应时间越长，权重越低，被选择到的概率就越低；响应时间越短，权重越高，被选择到的概率就越高。这个策略很贴切，综合了各种因素，如：网络、硬盘、IO等，这些因素直接影响着响应时间；
 *  ZoneAvoidanceRule：区域权衡策略，综合判断 server 所在区域的性能和 server 的可用性轮询选择 server，并且判定一个 AWS Zone 的运行性能是否可用，剔除不可用的 Zone 中的所有 server。

# Ribbon详细学习 #

https://www.jianshu.com/p/1bd66db5dc46  
https://www.baidu.com/link?url=tt1F\_NTaAurmQb8KG9125gCPWUUHYY-4KYHlMGY6TlfwW19Jwymxu190O3gqqAy-&wd=&eqid=9d348bed00081339000000035dda1b67

[20191124140953876.png]: https://img-blog.csdnimg.cn/20191124140953876.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMTUxNjU5_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191124140239798.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMTUxNjU5,size_16,color_FFFFFF,t_70