从零开始学架构-LVS

1，什么是LVS

全称为Linux Virtual Server，Linux系统虚拟服务器，主要用于IP层的负载均衡，使用集群技术为 Linux 构建高性能、高可用的服务器，提供良好的可扩展性、可靠性和可服务性。

2，分发模式

2.1，什么是分发模式

用户发起的请求达到负载均衡服务器后，负载均衡服务器根据已知的后台服务器列表，按照策略选择一个后台机器处理的过程叫负载均衡；将请求转发给后台服务器的方式被称为分发模式；

LVS支持的分发模式有三种：NAT、DR、TUN。
LVS支持的负载均衡策略有很多，如：无脑轮询、加权轮询、最少连接调度、加权最少连接调度、基于IP地址的最少连接调度、目标 IP Hash、源 IP Hash、预期最短延迟等。
接下来咱们先对分发模式展开详细介绍。

2.2，NAT

首先看下NAT的请求与响应流程。

NAT模式基于NAT技术，该技术主要流程为：当一个请求到NAT机器后，通过重写SIP地址、TIP地址，将请求转发给后台服务器，后台服务器处理完毕后将结果给NAT机器，NAT重写SIP、TIP地址最后将结果响应给用户。简单一句话理解为：NAT作为一个路由器角色对所有请求、响应重写SIP、TIP实现IP层负载均衡；
1，假设一个用户的IP为：117.117.117.1，LVS的对外的公网IP为：118.117.117.1；用户发起请求到LVS上，
2，LVS 通过NAT技术重写SIP、TIP，将请求转发给后台服务器； 3，后台服务器处理完毕后，将结果响应给LVS，LVS需要再次重写SIP地址、TIP地址。
4，LVS将结果响应给用户。

基于NAT技术优点非常明显，仅需要一个 公网IP 地址就可以完成多台机器的负载，横向扩展能力出色（不考虑吞吐量，仅考虑横向扩展能力的情况下）。
同样的，缺点也很明显：可扩展性有限。从上图中可以很明显的看出所有请求和响应都会经过LVS，因为请求包和响应包都需要被负载均衡器重写，导致LVS很容易成为系统的瓶颈。假设在一个单核LVS机器上，接收TCP 包的平均长度为 500Bytes，重写一个包的平均延迟为 50us 左右，单台后台服务器的平均吞吐量为 400Kb/s，计算得出LVS机器最大吞吐量为 9.53 MB/s。单台LVS最多可以调度 24 台后台服务器。
同样的问题也反映在带宽上，LVS作用在所有后台服务器端请求和响应的入口，所需的带宽是所有后台服务器响应带宽的总和。

那如何解决LVS成为系统瓶颈的问题呢？
不知大家是否留意过，绝大数请求的请求包很小，响应包却很大；我们根据这个特性继续往下思考，如果仅处理做流量转发，即仅处理请求包，响应包交给被转发的后台服务器处理，这样整体负载的性能是否可以成倍提高？于是LVS有了DR(全称为Director)、TUN（全称tunnel）两种分发模式。
如果还是基于NAT模式，是否还有其他解法呢？
答案是有的，LVS在实际生产环境中系统一般不会存在单机情况，如果LVS可以无限横向扩容，也可以解决问题(不考虑成本情况下)，那如何实现LVS的横向扩容呢？答案是多种负载均衡结合，如DNS负载+LVS NAT负载。

NAT模式介绍完毕后，接下来在看看DR模式。

2.3，DR

请求与响应流程：

实现原理：
相对于NAT模式，上图中多了画了MAC地址，为何要画这个呢？有什么作用呢？
IP地址： 按照规则为每台机分配的唯一逻辑的地址。
MAC地址： 全世界唯一地址，与所在网络没关系。
了解上面地址的区别后，我们再说为什么要画MAC地址，首先我们看下面这张图：

画MAC地址是因为通过IP地址无法定位到接受请求的网卡，首先通过IP定位到机器，再通过MAC地址找到对应的网卡，可能聪明的你有疑问了，既然MAC地址全球唯一，那为何还需要IP地址呢？这里就不做解释了，有兴趣可以阅读《TCP/IP详解卷一》。

