负载均衡，异构服务器的负载均衡和过载保护

1. 什么是负载均衡？

负载均衡（Load Balance）是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据均匀分摊到多个操作单元上执行。负载均衡的关键在于均匀。

常见互联网分布式架构如上，分为客户端层，反向代理nginx层，站点层，服务层，数据层。可以看出，每一个下游都要多个上游调用，只需要做到，每一个上游都均匀访问每一个下游，就能实现“将请求/数据均匀分摊到多个操作单元上执行”。

1.1 客户端层->反向代理层的负载均衡

客户端层到反向代理层的负载均衡，是通过DNS轮询实现的，DNS-server对于一个域名配置了多个解析IP，每次DNS解析请求来访问DNS-server，会轮询返回这些IP，保证每个IP的解析概率是相同的。这些IP就是nginx的外网IP，以做到每台nginx的请求分配也是均衡的。

1.2 反向代理层->站点层的负载均衡

反向代理层到站点层的负载均衡，是通过nginx实现的。通过修改nginx.conf，可以实现多种负载均衡策略：

（1）请求轮询，同DNS轮询类似，请求依次路由到各个web-server；

（2）最少连接路由，哪个web-server的连接少，路由到哪个web-server；

（3）IP哈希，按照访问用户的IP哈希来路由web-server，只要用户的IP分布式均匀的，请求理论上也是均匀的，IP哈希均衡方法可以做到，同一个用户的请求固定落到同一台web-server上，此策略适合有状态服务。

（4）等等

1.3 站点层->服务层的负载均衡

站点层到服务层的负载均衡，是通过“服务连接池”实现的。

上游连接池会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。

1.4 数据层的负载均衡

在数据量很大的情况下，由于数据层（db，cache）涉及数据的水平切分，所以数据层的负载均衡更为复杂一些，它分为“数据的均衡”和“请求的均衡”。

数据的均衡是指：水平切分后的每个服务（db，cache），数据量是差不多的。

请求的均衡是指：水平切分后的每个服务（db，cache），请求量是差不多的。

业内常见的水平切分方式有几种：

1.4.1 按照range水平切分

每一个数据服务，存储一定范围的数据，上图为例：

user0服务，存储uid范围1-1kw

user1服务，存储uid范围1kw-2kw

这个方案的好处是：

（1）规则简单，service只需执行以下uid范围就能路由到对应的存储服务；

（2）数据均衡性较好；

（3）比较容易扩展，可以随时加一个uid[2kw,3kw]的数据服务。

不足是：

（1）请求的负载不一定均衡，一般来说，新注册的用户会比老用户更活跃，大range的服务请求压力会更大。

1.4.2 按照id哈希水平切分

每一个数据服务，存储某个key值hash后的部分数据，上图为例：

user0服务，存储偶数uid数据；

user1服务，存储奇数uid数据；

这个方案的好处是：

（1）规则简单，service只需对uid进行hash能路由到对应的存储服务；

（2）数据均衡性较好；

（3）请求均匀性较好。

不足是：

（1）不容易扩展，扩展一个数据服务，hash方法改变时候，可能需要进行数据迁移。

2. 接入层的负载均衡

问题域：

（1）可用性：任何一台机器挂了，服务受不受影响；

（2）扩展性：能否通过增加机器，扩充系统的性能；

（3）反向代理+负载均衡：请求是否均匀分摊到后端的操作单元执行。

名词解释：

nginx：一个高性能的web-server和试试反向代理的软件。

lvs：Linux Virtual Server，使用集群技术，实现在linux操作系统层面的一个高性能、高可用、负载均衡服务器。

keepalived：一款用来检测服务状态存活性的软件，常用来做高可用。

f5：一个高性能、高可用、负载均衡的硬件设备。

DNS轮询：通过在dns-server上对一个域名设置多个IP解析，来扩充web-server性能及实施负载均衡的技术。

下面重点看一下接入层技术演进。

2.1 裸奔时代-单机架构

裸奔时代的架构图如上：

（1）浏览器通过DNS-server，域名解析到IP

（2）浏览器通过IP访问web-server

缺点：

（1）非高可用，web-server挂了，整个系统就挂了。

（2）扩展性查，当吞吐量达到web-server上限时，无法扩容。

注：单机不涉及负载均衡问题。

2.2 简易扩容方案-DNS轮询

假设tomcat的吞吐量是1000次每秒，当系统总吞吐量达到3000时，如何扩容是首先要解决的问题，DNS轮询是一个很容易想到的方案：

