分布式软件架构——常见的四层负载均衡

负载均衡（Load Balance）

负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。
真正的大型系统的负载均衡过程往往都是多级的。比如，在各地建有多个机房，或者是机房有不同网络链路入口的大型互联网站，然后它们会从DNS解析开始，通过“域名” —> “CNAME” —> “负载调度服务” —> "就近的数据中心入口"的路径，先根据IP地址（或者其他条件）将来访地用户分配到一个合适的数据中心当中，然后才到了各式负载均衡。

负载均衡的两种形式

无论在网关建立了多少级负载均衡，从形式上来说都可以分为两种：四层负载均衡和七层负载均衡。四层负载均衡性能高，七层负载均衡功能强。
这里的“四层”和“七层”指的是经典OSI七层模型中，第四层传输层和第七层应用层。OSI七层模型如下，

这里“四层负载均衡”，其实是多种均衡器工作模式的统称。“四层”的意思是说，这些工作模式的共同特点都维持着同一个TCP连接，而不是说它就只工作在第四层。
事实上，这些模式主要都是工作在第二层（数据链路层，可以改写MAC地址）和第三层（网络层，可以改写IP地址），单纯只处理第四层（传输层，可以改写TCP、UDP等协议的内容和端口）的数据无法做到负载均衡的转发，因为OSI的下面三层是媒体层（Media Layers），上面四层是主机层（Host Layers）。所以，既然流量都已经到达目标主机上了，也就谈不上什么流量转发，最多只能做代理了。

四层负载均衡的工作模式

数据链路层负载均衡

数据链路层传输的内容是数据帧（Frame），比如我们常见的以太网帧、ADSL（Asymmetric Digital Subscriber Line）带宽的PPP（Point to Point Protocol）帧等。我们所讨论的具体上下文中是以太网帧。按照IEEE802.3标准，最典型的1500 Bytes MTU的以太网帧结构如下，

帧结构中各个含义如下：

• 前导码（Preamble）：包含7个字节，由1和0循环组成，每个字节内容都是:10101010; 前导码的作用是在发送方和接收方之间进行时钟同步；
• 帧开始符（Frame Starting Symbol）：1个字节，用于标志帧的起始位置；
• MAC目的地址（Media Access Control Destination Address）：每一块网卡都有独立的MAC地址，此地址告诉交换机将此帧送至哪块网卡；
• MAC源地址（Media Access Control Source Address）：此地址告诉交换机从哪个端口的网卡发出此帧；
• 802.1Q标签（802.1Q Tag）：4个字节的802.1Q标签中，包含了两个字节的标签协议标识（Tag Protocol Identifier，TPID，它的值是8100）和两个字节的标签控制信息（Tag Control Information，TCI)，TPID是IEEE定义的新的类型，表明这是一个加了802.1Q标签的报文；
• 以太类型（Ethernet Type）：上层协议的类型。由于上层协议众多，所以在处理数据的时候必须设置该字段，标识数据交付哪个协议处理。例如，字段为 0x0800 时，表示将数据交付给 IP 协议；
• 有效负载（Payload）：也称为效载荷，表示交付给上层的数据。以太网帧数据长度最小为 46 字节，最大为 1500 字节。如果不足 46 字节时，会填充到最小长度。最大值也叫最大传输单元（MTU）。在 Linux 中，使用 ifconfig 命令可以查看该值，通常为 1500；
• 冗余校验（Redundancy Check）：检测该帧是否出现差错，占 4 个字节（32 比特）；
• 帧间距（InterFrame Gap）：表示以太网相邻两帧之间的时间段，以太网发送方式是一个帧一个帧的发送，帧与帧之间需要间隙，即帧间距；

