在上一篇文章中，介绍了负载均衡服务，常用的负载均衡服务器以及负载均衡服务在公司的应用情况。这一篇文章会对上篇提到的负载均衡服务器进行较为深入的分析，对其主要功能，优缺点，使用场景进行介绍。希望可以起到抛砖引玉的左右，对大家在了解，使用不同的负载均衡服务有所帮助。
LVS
LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个基于Linux的负载均衡服务器。LVS项目在1998年5月由章文嵩博士成立，现在已经得到了极为广泛的应用，国内外有很多网站和组织都在生产环境中使用LVS系统。
LVS是基于Linux内核模块，通过在协议包工作链上对应位置挂载hook代码，来实现对网络包的解析和重写。其工作原理与iptables相同。在Linux2.4之后，LVS打入Linux标准内核，不需要安装额外的软件即可使用。LVS运行于Linux内核之中，用户要通过运行于用户态的工具（ipvsadm）来对LVS进行配置。下图是Linux 数据包协议栈的工作链和LVS的挂载点：
这几个工作链主要是工作时间不同：
NF_IP_PRE_ROUTING：在报文作路由以前执行
NF_IP_FORWARD：在报文转向另一个NIC以前执行
NF_IP_POST_ROUTING：在报文流出以前执行
NF_IP_LOCAL_IN：在流入本地的报文作路由以后执行
NF_IP_LOCAL_OUT：在本地报文做流出路由前执行
对于数据包，LVS的工作流程是:PREROUTING -> LOCAL_IN -> POSTROUTING
对于出去的包（只有NAT有效）：PREROUTING -> FORWARD -> POSTROUTING
对于Ping包：PREROUTING -> FORWARD -> POSTROUTING
主要特点：
与应用层的负载均衡不同，LVS运行在内核模式，没有系统调用开销。而只支持四层负载均衡模式，LVS也不用处理复杂的七层协议，因此有着很高的性能。当单臂模式的设计又可以让LVS承载大量流量（与后端对比一般可以达到1：10左右），因此LVS常常被用作整个系统的流量入口。 由于LVS的资源占用很少，在日常的应用中，其瓶颈常在于网络带宽而不是CPU和内存，因此运行在物理机上的LVS一般都会配置万兆或以上的网卡。阿里云的LVS集群就采用了单台LVS配置四个万兆网卡的形式来提高资源利用率和处理能力。
功能介绍：
LVS是一个纯粹的负载均衡服务器，只支持四层负载均衡，支持三种模式，NAT，TUN和DR模式。
NAT模式：工作在TCP层，这时LVS的功能与其他四层负载均衡服务器类似，是通过NAT协议来修改数据包中的Source IP或者Dest IP地址，来实现负载均衡。在NAT模式下，上下行的流量都需要经过LVS，因此LVS的带宽可能成为瓶颈。
TUN模式：工作在IP层：是通过在IP包的基础上再进行一次独立的IP封装，加入额外的IP头，来实现包转发功能，因此TUN协议又叫做IPIP协议。TUN模式是单臂流量，只有上行数据会经过LVS，下行数据则直接通过后端服务器发给用户。为了实现TU模式，后端服务器上需要支持IPIP协议，并绑定一个TUN设备和对应的VIP地址。
DR模式：DR模式工作在二层，是通过直接修改mac帧中的目标mac地址，来实现数据转发功能。因为DR模式走的是mac层的协议，因此需要负载均衡服务和后端服务器在同一个二层（同一个广播域）之中。
总结：使用方面，NAT模式使用最为灵活，对后端无侵入性，但性能也最差。DR模式性能最好，但对网络拓扑结构有要求。而TUN模式可以达到和DR模式相近的性能，但是需要后端对IPIP协议的支持。
优缺点分析
优点：LVS运行简单，性能非常强大(运行在DR或者TUN模式下的一台LVS可以支持后端上百台服务器的需要），而且服务十分稳定（代码很少有改动）。同时，由于直接集成在Linux内核中，使用简单，不需要额外安装。
缺点：模式不够灵活，可配置项少，只支持三种固定模式，很难满足一些自定义的需求。而LVS服务本身也十分简单，没有其他负载均衡服务所带的健康检查等功能，需要其他工具（keepalived，OSPF等）支持。社区不够活跃，代码更新和活跃度不高。
应用场景：
LVS一般是用在网络入口的位置，使用一组高可用的LVS集群后面会再接Haproxy，Nginx，Apache等七层负载均衡服务。对于一些四层的应用，也会在前面直接架设一套LVS，使用LVS的NAT模式进行请求转发和负载均衡。
Nginx/Tengine/Open Resty
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，并在一个BSD-like 协议下发行。Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的，第一个公开版本0.1.0发布于2004年10月4日。其将源代码以类BSD许可证的形式发布，因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。
Nginx起源也是web服务器，但是与Apache不同，Nginx采用的是异步模式，epoll模型来实现，与Apache相比，Nginx在性能，资源消耗方面都有很大的提高。Nginx也是为了解决C 10K问题而开发的服务器之一。
主要功能：
作为一个web服务器，可以提供HTTP资源的访问，还可以与php结合，提供动态页面支持。而作为负载均衡服务器，Nginx除了HTTP/HTTPS协议之外，Nginx还支持IMAP/POP3协议，可以作为邮件的代理服务器使用。除了基本的负载均衡功能外，Nginx还支持URL重写，基于Cookie，URL的转发等功能。
Nginx还有良好的扩展性，支持通过lua脚本进行功能扩展，可以根据自己的需要，开发具体的业务逻辑。 Nginx基于多进程模型，首先启动一个master进程，然后fork出多个worker进程（可配置），worker进程通过抢占的方式来处理请求，具体运行架构如下图所示：
Master进程只负责接受连接，不会执行具体的业务逻辑。Worker进程通过抢占的方式从master那里得到请求，处理具体的业务逻辑，包括请求解析，提供http服务，请求转发等。 当重新reload时，Master会根据配置重新启动一组新的worker进程，同时把请求全部转发给新的worker。老的worker不再处理请求，当当前请求处理完毕之后才会退出。因此Nginx可以在运行时无缝加载和reload。
优缺点分析
优点：Nginx基于epoll的异步模型，资源占用很少，在实际测试中，在处理4000并发连接时，内存资源占用也仅仅只有123.63MB。而Nginx对于运维操作也非常友好，支持运行时reload，并且不会丢失用户请求。Nginx的多进程模型可以方便的使用多核资源，同时支持CPU绑定，可以把具体的Nginx worker进程绑定在具体的物理CPU之上。
缺点：Nginx在处理大的post请求时，会将请求先缓存在本地磁盘，当请求很大且并发请求很多时，磁盘性能会成为瓶颈，而且出现过由于硬盘写满导致请求失败的情况。同时，Nginx也不支持会话保持和主动监测，健康检查结果展示也不大优好。
衍生版本
Nginx社区十分活跃，并且在应用中有基于Ningx开发的很多衍生版本，这里就介绍两个版本：Tengine和OpenResty。
Tengine：是阿里基于Nginx开发的衍生版本，补齐了Nginx的短板（Post缓存，主动健康检查，监控页面等），并在此基础上进行了二次开发，对性能和易用性（加入了很多自动配置的选项）进行了优化。
优点：已经在阿里内部得到了广泛的应用，有大量的实践基础和调优经验。性能，稳定性方面有保障。
缺点：直接更改Nginx内核，因此需要通过人工兼容的方式来跟随Nginx主版本升级。
OpenResty:基于Nginx开发的另一个衍生版本，直接加入了很多优质的Nginx模块，从而大大扩展了Nginx本身的功能。与Tengine不同，它没有直接更改Nginx内核，而是通过加入模块的方式来提供功能扩展。
应用场景
Nginx可以直接运行在系统最前面，通过Keepalived实现高可用，作为系统流量的入口使用。也可以对接LVS，Haproxy等四层负载均衡，对流量进行二次分流。
Haproxy：
Haproxy是一个专门的负载均衡服务器，支持四层/七层负载均衡。与Nginx，apache等不同，Haproxy不提供静态资源访问，URL重写等web服务器相关功能。
功能介绍
Haproxy也是基于事件机制的异步模型，但与nginx不同，Haproxy是基于单进程模型，没有提供天然的多进程扩展。虽然可以通过fork进程来实现多进程模型，但是会引起一些问题，因此官方并不推荐这种做法。在实际应用中一般都是把它作为一个单进程负载均衡服务使用。
优缺点分析
优点：可以同时支持四层，七层负载均衡，有很高的性能。支持Seesion Sticky，有良好的监控页面，同时不存在Post缓存问题。
缺点：由于Haproxy是基于但进程模型，在reload时会导致短暂的不可用，同时不支持https。在作为四层四层负载均衡服务器时无法获取原始IP。单进程模型，对多核支持不好（需要多个实例），虽然可以运作在多核模式下，但存在着一些问题。
应用场景：
作为四层负载均衡服务，可以直接接后端服务使用，但由于是采用双臂模式和单进程模型，并不适合作为单独的流量入口。在不需要获取源IP或者对性能要求不是很高的情况下作为四层负载均衡服务器使用。或者作为七层负载均衡服务器，专门处理七层的上传请求。
Apache
Apache 起初由伊利诺伊大学香槟分校的国家超级电脑应用中心（NCSA）开发，是现在互联网中使用最热门和访问量最大的HTTP服务器，同时还可以通过加载模块来完成反向代理功能，但严格来说Apache并不是一个很好的负载均衡服务器，在性能，功能上与较为专业的负载均衡服务相比并无优势，而功能也乏善可陈。但是考虑到Apache的广泛应用以及基于Apache的负载均衡服务在实际的生产环境中还是有不少应用。
功能介绍：
Apache是一个web服务器，通过可以通过加载模块来实现负载均衡服务。作为一个强大的web服务器，Apache在解析HTTP协议有天然的优势，支持基于域名分流，URL分析，URL重写，转发等功能。
Apache支持两种模式的负载均衡：基于mod_proxy模块的一般负载均衡和基于mod_proxy_ajp模块的二进制负载均衡。这两种模式的主要区别在于Apache和后端服务之间的连接方式。一般的负载均衡是采用HTTP协议，使用文本传输，而ajp模式则采用二进制模式，因此性能上会更好。但相对的，AJP模式需要后端服务器的支持，在一般应用时，会通过跟tomcat结合来提供负载均衡服务。
优缺点分析
优点：Apache是应用最广的web服务器，因此在服务应用上面有着天然的优势。而Apache+Tomcat的模式可以满足现在大部分网站对于静态资源和动态资源的需求。而作为一个强大的web服务器，Apache还支持URL重写，URL转发等web服务相关的操作，可以对后端服务提供更多支持。
缺点：作为负载均衡服务器，主要问题是采用的多进程模式，每个连接在处理时都会开独立的线程，当连接请求数据很多时，会有在处理高并发时会有性能隐患。
应用场景：
因为无论从性能还是功能上看，都有更好的选择，因此Apache一般不会单独作为负载均衡服务器使用。一般是采用Apache服务作为静态文件服务器使用的时候，使用AJP模块与后端的Tomcat对接，提供简单的负载均衡支持。
总结
本文对常用的四种负载均衡服务进行了简单的介绍，在之后的文章中，会对具体的负载均衡服务进行更为深入的分析和说明。