简单系统设计 —— 负载均衡（二）
本系列，是自己学习Grokking the System Design过程中的笔记。
希望读者在看完全文后，也能留下你们的经验。我万分荣幸能收到你们的消息。
如果能从这里学到点东西，记得请我喝杯☕☕☕~
—— MinRam
一、前言 Overview
负载均衡, 指将流量分配到多个服务器，以确保流量能到合适的服务器进行处理。
负载均衡（Load Balance) 是分布式集群中的核心组件。分配流量到后端集群上的多个服务器中，主要目的是：
- 分摊： 将流量压力分摊到后端集群中的所有节点，这也是无状态水平扩容的基础要求之一。
- 可用： 将流量分配到可用的后端节点中，以保证对于前端使用者来说，服务一直是可用的。
- 安全: 能有效的分流压力攻击的流量，如DDOS.
- 环境隔离： 诸如协议转换（SSL流量的加解密）等一系列预处理，都会放在负载均衡上。
扩展概念：网关 Gateway, 架构上的概念，除了负载均衡外，直接分割了内部应用和外部服务，实现安全层的认证功能。解决服务治理的问题，将服务聚合的逻辑下沉到服务层。
二、在系统中的位置 Position
在商用级系统中，负载均衡常放在以下三种会面对较大流量的位置：
终端（PC, 移动设备， 物联网设备) 和 Web服务器集群
Web服务器集群 和 内部服务集群（业务服务，缓存服务等）
数据库 和 数据库操作的服务
可以看出每个集群前，理论上都可以放入负载均衡作为入口和出口。需要权衡成本，维护等因素，最终决定是否需要。
三、优势 Benefits
用户体验优化： 用户体验不间断，更快速的服务。用户并不需要等待故障节点的修复。
单点故障隔离： 隔离单点故障对整个系统的影响，从而提供额外修复迭代的时间。
可用时间增加： 减少系统的停机时间，可以做到不停机的组件维护，版本升级（滚动升级，灰度发布）。
流量统计： 通过在负载均衡器部署额外的预处理组件，可以构建流量模型，为后续性能提升和业务优化，提供数据参考。
自动化入口： 对于商业级系统开发团队，自动化是解放团队人力的关键措施。作为流量必经站，负载均衡器是自动化运维的重要切入点。
网络管家： 允许系统组件灵活的网络，在不影响安全性，服务或性能的情况下能挑战更复杂的业务场景。实现软件定义网络。
四、转发策略 Algorithms
负载均衡是如何选择要发给哪台后端节点？
对于负载均衡器，有两个重要的因素： 要发给谁 & 能发给谁。
前者是能处理流量的节点集合，后者是状态为健康的节点集合，两者的交集就是目标节点集合。那么剩下的就是以什么样的算法去将压力分布到目标节点集合上。
健康检查，是负载均衡器判断节点为健康的逻辑。基本思路：负载均衡器定期向后端节点发送健康检查请求，通过判断返回值来决定该节点是否为健康。如未收到返回值或者收到的返回内容中说明该节点无法接受流量，则负载均衡器将会把这个节点从目标节点集合移除，直到下一次检查或者节点主动告知。
面对不同场景，选择对应的转发策略：
最少连接 Least Connection Method
将流量转发给有效连接最少的服务器。适用于流量中有大量持久连接。最短响应时间 Least Response Time Method
将流量转发给有效连接最少且平均响应时间最短的后端节点。最少带宽 Least Bandwidth Method
将流量转发到处理流量最少的后端节点上。适用于大流量的业务场景。轮询调度 Round Robin Method
将可用后端节点组成环状队列，依次转发给该队列。适用于持久连接较少且后端节点处理流量的能力一致的场景。加权轮询调度 Weighted Round Robin Method
现实场景中，每个后端节点随着伸缩，处理流量的能力各不相同。因而加了一个参考的权值。权值高的后端节点，会比其他后端节点更早和更多地获取到流量。IP哈希分散 IP Hash
通过客户端的IP地址决定哪个后端节点接受请求。
五、自身可用性
单个负载均衡器仍存在故障的概率，因而可以设置冗余负载均衡器，构成主备HA或者集群形式。互相监听对方的健康状态。在主机故障的场景下，备用机能主动接管流量。
六、负载均衡的类型（加深内容）
在七层开放系系统互连模型（OSI)中， 网络防火墙 位于1-3层（L1-物理连线，L2-数据链路，L3-网络层）。而负载均衡器,则在4-7层（L4-传输层，L5-会话层, L6-表示层，L7-应用层)。
- L4 根据来自网络和传输层协议的数据（IP地址和端口）完成转发
- L7 读取数据包内容，可以根据HTTP Header，Uniform resource identifer，HTML form data和SSL Session ID的内容决定转发逻辑。
根据负载均衡的协议逻辑，主要分为一下几种类型：
6.1 SDN
使用SDN（软件定义网络）的负载平衡将控制平面与数据平面分离以进行应用交付。这允许控制多个负载平衡。
该类型的负载均衡器，笔者也是一知半解，目前只看到相关的学术论文，待后续补充。
6.2 UDP
针对UDP协议进行转发的负载均衡器，仅保留基础的纠错，追求极致的性能&延迟。特别适用于游戏和直播的产品中。
6.3 TCP
常见的业务负载均衡器基本是采用TCP协议。大部分的软件系统还是提供数据处理服务，光丢包就会丢失重要的数据。需要基于TCP协议保障数据包准确无误地到达目的地。
6.4 SLB
服务器负载均衡器，针对后端节点为服务器的使用场景，将客户端流量分配到服务器上，以确保一致的高性能业务交付。
6.5 Virutal
虚拟化负载均衡器，指负载均衡器的承载体是虚拟化设备（如虚拟机）。常见于正在尝试云化的产品。仍存在传统硬件的限制（维护，停机，可扩展性）
6.6 Elastic
弹性负载均衡器，在需要的时候拓展自身实例，以满足业务需求。如流量增大，或者后端节点增加，需要提升负载均衡器的流量处理能力和后端节点的管理能力。
6.7 Geographic
地理负载均衡器，可以根据需要将流量转发到指定地理位置的后端节点，或次级负载均衡器。在全球级商业系统，往往会有一个全球负载均衡器，来处理来自世界各地的流量，再交给离流量发送者较近的次级负载均衡器，以减少延迟。、
6.8 Multi-site
多站点负载均衡器，用来在多个站点间分配流量。如上一点提到全球负载均衡器。常见使用场景，如在生产和容灾站点间分配流量，以保证整个系统的可用性。
6.9 LBaaS
在云时代，负载均衡器被抽象成一种云服务类型。不再局限于某个服务器上，能更好地配合云计算的使用场景。大部分是指基于OpenStack虚拟架构的负载均衡器。
除了从功能的分类，负载均衡器还有硬件和软件的区分。
