微服务负载均衡器 Ribbon
# 简介
负载均衡，英文名称为Load Balance，其含义就是指将负载（工作任务）进行平衡、分摊到多个操作单元上进行运行，例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等，从而协同完成工作任务。
主流的负载均衡方案分为两种：一是集中式负载均衡，在消费者和提供者之间使用独立的代理方式进行负载，比如硬件的F5，或软件的Nginx；二是客户端根据自己的请求情况做负载均衡，比如Ribbon。
服务端负载均衡： 比如Nginx，先发送请求，然后通过负载均衡算法，在多个服务器之间进行访问，也就是所谓的在服务器端进行负载均衡算法分配。
客户端负载均衡： 比如Ribbon，spring cloud的客户端会有一个类似注册中心的服务器地址列表，在发送请求前通过负载均衡算法选择一个服务器，然后进行访问，也就是所谓的在客户端就进行负载均衡算法分配。
# 常见的负载均衡算法
- 随机,通过随机选择服务进行执行,一般这种方式使用较少
- 轮训,负载均衡默认实现方式,请求来之后排队处理
- 加权轮训,通过对服务器性能的分型,给高配置,低负载的服务器分配更高的权重,均衡各个服务器的压力
- 地址Hash,通过客户端请求的地址的HASH值取模映射进行服务器调度
- 最小链接数,即使请求均衡了,压力不一定均衡,最小连接数法就是根据服务器的情况,比如请求积压数等参数,将请求分配到当前压力最小的服务器上.
# Ribbon负载均衡策略
IRule是所有负载均衡策略的父接口，其中核心方法为choose，用来选择一个服务实例。
AbstractLoadBalancerRule抽象类，通过ILoadBalancer从现有服务器列表中通过均衡策略选择服务器。
RandomRule（随机规则） 在现有服务器之间随机分配流量的负载平衡策略。通过生成一个不大于服务实例总数的随机数选择服务实例。
RoundRobinRule（轮询规则） 基本负载均衡策略。通过遍历服务实例，先获取实例总数，如果为0，则会警告负载均衡器没有可用的服务器（No up servers available from load balancer:xxx）；如果实例数大于0，则会生成一个实例总数不断加1的数，取模后选取实例，如果连续十次都没取到实例，则会警告从负载均衡器尝试 10 次后没有可用的活动服务器（No available alive servers after 10 tries from load balancer:xxx）。
RetryRule（轮询+重试规则） 也是轮询机制，只是当轮询到一个已失效或者null的实例后，会在失效时间内进行不断重试，超时后返回null。
WeightedResponseTimeRule（权重规则） 会根据每个实例的运行情况计算出权重，默认情况下每30秒会计算一次，服务器的平均响应时间越短则权重越大，那么该实例被选中的概率也会越大。
BestAvailableRule（最佳可用规则） 此规则通常应与ServerListSubsetFilter一起使用，它对规则可见的服务器设置了限制。这确保了它只需要在少量服务器中找到最小的并发请求。此外，每个客户端将获得一个随机的服务器列表，避免了并发请求最低的服务器被大量客户端选择并立即不堪重负的问题。
ZoneAvoidanceRule（区域回避规则） 默认的规则，根据区域和可用性过滤服务器的规则，比如北京和上海的服务器，当你在北京访问时会优先请求北京的服务器。
AvailabilityFilteringRule（可用性过滤规则） 先过滤掉故障实例，再选择并发较小的实例。过滤规则：由于连续连接或读取失败而处于断路器跳闸状态，或 具有超过可配置限制的活动连接。
NacosRule（Nacos-权重） Nacos扩展了一个自己的配置，配置中通过spring.cloud.nacos.discovery.weight设置权重大小。
# LoadBalancer和Ribbon的区别
Spring Cloud LoadBalancer是Spring Cloud官方自己提供的客户端负载均衡器，用来替代已经闭源的Ribbon。
目前由于LoadBalancer只支持轮询的负载均衡策略，没有Ribbon强大，所以暂时不建议用LoadBalancer去替换Ribbon。