SpringCloud之Ribbon理论篇猿上生活-

1.Ribbon是什么？

Ribbon是一个客户端负载均衡工具，由Netflix公司开源，后来被spring整合到springcloud生态圈作为服务调用间的负载均衡组件。在springcloud中Ribbon一般不是单独使用，往往需要配合Eureka使用，从Eureka Server 获取服务列表，然后使用负载均衡算法（轮询，随机）选出一个合适Server进行调用，同时Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。

2.关于负载均衡

负载均衡从软硬件的角度可以分为硬负载与软负载，然后从负载执行角度又分为客户端负载均衡与服务端负载均衡

2.1软负载与硬负载

硬负载就是直接在服务器和外部网络间安装负载均衡硬件设备，这种设备我们通常称之为负载均衡器。由专门的设备完成，独立于操作系统，整体性能得到大量提高，加上更多的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。 一般来说，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵，很常见的有 F5负载均衡器，长的下图这个样子

软负载就是使用软件来做负载均衡，在服务器的操作系统上，安装软件，来实现负载均衡，如Nginx负载均衡。它的优点是基于特定环境、配置简单、使用灵活、成本低廉，可以满足大部分的负载均衡需求，我们常用的软负载有nginx，lvs，haproxy等等。

2.2 客户端负载与服务端负载均衡

服务端负载均衡，其实就像f5，nginx这样，当用户发起请求到服务端的时候，我们使用这些负载均衡器根据一定的负载均衡算法，然后将请求路由到目标服务器处理，如下图，用户发起请求，然后到达nginx ，nginx通过一定的负载均衡算法从服务器1，2，3，4 选择一台合适的服务器来进行用户请求的处理，其实服务端负载均衡往往用在用户请求服务器的情况下。

所谓的客户端负载均衡，就像Ribbon一样，其实还有很多的rpc框架里面的负载均衡都是客户端负载均衡。这个客户端负载均衡一般用在微服务中或者是SOA中，主要是服务调用服务的时候，服务调用者会根据服务提供者列表中选择出合适的一个，然后服务调用者拿着选出来的服务提供者信息去调用。就像下面我这张架构图，用户服务作为调用者需要从订单服务也就是服务提供者中获取某个用户的的订单列表，用户服务从注册中心中获取订单服务的3个实例信息，然后根据一定订的负载均衡策略，用户服务最终选择了订单服务02进行调用，这种负载均衡就叫做客户端负载均衡。

其实负载均衡算法在哪边就是哪个端的负载均衡算法。

3.Ribbon核心原理

Ribbon其实就是在请求的时候使用了个interceptor拦截器，然后将拦截到请求信息，然后根据请求信息做一系列判断，最终请求到了server端。
我们可以拿个例子来说，现在有下图这个架构的项目，其中用户服务（也就是服务调用者）这边使用了Ribbon+RestTemplate，然后这个订单服务有两个，端口分别是7071与7070，他们都注册到注册中心Eureka Server 上面。

现在我们用户服务中有这么一段代码，是调用订单服务某个接口的，我们来看下。

我们可以看到，拼接了个url，但是这个url中的ip+port使用服务名替代了这里spring-cloud-order-service-provider 服务名是订单服务的，然后使用resttemplate 请求这个url。
我们来解析下它的调用过程，resttemplate 发起请求，然后被Ribbon的拦截器拦截到这个请求，然后拿到请求信息，解析出来url中的服务名，然后通过服务列表找到所有注册在Eureka的订单服务的实例信息，其中包括比如说实例的ip，port等等一些元信息。然后根据负载均衡策略，然后找出一个合适的实例信息，接着就是拼接url,把那个请求url中的服务替换成咱们选出的实例（也就是订单服务中某一个）的ip+port，之后就是发往下一个interceptor ，最后到了server。

其实就是请求过程中经过一层层的过滤器，然后进行不同的操作，最终到达目的地。
Ribbon负载均衡器分为五个部分组成，分别是
负载均衡管理器LoadBalancer，主要是协调下面四个部分的运行，围绕它周围的多有IRule、IPing等
IRule:是在选择实例的时候的负载均衡策略对象
IPing:是用来向服务发起心跳检测的，通过心跳检测来判断该服务是否可用
ServerListFilter:根据一些规则过滤传入的服务实例列表
ServerListUpdater:定义了一系列的对服务列表的更新操作

4.Ribbon负载均衡策略

关于更多的Ribbon参考下面的链接：

1. Ribbon的使用
2. 策略介绍
3. 自定义负载均衡策略
4. 配置信息