架构之软件负载均衡

目前市面上最常见的负载均衡主要有三种：

基于DNS负载均衡(一个域名映射多个ip)

优点

缺点：

1. 可用性差：DNS解析是多级解析，新增/修改DNS后，解析时间较长；解析过程中，用户访问网站将失败。
2. 扩展性低：DNS负载均衡的控制权在域名商那里，无法对其做更多的改善和扩展。
3. 维护性差：也不能反映服务器的当前运行状态；支持的算法少；不能区分服务器的差异（不能根据系统与服务的状态来判断负载）。
4. 更新不及时：DNS缓存可能会保留较长时间。

基于硬件负载均衡，例如那些贵的离谱的硬件设备，F5，A10，并发百万级别

优点

1. 功能强大：全面支持各层级的负载均衡，支持全面的负载均衡算法，支持全局负载均衡。
2. 性能强大：对比一下，软件负载均衡支持到 10 万级并发已经很厉害了，硬件负载均衡可以支持 100 万以上的并发。
3. 稳定性高：商用硬件负载均衡，经过了良好的严格测试，经过大规模使用，稳定性高。
4. 支持安全防护：硬件均衡设备除具备负载均衡功能外，还具备防火墙、防 DDoS 攻击等安全功能。

缺点

1. 价格昂贵：最普通的一台 F5十多万，好一点近百万元。
2. 扩展能力差：硬件设备，可以根据业务进行配置，但无法进行扩展和定制。

实践建议

可以在DNS作地理级别负载均衡的情况下，在其下级使用F5或A10作为低级的负载均衡器，之后将流量转发到下级集群，如下图所示。

基于软件负载均衡

DNS一般由gslb本文也主要介绍利用软件进行负载均衡方案：Nginx、LVS、HAProxy 是目前使用最广泛的三种负载均衡软件，本人都在多个项目中实施过，通常会结合Keepalive做健康检查，实现故障转移的高可用功能。

 Nginx、HAproxy、LVS，其中的区别：

• Nginx：七层（OSI网络七层模型，第七层应用层）负载均衡，支持 HTTP、E-mail 协议，同时也支持四层负载均衡；
• HAproxy：支持七层规则的，性能也很不错。OpenStack 默认使用的负载均衡软件就是 HAproxy；
• LVS：运行在内核态，性能是软件负载均衡中最高的，严格来说工作在第三层网络层，所以更通用一些，适用各种应用服务。

在四层（tcp）实现负载均衡的软件：
lvs------>重量级
nginx------>轻量级，带缓存功能，正则表达式较灵活
haproxy------>模拟四层转发，较灵活

在七层（http）实现反向代理的软件
haproxy------>天生技能，全面支持七层代理，会话保持，标记，路径转移；
nginx------>只在http协议和mail协议上功能比较好，性能与haproxy差不多；
apache------>功能较差
 

总的来说，一般是lvs做4层负载；nginx做7层负载；haproxy比较灵活，4层和7层负载均衡都能做一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析：
1）如果是中小型的 Web 应用，比如日PV小于1000 万，用 Nginx 就完全可以了；
2）如果机器不少，可以用DNS轮询， LVS所耗费的机器还是比较多的；大型网站或重要的服务，且服务器比较多时，可以考虑用LVS。
还有一种是通过硬件来进行进行，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小
的网络服务来说暂时还没有需要使用；另外一种就是类似于 Nginx/LVS/HAProxy 的基于 Linux 的开源免费的负载均衡软件，这些都是通过软件级别来实现，所以费用非常低廉。目前关于网
站架构一般比较合理流行的架构方案： Web 前端采用Nginx/HAProxy+Keepalived 作负载均衡器；后端采用 MySQL 数据库一主多从和读写分离，采用 LVS+Keepalived 的架构。 当然要根据
项目具体需求制定方案。下面说说各自的特点和适用场合。
下面简单说下Nginx、LVS、HAProxy 负载均衡软件的优缺点：
 

1.LVS

LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。
现在 LVS 已经是 Linux 标准内核的一部分，从 Linux2.4 内核以后，已经完全内置了 LVS 的各个功能模块，无需给内核打任何补丁，可以直接使用 LVS 提供的各种功能。

1.1LVS 负载均衡机制

1.2LVS负载模式

1.2.1NAT 模式：网络地址转换

这种模式相当于网关。 

1.2.2DR 模式：直接路由

• 典型组网：

