SpringCloud微服务系列- 服务间通信之负载均衡

SpringCloud微服务系列- 服务间通信之负载均衡

    概要

    负载均衡是我们处理高并发、缓解网络压力和进行服务器扩容的重要手段之一

    负载均衡通器常有两种实现手段，一种是服务端负载均衡器，另一种是客户端负载均衡器。

    一、负载均衡的作用

    1.  服务端负载均衡

    在服务集群内设置一个中心化负载均衡器，比如Nginx。发起服务间调用的时候，服务请求并不直接发向目标服务器，而是发给这个全局负载均衡器，它再根据配置的负载均衡策略将请求转发到目标服务。  

    优缺点分析：

    1）优点

    服务端负载均衡应用范围非常广，它不依赖于服务发现技术，客户端并不需要拉取完整的服务列表；同时，发起服务调用的客户端也不用操心该使用什么负载均衡策略。

    2）缺点

    网络消耗(多出了10-20ms)、复杂度和故障率提升

    2. 客户端负载均衡

     Spring Cloud Loadbalancer 采用了客户端负载均衡技术，每个发起服务调用的客户端都存有完整的目标服务地址列表，根据配置的负载均衡策略，由客户端自己决定向那台服务器发起调用。

     优缺点分析：

     1）优点

     网络开销小、配置灵活

     2）缺点

     需要满足一个前置条件，发起服务调用的客户端需要获取所有目标服务的地址，这样它才能使用负载均衡规则选取要调用的服务。

     也就是说，客户端负载均衡技术往往需要依赖服务发现技术来获取服务列表。

     3.  总结

     服务端负载均衡器和客户端负载均衡器的区别如下图所示：

   

    总的来说，服务端负载均衡器的问题是，它提供了更强的流量控制权，但无法满足不同的消费者希望使用不同负载均衡策略的需求，而使用不同负载均衡策略的场景确实是存在的，所以客户端负载均衡就提供了这种灵活性。 然而客户端负载均衡也有其缺点，如果配置不当，可能会导致服务提供者出现热点，或者压根就拿不到任何服务的情况。

    二、客户端负载均衡需要解决两个最基本的问题

     1.  从哪里选服务实例？

     答案：从服务治理中心来

     2.  如何选择服务实例？

     通过负载均衡的策略（轮询、ip哈希、轮询等）从服务实例清单列表中选择具体实例。

     比如：Eureka和Loadbalancer搭配使用，一个通过服务发现获取服务列表，另一个使用负载均衡规则选出目标服务器。

     3. 什么是Spring Cloud Ribbon(客户端负载均衡器)

     是Netfix发布的负载均衡器，它有助于Http和Tcp的客户端行为。可以根据负载均衡算法（轮询、随机或自定义）自动帮助消费者请求，默认就是轮询。

     由于Spring Cloud Ribbon目前处于停更维护的状态，所以有了替代方案：Spring Cloud LoadBalancer

     4. 什么是Spring Cloud Loadbalancer？

     由于Spring Cloud Ribbon已经进入维护模式，并且Ribbon2并不与Ribbon1相互兼容，所以Spring Cloud全家桶在Spring Cloud Commons 项目中，添加了Spring cloud Loadbalancer作为新的负载均衡器，并且做了向前兼容，就算项目中继续用Spring Cloud Netflix套装(包括Ribbon、Eureka、Zuul、Hystrix等等)让你的项目中有这些依赖，你也可以通过简单的配置，把Ribbon替换成Spring Cloud LoadBalancer。

    三、负载均衡策略

    1. Ribbon

    Ribbon 是 Spring Cloud 技术栈中非常重要的基础框架，它为 Spring Cloud 提供了负载均衡的能力，比如 Fegin 和 OpenFegin 都是基于 Ribbon 实现的，就连 Nacos 中的负载均衡也使用了 Ribbon 框架。 Ribbon 框架的强大之处在于，它不仅内置了 7 种负载均衡策略，同时还支持用户自定义负载均衡策略，所以其开放性和便利性也是它得以流行的主要原因。

   1）RandomRule 随机策略

   2）RoundRobinRule 轮询策略

   3）RetryRule 重试策略

   说明：按照轮询策略来获取服务，如果获取的服务实例为 null 或已经失效，则在指定的时间之内不断地进行重试来获取服务，如果超过指定时间依然没获取到服务实例则返回 null。

   4）WeightedResponseTimeRule 权重策略

   是对轮询策略的扩展。

   这个Rule继承自RoundRobinRule,他会根据服务节点的响应时间计算权重，响应时间越长权重就越低，响应越快则权重越高，权重的高低决定了机器被选中概率的高低。也就是说，响应时间越小的机器，被选中的概率越大。  

   5）BestAvailableRule 最小连接数策略

   应该说这个Rule有点智能的味道了，在过滤掉故障服务以后，它会基于过去30分钟的统计结果选取当前并发量最小的服务节点，也就是最"闲"的节点作为目标地址。

   如果统计结果尚未生成，则采用轮询的方式选定节点。

   6）AvailabilityFilteringRule 可用性敏感策略

  先过滤掉非健康的服务实例，然后再选择连接数较小的服务实例。

  两步检查：1. 是否处于不可用  2.节点当前的active请求连接数超过阈值

  说明：每次AvailabilityFilteringRule(简称AFR都会请求RobinRule挑选一个节点，然后对这个节点做以下两步检查：是否处于不可用，节点当前的active请求连接数超过阈值，超过了则表示节点目前太忙，
不适合提供服务，如果被选中的server不幸挂掉了检查，那么AFR会自动重试（次数最多1O次），让RobinRule重新选择一个服务节点。

   7）ZoneAvoidanceRule 区域敏感策略

   根据服务所在区域的性能和服务的可用性选择服务实例。在没有区域的环境下，该策略和轮询策略类似。

   四、Spring Cloud Loadbalancer

   RandomLoadBalancer 随机 和 RoundRobinLoadBalancer 轮询

   不指定的时候默认用的是轮询。