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负载均衡策略
| 负载均衡策略 | 详细描述 |
|---|---|
| RoundRobinRule | 轮询，默认是超过10次服务不可用，就返回空，就是你这次请求，它帮你选出来一个实例，然后不可用，它会再帮你选一个，还不可用的话，就帮你再选一个，就这样选10次 |
| RandomRule | 随机策略，如果取到的实例不可用的话，他会一直帮你选，直到选出一个可用的来 |
| RetryRule | 重试策略，一定时限内循环重试。默认继承RoundRobinRule，也支持自定义 注入，RetryRule会在每次选取之后，对选举的server进行判断， 是否为null，是否alive，并且在500ms内会不停的选取判断。而 RoundRobinRule失效的策略是超过10次，RandomRule是没有失 效时间的概念，只要serverList没都挂。 |
| BestAvailableRule | 最小连接数策略，其实就是从服务列表中获取连接数最少的那个实例，算 法里面有一个LoadBalancerStats的成员变量，会存储所有server 的运行状况和连接数，如果选取的实例是null的话，就会使用RoundRobinRule算法帮你选取 |
| AvailabilityFilteringRule | 可用过滤策略，先通过轮询出来一个实例，然后再去判断是否超时可用，连接数是否超出限制，然后都符合的会返回。 |
| ZoneAvoidanceRule | 区域权衡策略，这是个默认策略，扩展了轮询策略，继承了2个过滤器:ZoneAvoidancePredicate和 AvailabilityPredicate，除了过滤超时和链接数过多的server，还会 过滤掉不符合要求的zone区域里面的所有节点，AWS --ZONE 在一个区域/机房内的服务实例中轮询 |
关于更多的Ribbon参考下面的链接：