思维导图

一、负载均衡

1.概念

将用户请求分摊到不同服务器上处理，以提高系统整体的并发处理能力及可靠性。

如图：我们用到负载均衡，实现访问商品服务的请求的分流。

在这里插入图片描述

负载均衡是一种常用且简单的提高系统并发和可靠性的手段，单体或微服务架构都会使用

2.分类

2.1 服务端

主要应用于系统外部请求和网关层，软件或硬件都可以实现。

如图使用Nginx：

在这里插入图片描述

2.1.1 硬件负载均衡

通过专门的硬件设备（如F5、A10、Array）实现负载均衡

优点性能很强且稳定，缺点是价格太贵。如基础款F5最低也要20万。

2.1.2 软件负载均衡

通过软件（如LVS、Nginx、HAproxy）实现负载均衡

日常开发接触最多，性能差一些，但价格便宜。如基础款的Linux服务器也就几千，好一点的2-3万就不错了。

分类：

一层、二层、三层、四层、七层负载均衡（根据OSI模型）

在这里插入图片描述

（1）四层负载均衡

工作在主要协议TCP/UDP的传输层
负载均衡器能够看到数据包里源端口地址、目的端口地址，基于这些信息通过一定负载均衡算法将数据包转发到后端真实服务器

大部分用LVS（Linux内核的4层负载均衡）

（2）七层负载均衡

工作在主要协议HTTP的应用层
这一层负载均衡比四层负载均衡路由网络请求的方式更加复杂，它会读取报文的数据部分（如HTTP报文），然后根据读取数据（如URL、Cookie）做出负载均衡决策

大部分使用Nginx

（3）四层与七层负载均衡比较

四层性能更强。七层比四层会消耗更多性能
七层功能更强。更加灵活，能够更加智能的路由网络请求

比如可以根据请求内容进行缓存、压缩、加密等优化

2.2 客户端

主要应用于系统内部的不同服务器之间，可以使用现成的负载均衡组件来实现。

2.2.1 概念

（1）客户端会自己维护一份服务器的地址列表。
发送请求之前，客户端会根据对应的负载均衡算法来选择具体某一台服务器处理请求。

（2）客户端负载均衡和服务运行在同一个进程或者Java程序里，不存在额外的网络开销。
不过它会受到编程语言的限制，比如SpringCloud Load Balancer 只能用于Java语言

2.2.2 Java框架客户端负载均衡

以下都内置了开箱即用：

2.2.2.1 Dubbo

默认自带

2.2.2.2 SpringCloud

通过可选的组件形式实现，常用的有：

（1）SpringCloud Load Balancer（官方推荐）

在这里插入图片描述

<1> 2种基本策略：

RandomLoadBalancer：随机
RoundRobinLoadBalancer（默认）：轮询

<2> 通过ServiceInstanceListSupplier实现类让其他支持类似于Ribbon的负载均衡策略

如：实现基于区域的负载均衡策略、基于hint提示的负载均衡策略等

（2） Ribbon（Netflix）
Netflix开发，功能全面支持的负载均衡策略多

7种策略：

RandomRule：随机
RoundRobinRule（默认）：轮询
WeightedResponseTimeRule：权重（根据响应时间决定权重）
BestAvailableRule：最小连接数
RestryRule：重试
按照轮询策略获取服务，如果获取的服务实例为null或者已经失效，则再指定时间之内不断重试来获取服务，如果超过指定时间依然没有获取到服务实例则返回null
AvailabilityFilteringRule：可用敏感性
先过滤掉非健康的服务实例，然后再选择连接数较小的服务实例
ZoneAvoidanceRule：区域敏感性
根据服务所在区域的性能和服务的可用性来选择服务实例