1. 负载均衡概述

  早期的网站流量和业务功能都比较简单，单台服务器足以满足基本的需求，但是随着互联网的发展，业务流量越来越大并且业务逻辑也跟着越来越复杂，单台服务器的性能及单点故障问题就凸显出来了，因此需要多台服务器进行性能的水平扩展及避免单点故障出现。那么如何将不同用户的请求流量分发到不同的服务器上呢？
  负载均衡就是在这样的场景下产生的。

2. 负载均衡的原理及处理流程

  系统的扩展可以分为纵向扩展和横向扩展。

• 纵向扩展： 从单机的角度出发，通过增加系统的硬件处理能力来提升服务器的处理能力。
• 横向扩展： 通过添加机器来满足大型网站服务的处理能力。

  而负载均衡就是在横向扩展的前提下，根据服务器硬件的实际情况 “公平” 的向他们分发请求。
  这里面涉及到两个重要的角色分别是 “应用集群” 和 “负载均衡器”。

• 应用集群： 将同一应用部署到多台机器上，组成处理集群，接收负载均衡设备分发的请求，进行处理并返回响应的数据。
• 负载均衡器： 将用户访问的请求根据对应的负载均衡算法，分发到集群中的一台服务器进行处理。

2.1 负载均衡的作用

1. 解决服务器的高并发压力，提高应用程序的处理性能，如果客户端的流量过多的话，有可能会导致服务器的反应速度减慢，所以需要将客户端的流量分摊到其他各种服务器上。
2. 提供故障转移，实现高可用，还能够监测数据安全，通过其内置功能自动隔离有异常情况的主机，以此来保护数据的安全，如果出现了问题就会直接将问题主机直接替换掉。
3. 通过添加或减少服务器数量，增强网站的可扩展性。
4. 在负载均衡器上提前进行过滤，可以提高系统的安全性。

2.2 负载均衡常用的处理方式

2.2.1 用户手动选择

  这种方式比较原始，实现的方式就是在网站主页上面提供不同线路、不同服务器链接方式，让用户来选择自己访问的具体服务器，来实现负载均衡。
  早些时候的人们，就是通过这种方式来下载小电影之类的资源😏

2.2.2 DNS轮询方式

域名系统（服务）协议（DNS）是一种分布式网络目录服务，主要用于域名与 IP 地址的相互转换。

  大多域名注册商都支持对同一个主机名添加多条 A 记录，这就是 DNS 轮询，DNS 服务器将解析请求按照 A 记录的顺序，随机分配到不同的 IP 上，这样就能完成简单的负载均衡。DNS 轮询的成本非常低，在一些不重要的服务器，被经常使用。
  虽然 DNS 轮询成本低廉，但是 DNS 负载均衡存在明显的缺点：

• 可靠性低
  • 假设一个域名 DNS 轮询多台服务器，如果其中的一台服务器发生故障，那么所有的访问该服务器的请求将不会有所回应，即使你将该服务器的
    IP 从 DNS 中去掉，但是由于各大宽带接入商将众多的 DNS 存放在缓存中，以节省访问时间，导致 DNS 不会实时更新。所以 DNS 轮询一定程度上解决了负载均衡问题，但是却存在可靠性不高的缺点。
• 负载均衡不均衡
  • DNS 负载均衡采用的是简单的轮询负载算法，不能区分服务器的差异，不能反映服务器的当前运行状态，不能做到为性能好的服务器多分配请求，另外本地计算机也会缓存已经解析的域名到 IP 地址的映射，这也会导致使用该 DNS 服务器的用户在一定时间内访问的是同一台 Web 服务器，从而引发 Web 服务器的负载不均衡。
  • 负载不均衡则会导致某几台服务器负荷很低，而另外几台服务器负荷确很高，处理请求的速度慢，配置高的服务器分配到的请求少，而配置低的服务器分配到的请求多。