了解上面基础信息后我们再看来DR的执行流程：
整体流程用户发起请求到LVS上后，LVS将用户请求中的SIP和MAC地址作为转发请求SIP和MAC，通过负载均衡算法选择一台后台服务器后，将后台服务器IP和MAC作为目的地址，给后台机器营造一个假象：用户直接发起请求到后台服务器的，后台服务器处理完毕后就可以直接将结果响应给用户了

优点： 可以轻松承接海量流量。假设TCP请求包为500Bytes，响应包为4KB，转发一个请求为10us，那么负载均衡器每秒最大占用带宽47.68MB，但是却可以支持390.62MB的响应结果，而实际中，经过一些优化后LVS的转发性能比案例中的高的多，LVS的DR的性能可以轻松做到每秒80W的负载。
缺点： 在NAT模式下仅需要一个公网IP，但是在DR模式下，需要为每一个后台服务器申请一个公网IP(这里的后台服务器一般都是NGINX)。该模式要求被转发的机器与LVS在同一个物理网段中，因此对被转发的机器数量受限于IP的最大数量

虽然DR模式解决了NAT模式导致LVS成为系统瓶颈的问题，但是被转发机器数量有很大的限制，TUN模式正好结合DR和NAT模式的优点。

2.4，TUN

实现原理：
tun全称tunnel，翻译为隧道。由此可以联想到IP隧道技术，难道TUN基于IP隧道技术实现的吗?实时的真相是什么呢？根据下面描述验证下猜想吧。
LVS在接受到请求包后，将原始IP包（包含用户IP和后台机器IP）作为数据包在封装一层，称为封装包，将LVS IP和最终目的IP作为请求头和封装包发送给接收机器，接受机器对请求拆包后得到原始IP包，转发原始IP包请求，给后台机器营造一个假象：用户直接发起请求到本机器的，那么本机器处理完毕后就可以直接将结果响应给用户了
看完上面糟糕的介绍后，相信聪明的你已经有了TUN是否基于IP隧道技术的答案，没错该模式就是基于IP隧道技术。
请求与响应路程

优点： 结合了NAT和DR的优势，机器的横向扩展能力很强。
缺点： 多了一次封包和拆包的过程，性能略低于DR，远高于NAT；兼容性不高，需要发起方和接受方都支持隧道技术。

至此LVS的三种分发模式已经全部介绍完毕了，下面再看看负载均衡。

3，负载均衡

目前我们常用的负载均衡算法有：
无脑轮询、加权轮询、最少连接调度、加权最少连接调度、目标 IP Hash、源 IP Hash。
LVS对常用负载均衡算法支持外，还支持：基于局部机器的最小连接调度、基于局部机器的最小连接复制连接调度算法、最短预期延迟调度、无队列调度算法。
由于篇幅较多，这里直接将本人总结好内容通过图片形式展示出来：

上图数据来自LVS路由算法直译。

4，高可用

LVS官网提供了五种高可用的方案，分别是：Keeplived+LVS，Piranha+LVS，UltraMonkey+LVS，heartbeat+mon+coda+LVS，heartbeat+ldirectord；
接下来本文以Keeplived+LVS为例展开介绍，其他方案感兴趣可以自行搜索。
什么是Keepalived？

作用是检测服务器的状态，如果有一台web服务器宕机，或工作出现故障，Keepalived将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。

与LVS结合的网络拓补图

5，负载均衡补充

5.1，硬件负载均衡和软件负载均衡

5.1.1，硬件负载均衡

定义： 是通过专门的硬件设备从而来实现负载均衡功能，比如：交换机、路由器就是一个负载均衡专用的网络设备。
常用硬件负载均衡设备： 目前典型有两款：F5 和 A10。 优点：

• 功能：支持四层、七层负载均衡及全面负载均衡算法；
• 性能：性能远超常见的软件负载均衡器，以F5 BIG-LTM-i10800为例，四层负载最大吞吐量160GB（数据来自这里），LVS在以每秒100W负载，响应包3K，最大吞吐量才2.86G；
• 稳定性高：商业设备，质量有相当高的保障，售后服务完善；
• 安全性：除具备负载均衡功能外，还具备防火墙、防 DDoS 攻击等安全功能；

缺点：

• 价格昂贵：以F5 BIG-LTM-i10800为例，单台设备72W+；
• 可扩展性差：如果流量突增，采购设备、负载配置等，那个时候黄花菜都凉了；

