负载均衡基本介绍

【负载均衡架构部分转自】 58沈剑 [架构师之路]( https://mp.weixin.qq.com/s

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

常见的负载均衡方案：

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

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

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

上游连接池会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。（也即是rpc框架实现的）

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

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

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

（1）按照range水平切分

（2）按照id哈希水平切分

[图片上传中...(-6b2508-1561902875888-0)]

常见的负载均衡系统包括 3 种：DNS 负载均衡、硬件负载均衡和软件负载均衡。

硬件负载均衡是通过单独的硬件设备来实现负载均衡功能，这类设备和路由器、交换机类似，可以理解为一个用于负载均衡的基础网络设备。比如业界非常出名的F5

缺点：

（1）价格实在非常昂贵

（2）扩展性不强

软件负载均衡通过负载均衡软件来实现负载均衡功能，常见的有 Nginx 和 LVS。

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

题目：日活跃用户 1000 万的论坛的负载均衡集群，该如何设计呢？

（1）评估流量

1000万DAU，换算成秒级（一天12小时），平均约等于232。

考虑每个用户操作次数，假定10，换算成平均QPS=2320。

考虑峰值是均值倍数，假定5，换算成峰值QPS=11600。

考虑静态资源、图片资源、服务拆分等，流量放大效应，假定10，QPS 10=116000。

（2）容量规划

考虑高可用、异地多活，QPS 2=232000。

考虑未来半年增长，QPS*1.5=348000。

（3）方案设计

可以用三级导流：

第一级，DNS，确定机房，以目前量级，可以不考虑。

第二级，确定集群，扩展优先，则选Haproxy/LVS，稳定优先则选F5。

第三级，Nginx+KeepAlived，确定实例。

（4）架构图

接入层技术：

缺点：

优点：

缺点：

优点：

缺点：

缺点：

nginx毕竟是软件，性能比tomcat好，但总有个上限，超出了上限，还是扛不住。lvs就不一样了，它实施在操作系统层面；f5的性能又更好了，它实施在硬件层面；它们性能比nginx好很多，例如每秒可以抗10w，这样可以利用他们来扩容。

99.9999%的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。 假设还扛不住的话，就要考虑使用硬件设备f5等。如果还是扛不住，那么只有DNS来扩容了。

水平扩展，才是解决性能问题的根本方案，能够通过加机器扩充性能的方案才具备最好的扩展性。 facebook，google，baidu的PV是不是超过80亿呢，它们的域名只对应一个ip么，终点又是起点，还是得通过DNS轮询来进行扩容：

比如购买了阿里云或者aws。那么基本会使用云厂商提供的负载均衡中间件，比如aws（elb）、阿里云（slb）。这个负载均衡软件可以认为是 lvs+keepalived的高可用负载均衡服务

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

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

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

（1）通过“静态权重”标识service的处理能力

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

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

（2）通过“动态权重”标识service的处理能力

提问：通过什么来标识一个service的处理能力呢？

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

动态权重设计：

例如：

（1）设置一个阈值，超过阈值直接丢弃

（2）借助“动态权重”来实施过载保护

案例策略：

1）service的负载均衡、故障转移、超时处理通常是RPC-client连接池层面来实施的

2）异构服务器负载均衡，最简单的方式是静态权重法，缺点是无法自适应动态调整

3）动态权重法，可以动态的根据service的处理能力来分配负载，需要有连接池层面的微小改动

4）过载保护，是在负载过高时，service为了保护自己，保证一定处理能力的一种自救方法

5）动态权重法，还可以用做service的过载保护

随着用户访问的增多，一个应用服务器不能满足需求了，就需要部署多台应用服务器，通过负载均衡，将数据分发到不同的应用服务器。

从作用来看，和缓存集群的分发很相似，但是有不同。缓存需要发送到特定的服务器。但是，由于应用服务器是无状态的，因此，负载均衡不用根据请求分发到特定服务器，发送到哪个应用服务器都可以。

因此，负载均衡关注的技术焦点有两个，分别是：网络通信、路由选择

网络通信分为以下几种方法。

负载均衡服务器什么都不做，重定向响应

这种方法优点是简单，但是缺点也很明显：

由于这些问题，这种方法，在现实中几乎没有人使用。

每次请求DNS解析到IP地址不同，从而访问到不同到应用服务器。

这种方法，性能方面没有问题，虽然，还是2次http请求，但是不是每一次请求都需要域名解析，一次解析，ip就会记录到本地。下次，直接访问记录的ip。因此，性能无问题。

但是，由于域名解析服务器解析出的ip，如果出错，不会很快更新，且用户已经本地存储了ip也不会很快改变。因此，采用这种方案时，需要两级负载均衡。若应用服务器出错，在第二层负载均衡去掉。

对于安全性，现实使用时，该方法主要适用于两层负载均衡的情况，DNS负载均衡用于第一层负载均衡，解析出来的是第二层负载均衡服务器，因此，脆弱的服务器还是可以在内网中。淘宝、百度，不同时间ping，返回地址不同，意味着都是用了DNS负载均衡。

在应用层进行负载均衡，收到请求时，将请求转发到内网，再将收到的内网响应，返回给用户。

nagix本身的反向代理服务器，就有该功能。一般应用服务器是几十台，这种模式够用，再多一些，会不够用。因此，大一些的网站不会使用。

因为用的http请求协议，http比较重（比tcp的包重）。对反向代理服务器压力很大，其通过应用程序级别的线/进程才能完成分发，还要等应用服务器返回，因此，会有性能瓶颈。即使负载均衡做集群效率也低，因为后面的应用服务器有限。

因此，可以应用的规模很有限。

负载均衡服务器，和反向代理负载均衡原理相同，但是是在tcp层，修改包中源地址和目标地址，并发送到内网，收到响应后，再修改目标地址和原地址，返回给用户。

因为，负载均衡服务器处理的是ip那一层包，因此，处理能力可以提高。

但是，这种方法，请求和响应都通过了负载均衡，尤其是响应一般比较大。响应出口网络带宽会成为瓶颈。

数据链路层负载均衡，IP地址不变，只修改网卡MAC地址。应用服务器和负载均衡服务器共享一个虚拟ip。因为ip没有被修改过，tcp/ip协议还是通的，可以通过校验。又由于目的地址的mac地址改变了，因此，处理响应不用再经过负载均衡服务器。

大型互联网应用主要使用的负载均衡方案，也称为负载均衡的三角模式。

轮询

....

该方案已经被淘汰的。

通过session复制的方式，集群规模会受限制，复制不过来。做集群就是因为用户请求多，请求多，session也多，如果每个都有所有的session，对服务器压力很大。

来自相同的ip，总是到同一个应用服务器。这种方法也很快就淘汰了。

因为，会话需要会话关闭，如果因为发布程序，kill进程，session丢失。系统的可用性会下降。

发请求时，带cookie发送服务器，session记录的cookie中，返回给浏览器。任何一台服务器可以重cookie里得到session。

缺点：cookie变大，网络开销有影响。且有些浏览器禁用cookie，不好用。

早期使用的这个方案。缺点明显，但是生命力强。

对服务器架构要求很低。

---