负载均衡，异构服务器的负载均衡和过载保护
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集群”的处理能力，怎么转移请求也是处理不过来的，还得通过抛弃请求来实施自我保护。
