Load balancer(负载均衡器)

多服务器下的请求调度机制称为负载均衡（Load balancing），调度器（Dispatcher）即负载均衡器（Load balancer）：

负载平衡器的基本功能是能够根据调度算法在集群中的多个后端服务器上分发传入请求。
其主要作用是根据既定策略（如随机、轮流）将客户端请求分发给各个服务器，之前有过相关算法整理：13种负载均衡算法
优点：

防止请求到达不可用的服务器
防止资源过载
消除单点故障，提升可用性

还可以用于：

SSL termination：处理 SSL 连接，将加密解密的工作前置到调度层
会话保留（Session persistence）：集中处理会话，避免切换服务器造成会话状态丢失

也就是说，多机场景下，必须要有一个负责分发/调度请求的负载均衡器，那么，接下来的问题是应该在哪一层实现负载均衡机制

请求传输拆解

考虑一个 HTTP 请求从客户端到服务器的通信过程，可以简单划分为 3 个阶段：

出发：客户端发出请求
途中：请求经网络传输
到达：服务器收到请求

对请求进行分发/调度，就是要想办法（按既定策略）改变请求的目的地，那么，至少有 3 种思路：

出发前：在请求经网络传输之前，就确定最终目的地，例如 DNS 负载均衡、客户端负载均衡
传输中：在网络传输的某些环节改变目的地，例如 4 层负载均衡
到达后：在请求抵达服务器后，进行二次分发，例如 7 层负载均衡

下面逐个讲解这几种负载均衡

DNS 负载均衡

客户端要向服务器发起请求，首先要知道服务器的 IP 地址，通过DNS来查询，DNS 维护着域名与 IP 地址之间的映射关系，因此可以在这里实现负载均衡策略，将请求指向目标服务器（的 IP 地址），例如：

轮流分发：添加一系列 A 记录，将同一域名指向多个不同的 IP 地址即可，称为round-robin DNS
随机分发：采用支持多值应答路由策略的 DNS 服务

这两个方法简单易用，但缺陷也很明显：

可靠性没有保障：DNS 并不检查服务器的可用性，即便目标服务器 down 掉了或者无法访问了，也返回其 IP 地址
更新不及时：DNS 的解析结果往往会被层层缓存，记录更新无法立即生效

客户端负载均衡

同理，把服务器 IP 地址选择机制拿到客户端来实现，就叫客户端负载均衡，由客户端自行选择目标服务器的 IP 地址（不再通过 DNS 查询）：

例如，向客户端提供服务器 IP 列表，客户端发起请求之前随机选取一个 IP，就能达到随机分发的目的
比起 DNS 负载均衡，客户端不存在缓存的问题，而且能够进行更精细的控制，比如检查服务可用性，并从中选取可用的 IP 地址

OSI 七层模型回顾

在计网中我们学过网络的七层模型，将网络通信分为 7 个抽象层：

自下而上，依次为：

物理层(1)：通过物理介质传输原始比特流，即物理信号
数据链路层(2)：提供可靠的节点间数据帧传输机制，具体工作包括MAC寻址
网络层(3)：决定数据包传输采取的物理路径，支持IP、ARP等协议，具体包括IP寻址、路由和流量控制
传输层(4)：提供可靠的报文传输机制，支持TCP、UDP等传输协议，此时依赖于IP和端口号通信
会话层(5)：负责管理会话，以支持通过多次传输连续交换信息
表现层(6)：将来自网络服务的数据翻译成应用层可用的格式，具体工作包括字符编码转换、数据压缩、加密解密等
应用层(7)：提供高级API的人机交互层，应用能够通过该层访问网络服务，如资源共享、远程文件访问等

其中，第 1 层是原始数据，第 2 层确定目标机器的 MAC 地址，第 3 层确定终点的 IP 地址，以及途经的具体路线，到第 4 层，要根据传输协议确定目标端口号，第 5~7 层不关心终点，因为 IP 地址 + MAC 地址 + 端口号已经唯一确定了目标应用程序.
也就是说，一个 HTTP 请求必须经由这些层才能到达目标服务器，那么，理论上，在第 2~7 层中的任意一层都有机会变更终点，实现负载均衡。而常见的负载均衡机制多实现在第 4 层和第 7 层。

2 层、3 层负载均衡

2 层负载均衡：根据源/目标 MAC 地址进行分发，例如将虚拟 MAC 地址根据既定策略映射到实际 MAC 地址
3 层负载均衡：根据源/目标 IP 地址，以及第 2 层信息进行分发，例如解析虚拟 IP（Virtual IP address）

越靠近底层，所能用来进行分发决策的信息越少，所以 2 层负载均衡的实际用途有限，常见的只有冗余网关协议（如GLBP、VRRP）和链路聚合（Link aggregation，也叫 etherchannel）等。

