一文带你了解SLB、F5、Nginx负载均衡

负载均衡（Load Balance），其含义就是指将负载（工作任务）进行平衡、分发到多个操作单元上进行运行，负载均衡构建在原有网络结构之上，它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。 市面上常见的负载均衡有以下三种： 1.基于DNS负载均衡 2.基于软件负载均衡 3.基于硬件负载均衡 三种方案各有优劣，DNS负载均衡可以实现在地域上的流量均衡，硬件负载均衡主要用于大型服务器集群中的负载需求，而软件负载均衡大多是基于机器层面的流量均衡。具体优劣在此不多加赘述。

负载均衡（Server Load Balancer，简称SLB）是一种网络负载均衡服务，针对阿里云弹性计算平台而设计，可以对多台云服务器进行流量分发，在系统架构、系统安全及性能，扩展，兼容性设计上都充分考虑了弹性计算平台云服务器使用特点和特定的业务场景。

1.高可用：采用全冗余设计，无单电，可用性高达99.99%，根据应用负载进行弹性扩容，在流量波动的情况下不中断对外服务。 2.低成本：相对于传统硬件负载均衡的高投入，可以节省极大的成本，无需一次性采购昂贵的负载均衡设备。 3.安全性：结合云盾提供的防DDoS攻击能力，包含：CC、SYN、flood等DDoS攻击方式。 4.收费模式：按出口流量计费 5.高并发：集群支持亿级并发连接，单实例提供千万级并发能力

1.可以通过流量分发扩展应用系统对外的服务能力，消除单点故障提升应用系统的可用性，当求中一部分ECS宕机后，应用系统仍可以正常工作。 2.slb通过设置虚拟服务地址（IP），将位于同一地域（Region）的多台云服务器（ECS）资源虚拟成一个高性能，高可用的应用服务池。之后将客户端的网络请求分发到云服务器池中，根据规则转发到具体的ECS里。 3.slb服务会检查云服务器池中ECS的健康状态，自动隔离异常状态的ECS，从而解决了单台ECS的单点问题，提高了应用的整体服务能力。 4.在标准的负载均衡功能之外，slb服务还具备TCP和HTTP抗DDoS攻击的特性，增强应用服务器的防护能力。

LoadBalancer代表一个SLB实例 Listener代表用户定制的负载均衡策略和转发规则 BackendServer是后端的一组ECS。 来自外部的访问请求，通过SLB实例并根据相关的策略和转发规则分发到后端ECS进行处理。

阿里云当前提供四层和七层的负载均衡服务。 四层采用开源软件LVS（Linux Virtual Server）+ keepalived的方式实现负载均衡，并根据云计算需求对其进行了个性化定制。 七层采用Tengine实现负载均衡。Tengine是由淘宝网发起的Web服务器项目，它在Nginx的基础上，针对有大访问量的网站需求，添加了很多高级功能和特性。

1.当前提供4层（TCP协议）和7层（HTTP和HTTPS协议）的负载均衡服务。 2.可以对后端ECS进行健康检查，自动屏蔽异常状态的ECS，待该ECS恢复正常后自动解除屏蔽。 3.提供会话保持功能，在Session的生命周期内，可以将同一客户端请求转发到同一台后端ECS上。 4.支持加权轮询（WRR），加权最小连接数（WLC）转发方式。WRR的方式将外部请求依序分发到后端ECS上，WLC的方式将外部请求5.分发到当前连接数最小的后端ECS上，后端ECS权重越高被分发的几率也越大。 6.支持针对监听来分配其对应服务所能达到的带宽峰值。 7.可以支持公网或私网类型的负载均衡服务。 8.提供丰富的监控数据，实时了解SLB运行状态。 9.结合云盾，提供WAF及防DDOS攻击能力，包括CC,SYN FLOOD等。 10.支持同一地域（REGION）跨数据中心容灾，结合DNS还可以支持跨REGION容灾。 11.针对HTTPS协议，提供统一的证书管理服务，证书无需上传后端ECS，解密处理在SLB上进行，降低后端ECS CPU开销。 12.提供控制台，API，SDK多种管理方式。

开通slb之前考虑的问题 ： 1服务放在上面区域 2.多少台后端服务器 3.服务采用什么协议进行slb转发 4.负载均衡内网或者公网 考虑好以上问题之后，可以参考阿里云SLB使用手册使用。 阿里云手册地址

F5 Network Big-IP，也就是我们常说的 F5，它是一个网络设备，可以简单的理解成类似于网络交换机的东西，性能是非常的好，每秒能处理的请求数达到百万级，当然价格也就非常非常贵了，十几万到上百万人民币都有。 F5详细介绍请看百度百科F5方案，这里只介绍相关流程和一些认知：

F5会以一定的频率去探测一组服务器资源可用的port，之后提供一个统一的虚拟IP，应用请求到这个虚拟的IP后，F5会请求转发到服务器资源中能够处理请求的服务器里，之后把response响应给请求方。

1.应用发出服务请求到F5暴露的虚拟Ip 2.BIGIP接收到请求，将请求数据包中目的IP地址改为可用的后台服务器IP地址，然后将数据包发出到后台选定的服务器 3.后台服务器收到后，将response包按照其路由发回到BIGIP 4.BIGIP收到response包后将其中的源地址改回成虚拟IP地址，发回客户端，由此就完成了一个标准的服务器负载平衡的流程。

