负载均衡技术(二）———经常使用负载均衡服务介绍

在上一篇文章中，介绍了负载均衡服务，经常使用的负载均衡服务器以及负载均衡服务在公司的应用状况。这一篇文章会对上篇提到的负载均衡服务器进行较为深刻的分析，对其主要功能，优缺点，使用场景进行介绍。但愿能够起到抛砖引玉的左右，对你们在了解，使用不一样的负载均衡服务有所帮助。

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对接，提供简单的负载均衡支持。

总结

本文对经常使用的四种负载均衡服务进行了简单的介绍，在以后的文章中，会对具体的负载均衡服务进行更为深刻的分析和说明。

若是你也对Java高并发、分布式、微服务、源码分析技术感兴趣能够加个人Java后端架构群，群里有免费的资料，也有一些一线互联网的大牛，欢迎你们来学习交流，群号：836036968