此时的架构图如上：

（1）多部署几份web-server，1个tomcat抗1000，部署3个tomcat就能抗3000

（2）在DNS-server层面，域名每次解析到不同的IP

优点：

（1）零成本：在DNS-server上多配几个IP即可，功能也不收费

（2）部署简单：多部署几个web-server即可，原系统架构不需要做任何改造

（3）负载均衡：变成了多机，但负载基本是均衡的

缺点：

（1）非高可用：DNS-server只负责域名解析IP，这个IP对应的服务是否可用，DNS-server是不保证的，假设有一个web-server挂了，部分服务会受到影响。

（2）扩容非实时：DNS解析有一个生效周期

（3）暴露了太多的外网IP

2.3 简易扩容方案-nginx

tomcat的性能较差，但nginx作为反向代理的性能就强多了，假设线上跑1w，就比tomcat高10倍，可以利用这个特性来做扩容：

此时的架构图如上：

（1）站点层与浏览器层之间加入了一个反向代理层，利用高性能的nginx来做反向代理

（2）nginx将http请求分发给后端多个web-server

优点：

（1）DNS-server不需要动

（2）负载均衡：通过nginx来保证

（3）只暴露一个外网IP，nginx->tomcat之间使用内网访问

（4）扩容实时：nginx内部可控，随时增加web-server随时实时扩容

（5）能够保证站点的可用性：任何一台tomcat挂了，nginx可以将流量迁移到其他tomcat

缺点：

（1）时延增加+架构更复杂：中间多加了一个反向代理层

（2）反向代理层成了单点，非高可用：tomcat挂了不影响服务，nginx挂了怎么办？

2.4 高可用方案-keepalived

为了解决高可用的问题，keepalived出场了。

（1）做两台nginx组成一个集群，分别部署到keepalived，设置成相同的虚IP，保证nginx的高可用；

（2）当一台nginx挂了，keepalived能够探测到，并将流量自动迁移到另一台nginx上，整个过程对调用方透明

优点：

（1）解决了高可用的问题

缺点：

（1）资源利用率只有50%

（2）nginx仍然是接入单点，如果接入吞吐量超过的nginx的性能上限怎么办，例如qps达到了5w？

2.5 scale up（垂直扩展）扩容方案-LVS/F5

nginx毕竟是软件，性能比tomcat好，但总有个上限，超出了上限，还是扛不住。

LVS就不一样了，它实施在操作系统层面；F5的性能又更好了，它实施在硬件层面；它们性能比nginx好很多，例如每秒可以抗10w，这样可以利用他们来扩容，常见的架构图如下：

（1）如果通过nginx可以扩展多个tomcat一样，可以通过lvs来扩展多个nginx

（2）通过keepalived+VIP的方案可以保证可用性

99.9999%公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。

但是，不管使用lvs还是f5，这些都是scale up的方案，根本上，lvs/f5还是会有性能上限，假设每秒能处理10w的请求，一天也只能处理80亿的请求（10w秒吞吐量*8w秒[一天]），那万一系统的日PV超过80亿怎么办？

2.6 scale out（水平扩展）扩容方案-DNS轮询

如之前文章所述，水平扩展，才是解决性能问题的根本方案，能够通过加机器扩充性能的方案才具备最好的扩展性。

 

（1）通过DNS轮询来线下扩展入口LVS层的性能

（2）同keepalived来保证高可用

（3）通过lvs来扩展多个nginx

（4）同nginx来做负载均衡，业务七层路由

小结：

（1）接入层架构要考虑的问题域为：高可用、扩展性、反向代理+扩展均衡

（2）nginx、keepalived、lvs、f5可以很好的解决高可用、扩展性、反向代理+扩展均衡的问题

（3）水平扩展scale out是解决扩展性问题的根本方案 

3. 异构服务器的负载均衡和过载保护

后端的service有可能部署在硬件条件不同的服务器上：

（1）如果对标最低配的服务器“均匀”分摊负载，高配的服务器的利用率不足；

（2）如果对标最高配的服务器“均匀”分摊负载，低配的服务器可能会扛不住；

能否根据异构服务器处理能力来动态、自适应进行负载均衡及过载保护，是本文要讨论的问题。

service层的负载均衡，一般是通过service连接池来实现的，调用方连接池会建立与下游服务多个连接，每次请求“随机”获取连接，来保证service访问的均衡性。

