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。
三、负载均衡策略
一、Ribbon
Ribbon 是 Spring Cloud 技术栈中非常重要的基础框架，它为 Spring Cloud 提供了负载均衡的能力，比如 Fegin 和 OpenFegin 都是基于 Ribbon 实现的，就连 Nacos 中的负载均衡也使用了 Ribbon 框架。
Ribbon 框架的强大之处在于，它不仅内置了 7 种负载均衡策略，同时还支持用户自定义负载均衡策略，所以其开放性和便利性也是它得以流行的主要原因。
1. RandomRule 随机策略
2. RoundRobinRule 轮询策略
3. RetryRule 重试策略
说明：按照轮询策略来获取服务，如果获取的服务实例为 null 或已经失效，则在指定的时间之内不断地进行重试来获取服务，如果超过指定时间依然没获取到服务实例则返回 null。
4. WeightedResponseTimeRule 权重策略
这个Rule继承自RoundRibbonRule,他会根据服务节点的响应时间计算权重，响应时间越长权重就越低，响应越快则权重越高，权重的高低决定了机器被选中概率的高低。也就是说，响应时间越小的机器，被选中的概率越大。
是对轮询的扩展。
5. BestAvailableRule 最小连接数策略
应该说这个Rule有点智能的味道了，在过滤掉故障服务以后，它会基于过去30分钟的统计结果选取当前并发量最小的服务节点，也就是最"闲"的节点作为目标地址。如果统计结果尚未生成，则采用轮询的方式选定节点。
6. AvailabilityFilteringRule 可用性敏感策略
两步检查：1. 是否处于不可用 2.节点当前的active请求连接数超过阈值
说明：每次AvailabilityFilteringRule(简称AFR都会请求RobinRule挑选一个节点，然后对这个节点做以下两步检查：是否处于不可用，节点当前的active请求连接数超过阈值，超过了则表示节点目前太忙，
不适合提供服务，如果被选中的server不幸挂掉了检查，那么AFR会自动重试（次数最多1O次），让RobinRule重新选择一个服务节点。
7. ZoneAvoidanceRule 区域敏感策略
根据服务所在区域的性能和服务的可用性选择服务实例。在没有区域的环境下，该策略和轮询策略类似。
四、Spring Cloud Loadbalancer
RandomLoadBalancer 随机 和 RoundRibbonLoadBalancer 轮询
不指定的时候默认用的是轮询。
