负载均衡浅析（更新ing）

1.什么是负载均衡

简单地说，就是将请求（或者说流量）按照既定规则分发给多个真实后端服务器的过程。

2.为什么需要负载均衡

2.1 没有负载均衡的应用架构

会有什么问题？

用户通过浏览器直接访问后端服务。当请求量过于庞大，超出了服务器处理请求的极限， 或者服务器因其他原因导致宕机时，都会导致用户的访问速度变慢甚至无法访问。（单点故障）

解决办法：Scale out 水平扩展

Scale up垂直扩展虽然可以增强单机处理能力，但是依旧会出现单点故障导致服务不可用。因此可以通过Scale out水平扩展增加服务器数量来减小因单点故障导致的服务不可用。

2.2 水平扩展

水平扩展后，即使一台服务器宕机，用户请求也会访问到其他正常的服务器上。

会有什么问题？

由哪台服务器处理用户请求呢？总不能每一台都去处理吧？

解决办法：负载均衡

2.3 负载均衡应用架构

添加了负载均衡服务器，就可以将用户的请求按照既定的算法转发到对应的后端server节点上。

好处

1、解决并发压力，提高应用处理性能

2、提供故障转移，实现高可用

3、可扩展性（水平扩展）

4、安全防护。（黑白名单等）

需要注意的是

服务器应设置成无状态的，即不存储请求上下文，这样子每个服务器节点对于用户的请求返回的结果都是相同的。换言之，用户不需要每次都请求到同一服务器，也减小了相同用户对单一服务器的压力。

3.负载均衡的种类

3.1 DNS负载均衡

DNS服务器中会存储域名到ip地址的映射关系。

请求-响应流程

1、用户在浏览器上输入访问域名 www.bilibili.com

2、浏览器向DNS服务器发起请求

3、DNS服务器通过轮询算法，找到www.bilibili.com的服务器ip地址（119.3.77.172）

4、DNS服务器将解析出来的ip返回给浏览器（119.3.77.172）

5、浏览器拿着从DNS服务器那获取到的ip地址，去访问真实服务器

6、服务器处理完请求后，返回响应。

优点

部署简单、成本低、服务器可以位于互联网的任意位置

缺点

1、DNS缓存导致访问到已下线的服务

2、由于采用轮询算法，因此不能合理地根据服务器情况去分配请求

3.2 http重定向负载均衡？

利用http的重定向实现

请求和响应流程

1、用户发起请求www.bilibili.com,会先被http重定向服务器接收

2、重定向服务器计算出个真实的物理服务器ip地址，并返回给用户

3、用户浏览器根据这个ip地址，再去请求一次

4、服务器处理完请求，返回响应

优点

部署简单

缺点

1、用户需要两次请求服务器才能完成一次访问，性能差

2、难以合理利用吞吐率。重定向服务器吞吐率 = 真实服务器吞吐率 * 真实服务器数量。当网站规模达到一定规模时，重定向服务器的处理能力将成为瓶颈。

3.3 IP负载均衡（四层负载均衡）

四层负载均衡又可称为3-4层负载均衡，三层传输层的ip + 四层网络层的端口。

3.3.1 LVS-NAT模式

NAT（Network Address Translation）：网络地址转换。

slb（server load balance）：服务负载均衡

RS（real server）：真实服务器

slb向外暴露ip（10.23.34.45）供外网访问，向内暴露网关ip（192.168.0.100），供后端RS访问

流程

1、用户向www.bilibili.com发起请求，请求首先访问到slb（10.23.34.45）

2、负载均衡器slb收到请求后，根据负载均衡算法修改数据包的源地址和目标地址，而后转发到RS真实服务器上

3、RS处理请求返回响应

4、slb修改响应包源地址和目标地址，返回给用户浏览器

数据包

1、 client--------> SLB

用户的请求数据包中带有slb的对外开放的ip地址10.23.34.45以及端口80

2、 SLB---------> RS1

slb接收到请求后，根据负载均衡算法计算出处理请求的真实服务器节点RS1，并将数据包中的目标ip地址和目标端口修改为RS1的ip端口

3、RS1----------->SLB

RS1接收请求并处理，返回响应时依旧要将数据报层层封装

4、SLB----------->client

SLB接收到响应后，再将源地址ip端口修改为自身的ip端口，这样用户收到请求后，就会认为这是slb返回的数据，对于真实后端服务毫无察觉，也保证了后端服务的安全性。

缺点

客户端的所有请求都要经过SLB，真实服务器的所有响应也要经过SLB，对SLB的处理能力是一个极大地考验。通常我们的浏览器请求request数据报较短，而响应数据报很大，SLB往往需要将数据报分段发送，每一个数据报通需要修改源地址和目标地址，这会对SLB的性能产生巨大影响。 因此：

有什么办法可以让SLB只处理请求，而让RS的响应跳过SLB，直接发送给客户端呢？

3.3.2 LVS-DR模式

对SLB设置一个虚拟ip（VIP） 10.23.34.45。 每个真实服务器都配置一个loopback（路由回环接口，对于送到该接口的请求，服务器会认为就是送到设备本身），指向vip。

流程

1、用户向www.bilibili.com发起请求

2、由于局域网中存在多个 10.23.34.45，用户的请求数据在封装数据帧时无法判断目的地的mac地址，因此会先向局域网广播10.23.34.45。（ARP协议）