数据链路层负载均衡所做的工作，是修改请求的数据帧中的MAC目的地址，让用户原来是发给负载均衡器的请求的数据帧，被二层交换机根据新的MAC目的地址，转发到服务器集群中，对应的服务器（真实服务器，Real Server）的网卡上，这样真实服务器就获得了一个原本目标并不是发送给它的数据帧。
由于二层负载均衡器在转发请求过程中，只修改了帧的MAC目的地址，不涉及更上层协议（没有修改PayLoad数据），所以在上层看来，所有数据是没有改变过的。
这是因为第三层的IP数据包中，包含了源（客户端）和目的（均衡器）的IP地址，只有真实服务器保证自己的IP地址与数据包中的目的IP地址一致，这个数据包才能被正确处理。
所以，在使用这种负载均衡模式时，需要把真实物理服务器集群所有机器的虚拟IP地址（Virtual IP Address，VIP），配置成跟负载均衡器的虚拟IP一样，这样经负载均衡器转发后的数据包，就能在真实服务器中顺利使用。
另外，也正是因为实际处理请求的真实物理服务器IP和数据请求中的目的IP是一致的，所以响应结果就不再需要通过负载均衡服务器进行地址交换，我们可以把响应结果的数据包直接从真实服务器返回给用户的客户端，避免负载均衡器网卡带宽成为瓶颈，所以数据链路层的负载均衡效率是相当高的。
整个请求到响应的过程如下图，

如上图所示，数据链路层负载均衡的工作模式是只有请求会经过负载均衡器，而服务的响应不需要从负载均衡器返回，整个请求、转发、响应的链路形成了一个“三角关系”。所以，这种负载均衡模式也被形象地成称为“三角传输模式”（Direct Server Return，DSR），也有人叫它是“单臂模式”（Single Legged Mode）或者“直接路由”（Direct Routing）。不过，虽然数据链路层负载均衡的效率很高，但它并不适用于所有的场合。除了那些需要感知应用层协议信息的负载均衡场景它无法胜任外（所有四层负载均衡器都无法胜任），在网络一侧收到的约束也很大。
原因是，二层负载均衡器直接改写MAC地址的工作原理，决定了它与真实服务器的通讯必须是二层可达的。通俗地说，就是它们必须位于同一个子网当中，无法跨VLAN。
所以，这个优势（效率高）和劣势（不能跨子网）就共同决定了，数据链路层负载均衡器最适合用来做数据中心的第一级均衡设备，用来连接其他的下级负载均衡器。

网络层负载均衡

根据OSI七层模型，第三层网络层传输的单位是分组数据包（Packets），这是一种在分组交换网络（Packet Switching Network，PSN）中传输的结构化数据单位。
以IP协议为例，一个IP数据包由Headers和Payload两部分组成，Headers长度最大60 Bytes，它是由20 Bytes的固定数据和最长不超过40 Bytes的可选数据组成。按照IPv4标准，典型的分组数据包的Header部分的结构如下，

沿用二层改写MAC地址相似的思路，这里通过改变IP地址，来实现数据包的转发。

修改IP地址的两种常见方式如下：

1. 第一种修改IP方式：保持原来的数据包不变，新创建一个数据包，把原来数据包的Headers和Payload整体作为另一个新的数据包Payload，在这个新数据包的Headers中，写入真实服务器的IP作为目的地址，然后把它发送出去。
   如此经过三层交换机的转发，在真实服务器接收到数据包后，必须针对原来负载均衡器自动添加的那层Header去掉（拆包机制），还原出原来的数据包进行使用。真实服务器就拿到了原本不是发给它（目标IP非自己）的数据包，从而达到了流量转发的目的。这种“套娃式”的传输也叫“IP隧道”（IP Tunnel）传输。
   
   IP隧道的转发模式比直接路由的模式，效率上有所下降，因为它并没有修改原有数据包中的任何信息，所以IP隧道的转发模式仍然具备三角传输的特性。另外，因为IP隧道工作在网络层，所以是可以跨越VLAN的。不过这种转发模式也有缺点，即它要求真实服务器必须得支持“IP隧道协议”（IP Encapsulation），也就是它得学会自己拆包扔掉一层Headers。
   另一个问题是，这种模式仍然必须通过专门的配置，必须保证所有的真是服务器与均衡器有着相同的虚拟IP地址。因为真实服务器在回复该数据包时，需要使用这个虚拟IP作为响应数据包的源地址，这样客户端在收到这个数据包的时候才能正确解析。
