玩转企业集群运维管理系列（二）：主流软件负载均衡器(LVS、Nginx、HAproxy)对比
玩转企业集群运维管理系列（二）：主流软件负载均衡器(LVS、Nginx、HAproxy)对比
前面介绍了负载均衡入门等相关的知识点，今天我将详细的为大家介绍主流软件负载均衡相关知识，希望大家能够从中收获多多！如有帮助，请点在看、转发朋友圈支持一波！！！
负载均衡的实现方式一般来说有以下三种：
- 基于DNS负载均衡：直接通过DNS来实现负载均衡。优点是非常简单，缺点是调整后不知道啥时生效(当然正常情况下几十分钟，长的也可能更长)
- 基于硬件负载均衡：购买硬件，也就是我们常常说的F5（F5 Network Big-IP），不过F5就贵一般来说单台硬件也得几十万块，要是搞个双机，多机就更贵了
- 基于软件负载均衡：基于软件的方式也非常多，类似几个主流LVS、Nginx、HAproxy(当然IBM也有个HIS)。
接下来就针对以下几种具体说明：三大主流软件负载均衡器对比(LVS、Nginx、HAproxy)。更多关于企业集群运维管理系列的学习文章，请参阅：玩转企业集群运维管理专栏，本系列持续更新中。
LVS
LVS 的体系结构
LVS 架设的服务器集群系统有三个部分组成：
- (1) 最前端的负载均衡层，用 Load Balancer 表示
- (2) 中间的服务器集群层，用 Server Array 表示
- (3) 最底端的数据共享存储层，用 Shared Storage 表示
1.抗冲击能力强，能力最高可达F5（一种硬件的负载均衡器，功能强大，性能稳定，拥有很多软件负载无法做到的能力）设备性能的60%。
2.工作在网络层。采用VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）进行转发（仅仅用于分发）。
3.良好的可靠性和稳定性，拥有优秀的热备方案。
4.具有广泛的应用范围，可以对所有的应用程序进行负载均衡。
5.不支持动静分离。
6.支持的均衡算法有：RR（round robin），WRR（weighted round robin），LC（minimum connection），WLC（minimum weight connection）等。
7.结构复杂，非常依赖于网络情况。
Nginx
Nginx 的架构设计是采用模块化的、基于事件驱动、异步、单线程且非阻塞。
1.工作在应用层，你可以为HTTP应用程序设置一些转移策略，如依据域名和目录结构。
2.Nginx轻度依赖于网络。理论上来说，只要ping的通，就能执行负载均衡。
3.相对于LVS，Nginx的配置相对简单且易于测试。
4.Nginx同样可以承受较大的负载压力并保持稳定性。通常Nginx可以同时承载1w条操作。
5.后端服务器的健康检查只支持端口，不支持URL。
6.Nginx可以通过对请求的异步处理来减少服务器节点的负载。
7.Nginx只支持HTTP，HTTPS以及Email协议，所以应用范围较窄。
8.不支持会话保持，但是可以通过IP哈希来间接解决，对于较大的请求头不太友好。
9.支持的负载均衡算法：RR，WRR和IP-Hash。
10.Nginx在某些应用场景下也可以充当web服务器，例如缓存。
更多关于企业集群运维管理系列的学习文章，请参阅：玩转企业集群运维管理专栏，本系列持续更新中。
Haproxy
1.支持两种协议模式：网络层的TCP和应用层的HTTP，支持虚拟主机。
2.可以弥补Nginx的一些短板，例如会话保持等。
3.支持URL检测和后端服务器问题检测。
4.支持更多的负载均衡算法，例如：DRR（dynamic round robin），WSH（weighted source hash），weighted URL hash 和weighted parameter hash。
5.同等效率下，Haproxy比Nginx负载均衡速度更快。
6.Haproxy可以对mysql实行负载均衡，对后端的数据库节点进行检测和负载均衡。
7.不能充当web服务器。
比较负载均衡器的几个关键因素
- 1.单位时间内的请求处理数。
- 2.会话并发能力。
- 3.数据处理能力。
业务场景
三大主流软件负载均衡器适用的生产场景：
1.网站建设初期，可以选用Nginx、HAproxy作为反向代理负载均衡（流量不大时可以选择不用负载均衡）因为其配置简单，性能也能满足一般业务场景。如果考虑到负载均衡器是有单点失败问题，可以采用Nginx+Keepalived避免负载均衡器自身单点问题。
2.网站并发达到一定程度后，为了提高稳定性和转发效率，可以使用LVS，毕竟LVS比Nginx/HAproxy要更稳定，转发效率也高。但是如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有Windows Server的机器的话，实施及配置还有维护过程会比较痛苦。
3.HAProxy对于后端服务器一直在做健康检测（就算请求没过来的时候也会做健康检查），后端机器故障发生在请求还没到来的时候，haproxy会将这台故障机切掉，但如果后端机器故障发生在请求到达期间，那么前端访问会有异常。也就是说HAProxy会把请求转到后端的这台故障机上，并经过多次探测后才会把这台机器切掉，并把请求发给其他正常的后端机，这势必会造成一小段时间内前端访问失败。 Nginx对于后端的服务器没有一直在做健康检测：后端机器发生故障，在请求过来的时候，分发还是会正常进行分发，只是请求不到数据的时候，它会再转向好的后端机器进行请求，直到请求正常为止。也就是说Nginx请求转到后端一台不成功的机器的话，还会再转向另外一台服务器，这对前端访问没有什么影响。
因此，如果用HAProxy做为前端负载均衡的话 ，如果后端服务器要维护，在高并发的情况，肯定是会影响用户的。但如果是Nginx做为前端负载均衡的话，只要并发撑得住，后端切掉几台不会影响到用户。
4.对于Http协议，Haproxy处理效率比Nginx高。所以，没有特殊要求的时候或者一般场景，建议使用Haproxy来做Http协议负载！但如果是Web，那么建议使用Nginx。
5.nginx故意缺少所有监视功能。它不显示负载平衡的应用程序。它不显示哪些服务器在线，但它们可以付费提供。如果您需要一个合适的监控页面和用于集成的JSON API，则必须支付“ Nginx Plus”版本的费用。价格从每台服务器每年1900美元起。 而在HAproxy里，我们可以看到哪些服务器上升或下降，使用了多少带宽，连接了多少客户端等等 。
6.Linux上Haproxy理论上最大连接数
最大连接数 = maxconn( global | defaults | listen )
#Linux上Nginx理论上最大连接数
正向代理：最大连接数 = work_processes * worker_connections
反向代理：最大连接数 = work_processes * worker_connections / 4
现在网站发展的趋势对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。更多关于企业集群运维管理系列的学习文章，请参阅：玩转企业集群运维管理专栏，本系列持续更新中。
第一阶段：利用Nginx或者HAProxy进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是仍然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用Nginx或者HAproxy就是第一选择，此时这些东西上手快，配置容易，在七层之上利用HTTP协议就可以。这时是第一选择。
第二阶段：随着网络服务进一步扩大，这时单点的Nginx已经不能满足，这时使用LVS或者商用F5就是首要选择，Nginx此时就作为LVS或者 F5的节点来使用，具体LVS或者F5的是选择是根据公司规模，人才以及资金能力来选择的，这里也不做详谈，但是一般来说这阶段相关人才跟不上业务的提升，所以购买商业负载均衡已经成为了必经之路。
第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，这时无论从开发适合自身产品的定制，以及降低成本来讲开源的LVS，已经成为首选，这时LVS会成为主流。
最终形成比较理想的状态为：F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。更多关于企业集群运维管理系列的学习文章，请参阅：玩转企业集群运维管理专栏，本系列持续更新中。
推荐阅读 点击标题可跳转
PS：因为公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“在看”，加个“星标”，这样每次新文章推送才会第一时间出现在你的订阅列表里。点“在看”支持我们吧!