5.1.2，软件负载均衡

常见负载均衡技术： LVS、NGINX、HAproxy、DNS负载。 优点：

• 简单： 学习成本不高，网上大量的文档和教程。
• 灵活：可以根据流量大小动态扩容机器。
• 便宜：常见软件负载都是开源免费，使用普通的机器就可以实现一定量级的负载均衡。 缺点：
• 性能：相对于硬件负载，性能差距好几个量级。

5.2，分层负载均衡

所谓的分层负载是针对OSI模型的不同层级做负载均衡；我们先来回顾下OSI的分层，具体分层如下图所示：

虽然OSI严格定义了分层结构和功能，但大部分实现却按照上图右侧四层方式实现，分层负载同样是这样。为了方便理解这里把实际层级负载对应到OSI分层来介绍。负载分层分别有：二层负载、三层负载、四层负载、七层负载。

负载层级	实现原理说明	常见技术实现
二层负载	请求到虚拟MAC（数据链路层能够表示唯一的只有MAC地址），再转发到真正的MAC主机上。	链路聚合方法和PPP捆绑
三层负载	相对于二层负载，该层是将MAC地址更换成了IP地址，请求到虚拟IP上，然后再转发到真正的IP上。	IP隧道，NAT
四层负载	IP地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。	LVS
七层负载	通过解析7层协议包，根据资源类型、自定义规则等来实现负载。	NGINX、Apache

5.3 常见负载均衡对比

对比项	NGINX	LVS	F5
负载均衡方式	TCP/IP协议中的第7层	TCP/IP协议中的第4层	硬件负载
性能	官网宣称最大负载5w/s	不同的转发模式性能差异很大，DR模式一般在50~100w/s左右	不同规格差异挺大的，比LVS高出很多倍
功能	除负载均衡外，提供域名解析、静态资源解析、动态接口转发、限流、响应压缩、缓存等功能，可以结合其他语言实现本身不能提供的功能	仅包含负载均衡	安全防护、负载均衡
收费情况	开源免费	开源免费	收费，以F5 BIG-LTM-i10800为例，单机72W+
安全性	限流、黑白IP名单	-	具备防火墙，防 DDos 攻击等安全功能
支持网络协议	http、https和Email	四层及以上任意协议	四层及以上任意协议
难易程度	功能强大，配置较多，有一定的学习成本	功能不多，配置较少	-
负载均衡算法	无脑轮询、加权轮询、ip_hash、fair、url_hash	无脑轮询、加权轮询、最少连接调度、加权最少连接调度、目标 IP Hash、源 IP Hash、基于局部机器的最小连接调度、基于局部机器的最小连接复制连接调度算法、最短预期延迟调度、无队列调度算法	无脑轮询、最小的连接数、优先级、自定义规则、流量比例
扩展性	用户可以根据业务需求动态扩展功能，如：lua-nginx-module	-	-
可用性	常用Keeplived+Nignx实现双机主备	官网给出5种高可用方案。Keeplived+LVS实现双机主备就是一种	待研究研究再补充上

总结概述：
NGINX：

• 安全性：安全性较高，处于OSI第7层，很容易得到请求IP、URL等信息用于实现安全防护，如限流、黑名单等功能
• 性能相对于四层负载较差：处于OSI第7层，由于需要对协议进行解析+提供功能损耗，官网测试每秒最大负载5W
• 功能强大：提供限流、缓存，域名解析等多重功能，因此有一定学习成本，排查问题依赖经验
• 高可用：配合Keeplived等技术，轻松实现高可用

LVS：

• 性能较高：本身不产生任何流量，对CPU、内存占用较低。位于OSI第4层，通讯效率高。每秒负载量级为几十万级别
• 简单易上手：仅提供负载均衡功能，可操作性较少，上手、维护都很容易。
• 安全性：安全性不高，仅做流量转发，无识别DDOS攻击等。
• 高可用：配合Keeplived等技术，轻松实现高可用

6. FAQ

6.1，LVS 采用 IP 负载均衡技术和基于内容请求分发技术，为什么却说 LVS 是四层负载均衡？

LVS处理的是连接请求，包含IP地址+端口号，端口号的概念在OSI第四层传输层才有。