2. 第二种修改IP方式：直接把数据包Headers中的目标地址改掉，修改后原本由用户发给均衡器的数据包，也会被三层交换机转发到真实服务器的网卡上，而且因为没有经过IP隧道的额外包装，也就无需拆包。
   但问题是，这种模式修改了目标IP才能到达真实服务器，如果真实服务器直接把应答包发回给客户端的话，这个应答数据包的源IP是真实服务器的IP，也就是均衡器修改以后的IP地址，那么客户端就不可能认识该IP，自然也就无法再正常处理这个应答了。因此，只能让应答流量继续回到负载均衡，负载均衡把应答包的源IP改回自己IP，然后再发给客户端，这样才能保证客户端与真实服务器之间的正常通信。
   这种负载均衡模式也被称为NAT（Network Address Translation）模式，比如一台路由器带着一群内网机器上网的操作。
   
   在流量压力比较大的时候，NAT模式的负载均衡会带来较大的性能损失，比起直接路由和IP隧道模式，甚至会出现数量级上的下降。还有种更加彻底的NAT模式，就是均衡器在转发时，不仅修改目标IP地址，连源IP地址也一起修改了，这样源地址就改成了均衡器自己的IP。这种也叫做SNAT（Source Network Address Translation）。
   在这样的好处是真实服务器连网关都不需要陪着孩子了，它能让应答流量经过正常的三层路由，回到负载均衡器上，做到了彻底的透明。
   缺点是由于做了SNAT，真实服务器处理请求时就无法拿到客户端的IP地址，在真实服务器的视角看来，所有的流量都来自于负载均衡器，这样有一些需要根据目标IP进行控制的业务逻辑就无法进行。

应用层负载均衡

前面的四层负载均衡的工作模式都属于“转发”，即直接将承载着TCP报文的底层数据格式（IP数据包或以太网帧），转发到真实服务器上，此时客户端到响应请求的真实服务器维持着同一条TCP通道。
工作在四层这之后的负载均衡模式无法再进行转发，只能进行代理。此时，正式服务器、负载均衡器、客户端三者之间，是由两条独立的TCP通道来维持通信的。

代理分为下面三种：

• 正向代理：客户端设置的代理，代表客户端与服务器通讯的代理服务。它是客户端可知，而对服务器是透明的。
• 反向代理：服务端设置的代理，代表真实服务器来与客户端通讯的代理服务。此时它对客户端来说是透明的。
• 透明代理：指对双方都透明的，配置在网络中间设备上的代理服务。比如，架设在路由器上的透明代理。

根据上面的定义，七层负载均衡器属于反向代理。如果只论网络性能，七层负载均衡器肯定是无论如何比不过四层负载均衡器的。毕竟它比四层负载均衡器至少要多一轮TCP握手，还有着跟NAT转发模式一样的带宽问题，而且通常要耗费更多的CPU，因为可用的解析规则远比四层丰富。
所以说，如果要用七层负载均衡器去做下载站、视频站这种流量应用，一定是不合适的，起码它不能作为第一级均衡器。
但是，如果网站的性能瓶颈并不在于网络性能，而是要论整个服务集群对外所体现出来的服务性能，七层负载均衡器就有它的用武之地了。这里，七层负载均衡器的底气就来源于，它是工作在应用层的，可以感知应用层通讯的具体内容，往往能够做出更明智的决策，玩出更多的花样来。
比如说，反向代理的工作模式就能够实现静态资源缓存，对于静态资源的请求就可以在反向代理上直接返回，无需转发到真实服务器。
所有CDN可以做的缓存方面的工作（除去CDN根据物理位置就近返回这种优化链路的工作外），七层负载均衡器全部都可以实现，比如静态资源缓存、协议升级、安全防护、访问控制，等等。
七层负载均衡器可以实现更智能化的路由。比如，根据Session路由，以实现亲和性的集群；根据URL路由，实现专职化服务（相当于网关指责）；甚至根据用户身份路由，实现对部分用户的特殊服务（如某些站点的贵宾服务器），等等。
某些安全攻击可以由七层负载均衡器来抵御。比如，一种常见的DDos（Distributed Denial of Service）手段是SYN Flood攻击，即攻击者控制众多客户端，使用虚假IP地址对同一目标大量发送SYN报文。从技术原理上看，因为四层负载在均衡器无法感知上层协议的内容，这些SYN攻击都会被转发到后端的真实服务器上；而在七层负载均衡器下，这些SYN攻击自然就会在负载均衡器设备上被过滤掉，不会影响到后端服务器的正常运行。
另外，很多微服务器架构系统中，链路治理措施都需要在七层中进行，比如服务降级、熔断、异常诸如，等等。

