Linux的负载均衡详解

Linux的负载均衡常用的有三种技术：中国人搞出来的大神级产品 LVS Linux Virtual Server，俄罗斯的Nginx，来发法国的HAProxy。都是基于Linux的开源免费的负载均衡软件。

1. 抗负载能力强，性能高，能达到F5的60%，对内存和CPU资源消耗比较低

2. 工作在网络4层，通过VRRP协议(仅作代理之用)，具体的流量是由linux内核来处理，因此没有流量的产生。

3. 稳定，可靠性高，自身有完美的热备方案(Keepalived+lvs)

4. 不支持正则处理，不能做动静分离。

5. 支持多种负载均衡算法：rr(轮询)，wrr(带权轮询)、lc(最小连接)、wlc(带权最小连接)

6. 配置相对复杂，对网络依赖比较大，稳定性很高。

7. LVS工作模式有4种：

    (1) nat 地址转换

    (2) dr 直接路由

    (3) tun 隧道

    (4) full-nat

1. 工作在网络7层，可以针对http应用做一些分流的策略，比如针对域名，目录结构

2. Nginx对网络的依赖较小，理论上能ping通就能进行负载功能

3. Nginx安装配置比较简单，测试起来很方便

4. 也可以承担较高的负载压力且稳定，nginx是为解决c10k问题而诞生的

5. 对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测

6. Nginx对请求的异步处理可以帮助节点服务器减轻负载压力

7. Nginx仅能支持http、https和Email协议，这样就在适用范围较小。

8. 不支持Session的直接保持，但能通过ip_hash来解决。对Big request header的支持不是很好。

9. Nginx还能做Web服务器即Cache功能。

1.支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；

2.能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作

3.支持url检测后端的服务器出问题的检测会有很好的帮助。

4.更多的负载均衡策略比如：动态加权轮循(DynamicRoundRobin)，加权源地址哈希(Weighted SourceHash)，加权URL哈希和加权参数哈希(WeightedParameterHash)已经实现

5.单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。

6.HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。

7.支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）

8.不能做Web服务器即Cache。

1. 负载能力

lvs抗负载能力最强，因为仅作分发不处理请求，相当于只作转发不做进一步处理直接在内核中完成，对系统资源消耗低（LVS DR模式）；

nginx和haproxy相对来说会弱，但是日PV2000万也没什么问题，因为不仅接受客户端请求，还与后端upstream节点进行请求并获取响应，再把响应返回给客户端，对系统资源和网络资源消耗高；

注：建议如果公司网站流量日PV在2000万以上，并发在7，8万以上才考虑用lvs+keepalived架构

2. 功能性

lvs仅支持4层tcp负载均衡，haproxy可以支持4层tcp和7层http负载均衡，nginx可以支持7层http负载均衡（新版本也支持7层负载均衡）；

nginx功能强大，配置灵活，可做web静态站点，静态缓存加速，动静分离，并支持域名，正则表达式，Location匹配，rewrite跳转，配置简单直观明了，还可以结合etc或consule做发布自动化上下线等等；

haproxy相对nginx的7层负载均衡会弱一些，灵活性不足，个人建议一般用haproxy做TCP负载均衡更合适一些；

3. 运维复杂度

lvs相对来说部署架构更复杂一些，lvs对网络是有要求，lvs必须与real server在同一个网段，也更费资源，需要多2台服务器成本；

nginx和haproxy部署架构更简单，对网络也没要求，更便于后续维护；

像对于大型的，需要进行高并发的网站或者对网络不太严格的时候，可以使用nginx；

对于大型的Web服务器的时候可以使用haproxy；

对性能有严格要求的时候可以使用lvs，就单纯从负载均衡的角度来说，lvs也许会成为主流，更适合现在大型的互联网公司。

注：lvs,nginx,haproxy要实现高可用，都需要借助keepalived软件

TCP/IP 的分层管理

TCP/IP 协议按照层次分为 4 层：应用层、传输层、网络层、数据链路层。 对于分层这个概念，大家一定不陌生，比如我们的分布式架构体系中会分为业务层、服务层、基础支撑层。比如docker，也是基于分层来实现。所以我们会发现，复杂的程序都需要分层，这个是软件设计的要求，每一层专注于当前领域的事情。如果某些地方需要修改，我们只需要把变动的层替换掉就行，一方面改动影响较少，另一方面整个架构的灵活性也更高。 最后，在分层之后，整个架构的设计也变得相对简单了。

分层负载

了解了分层的概念以后，我们再去理解所谓的二层负载、三层负载、四层负载、七层负载就容易多了。

一次 http 请求过来，一定会从应用层到传输层，完成整个交互。只要是在网络上跑的数据包，都是完整的。可以有下层没上层，绝对不可能有上层没下层。

二层负载

二层负载是针对 MAC，负载均衡服务器对外依然提供一个 VIP（虚 IP），集群中不同的机器采用相同 IP 地址，但是机器的 MAC 地址不一样。当负载均衡服务器接受到请求之后，通过改写报文的目标 MAC 地址的方式将请求转发到目标机器实现负载均衡

二层负载均衡会通过一个虚拟 MAC 地址接收请求，然后再分配到真实的 MAC 地址

三层负载均衡

三层负载是针对 IP，和二层负载均衡类似，负载均衡服务器对外依然提供一个 VIP（虚 IP），但是集群中不同的机器采用不同的 IP 地址。当负载均衡服务器接受到请求之后，根据不同的负载均衡算法，通过 IP 将请求转发至不同的真实服务器

三层负载均衡会通过一个虚拟 IP 地址接收请求，然后再分配到真实的 IP 地址

四层负载均衡

四层负载均衡工作在 OSI 模型的传输层，由于在传输层，只有 TCP/UDP 协议，这两种协议中除了包含源 IP、目标 IP 以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。

四层通过虚拟 IP + 端口接收请求，然后再分配到真实的服务器

七层负载均衡

七层负载均衡工作在 OSI 模型的应用层，应用层协议较多，常用 http、radius、dns 等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个Web 服务器的负载均衡，除了根据 IP 加端口进行负载外，还可根据七层的 URL、浏览器类别来决定是否要进行负载均衡

比如：在nginx层做7层均衡，让一个uid的请求尽量落到同一个机器上

---