1、F5 BIG-IP是一台对流量和内容进行管理分配的设备，它提供12种灵活的算法将所有流量均衡的分配到各个服务器，而面对用户，只是一台虚拟服务器。 　　2、F5 BIG-IP可以确认应用程序能否对请求返回对应的数据。假如F5 BIG-IP后面的某一台服务器发生服务停止、死机等故障，F5会检查出来并将该服务器标识为宕机，从而不将用户的访问请求传送到该台发生故障的服务器上。这样，只要其它的服务器正常，用户的访问就不会受到影响。宕机一旦修复，F5 BIG-IP就会自动查证应用已能对客户请求作出正确响应并恢复向该服务器传送。 　　3、F5 BIG-IP通过OneConnection连接优化技术，卸载服务器端的处理压力，提升服务器处理性能。 　　4、F5 BIG-IP通过流量整形和Qos机制区分和保证重要应用的带宽和服务等级。

通过上述的图解大家就可以看到，多个客户端给服务器发送的请求，Nginx服务器接收到之后，按照一定的规则分发给了后端的应用服务器进行处理。此时请求的来源也就是客户端是明确的，但是请求具体由哪台服务器处理的并不明确了，Nginx扮演的就是一个反向代理角色。反向代理时也可以通过多种算法来实现代理的负载均衡。

静态负载均衡算法：主要包括轮询算法、基于比率的加权轮询算法或者基于优先级的加权轮询算法。 　　动态负载均衡算法：主要包括基于任务量的最少连接优化算法、基于性能的最快响应优先算法、预测算法及动态性能分配算法等。 　　静态负载均衡算法在一般网络环境下也能表现的比较好，动态负载均衡算法更加适用于复杂的网络环境。 　常用算法如下：

他会根据你upstream中配的server地址，依次请求到对应的服务器中，第一次请求到8080，第二次请求到8081，第三次请求到8080，以此类推。

假如说，上述其中一台tomcat配置更高，扛得住更强的并发，而另一台相对配置较低，那我们就可以采用加权的方式，让请求更多的打到配置更高的tomcat服务器上，配置如下：

其实对比上面不加权的轮询方式，这里在 upstream 指令中多了一个 weight 指令。该指令用于配置前面请求处理的权重，默认值为 1，weight可以控制请求到具体某一台服务器上的次数。

我们设想一个问题，用户在浏览一个网页时需要请求到不同的资源，每个资源前可能都会有拦截器用来让用户去登录，这时用户在访问其中一个资源时已经登陆了，这个session存储到了当前服务器里，但是用户请求其他资源，负载均衡给代理到其他服务器了，用户的session就获取不到了，用户还需要重新登录，十分影响用户体验，这种情况我们常用两种解决方案： ①第一种方法是选择一个中间件，将登录信息保存在一个中间件上，这个中间件可以为 Redis 这样的数据库。那么第一次登录，我们将session 信息保存在 Redis 中，跳转到第二个服务器时，我们可以先去Redis上查询是否有登录信息，如果有，就能直接进行登录之后的操作了，而不用进行重复登录。 ②第二种方法是根据客户端的IP地址划分，每次都将同一个 IP 地址发送的请求都分发到同一个 Tomcat 服务器，那么也不会存在 session 共享的问题。

注意：我们在 upstream 指令块中增加了 ip_hash 指令。该指令就是告诉 nginx 服务器，同一个 IP 地址客户端发送的请求都将分发到同一个 Tomcat 服务器进行处理。

根据服务器处理请求的时间来进行负载，处理请求越快，也就是响应时间越短的优先分配。

fair：智能调整调度算法，动态的根据后端服务器的请求处理到响应的时间进行均衡分配，响应时间短处理效率高的服务器分配到请求的概率高，响应时间长处理效率低的服务器分配到的请求少；结合了前两者的优点的一种调度算法。但是需要注意的是Nginx默认不支持fair算法，如果要使用这种调度算法，请安装upstream_fair模块。

按照访问的域名的hash结果分配请求，每个请求的url会指向后端固定的某个服务器，可以在Nginx作为静态服务器的情况下提高缓存效率。同样要注意Nginx默认不支持这种调度算法，要使用的话需要安装Nginx的hash软件包。

F5，硬负载 优点：能够直接通过智能交换机实现,处理能力更强，而且与系统无关，负载性能强 缺点：成本高，除设备价格高昂，而且配置冗余，很难想象后面服务器做一个集群，但最关键的负载均衡设备却是单点配置，无法有效掌握服务器及应用状态。 硬件负载均衡，一般都不管实际系统与应用的状态，而只是从网络层来判断，所以有时候系统处理能力已经不行了，但网络可能还来得及反应（这种情况非常典型，比如应用服务器后面内存已经占用很多，但还没有彻底不行，如果网络传输量不大就未必在网络层能反映出来）

Nginx，软负载 优点：基于系统与应用的负载均衡，能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的，性价比高，实际上如果几台服务器，用F5之类的硬件产品显得有些浪费，而用软件就要合算得多，因为服务器同时还可以跑应用、做集群等。 缺点：负载能力受服务器本身性能的影响，性能越好，负载能力越大。