3、此时可能会有多个设备响应该广播，因此需要关闭RS的响应，让slb响应广播。

4、slb通过负载均衡算法计算出用于处理请求的RS服务器节点，并将RS的mac地址写入数据帧中，直接转发。

5、RS响应请求，直接返回数据给客户端，不经过slb

数据包

1、client----->SLB

client并不知道slb的mac地址，通过arp协议获取

2、SLB----->RS1

SLB通过负载均衡算法，计算出由rs1处理请求，并将以太网帧的目的地mac地址修改为rs1的mac地址。 由于rs1的loopback绑定了vip，因此ip数据报中的目标ip无需修改。

3、RS1----->SLB

rs1收到请求数据包并拆包，发现以太网帧的mac地址和ip数据报中的ip都是自身，便开始处理请求并返回数据。由于此时的源地址信息全都是浏览器，因此rs1的响应会直接送到浏览器，完全跳过slb。

3.3.3 LVS-Tunnel模式

NAT和DR模式对于负载均衡器和真实服务器的网络要求较为严苛，需要二者处于同一网段。

而Tunnel模式可以跨网段进行负载均衡。

Tunnel与DR类似，区别在于DR是通过修改目标mac地址来转发请求，Tunnel通过额外地封装一层ip报文，并通过隧道的形式将数据包发送给RS。 RS收到数据包后会先将tunnel封装的ip报文去除，然后拆解剩余的数据包，处理数据并响应。

Ip Tunnel模式最大的优点就在于它可以跨网段转发，没有DR和NAT模式的组网限制。这在部署上带来的很大的灵活性，甚至还可以跨机房转发，不过不建议这样使用，一是会带来跨机房间的流量，提高了成本；二是跨机房转发必然会要在RS机房上绑定LVS机房的VIP，这有可能会被运营商的防火墙认为是IP伪造请求而拦截。

3.4 七层负载均衡

7层主要指的是应用层的负载均衡，实际上也涉及了会话层、表示层的信息。负载均衡器会基于request信息进行请求转发。

3.4.1 与四层负载均衡的区别

	4层	7层
转发方式	基于tcp/udp	基于http
osi作用层	2～4层	5～7层
应用场景	作为7层的前置lb，保证7层lb的高可用	根据请求的路径、参数等信息做转发，通常作为真实后端服务器的负载均衡设备。 相比于4层更加智能化
性能	对于请求只做转发，不做处理，性能高	对于请求既做转发，也做处理，性能相比于4层较低
安全性	接收请求直接转发，安全性不高	可获取请求链路上所有信息，可针对性地做防范。如 洪泛攻击

4.负载均衡算法

4.1 轮询法

均匀地、按顺序地将请求分配到真实服务器上

4.2 随机法

随机地选择一台真实服务器。当请求的数量足够多时，随机法结果趋近于轮询法

4.3 源地址哈希法

根据客户端的ip地址，通过哈希函数计算得到一个数值，并取模真实服务器列表大小得到一个序号，这个序号就是实际处理请求的真实服务器序号。

4.4 加权轮询法

给配置较高，负载较低的机器配置较高的权重，让其处理更多的请求。给配置较低，负载较高的机器配置较低的权重，降低其负载。请求会根据权重进行分配。

4.5 加权随机法

与随机法不同的是，权重越大的服务器被随机到的概率就越大。

4.6 最小连接数法

根据当前真实服务器的连接情况，动态地选取当前积压连接数最少的一台服务器来处理请求。

4.7 各类算法优缺点

算法	优点	缺点
轮询法	简单	无法根据服务器当前的状态合理获取节点，可能导致服务器“难上加难”。不适合机器配置不同的场景
随机法	简单	同轮询法
源地址哈希法	能够较为合理地分配请求	服务器数量不变时，同一源地址的请求将会打在同一服务器上。当请求过多时，会对该服务器造成影响。如果服务器宕机，那将丢失会话
加权轮询法	能够根据服务器的负载情况以及性能分配请求	使用较为复杂
加权随机法	同上	同上
最小连接数法	根据服务器当前的请求处理情况，动态分配；	算法实现相对复杂，且需要监听服务器请求连接数

5. SLB

在特大型网站中，应用服务器是可以横向扩容的，而nginx是不支持横向扩容的，此时nginx就会成为性能瓶颈。而lvs是一款负载均衡工具，因而如果我们结合lvs和nginx，那么就可以通过部署多台nginx服务器，通过lvs的负载均衡能力，将请求均衡的分发到各个nginx服务器上，再由nginx服务器分发到各个应用服务器，这样，我们就实现了nginx的横向扩展了。由于nginx本质上也是一款应用服务器，因而其也有可能宕机，因而这里结合keepalived就可以实现nginx的故障检测和服务切换。也就是说，通过keepalived+lvs+nginx，我们实现了nginx的高可用集群模式。

但是对于keepalived的主备模式，只有master节点在处理转发请求，slave节点永远是空闲的，机器的利用率并不高。因此业界改造方案之一：采用ospf协议 + lvs 组成4层lb， nginx集群组成7层lb， 共同构成企业SLB。

ospf（Open Shortest Path First开放式最短路径优先）的好处是可以找到网络中开销最少且相同的路由路径，那么每条请求可以均匀地分散到这些路径并转发到nginx集群上。如此：配置在不同路径上的lvs服务器就可以合理利用起来了，此时每一个lvs都是master节点。