NOTE
2.5 如何设计负载均衡组件
1. 什么是负载均衡 - 将请求（工作负载）平均的打到到多个机器上以提高性能和可用性 2. 为什么需要负载均衡 - 通过机器冗余提高可用性 - 便于横向扩展以提高性能和吞吐量 - 垂直扩展指更换性能更强劲的机器，价格自然更高，性价比不咋地 3. 如何实现负载均衡组件 3.1. 负载均衡算法有哪些 负
这是历史学习笔记，可能存在过时或不完整的理解。
1. 什么是负载均衡
- 将请求（工作负载）平均的打到到多个机器上以提高性能和可用性
2. 为什么需要负载均衡
- 通过机器冗余提高可用性
- 便于横向扩展以提高性能和吞吐量
- 垂直扩展指更换性能更强劲的机器，价格自然更高，性价比不咋地
3. 如何实现负载均衡组件
3.1. 负载均衡算法有哪些
负载均衡算法决定了后端的哪些健康服务器会被选中。几个常用的算法：
3.1.1. 轮循均衡（Round Robin）
- 每一次来自网络的请求轮流分配给内部中的服务器，从 1 至 N 然后重新开始。
- 此种均衡算法适合于集群中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况
3.1.2. 权重轮循均衡（Weighted Round Robin）
- 根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求
- 此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。
3.1.3. 随机均衡（Random）
- 把来自客户端的请求随机分配给内部中的多个服务器
- 在数据足够大的场景下能达到相对均衡的分布
3.1.4. 一致性哈希均衡（Consistency Hash）
- 根据请求中某一些数据（可以是 MAC、IP 地址，也可以是更上层协议中的某些参数信息）作为特征值来计算需要落在的节点上，算法一般会保证同一个特征值每次都一定落在相同的服务器上
3.1.5. 响应速度均衡（Response Time）
- 负载均衡设备对内部各服务器发出一个探测请求（例如 Ping），然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。
- 此种均衡算法能较好的反映服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户端与服务器间的最快响应时间
3.1.6. 最少连接数均衡（Least Connection）
- 最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器
- 此种均衡策略适合长时处理的请求服务
3.2. 负载均衡器选择硬件还是软件
3.2.1. 硬件 vs 软件
| 硬件 | 软件 | DNS | |
|---|---|---|---|
| 原理 | 直接采用应用专用集成电路（ASIC）来实现 | 操作系统内核或者应用程序 | 一个域名通过 DNS 解析到多个 IP |
| 举例 | F5、A10 | LVS和Nginx、L5、HAProxy、KeepAlived | DNS |
| 优点 | 效率高，避免操作系统或者应用层面的损耗 | 灵活度高 | 简单，无需开发维护负载均衡；就近访问,提升访问速度 |
| 缺点 | 价格贵；灵活度低 | 效率低；便宜 | 更新不及时；负载均衡策略少 |
- 软件负载均衡分为直接建设在操作系统内核的均衡器和应用程序形式的均衡器两种
- 前者性能高，无须在内核空间和应用空间中来回复制数据包
- 后者灵活度高，效率低
3.3. 负载均衡器选择工作在四层还是七层
3.3.1. 四层 vs 七层
| 四层 | 七层 | |
|---|---|---|
| 层次 | 网络层或者数据链路层 | 应用层 |
| 软件 | F5负载均衡、LVS四层负载均衡、HAProxy四层负载均衡、Nginx四层负载均衡 | Nginx七层负载均衡、HAProxy七层负载均衡 |
| 原理 | 虚拟MAC<->真实MAC或者虚拟IP<->真实IP | 解析HTTP请求转发到应用服务器 |
| 优点 | 效率高 | 灵活度高 |
- 四层负载均衡器并不是真的工作在四层（传输层），而是包含了二层和三层，毕竟传输层已经到到主机上的某个应用程序了，还负载个锤子
- 二层负载均衡器（数据链路层）
- 优点：工作在二层效率高
- 缺点：无法感知应用；不能跨子网
- 三层负载均衡器（网络层）
- IP隧道模式：
- NAT模式：
- IP隧道模式：
- 二层负载均衡器（数据链路层）
- 七层负载均衡是代理而不是转发；同时指的是反向代理
- 代理 VS 转发：
- 代理类型
- 正向代理：客户端能感知，服务器感知不到
- 反向代理：客户端感知不到，服务器能感知
- 透明代理：客户端和服务器都感知不到。配置在网络中间设备上的代理服务，譬如，架设在路由器上的透明翻墙代理。
- 代理 VS 转发：
3.4. 负载均衡器放在客户端还是服务端
3.4.1. 服务端
- 负载均衡组件是服务端的（比如F5，Nginx等），可以配合注册中心使用
- 服务提供方将地址注册到注册中心中
- 服务消费方从DNS寻找到该负载均衡组件的地址，然后由负载均衡组件将请求转发到服务提供方
- 优点：对客户端透明
- 缺点：相比于客户端方案，服务端涉及网络传输效率偏低
3.4.2. 客户端
3.4.2.1. 内置在消费方
- 负载均衡组件是客户端的，内置在服务消费方里的，可以配合注册中心使用
- 服务提供方将地址注册到注册中心中
- 服务消费方从注册中心取出地址，然后负载均衡将请求转发到任意一个节点
- 优点：进程间通讯不涉及网络效率高
- 缺点：每种语言都得自己写一个负载均衡组件
3.4.2.2. 独立组件
- 负载均衡组件是客户端的，是独立的，可以配合注册中心使用
- 服务提供方将地址注册到注册中心中
- 服务消费方从注册中心取出地址，然后负载均衡将请求转发到任意一个节点
- 优点：虽然涉及网络通讯但是和客户端一起处于localhost，效率不低；无需每种语言都得自己写一个负载均衡组件
- 缺点：每种语言都得自己写一个负载均衡客户端，组件是通用的
3.4.3. 客户端 vs 服务端
| 客户端 | 服务端 | |
|---|---|---|
| 定义 | 由客户端获取所有后端服务器地址，再调用负载均衡 | 客户端直接调用负载均衡服务器，负载均衡转发到后端服务器 |
| 举例 | Ribbon | Nginx |
| 优点 | 进程间通讯不涉及网络效率高 | 对客户端透明 |
| 缺点 | 每种语言都得自己实现一遍 | 涉及网络传输效率偏低 |
讨论
使用 GitHub 账号参与讨论，评论会保存在 GitHub Issues 中。在 GitHub 查看