• 将2台弹性云服务器绑定同一个虚拟IP。将绑定了虚拟IP的这2台弹性云服务器配置Keepalived+LVS（DR模式），组成LVS主备服务器。这2台服务器作为分发器将请求均衡地转发到不同的后端服务器上执行。
• 配置另外2台弹性云服务器作为后端RealServer服务器。
• 关闭2台后端RealServer弹性云服务器的源/目的检查。
• 检查LVS主备服务器的源/目的检查是否关闭，请参见关闭源/目的检查（适用于高可用负载均衡集群场景）。若采用控制台方式将弹性云服务器与虚拟IP绑定，则源/目的检查自动关闭；若采用调用接口方式将弹性云服务器与虚拟IP绑定，则需要手动关闭源/目的检查。

优点：

1. 负载均衡器VS只负责将请求包分发给物理服务器RS，而物理服务器RS将应答包直接发给用户。所以负载均衡器VS能处理很巨大的请求量。
2. 这种方式，一台负载均衡能为超过100台的物理服务器服务，负载均衡器不再是系统的瓶颈。
3. 使用LVS/DR方式，如果你的负载均VS拥有100M的全双工网卡的话，就能使得整个Virtual Server能达到1G的吞吐量，甚至更高。

缺点

• 这种方式需要所有的DIR和RIP都在同一广播域；不支持异地容灾；配置麻烦，不能进行故障检测和日志记录。
• LVS/DR是三种模式中性能最高的一种模式，比LVS-NAT模式下负载的RS serve更多，通常在100台左右，对网络环境要求更高，也是日常应用的最多的一种工作模式。

Keepalived + LVS调度服务端安装配置以及后端RealServer服务器配置可以参考业内通用的配置方法，此处不做详细介绍
 

1.2.3IP隧道模式

隧道模式则类似于VPN的方式,使用网络分层的原理,在从客户端发来的数据包的基础上,封装一个新的IP头标记(不完整的IP头,只有目的IP部)发给RS,RS收到后,先把DR发过来的数据包的头给解开,还原其数据包原样,处理后,直接返回给客户端,而不需要再经过DR｡

1.3LVS调度算法

1.3.1轮询调度(Round-RobinScheduling)
调度器通过"轮询"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载｡

1.3.2加权轮询调度(WeightedRound-RobinScheduling)
调度器通过"加权轮询"调度算法根据真实服务器的不同处理能力来调度访问请求｡这样可以保证处理能力强的服务器处理更多的访问流量｡调度器可以自动问询真实服务器的负载情况,并动态地调整其权值｡

1.3.3最小连接调度(Least-ConnectionScheduling)
调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上｡如果集群系统的真实服务器具有相近的系统性能,采用"最小连接"调度算法可以较好地均衡负载｡

1.3.4加权最小连接调度(WeightedLeast-ConnectionScheduling)
在集群系统中的服务器性能差异较大的情况下,调度器采用"加权最少链接"调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载｡调度器可以自动问询真实服务器的负载情况,并动态地调整其权值

1.4LVS的优势和缺点

1.4.1 优点
1、抗负载能力强，因为lvs工作方式的逻辑是非常之简单，而且工作在网络4层仅做请求分发之用，没有流量，所以在效率上基本不需要太过考虑。在我手里的 lvs，仅仅出过一次问题：在并发最高的一小段时间内均衡器出现丢包现象，据分析为网络问题，即网卡或linux2.4内核的承载能力已到上限，内存和 cpu方面基本无消耗。
2、配置性低，这通常是一大劣势，但同时也是一大优势，因为没有太多可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率。
3、工作稳定，因为其本身抗负载能力很强，所以稳定性高也是顺理成章，另外各种lvs都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，lvs会自动判别，所以系统整体是非常稳定的。
4、无流量，上面已经有所提及了。lvs仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。
5、基本上能支持所有应用，因为lvs工作在4层，所以它可以对几乎所有应用做负载均衡，包括http、数据库、聊天室等等

1.4.2 缺点

LVS 的缺点是：
1）软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是 Nginx/HAProxy+Keepalived 的优势所在。
2）如果是网站应用比较庞大的话， LVS/DR+Keepalived 实施起来就比较复杂了，特别后面有 Windows Server 的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，
Nginx/HAProxy+Keepalived 就简单多了。

2.Nginx

Nginx 是一个强大的 Web 服务器软件，用于处理高并发的 HTTP 请求和作为反向代理服务器做负载均衡。具有高性能、轻量级、内存消耗少，强大的负载均衡能力等优势。

2.1 Nignx 的架构设计