2.2.3 四/七层负载均衡

  介绍四/七层负载均衡之前，我们先了解一个概念，OSI(open system interconnection)，叫开放式系统互联模型，这个是由国际标准化组织 ISO 指定的一个不基于具体机型、操作系统或公司的网络体系结构。该模型将网络通信的工作分为七层。

• 应用层： 为应用程序提供网络服务。
• 表示层： 对数据进行格式化、编码、加密、压缩等操作。
• 会话层： 建立、维护、管理会话连接。
• 传输层： 建立、维护、管理端到端的连接，常见的有 TCP/UDP。
• 网络层： IP 寻址和路由选择
• 数据链路层： 控制网络层与物理层之间的通信。
• 物理层： 比特流传输。

  所谓四层负载均衡指的是 OSI 七层模型中的传输层，主要是基于 IP+PORT 的负载均衡在三层负载均衡的基础上，通过发布三层的 IP 地址，然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行 NAT 处理，转发至后台服务器，并记录下这个 TCP 或者 UDP 的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理：

实现四层负载均衡的方式：
硬件：F5 BIG-IP、Radware等
软件：LVS、Nginx、Hayproxy等
1
2
3

  所谓的七层负载均衡指的是在应用层，主要是基于虚拟的 URL 或主机 IP 的负载均衡，在四层负载均衡的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个 Web 服务器的负载均衡，除了根据 IP 加 80 端口辨别是否需要处理的流量，还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的 Web 服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理：

实现七层负载均衡的方式：
软件：Nginx、Hayproxy等
1
2

  四层和七层负载均衡的区别：

• 四层负载均衡数据包是在底层就进行了分发，而七层负载均衡数据包则在最顶端进行分发，所以四层负载均衡的效率比七层负载均衡的要高。
• 四层负载均衡不识别域名，而七层负载均衡识别域名。
• 四层负载均衡本质是转发，而七层负载本质是内容交换和代理。

  还有二层、三层负载均衡，二层是在数据链路层基于 mac 地址来实现负载均衡，三层是在网络层一般采用虚拟 IP 地址的方式实现负载均衡。
  而实际环境中一般采用四层负载(LVS)+七层负载(Nginx)的模式。

3. Nginx七层负载均衡

  Nginx 要实现七层负载均衡需要用到proxy_pass代理模块配置。Nginx 默认安装支持这个模块，我们不需要再做任何处理。Nginx 的负载均衡是在 Nginx 的反向代理基础上把用户的请求根据指定的算法分发到一组upstream虚拟服务池。

3.1 Nginx七层负载均衡的指令

3.1.1 upstream指令

  该指令是用来定义一组服务器，它们可以是监听不同端口的服务器，并且也可以是同时监听 TCP 和 Unix socket 的服务器。服务器可以指定不同的权重，默认为 1。

3.1.1 server指令

  该指令用来指定后端服务器的名称和一些参数，可以使用域名、IP、端口或者 unix socket。

3.2 Nginx七层负载均衡的实现流程

  服务端设置:

server {
	listen 9001;
	server_name localhost;
	default_type text/html;
	location /{
		return 200 '<h1>10.7.2.206:9001</h1>';
	}
}
server {
	listen 9002;
	server_name localhost;
	default_type text/html;
	location /{
		return 200 '<h1>10.7.2.206:9002</h1>';
	}
}
server {
	listen 9003;
	server_name localhost;
	default_type text/html;
	location /{
		return 200 '<h1>10.7.2.206:9003</h1>';
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

  负载均衡器设置:

upstream backend{
	server 10.7.2.206:9091;
	server 10.7.2.206:9092;
	server 10.7.2.206:9093;
}
server {
	listen 8083;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12

3.3 负载均衡状态

  代理服务器在负责均衡调度中的状态有以下几个：

3.3.1 down

  将该服务器标记为永久不可用，那么该代理服务器将不参与负载均衡。

upstream backend{
	server 10.7.2.206:9001 down;
	server 10.7.2.206:9002
	server 10.7.2.206:9003;
}
server {
	listen 8083;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12

  该状态一般会对需要停机维护的服务器进行设置。

3.3.2 backup

  将该服务器标记为备份服务器，当主服务器不可用时，将用来传递请求。

upstream backend{
	server 10.7.2.206:9001 down;
	server 10.7.2.206:9002 backup;
	server 10.7.2.206:9003;
}
server {
	listen 8083;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12

  此时需要将 9094 端口的访问禁止掉来模拟下唯一能对外提供访问的服务宕机以后，backup 的备份服务器就要开始对外提供服务，此时为了测试验证，我们需要使用防火墙来进行拦截。
  介绍一个工具firewall-cmd，该工具是 Linux 提供的专门用来操作 firewall 的。

• 查询防火墙中指定的端口是否开放：

  firewall-cmd --query-port=9001/tcp
  1

• 如何开放一个指定的端口

  firewall-cmd --permanent --add-port=9002/tcp
  1

• 批量添加开发端口

  firewall-cmd --permanent --add-port=9001-9003/tcp
  1

• 如何移除一个指定的端口

  firewall-cmd --permanent --remove-port=9003/tcp
  1

• 重新加载

  firewall-cmd --reload
  1

• --permanent表示设置为持久。
• --add-port表示添加指定端口。
• --remove-port表示移除指定端口。

3.3.3 max_conns

  max_conns=number： 用来设置代理服务器同时活动链接的最大数量，默认为 0，表示不限制，使用该配置可以根据后端服务器处理请求的并发量来进行设置，防止后端服务器被压垮。

3.3.4 max_fails和fail_timeout

  max_fails=number： 设置允许请求代理服务器失败的次数，默认为 1。
  fail_timeout=time： 设置经过 max_fails 失败后，服务暂停的时间，默认是 10 秒。

upstream backend{
	server 10.7.2.206:9001 down;
	server 10.7.2.206:9002 backup;
	server 10.7.2.206:9003 max_fails=3 fail_timeout=15;
}
server {
	listen 8083;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12

3.4 Nginx负载均衡策略

  介绍完 Nginx 负载均衡的相关指令后，我们已经能实现将用户的请求分发到不同的服务器上，那么除了采用默认的分配方式以外，我们还能采用什么样的负载算法?
  Nginx 的 upstream 支持如下六种方式的分配算法，分别是：

3.4.1 轮询

  是 upstream 模块负载均衡默认的策略。每个请求会按时间顺序逐个分配到不同的后端服务器。轮询不需要额外的配置。

upstream backend{
	server 10.7.2.206:9001 weight=1;
	server 10.7.2.206:9002;
	server 10.7.2.206:9003;
}
server {
	listen 8083;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12

3.4.2 weight加权（加权轮询）

  用来设置服务器的权重，默认为 1，权重数据越大，被分配到请求的几率越大；该权重值，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的，所有此策略比较适合服务器的硬件配置差别比较大的情况。

upstream backend{
	server 10.7.2.206:9001 weight=10;
	server 10.7.2.206:9002 weight=5;
	server 10.7.2.206:9003 weight=3;
}
server {
	listen 8083;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12

3.4.3 ip_hash

  当对后端的多台动态应用服务器做负载均衡时，ip_hash 指令能够将某个客户端 IP 的请求通过哈希算法定位到同一台后端服务器上。这样，当来自某一个 IP 的用户在后端 Web 服务器 A 上登录后，在访问该站点的其他 URL，能保证其访问的还是后端 web 服务器 A。

upstream backend{
	ip_hash;
	server 10.7.2.206:9001;
	server 10.7.2.206:9002;
	server 10.7.2.206:9003;
}
server {
	listen 8083;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13

  需要注意的是使用 ip_hash 指令无法保证后端服务器的负载均衡，可能导致有些后端服务器接收到的请求多，有些后端服务器接收的请求少，而且设置后端服务器权重等方法将不起作用。

3.4.4 least_conn

  最少连接，把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高。这种情况下，least_conn 这种方式就可以达到更好的负载均衡效果。

upstream backend{
	least_conn;
	server 10.7.2.206:9001;
	server 10.7.2.206:9002;
	server 10.7.2.206:9003;
}
server {
	listen 8083;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13

  此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况。

3.4.5 url_hash

  按访问 url 的 hash 结果来分配请求，使每个 url 定向到同一个后端服务器，要配合缓存命中来使用。同一个资源多次请求，可能会到达不同的服务器上，导致不必要的多次下载，缓存命中率不高，以及一些资源时间的浪费。而使用 url_hash，可以使得同一个 url（也就是同一个资源请求）会到达同一台服务器，一旦缓存住了资源，再此收到请求，就可以从缓存中读取。

upstream backend{
	hash &request_uri;
	server 10.7.2.206:9001;
	server 10.7.2.206:9002;
	server 10.7.2.206:9003;
}
server {
	listen 8083;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13

3.4.6 fair

  fair 采用的不是内建负载均衡使用的轮换的均衡算法，而是可以根据页面大小、加载时间长短智能的进行负载均衡。那么如何使用第三方模块的 fair 负载均衡策略：

upstream backend{
	fair;
	server 10.7.2.206:9001;
	server 10.7.2.206:9002;
	server 10.7.2.206:9003;
}
server {
	listen 8083;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13

  但是如何直接使用会报错，因为 fair 属于第三方模块实现的负载均衡。需要添加nginx-upstream-fair，如何添加对应的模块：

1. 下载nginx-upstream-fair模块

   下载地址为:
   https://github.com/gnosek/nginx-upstream-fair
   1
   2

2. 将下载的文件上传到服务器并进行解压缩

   unzip nginx-upstream-fair-master.zip
   1

3. 重命名资源

   mv nginx-upstream-fair-master fair
   1

4. 使用./configure命令将资源添加到 Nginx 模块中

   ./configure --add-module=/root/fair
   1

5. 编译

   make
   1

   编译可能会出现如下错误，ngx_http_upstream_srv_conf_t结构中缺少default_port
   
   解决方案：
   在 Nginx 的源码中src/http/ngx_http_upstream.h，找到ngx_http_upstream_srv_conf_s，在模块中添加添加default_port属性：

   in_port_t default_port
   1

   
   然后再进行 make
6. 将 sbin 目录下的 nginx 进行备份

   mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginxold
   1

7. 将安装目录下的 objs 中的 nginx 拷贝到 sbin 目录

   cd objs
   cp nginx /usr/local/nginx/sbin
   1
   2

8. 更新 Nginx

   cd ../
   make upgrade
   1
   2

9. 编译测试使用 Nginx

  上面介绍了 Nginx 常用的 6 种负载均衡的策略，那么在咱们以后的开发中到底使用哪种，这个需要根据实际项目的应用场景来决定的。

4. 负载均衡案例

4.1 案例一：对所有请求实现一般轮询规则的负载均衡

upstream backend{
	server 10.7.2.206:9001;
	server 10.7.2.206:9002;
	server 10.7.2.206:9003;
}
server {
	listen 8083;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12

4.2 案例二：对所有请求实现加权轮询规则的负载均衡

upstream backend{
	server 10.7.2.206:9001 weight=7;
	server 10.7.2.206:9002 weight=5;
	server 10.7.2.206:9003 weight=3;
}
server {
	listen 8083;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12

4.3 案例三：对特定资源实现负载均衡

upstream videobackend{
	server 10.7.2.206:9001;
	server 10.7.2.206:9002;
}
upstream filebackend{
	server 10.7.2.206:9003;
	server 10.7.2.206:9004;
}
server {
	listen 8084;
	server_name localhost;
	location /video/ {
		proxy_pass http://videobackend;
	}
	location /file/ {
		proxy_pass http://filebackend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

4.4 案例四：对不同域名实现负载均衡

upstream itcastbackend{
	server 10.7.2.206:9001;
	server 10.7.2.206:9002;
}
upstream itheimabackend{
	server 10.7.2.206:9003;
	server 10.7.2.206:9004;
}
server {
	listen 8085;
	server_name www.itcast.cn;
	location / {
		proxy_pass http://itcastbackend;
	}
}
server {
	listen 8086;
	server_name www.itheima.cn;
	location / {
		proxy_pass http://itheimabackend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

4.5 案例五：实现带有URL重写的负载均衡

upstream backend{
	server 10.7.2.206:9001;
	server 10.7.2.206:9002;
	server 10.7.2.206:9003;
}
server {
	listen 80;
	server_name localhost;
	location /file/ {
		rewrite ^(/file/.*) /server/$1 last;
	}
	location / {
		proxy_pass http://backend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

5. Nginx四层负载均衡

  Nginx 四层负载均衡就是实现通过访问某个 IP 的端口转发至对应的服务器上。

5.1 Nginx四层负载均衡的指令

5.1.1 stream指令

  该指令提供在其中指定流服务器指令的配置文件上下文，和 http 指令同级。

5.1.2 upstream指令

  该指令和 http 的 upstream 指令是类似的。

5.2 Nginx四层负载均衡的案例

  实现步骤：
  准备 Redis 服务器，在一条服务器上准备三个 Redis，端口分别是 6379，6378。

1. 上传 redis 的安装包，redis-4.0.14.tar.gz
2. 将安装包进行解压缩

   tar -zxf redis-4.0.14.tar.gz
   1

3. 进入 redis 的安装包

   cd redis-4.0.14
   1

4. 使用 make 和 install 进行编译和安装

   make PREFIX=/usr/local/redis/redis01 install
   1

5. 拷贝 redis 配置文件redis.conf到/usr/local/redis/redis01/bin目录中

   cp redis.conf /usr/local/redis/redis01/bin
   1

6. 修改redis.conf配置文件

   port 6379 #redis的端口
   daemonize yes #后台启动redis
   1
   2

7. 将 redis01 复制一份为 redis0

   cd /usr/local/redis
   cp -r redis01 redis02
   1
   2

8. 对 redis02 文件夹中的redis.conf进行修改

   port 6378 #redis的端口
   daemonize yes #后台启动redis
   1
   2

9. 分别启动，即可获取两个 Redis

   ps -ef | grep redis
   1

   使用 Nginx 将请求分发到不同的 Redis 服务器上。

  准备 Tomcat 服务器：

1. 上传 tomcat 的安装包，apache-tomcat-8.5.56.tar.gz
2. 将安装包进行解压缩

tar -zxf apache-tomcat-8.5.56.tar.gz
1

3. 进入 tomcat 的bin目录

cd apache-tomcat-8.5.56/bin
./startup
1
2

  nginx.conf 配置：

stream {
	upstream redisbackend {
		server 10.7.2.207:6379;
		server 10.7.2.207:6378;
	}
	upstream tomcatbackend {
		server 10.7.2.207:8080;
	}
	server {
		listen 81;
		proxy_pass redisbackend;
	}
	server {
		listen 82;
		proxy_pass tomcatbackend;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

参考文献

  【1】https://www.bilibili.com/video/BV1ov41187bq?p=93
  【2】https://kb.cnblogs.com/page/559213/
  【3】https://blog.z0ukun.com/?p=793
  【4】https://mp.weixin.qq.com/s?__biz=Mzg3ODAyNDI0OQ==&mid=2247484047&idx=1&sn=ffce58518ca1e439dad22033a0295f44&chksm=cf1b41d9f86cc8cf97f34f736e7e61c7eae1d5e379abbfde2e074be0c418a2a4302301afdd6d&mpshare=1&scene=23&srcid=&sharer_sharetime=1587997041653&sharer_shareid=6d0541e301a4fa3892dd3e84730e5ada#rd
  【5】http://www.yujujie.cn/shbk/40691.html
  【6】https://www.yisu.com/zixun/22329.html
  【7】https://blog.csdn.net/Kangyucheng/article/details/90673399
  【8】https://blog.51cto.com/jiangxl/5283968