这个调用方连接池能否实现，根据service的处理能力，动态+自适应进行负载调度呢？

3.1 通过“静态权重”标示service的处理能力

 

调用方通过连接池主键访问下游service，通常采用“随机”的方式返回连接，以保证下游service访问的均衡性。

要打破这个随机性，最容易想到的方法，只要为每个下游service设置一个“权重”，代表service的处理能力，来调整访问到每个service的概率，例如：

加入service-ip1,service-ip2,service-ip3的处理能力相同，可以设置weight1=1，weight2=1，weight3=1，这样三个service连接被获取到的概率分布式1/3,1/3,1/3，能够保证均衡访问。

假设service-ip1的处理能力是service-ip2，service-ip3的处理能力的2倍，可以设置weight1=2，weight2=1，weight3=1，这样三个service连接被获取到的概率分布式2/4，1/4，1/4，能够保证处理能力强的service分配到等比的流量，不至于资源浪费。

使用nginx做反向代理与负载均衡，就有类似的机制。

这个方案的优点是：简单，能够快速的实现异构服务器的负载均衡。

缺点也很明显：这个权重是固定的，无法自适应动态调整。而很多时候，服务器的处理能力是很难用一个固定的数值量化。

3.2 通过“动态权重”标示service的处理能力

通过什么来标示一个service的处理能力呢？

其实一个service能不能处理得过来，能不能响应得过来，应该由调用方说了算。调用服务，快速处理了，处理能力跟得上；调用服务，处理超时了，处理能力很有可能跟不上了。

动态权重设计：

（1）用一个动态权重来标示每个service的处理能力，默认初始处理能力相同，即分配给每个service的概率相等；

（2）每当service成功处理一个请求，认为色如此恶处理能力足够，权重动态+1；

（3）每当service超时处理一个请求，认为service处理能力可能要跟不上了，权重动态-10（权重下降会更快）；

（4）为了方便权重的处理，可以把权重的范围限定为[0, 100]，把权重的初始值设为60。

举例说明：

假设service-ip1,service-ip2,service-ip3的动态权重初始值weight1=weight2=weight3=60，刚开始时，请求分配给这3台service的概率分别是60/180，60/180,60/180，即负载是均衡的。

随着时间的推移，处理能力强的service成功处理的请求越来越多，处理能力弱的service偶尔有超时，随着动态权重的增减，权重可能变化成了weight1=100，weight2=60，weight3=40，那么此时，请求分配给这3台service的概率分别是100/200,60/200,40/200，即此处理能力强的service会被分配到更多的流量。

3.3 过载保护

什么是过载保护？

当系统负载超过一个service的处理能力时，如果service不进行自我保护，可能导致对外呈现处理能力为0，且不能自动恢复的现象。而service的过载保护，是指即使系统负载超过一个service的处理能力，service让能保证对外提供有损的稳定服务。

如何进行过载保护？

最简易的方式，服务器设定一个负载阈值，超过这个阈值的请求压过来，全部抛弃，这个方式不是特别优雅。

3.4 如何借助“动态权重”来实施过载保护

动态权重使用来标示每个service的处理能力的一个值，它是RPC-Client客户端连接池层面的一个东西。服务端处理超时，客户端RPC-Client连接池都能够知道，这里只要实施一些策略，就能够对“疑似过载”的服务器进行降压，而不是服务器“抛弃请求”这么粗暴的实施过载保护。

应该实施一些什么样的策略呢，例如：

（1）如果某一个service的连接上，连续3个请求都超时，即连续-10三次（即-30），客户端就可以认为，服务器慢慢的要处理不过来了，得给这个service缓一小口气，于是设定策略：接下来的若干时间内，例如1秒（或接下来的若干个请求），请求不再分配给这个service；

（2）如果某一个service的动态权重，降为了0（连续10个请求超时，中间休息了3次还超时），客户端就可以认为，服务器完全处理不过来了，得给这个service喘一口气，于是设定策略：接下来的若干时间内，例如1分钟，请求不再分配给这个service；

（3）可以有更复杂的保护策略。

这样的话，不但能借助“动态权重”来试试动态自适应的异构服务器负载均衡，还能够在客户端层面更优雅的实施过载保护，在某个下游service快要响应不过来的时候，给其喘息的机会。

需要注意的是：要防止客户端的过载保护引起的service的雪崩，如果“整体负载”已经超过了“service集群”的处理能力，怎么转移请求也是处理不过来的，还得通过抛弃请求来实施自我保护。