1. 负载均衡概述

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

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

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

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

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

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

2.1 负载均衡的作用

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

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

2.2.1 用户手动选择

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

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 的流量是由哪台服务器处理的,后续这个连接的所有流量都同样转发到同一台服务器处理:

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

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

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

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

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

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

3. Nginx七层负载均衡

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

3.1 Nginx七层负载均衡的指令

3.1.1 upstream指令

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

语法 upstream name {…}
默认值
位置 http

3.1.1 server指令

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

语法 server name [paramerters]
默认值
位置 upstream

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


  服务端设置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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
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;
}
}

3.3 负载均衡状态

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

状态 概述
down 当前的 server 暂时不参与负载均衡
backup 预留的备份服务器
max_fails 允许请求失败的次数
fail_timeout 经过 max_fails 失败后, 服务暂停时间
max_conns 限制最大的接收连接数

3.3.1 down

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

1
2
3
4
5
6
7
8
9
10
11
12
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;
}
}

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

3.3.2 backup

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

1
2
3
4
5
6
7
8
9
10
11
12
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;
}
}

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

  • 查询防火墙中指定的端口是否开放:
    1
    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
  • --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 秒。

1
2
3
4
5
6
7
8
9
10
11
12
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;
}
}

3.4 Nginx负载均衡策略

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

算法名称 说明
轮询 默认方式
weight 权重方式
ip_hash 依据ip分配方式
least_conn 依据最少连接方式
url_hash 依据URL分配方式
fair 依据响应时间方式

3.4.1 轮询

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

1
2
3
4
5
6
7
8
9
10
11
12
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;
}
}

3.4.2 weight加权(加权轮询)

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

1
2
3
4
5
6
7
8
9
10
11
12
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;
}
}

3.4.3 ip_hash

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

语法 ip_hash
默认值
位置 upstream
1
2
3
4
5
6
7
8
9
10
11
12
13
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;
}
}

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

3.4.4 least_conn

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

1
2
3
4
5
6
7
8
9
10
11
12
13
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;
}
}

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

3.4.5 url_hash

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

1
2
3
4
5
6
7
8
9
10
11
12
13
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;
}
}

3.4.6 fair

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

1
2
3
4
5
6
7
8
9
10
11
12
13
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;
}
}

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

  1. 下载nginx-upstream-fair模块
    1
    2
    下载地址为:
    https://github.com/gnosek/nginx-upstream-fair
  2. 将下载的文件上传到服务器并进行解压缩
    1
    unzip nginx-upstream-fair-master.zip
  3. 重命名资源
    1
    mv nginx-upstream-fair-master fair
  4. 使用./configure命令将资源添加到 Nginx 模块中
    1
    ./configure --add-module=/root/fair
  5. 编译
    1
    make
    编译可能会出现如下错误,ngx_http_upstream_srv_conf_t结构中缺少default_port

    解决方案:
    在 Nginx 的源码中src/http/ngx_http_upstream.h,找到ngx_http_upstream_srv_conf_s,在模块中添加添加default_port属性:
    1
    in_port_t default_port

    然后再进行 make
  6. 将 sbin 目录下的 nginx 进行备份
    1
    mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginxold
  7. 将安装目录下的 objs 中的 nginx 拷贝到 sbin 目录
    1
    2
    cd objs
    cp nginx /usr/local/nginx/sbin
  8. 更新 Nginx
    1
    2
    cd ../
    make upgrade
  9. 编译测试使用 Nginx

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

4. 负载均衡案例

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

1
2
3
4
5
6
7
8
9
10
11
12
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;
}
}

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

1
2
3
4
5
6
7
8
9
10
11
12
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;
}
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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;
}
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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;
}
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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;
}
}

5. Nginx四层负载均衡

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

5.1 Nginx四层负载均衡的指令

5.1.1 stream指令

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

语法 stream { … }
默认值
位置 main

5.1.2 upstream指令

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

5.2 Nginx四层负载均衡的案例


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

  1. 上传 redis 的安装包,redis-4.0.14.tar.gz
  2. 将安装包进行解压缩
    1
    tar -zxf redis-4.0.14.tar.gz
  3. 进入 redis 的安装包
    1
    cd redis-4.0.14
  4. 使用 make 和 install 进行编译和安装
    1
    make PREFIX=/usr/local/redis/redis01 install
  5. 拷贝 redis 配置文件redis.conf/usr/local/redis/redis01/bin目录中
    1
    cp redis.conf /usr/local/redis/redis01/bin
  6. 修改redis.conf配置文件
    1
    2
    port 6379 #redis的端口
    daemonize yes #后台启动redis
  7. 将 redis01 复制一份为 redis0
    1
    2
    cd /usr/local/redis
    cp -r redis01 redis02
  8. 对 redis02 文件夹中的redis.conf进行修改
    1
    2
    port 6378 #redis的端口
    daemonize yes #后台启动redis
  9. 分别启动,即可获取两个 Redis
    1
    ps -ef | grep redis
    使用 Nginx 将请求分发到不同的 Redis 服务器上。

  准备 Tomcat 服务器:

  1. 上传 tomcat 的安装包,apache-tomcat-8.5.56.tar.gz
  2. 将安装包进行解压缩
1
tar -zxf apache-tomcat-8.5.56.tar.gz
  1. 进入 tomcat 的bin目录
1
2
cd apache-tomcat-8.5.56/bin
./startup

  nginx.conf 配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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】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