均衡策略与实现

负载均衡的两大职责是：
-1.选择谁来处理用户请求；
-2.将用户请求转发过去；
前面只介绍了后者，即请求的转发或代理过程，而“选择谁来处理用户请求”是指均衡器所采取的均衡策略，下面就看看常见的策略。

常见的均衡策略

轮询均衡（Round Robin）

即每一次来自网络的请求，会轮流分配给内部中的服务器，从1到N然后重新开始。这种均衡算法适用于服务器组中的所有服务器都有相同的软硬件配置，并且平均服务器请求相对均衡的情况。

权重轮训均衡（Weighted Round Robin）

根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。

随机均衡（Random）

即把来自客户端的请求随机分配给内部中的多个服务器。这种均衡算法在数据足够大的场景下，能够达到相对平衡的分布。

权重随机均衡（Weighted Random）

类似权重轮询算法，不过在处理请求分担的时候，它是随机选择的过程。

一致性哈希均衡（Consistency Hash）

即根据请求中的某些数据（可以是MAC、IP地址子，也可以是更上层协议中的某些参数信息）作为特征值，来计算需要落在哪些节点上，算法一般会保证同一个特征值，每次都一定落在相同的服务器上。在这里的一致性是，保证当服务集群的某个真实服务器出现故障的时候，只影响该服务器的哈希，而不会导致整个服务器集群的哈希键值重新分布。

响应速度均衡（Response Time）

即负载均衡设备对内部各服务器发出一个探测请求（如Ping），然后根据内部中各服务器对探测请求的最快响应时间，来决定哪一台服务器来响应客户端的服务请求。这种均衡算法能比较好地反应服务器的当前运行状态。这里的最快响应时间，仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户端与服务器间的最快响应时间。

最少连接数均衡（Least Connection）

客户端的每一次请求服务，在服务器停留的时间可能会有比较大的差异。那么随着工作时间加长，如果采用简单的轮询或者随机均衡算法，每一台服务器的连接进程可能会产生极大的不平衡，并没有达到真正的负载均衡。所以，最少连接数均衡算法就会对内部中需要负载的每一台服务器，都有一个数据记录，也就是记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，就把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况。这种算法适用于长时间处理的请求服务，比如FTP传输。

均衡器的实现

从实现角度来看，负载均衡器的实现有软件均衡器和硬件均衡器。

软件均衡器

分为直接建设在操作系统内核的均衡器和应用程序形式的均衡器两种。

• 操作系统内核的均衡器：代表是LVS（Linux Virtual Server），相比性能会更好，因为它不需要在内核空间和应用空间中来回复制数据包；
• 应用程序形式的均衡器：代表是Nginx、HAProxy、KeepAlived，优势是选择广泛，使用方便，功能不受限于内核版本；

硬件均衡器

直接采用应用专用集成电路（Application Specific Integrated Circuit，ASIC）来实现。因为它有专门处理芯片的支持，可以避免操作系统层面的损耗，从而能够达到最高的性能。这类的代表就是著名的F5和A10公司的负载均衡产品。