前言：笔者在写本文之前，请教了多位技术专家，如Redhat的张家驹、陈立峰、陈镇、张亚光等，也参考了网络上的一些文章（文章最后会列出参考文献）。本文书写的目的基于对软负载方案的探讨，并不对各个厂商负载均衡做竞争性分析。本文仅代表个人观点。
软负载方案介绍
谈到负载均衡，目前业内全球最出名的应该是F5，国内深信服在这方面知名度也很高。硬件厂商的负载均衡方案有其优势，这点毋庸置疑。那么，负载相对较低的环境下，是否有基于开源的软负载方案呢？
目前业内常见的几种软负载方案有：
1.LVS （Linux Virtual Server）。红帽RHEL6及以前版本的操作系统的软负载方案就是LVS，有单独的订阅服务。
2. HAproxy。红帽RHEL7软负载方案是HAProxy，并且有单独的订阅服务。红帽PaaS解决方案中，也是用HAproxy做容器的router。
3.Nginx。最近一两年非常火的软负载解决方案。红帽对于运行在RHEL上，并且有RHEL订阅的客户，提供如下版本Nginx的一定的技术支持：nginx18、nginx 1.10。
相面，我们对三种软负载进行对比：
| 方案名称 | 使用层面 | 优势 | 劣势 |
| LVS | 四层 | 抗负载能力强、工作稳定、无流量、应用范围比较广 | 不支持正则表达式处理，不能做动静分离 |
| Haproxy | 四层到七层 | 支持http类应用和HAProxy和TCP协议、负载均衡策略丰富、负载均衡性能高、速度快。 | 反向代理能力若于Nginx |
| Nginx | 七层 | 对网络稳定性的依赖非常、中层反向代理能力强 | 仅能支持http、https和Email协议、对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测、不支持Session的直接保持 |
软负载支持的路由方式
1.NAT方式
2.Direct Routing方式
从访问方式看，在NAT方式下，客户端请求入口和出口相同，都会经过软负载。而在Director Route方式下，客户端请求入口和出口不同，因此软负载的压力会小很多。
目前LVS和HAproxy都支持NAT和DR这两种方式。
软负载VIP的切换速度
LVS和HAproxy主从节点之间的维护，是由keepalived实现的。keepalived会同时运行自主从软负载上。它做两件事：
To balance the load across the real servers.
To check the integrity of the services on each real server。
而主从负载之间的健康状态通讯，是通过VRRP（Virtual Router Redundancy Protocol）协议实现的。所以说，当主软负载出现问题后，VIP会切换到备的软负载。而切换的速度，很大程度上取决于VRRP的最小检测时间。
VRRP V3将V2版本中检测时间最短1秒一次，提升到最短10毫秒1次。这将大幅提升当LVS单节出现问题时，VIP的切换速度。如下为VRRP源码：
VRRP3支持新版本Keepalived 1.3.5，将在红帽RHEL7.4中一起发布。 (RHEL7.4计划8月1日发布) 。
所以说，目前RHEL7.3中的LVS或者HAproxy，基于keepalived的主备切换，一定是秒级，因为VRRP2最小的检测时间间隔是1秒。但当RHEL7使用VRRP3以后，相信这个速度会得到大幅提升。
性能极限
HAproxy性能参考：http://www.haproxy.org/10g.html
单个haproxy节点跑满10Gbps吞吐，单个haproxy单位时间响应最大请求数为20000个，可以维护40000个并发连接。
关于LVS的最大性能。此前我们内部做的一些测试，单个LVS节点可以维护超过10万的并发连接。
而一位淘宝的大牛，通过优化，可以将LVS达到如下性能：
方案建议
首先我们先看一个技术专家的建议：
http://www.jianshu.com/p/184243e36318
现在网站发展的趋势对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术：
第一阶段：利用Nginx或者HAProxy进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是仍然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用Nginx或者HAproxy就是第一选择，此时这些东西上手快， 配置容易，在七层之上利用HTTP协议就可以，这时是第一选择。
第二阶段：随着网络服务进一步扩大，这时单点的Nginx已经不能满足，这时使用LVS或者商用F5就是首要选择，Nginx此时就作为LVS或者 F5的节点来使用，具体LVS或者F5的是选择是根据公司规模，人才以及资金能力来选择的，这里也不做详谈，但是一般来说这阶段相关人才跟不上业务的提 升，所以购买商业负载均衡已经成为了必经之路。
第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，这时无论从开发适合自身产品的定制，以及降低成本来讲开源的LVS，已经成为首选，这时LVS会成为主流。
最终形成比较理想的状态为：F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。
以上的观点我基本赞同。
笔者的建议是，对于金融行业对软负载有一定性能要求的场景，可以使用LVS+HAproxy两层架构来实现软负载。这样做到了将LVS和HAproxy做到优势互补，架构又比较简洁。
在技术支持方面，可以通过购买红帽RHEL订阅加一定量的人天服务，作为技术保障，为客户托底。
