为什么需要 Ribbon?
Ribbon是Netflix公司的一个开源负载平衡项目。它是在使用者端运行的客户机/进程内负载平衡器。
再举一个例子。例如，我们设计了一个seckill系统，但是为了整个系统的高可用性，我们需要把这个系统做成一个集群，此时我们的消费者可以有多种方式调用seckill系统。
如果此时不进行一些平衡操作，如果大量调用seckill系统1，另外两个基本不请求，就会导致seckill系统1崩溃，另外两个变成傀儡，那么为什么要做集群，我们的高可用性有什么意义?
于是丝带出现了，注意到上面的粗体字——在消费者方面。也就是说，功能区是在用户端运行的负载平衡器。
其工作原理是在用户获取所有服务列表后，使用负载均衡算法调用多个系统。
nginx与ribbon的比较
说到负载平衡，我们不得不提到著名的nignx。与功能区不同，它是一个集中的负载平衡器。
什么是集中?简单的理解是集中所有请求，然后进行负载平衡。
我们可以看到，nginx接收所有的负载平衡请求，而对于ribbon，它是用户端的负载平衡。
请注意请求的位置。在nginx中，请求首先进入负载平衡器，而在功能区中，请求是在客户端的负载平衡之后发出的。
Ribbon 的几种负载均衡算法
对于负载平衡，nginx和ribbon都需要算法的支持。如果我没记错的话，nginx使用了轮询和加权轮询算法。ribbon中有更多的负载平衡调度算法，默认为循环规则轮询策略。
RoundRobinRule：投票策略。功能区采用的默认策略。如果在一轮轮询后找不到可用的提供程序，则它最多可以轮询10轮。如果找不到，则返回空值。
RandomRule：随机选择所有可用提供者之一的随机策略。
Retryrule:重试策略。首先，根据循环规则策略获取提供者。如果采集失败，请在指定的时间限制内重试。默认时间限制为500毫秒。
还有很多。这里没有例子。您需要知道的最重要的事情是默认的轮询算法，您可以更改默认的负载平衡算法，只需在配置文件中进行更改。