目前主流的负载方案分为以下两种：

    • 集中式负载均衡，在消费者和服务提供方中间使用独立的代理方式进行负载，有硬件的（比如 F5），也有软件的（比如 Nginx）。
    • 客户端根据自己的请求情况做负载均衡，Ribbon 就属于客户端自己做负载均衡。

    第一次调用比较慢，需要初始化当前的负载均衡器，延迟懒加载的
    ribbon默认使用轮询的算法
    常见负载均衡算法

    • 随机，通过随机选择服务进行执行，一般这种方式使用较少;
    • 轮训，负载均衡默认实现方式，请求来之后排队处理;
    • 加权轮训，通过对服务器性能的分型，给高配置，低负载的服务器分配更高的权重，均衡各个服务器的压力;
    • 地址Hash，通过客户端请求的地址的HASH值取模映射进行服务器调度。 ip hash
    • 最小连接数，即使请求均衡了，压力不一定会均衡，最小连接数法就是根据服务器的情况，比如请求积压数等参数，将请求分配到当前压力最小的服务器上。 最小活跃数

    可以自己实现去注册中心获取实例
    image.png

    ribbon内核原理
    image.png
    ribbon相关接口
    IClientConfig：Ribbon的客户端配置，默认采用DefaultClientConfigImpl实现。
    IRule：Ribbon的负载均衡策略，默认采用ZoneAvoidanceRule实现，该策略能够在多区域环境下选出最佳区域的实例进行访问。
    IPing：Ribbon的实例检查策略，默认采用DummyPing实现，该检查策略是一个特殊的实现，实际上它并不会检查实例是否可用，而是始终返回true，默认认为所有服务实例都是可用的。
    ServerList：服务实例清单的维护机制，默认采用ConfigurationBasedServerList实现。服务的列表
    ServerListFilter：服务实例清单过滤机制，默认采ZonePreferenceServerListFilter，该策略能够优先过滤出与请求方处于同区域的服务实例。
    ILoadBalancer：负载均衡器，默认采用ZoneAwareLoadBalancer实现，它具备了区域感知的能力。

    ribbon负载均衡策略

    • RandomRule： 随机选择一个Server。
    • RetryRule： 对选定的负载均衡策略机上重试机制，在一个配置时间段内当选择Server不成功，则一直尝试使用subRule的方式选择一个可用的server。
    • RoundRobinRule： 轮询选择， 轮询index，选择index对应位置的Server。
    • AvailabilityFilteringRule： 过滤掉一直连接失败的被标记为circuit tripped的后端Server，并过滤掉那些高并发的后端Server或者使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就是检查status里记录的各个Server的运行状态。
    • BestAvailableRule： 选择一个最小的并发请求的Server，逐个考察Server，如果Server被tripped了，则跳过。
    • WeightedResponseTimeRule： 根据响应时间加权，响应时间越长，权重越小，被选中的可能性越低。
    • ZoneAvoidanceRule：默认的负载均衡策略，即复合判断Server所在区域的性能和Server的可用性选择Server，在没有区域的环境下，类似于轮询(RandomRule)
    • NacosRule: 同集群优先调用