3/4 层负载均衡

4 层负载均衡基于传输层（第 4 层）信息进行请求分发，包括源/目标 IP 地址，以及数据包头部的端口号，但不考虑数据包内容：

第4层负载平衡使用在网络传输层（第4层）定义的信息作为决定如何在一组服务器之间分发客户端请求的基础。
具体来说，对于Internet流量，第4层负载平衡器根据包头中记录的源和目标IP地址以及端口来做出负载平衡决策，而不考虑包的内容

客户端将将负载均衡器的 IP 地址作为目标 IP 地址发起请求，4 层负载均衡器收到请求后，对数据包进行NAT转换，将目标 IP 地址修改成实际服务器的地址，在将服务器响应转发给客户端之前，负载均衡器再将源 IP 地址改成自身的 IP 地址。类似的，对数据包中的源/目标端口号也以这种方式进行修改。
第 4 层负载均衡器通常是专用的硬件设备，NAT 操作可能会由专用芯片来完成。
与更复杂的 7 层负载均衡相比，4 层负载均衡所需的计算更少，但在目前的硬件条件下，由此带来的性能优势已经不重要了。严格来讲，4 层负载均衡应该叫 3/4 层负载均衡，因为结合了第 3 层的 IP 地址和第 4 层的端口号信息

7 层负载均衡

第7层负载平衡器根据HTTP头的各种特征和消息的实际内容（例如URL、数据类型（文本、视频、图形）或cookie中的信息）来决定路由。
比起 4 层负载均衡，7 层负载均衡可以读取请求和响应内容，所需的计算虽然更多，但不见得比 4 层负载均衡性能更差，因为拥有更全面的上下文信息，可以在此基础上进行更聪明的全局决策（比如剔除慢速连接、重定向超时请求），甚至还能对内容进行优化（比如压缩），从而提高性能。
严格来讲，7 层负载均衡应该叫 5~7 层负载均衡，因为结合了 OSI 模型中 5~7 层的相关信息：

后台系统可扩展性学习笔记（五）负载均衡相关推荐

后台系统可扩展性学习笔记
整理了一下笔记目录,将以前学习的一些知识串联起来了,比如cdn.负载均衡.中间件,以前只是各自了解了一点,现在大概理清了后台系统设计中他们各自的作用. 后台系统可扩展性学习笔记(一)概要后台系统可扩 ...
后台系统可扩展性学习笔记（一）概要
文章目录系统大致架构可扩展性负载均衡器与会话保持引入冗余增强系统可用性缓存减轻数据库压力异步处理参考系统大致架构当一个用户请求从客户端出发,经过网络传输,达到 Web 服务层,接着进 ...
后台系统可扩展性学习笔记（七）Service Discovery与微服务
文章目录应用层微服务架构服务注册查询 Service Discovery 客户端 Service Discovery DNS-SD DNS-based Service Discovery 服务端 ...
后台系统可扩展性学习笔记（三）DNS机制原理
文章目录 DNS概念梳理域名基本概念资源记录基本概念路由策略 DNS 域空间结构实现原理复制机制查询机制缓存机制参考 DNS概念梳理 DNS(Domain Name System)相当 ...
后台系统可扩展性学习笔记（十四）异步机制与MQ
对于 Web 服务而言,提升可扩展性的主要途径是将耗时的同步工作改成异步处理,从而允许将这些工作"外包"给多个 Worker 去做,或者提前完成能够预知的部分. 异步机制与可扩展性 ...
后台系统可扩展性学习笔记（十）Database Partitioning
为了提升数据库的处理能力,我们把单库扩展成多库,并通过更新同步机制(即Replication)来保证多份数据的一致性.然而,在各种复制方案下,每个数据库都持有一份完整数据,基于全量数据提供增删改查服 ...
后台系统可扩展性学习笔记（十二）NoSQL
文章目录 NoSQL定义 NoSQL种类键值存储文档存储宽列存储图形数据库 NoSQL 意味着什么 ACID vs. BASE SQL or NoSQL NoSQL定义不同于关系型数据库,N ...
后台系统可扩展性学习笔记（十三）缓存
文章目录在哪儿加缓存缓存什么内容缓存原始查库结果缓存数据对象怎么查询缓存结果预留缓存模式直读模式直写模式回写式缓存绕写式缓存提前刷新模式缓存满了如何处理参考读写分离.分库分 ...
后台系统可扩展性学习笔记（十一）Database Denormalization
之前的两篇笔记中谈到了从单库扩展到多库以承载更多的请求量以及单库(表)拆分成多库(表),打破单库的性能瓶颈. 这都是为了应对大数据量下的措施. 然而,除却数据量外,还有一个极其影响单库性能的因素--数 ...

后台系统可扩展性学习笔记（五）负载均衡

文章目录