负载均衡是实现高可用的一项重要技术，我的理解是一种将请求“均衡”分配到不同的机器上的技术，目的是提升系统整体的负载能力。从单机网站到分布式网站，解决了大型网站访问量大，并发量高，海量数据的问题。然而每个部署的独立业务面临单点问题和访问统一入口问题，需要通过负载均衡技术来实现流量分发。
最直接的分类方式可以将负载均衡分为基于硬件的负载均衡和基于软件的负载均衡；根据处理的对象不同，可以将其分为基于内容的负载均衡和基于请求的负载均衡；根据算法本身的处理方式可以分为静态负载均衡算法和动态负载均衡算法；根据网络协议可以分为四层负载均衡算法和七层负载均衡算法。
下面首先对常见的负载均衡算法介绍；然后对不同算法的应用场景进行比较，分析几个负载均衡相关的业务案例。
0.基本概念
0.1 名词
| 解释 | 备注 | |
|---|---|---|
| LVS | Linux Virtual Server | 意即Linux虚拟服务器，是一个虚拟的服务器集群系统。 |
| VIP | 虚拟IP | |
| RIP | 真实IP | |
| RS | 真实服务器 | |
| A记录 | 一个域名对应一个ip | |
| CNAME | 一个域名对应另外一个域名 |
1.负载均衡算法
1.1. 基于请求的负载均衡算法
1.1.1 简单轮询
1.1.2加权轮询算法
- 参考[1]
- 原理：轮询调度算法就是以轮询的方式依次将请求调度到不同的服务器，即每次调度执行i = (i + 1) mod n，选出第 i 台服务器。加权轮询调度算法可以解决服务器间性能不一的情况，它用相应的权值表示服务器的处理性能，按权值的高低和轮询方式分配请求到各服务器。权值高的服务器先收到连接，权值高的服务器比权值低的服务器处理更多的连接，相同权值的服务器处理相同数目的连接数。
- 优势：算法简洁。它无需记录当前所有连接的状态，所以它是一种无状态调度。
- 劣势：不适用于请求服务时间变化比较大，或者每个请求所消耗的时间不一致的情况，此时轮询调度算法容易导致服务器间的负载不平衡。
- 适用场景：每个请求所占用的后端服务器时间基本相同，常用于短连接服务，例如 HTTP 等服务。
- 用户推荐：用户可知每个请求所占用后端时间基本相同或相差较小时，如已知后端服务器处理的都是同类型或者相似类型的请求时，推荐选择加权轮询的方式，因为该实现方式消耗小，无需遍历，效率较高。
1.1.3加权最小连接数算法
- 参考[1]
原理：在实际情况中，客户端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间的延伸，如果采用简单的轮询算法，每一台服务器上的连接进程数目可能会产生极大的不同，这样实际上并没有达到真正的负载均衡。最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1; 当连接中止或超时，其连接数减一。加权最小连接数算法是在最小连接数调度算法的基础上，根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。
- 假设各台 机器 的权值依次为 wi,当前连接数依次为 ci,依次计算 ci/wi,值最小的 机器 作为下一个分配的 机器
- 如果存在ci/wi相同的 机器，这些 机器 再使用加权轮询的方式调度
优势：此种均衡算法适合处理长时的请求服务，如 FTP 等应用。
- 劣势：相较于加权轮询算法，加权最小连接数算法需要保存服务器现有的连接数目，它是一种有状态调度。
- 适用场景：每个请求所占用的后端时间相差较大的场景，常用于长连接服务。
- 用户推荐：如果用户需要处理不同的请求，且请求所占用后端时间相差较大，如 2 ms 和 2s 这种数量级的差距时，推荐使用加权最小连接数算法实现负载均衡。
1.1.4 随机策略
1.1.5 动态负载均衡
1.2. 基于数据的负载均衡算法
1.2.1. hash
如根据请求uri进行负载均衡，在Ngnix配置如下：
1 | upstream backend { |
1.2.2. 一致性hash算法
upstream ngnix_local_server {
hash $consistent_key consistent;
server 192.168.61.9080 weight=1;
server 192.168.62.9081 weight=2;
}
1.2.3. 基于关键字
1.3. 全局负载均衡
全局负载均衡技术将用户的访问指向离用户最近的工作正常的流媒体服务器上, 带来的益处包括 increased reliability 和 reductions in latency。GSLB一般是通过CDN（Content Delivery Network）来实现的，那CDN又是如何来实现呢？CDN是构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。
主流的实现技术如下。
- DNS：GSLB会替代最终的DNS的服务器从而实现自己的解析策略，返回给用户最合适的IP(列表)。代表性的实现如F5。
- HTTP redirection：使用HTTP重定向将内容转发到不同位置。
- IP Route：更改IP首部实现使用跳转，并利用IP tunneling技术实现只对请求负载均衡(响应直接返回)。
- 统一调度服务层：客户端SDK+调度服务完成GSLB设备的功能。使用的策略可以是当前用户所在的区域，或者是userId等信息。
2. 均衡算法选取实例
2.1 轮询之场景1
若用户首次接触云服务，且建站时间不长，网站负载较低，则建议购买相同配置的 机器，因此 机器 都是无差别的接入层服务器。在此场景下，用户可以将 机器 的权重设置为相同的值，采用加权轮询的方式进行流量分发。
2.2 最小连接数之场景2
设有2台配置相同（CPU 和 内存）的 机器，由于性能一致，用户可以将 机器 权重都设置为10。设现在每台 机器 与客户端端建立了50个 TCP 连接，此时新增一台 机器。在此场景下，推荐用户使用最小连接数的均衡方式，这样能快速的提升新加入 机器 的负载，降低另外2台 机器 的压力。
2.3 加权轮询之场景3
用户有4台服务器，用于承载简单的静态网站访问，且4台服务器的计算能力的比例为 6：3：2：1（按CPU、内存换算）。在此场景下，用户可以依次将 机器 权重比例设置为60，30，20，10，由于静态网站访问大多数是短连接请求，因此可以采用加权轮询的均衡方式，让 SLB 按 机器 的性能比例分配请求。
2.4 加权轮询之场景4
某用户有12台 机器 用于承担海量的 WEB 访问请求，且不希望多购置 机器 增加支出。 某台 机器 经常会因为负载过高，导致服务器重启。在此场景下，建议用户根据 机器 的性能设置相应的权重，给负载过高的 机器 设置较小的权值。除此之外，可以采用最小连接数的负载均衡方式，将请求分配到活跃连接数较少的 机器 上，从而解决某台 机器 负载过高的问题。
2.5 加权轮询之场景5
某用户有3台 机器 用于处理若干长连接请求，且这3太服务器的计算能力比例为4：2：1（按CPU、内存换算）。 此时性能最好的服务器处理请求较多，用户不希望过载此服务器，希望能够将新的请求分配到空闲服务器上。在此场景下，可以采用加权最小连接数的均衡方式，并适当降低繁忙服务器的权重，便于 SLB 将请求分配到活跃数较少的 机器 上，实现负载均衡。
3. 负载均衡实战
3.1. Ngnix
3.1.1. 七层负载均衡
根据端口+应用层协议(如HTTP协议的主机名，URL)转发报文到上游服务器[2]。
3.1.2. 四层负载均衡
根据端口将报文转发报文到上游服务器[2]。
3.2. Dubbo
3.3. Haproxy
在之前的博客里讲述了如何使用docker搭建一个软件应用栈，使用到的配置文件如下：
1 | global |
