【负载均衡架构部分转自】58沈剑 [架构师之路](https://mp.weixin.qq.com/s
- 单台服务器不管好好坏总是会遇到性能瓶颈，而解决单台服务器瓶颈方式就是采用集群。高性能集群的本质很简单，通过增加更多的服务器来提升系统整体的计算能力。在一个集群中，每一台服务器提供的功能是一样，但是每一台服务器的类型可能是不一样的（性能、配置、价格等等），因此需要设计合理的任务分配策略，将计算任务分配到多台服务器上执行，并且保证在每一台服务器上输入相同的参数，输出的结果一样。
- 高性能集群的复杂性主要体现在需要增加一个任务分配器，以及为任务选择一个合适的任务分配算法。对于任务分配器，现在更流行的通用叫法是“负载均衡器”。
一、了解复杂均衡
负载均衡：是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】
常见的负载均衡方案：
常见互联网分布式架构如上，分为客户端层、反向代理nginx层、站点层、服务层、数据层。可以看到，每一个下游都有多个上游调用，只需要做到，每一个上游都均匀访问每一个下游，就能实现“将请求/数据【均匀】分摊到多个操作单元上执行”
1、【客户端层->反向代理层】的负载均衡
【客户端层】到【反向代理层】的负载均衡，是通过“DNS轮询”实现的：DNS-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问DNS-server，会轮询返回这些ip，保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip，以做到每台nginx的请求分配也是均衡的。
2、【反向代理层->站点层】的负载均衡
【反向代理层】到【站点层】的负载均衡，是通过“nginx”实现的。通过修改nginx.conf，可以实现多种负载均衡策略：
3、【站点层->服务层】的负载均衡
【站点层】到【服务层】的负载均衡，是通过“服务连接池”实现的。
上游连接池会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。（也即是rpc框架实现的）
4、【数据层】的负载均衡
在数据量很大的情况下，由于数据层（db，cache）涉及数据的水平切分，所以数据层的负载均衡更为复杂一些，它分为“数据的均衡”，与“请求的均衡”。
数据的均衡是指：水平切分后的每个服务（db，cache），数据量是差不多的。
请求的均衡是指：水平切分后的每个服务（db，cache），请求量是差不多的。
（1）按照range水平切分
存储均匀，容易扩展，但是请求会不均价（存在新老用户，活跃用户僵尸用户等情况）
（2）按照id哈希水平切分
[图片上传中...(image.png-6b2508-1561902875888-0)]
存储均匀、请求均匀、规则简单。但是不容易扩展，扩展一个数据服务，hash方法改变时候，可能需要进行数据迁移
5、总结
（1）【客户端层】到【反向代理层】的负载均衡，是通过“DNS轮询”实现的
（2）【反向代理层】到【站点层】的负载均衡，是通过“nginx”实现的
（3）【站点层】到【服务层】的负载均衡，是通过“服务连接池”实现的
（4）【数据层】的负载均衡，要考虑“数据的均衡”与“请求的均衡”两个点，常见的方式有“按照范围水平切分”与“hash水平切分”
二、负载均衡分类
常见的负载均衡系统包括 3 种：DNS 负载均衡、硬件负载均衡和软件负载均衡。
1、DNS负载均衡
优点：
（1）简单、成本低
（2）就近访问，提升访问速度
缺单：
（1）由于缓存存在会产生数据不一致现象，也就是服务变更不及时
（2）DNS 负载均衡的控制权在域名商那里，无法根据业务特点针对其做更多的定制化功能和扩展特性。
（3）分配策略比较简单，也就是提供的负载均衡算法少
2、硬件负载均衡器
硬件负载均衡是通过单独的硬件设备来实现负载均衡功能，这类设备和路由器、交换机类似，可以理解为一个用于负载均衡的基础网络设备。比如业界非常出名的F5
优点：
（1）功能强大，支持多层负载均衡(通常是四层和七层），支持多种负载均衡算法
（2）性能强大
（3）稳定性和安全性强大
缺点：
（1）价格实在非常昂贵
（2）扩展性不强
3、软件负载均衡器
软件负载均衡通过负载均衡软件来实现负载均衡功能，常见的有 Nginx 和 LVS。
优点：
（1）简单
（2）便宜
（3）可扩展、可定制性强
缺点：
（1）性能一般（相比硬件负载均衡）、功能也没有硬件负载均衡强大
（2）一般不具备防火墙和防 DDoS 攻击等安全功能
4、业界常用负载均衡简介
nginx和F5：https://blog.csdn.net/chabale/article/details/8956717
nginx和lvs比较：https://blog.51cto.com/hzcto/2086691
lvs：https://www.cnblogs.com/liwei0526vip/p/6370103.html
ELB： https://aws.amazon.com/cn/elasticloadbalancing/
SLB：https://help.aliyun.com/product/27537.html
5、一个千万级别的负载均衡架构设计
题目：日活跃用户 1000 万的论坛的负载均衡集群，该如何设计呢？
（1）评估流量
1000万DAU，换算成秒级（一天12小时），平均约等于232。
考虑每个用户操作次数，假定10，换算成平均QPS=2320。
考虑峰值是均值倍数，假定5，换算成峰值QPS=11600。
考虑静态资源、图片资源、服务拆分等，流量放大效应，假定10，QPS10=116000。
（2）容量规划
考虑高可用、异地多活，QPS2=232000。
考虑未来半年增长，QPS*1.5=348000。
（3）方案设计
可以用三级导流：
第一级，DNS，确定机房，以目前量级，可以不考虑。
第二级，确定集群，扩展优先，则选Haproxy/LVS，稳定优先则选F5。
第三级，Nginx+KeepAlived，确定实例。
（4）架构图
- 组合的基本原则为：DNS 负载均衡用于实现地理级别的负载均衡；硬件负载均衡用于实现集群级别的负载均衡；软件负载均衡用于实现机器级别的负载均衡。
- 三种主流负载均衡器选型参考：
Ngxin 的性能是万级，一般的 Linux 服务器上装一个 Nginx 大概能到 5 万 / 秒；LVS 的性能是十万级，据说可达到 80 万 / 秒；而 F5 性能是百万级，从 200 万 / 秒到 800 万 / 秒都有
三、再论接入层负载均衡
接入层技术：
1）nginx：一个高性能的web-server和实施反向代理的软件
2）lvs：Linux Virtual Server，使用集群技术，实现在linux操作系统层面的一个高性能、高可用、负载均衡服务器
3）keepalived：一款用来检测服务状态存活性的软件，常用来做高可用
4）f5：一个高性能、高可用、负载均衡的硬件设备（听上去和lvs功能差不多？）
5）DNS轮询：通过在DNS-server上对一个域名设置多个ip解析，来扩充web-server性能及实施负载均衡的技术
- 接入层技术演进
1、裸奔时代（0）单机架构
1）浏览器通过DNS-server，域名解析到ip
2）浏览器通过ip访问web-server
缺点：
1）非高可用，web-server挂了整个系统就挂了
2）扩展性差，当吞吐量达到web-server上限时，无法扩容
注：单机不涉及负载均衡的问题
2、简易扩容方案（1）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
3、简易扩容方案（2）nginx
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挂了怎么办？
4、高可用方案（3）keepalived
1）做两台nginx组成一个集群，分别部署上keepalived，设置成相同的虚IP，保证nginx的高可用
2）当一台nginx挂了，keepalived能够探测到，并将流量自动迁移到另一台nginx上，整个过程对调用方透明
缺点：
1）资源利用率只有50%
2）nginx仍然是接入单点，如果接入吞吐量超过的nginx的性能上限怎么办，例如qps达到了50000咧？
5、scale up扩容方案（4）lvs/f5
nginx毕竟是软件，性能比tomcat好，但总有个上限，超出了上限，还是扛不住。lvs就不一样了，它实施在操作系统层面；f5的性能又更好了，它实施在硬件层面；它们性能比nginx好很多，例如每秒可以抗10w，这样可以利用他们来扩容。
1）如果通过nginx可以扩展多个tomcat一样，可以通过lvs来扩展多个nginx
2）通过keepalived+VIP的方案可以保证可用性
99.9999%的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。假设还扛不住的话，就要考虑使用硬件设备f5等。如果还是扛不住，那么只有DNS来扩容了。
6、scale out扩容方案（5）DNS轮询
水平扩展，才是解决性能问题的根本方案，能够通过加机器扩充性能的方案才具备最好的扩展性。facebook，google，baidu的PV是不是超过80亿呢，它们的域名只对应一个ip么，终点又是起点，还是得通过DNS轮询来进行扩容：
1）通过DNS轮询来线性扩展入口lvs层的性能
2）通过keepalived来保证高可用
3）通过lvs来扩展多个nginx
4）通过nginx来做负载均衡，业务七层路由
7、云服务负载均衡
比如购买了阿里云或者aws。那么基本会使用云厂商提供的负载均衡中间件，比如aws（elb）、阿里云（slb）。这个负载均衡软件可以认为是lvs+keepalived的高可用负载均衡服务
8、接入层负载均衡总结
1）接入层架构要考虑的问题域为：高可用、扩展性、反向代理+扩展均衡
2）nginx、keepalived、lvs、f5可以很好的解决高可用、扩展性、反向代理+扩展均衡的问题
3）水平扩展scale out是解决扩展性问题的根本方案，DNS轮询是不能完全被nginx/lvs/f5所替代的
四、异构服务器的负载均衡及过载保护
1、需求缘起
后端的service有可能部署在硬件条件不同的服务器上：
1）如果对标最低配的服务器“均匀”分摊负载，高配的服务器的利用率不足；
2）如果对标最高配的服务器“均匀”分摊负载，低配的服务器可能会扛不住；
- 能否根据异构服务器的处理能力来动态、自适应进行负载均衡及过载保护？
2、service层的负载均衡回顾
- service层的负载均衡，一般是通过service连接池来实现的，调用方连接池会建立与下游服务多个连接，每次请求“随机”获取连接，来保证service访问的均衡性。
负载均衡、故障转移、超时处理等细节也都是通过调用方连接池来实现的。
3、实现动态+自适应的进行负载调度
（1）通过“静态权重”标识service的处理能力
为每个下游service设置一个“权重”，代表service的处理能力，来调整访问到每个service的概率。例如：
1、假设service-ip1，service-ip2，service-ip3的处理能力相同，可以设置weight1=1，weight2=1，weight3=1，这样三个service连接被获取到的概率分别就是1/3，1/3，1/3，能够保证均衡访问。
2、假设service-ip1的处理能力是service-ip2，service-ip3的处理能力的2倍，可以设置weight1=2，weight2=1，weight3=1，这样三个service连接被获取到的概率分别就是2/4，1/4，1/4，能够保证处理能力强的service分别到等比的流量，不至于资源浪费。
优点：简单，能够快速的实现异构服务器的负载均衡。
缺点：权重是固定的，无法自适应动态调整，而很多时候，服务器的处理能力是很难用一个固定的数值量化。
（2）通过“动态权重”标识service的处理能力
提问：通过什么来标识一个service的处理能力呢？
回答：其实一个service能不能处理得过来，能不能响应得过来，应该由调用方说了算。调用服务，快速处理了，处理能力跟得上；调用服务，处理超时了，处理能力很有可能跟不上了。
动态权重设计：
1）用一个动态权重来标识每个service的处理能力，默认初始处理能力相同，即分配给每个service的概率相等；
2）每当service成功处理一个请求，认为service处理能力足够，权重动态+1
3）每当service超时处理一个请求，认为service处理能力可能要跟不上了，权重动态-10（权重下降会更快）
4）为了方便权重的处理，可以把权重的范围限定为[0, 100]，把权重的初始值设为60分
例如：
1、假设service-ip1，service-ip2，service-ip3的动态权重初始值weight1=weight2=weight3=60，刚开始时，请求分配给这3台service的概率分别是60/180，60/180，60/180，即负载是均衡的。
2、随着时间的推移，处理能力强的service成功处理的请求越来越多，处理能力弱的service偶尔有超时，随着动态权重的增减，权重可能变化成了weight1=100，weight2=60，weight3=40，那么此时，请求分配给这3台service的概率分别是100/200，60/200，40/200，即处理能力强的service会被分配到更多的流量。
4、过载保护
互联网软件架构设计中所指的过载保护，是指当系统负载超过一个service的处理能力时，如果service不进行自我保护，可能导致对外呈现处理能力为0，且不能自动恢复的现象。而service的过载保护，是指即使系统负载超过一个service的处理能力，service让能保证对外提供有损的稳定服务。
（1）设置一个阈值，超过阈值直接丢弃
- 最简易的方式，服务端设定一个负载阈值，超过这个阈值的请求压过来，全部抛弃。这个方式不是特别优雅。
（2）借助“动态权重”来实施过载保护
案例策略：
1）如果某一个service的连接上，连续3个请求都超时，即连续-10分三次，客户端就可以认为，服务器慢慢的要处理不过来了，得给这个service缓一小口气，于是设定策略：接下来的若干时间内，例如1秒（或者接下来的若干个请求），请求不再分配给这个service；
2）如果某一个service的动态权重，降为了0（像连续10个请求超时，中间休息了3次还超时），客户端就可以认为，服务器完全处理不过来了，得给这个service喘一大口气，于是设定策略：接下来的若干时间内，例如1分钟（为什么是1分钟，根据经验，此时service一般在发生fullGC，差不多1分钟能回过神来），请求不再分配给这个service；
3）可以有更复杂的保护策略…
5、总结
1）service的负载均衡、故障转移、超时处理通常是RPC-client连接池层面来实施的
2）异构服务器负载均衡，最简单的方式是静态权重法，缺点是无法自适应动态调整
3）动态权重法，可以动态的根据service的处理能力来分配负载，需要有连接池层面的微小改动
4）过载保护，是在负载过高时，service为了保护自己，保证一定处理能力的一种自救方法
5）动态权重法，还可以用做service的过载保护