• 相对于传统基于进程或线程的模型（Apache就采用这种模型）在处理并发连接时会为每一个连接建立一个单独的进程或线程，且在网络或者输入/输出操作时阻塞。这将导致内存和 CPU 的大量消耗，因为新起一个单独的进程或线程需要准备新的运行时环境，包括堆和栈内存的分配，以及新的执行上下文，当然，这些也会导致多余的 CPU 开销。最终，会由于过多的上下文切换而导致服务器性能变差。
• Nginx 的架构设计是采用模块化的、基于事件驱动、异步、单线程且非阻塞。
• Nginx 大量使用多路复用和事件通知，Nginx 启动以后，会在系统中以 daemon 的方式在后台运行，其中包括一个 master 进程，n(n>=1) 个 worker 进程。所有的进程都是单线程（即只有一个主线程）的，且进程间通信主要使用共享内存的方式。
  

2.2Nginx 负载均衡

1、Nginx 负载均衡主要是对七层网络通信模型中的第七层应用层上的 http、https 进行支持。
2、Nginx 是以反向代理的方式进行负载均衡的。反向代理（Reverse Proxy）方式是指以代理服务器来接受 Internet 上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 Internet 上请求连接的客户端，此时代理服务器对外就表现为一个服务器。
3、Nginx 实现负载均衡的分配策略有很多，Nginx 的 upstream 目前支持以下几种方式：

• 轮询（默认）：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器 down 掉，能自动剔除。
• weight：指定轮询几率，weight 和访问比率成正比，用于后端服务器性能不均的情况。
• ip_hash：每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决 session 的问题。
• fair（第三方）：按后端服务器的响应时间来分配请求，响应时间短的优先分配。
• url_hash（第三方）：按访问 url 的 hash 结果来分配请求，使每个 url 定向到同一个后端服务器，后端服务器为缓存时比较有效。

3.Haproxy

4.Keepalived

1、keepalived是保证集群高可用的一个服务软件，其功能类似于heartbeat，用来防止单点故障。
2、以VRRP协议为实现基础的，VRRP全称Virtual Router Redundancy Protocol，即虚拟路由冗余协议。
3、keepalived是可以工作在第三层、第四层、第五层的检测服务器状态的软件
4、如果有一台web服务器死机，或工作出现故障，keepalived将检测到，并将其从系统中剔除；当web服务器工作正常后keepalived自动将web服务器加入到服务器集群中

4.1Keepalived的工作原理

1、三层、四层、五层工作在TCP/IP协议栈的IP层、TCP层、应用层。原理如下：

4.2keepalived的作用

高可用-可持续的服务器质量
负载均衡-横向扩展
实现对失效服务器的隔离-通过健康监测，保证服务的可用性
实现：vrrp协议实现。（冗余网关路由协议）

5 Nginx和LVS对比的总结

6 现在对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术

1）第一阶段：利用 Nginx 或 HAProxy 进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是仍 然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用Nginx 或 HAproxy 就是第一选择，此时这些东西上手快， 配置容易，在七层之上利用 HTTP 协议就可以。这时是第一选择。
2）第二阶段：随着网络服务进一步扩大，这时单点的 Nginx （nginx也需要双高可用，或者增加节点，因为niginx的并发只有几万）已经不能满足，这时使用 LVS 或者商用 Array 就是首要选择， Nginx 此时就作为 LVS 或者 Array 的节点来使用，具体 LVS 或 Array 的是选择是根据公司规模和预算来选择，Array 的应用交付功能非常强大，本人在某项目中使用过，性价比也远高于 F5，商用首选！但是一般来说这阶段相关人才跟不上业务的提升，所以购买商业负载均衡已经成为了必经之路。
3）第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，这时无论从开发适合自身产品的定制，以及降低成本来讲开源的 LVS，已经成为首选，这时LVS 会成为主流。最终形成比较理想的基本架构为： Array/LVS — Nginx/Haproxy —Squid/Varnish — AppServer。
软件负载均衡一般通过两种方式来实现：基于操作系统的软负载实现和基于第三方应用的软负载实现。LVS就是基于Linux操作系统实现的一种软负载，HAProxy就是开源的并且基于第三应用实现的软负载。HAProxy相比LVS的使用要简单很多，功能方面也很丰富。当前，HAProxy支持两种主要的代理模式:"tcp"也即4层（大多用于邮件服务器、内部协议通信服务器等），和7层（HTTP）。在4层模式 下，HAProxy仅在客户端和服务器之间转发双向流量。7层模式下，HAProxy会分析协议，并且能通过允许、拒绝、交换、增加、修改或者删除请求 (request)或者回应(response)里指定内容来控制协议，这种操作要基于特定规则。

参考：
1、https://www.cnblogs.com/onesea/p/15069992.html
2、https://www.cnblogs.com/liping0826/p/13524397.html

相关文章：