5-1：技术选型_负载均衡

一、负载均衡

负载均衡的关键在于任务分配

应用程序执行相同的处理逻辑，如何分配任务，不让其中的一台服务器压力过大，也不让另一台服务器压力过小，需要有策略进行合理分配

当前互联网环境下，负载均衡应用于基于 HTTP 协议的 Web 应用，即 Web 应用集群

关键点：

1、HTTP 请求如何分发到应用服务器，即负载均衡服务器如何将 HTTP 请求转发到应用服务器

2、HTTP 请求分配到哪一台应用服务器之上

注意点：

Web 应用服务器 IP 地址不对外暴露

二、HTTP 重定向负载均衡

重定向的负载均衡服务器，响应返回重定向的 IP 地址，为了能够实现用户请求地址的重定向，应用服务器的地址必须对外暴露，否则用户是无法正常请求应用服务器进行业务处理

基于 HTTP 重定向原理，各种语言都可以编写负载均衡服务器，对于 Java 而言，直接使用 servlet，接受 request 请求，然后，根据算法，new 一个新的 response，response 包含重定向新的应用服务器的 IP 地址

缺点：

1、用户的一次 HTTP 请求变成了两次，效率比较低，并且，HTTP 协议是一种较重的应用层协议，每一次请求都要进行重定向

2、安全性差，由于应用服务器地址对外暴露，容易遭受黑客攻击，应当把应用服务器地址变为内网，不对外暴露，降低被攻击的风险

三、DNS 负载均衡

DNS，Domain Name Serve，通过域名解析，将域名转换为 ip 地址，用户才能够去正确访问实际的应用服务器，进行业务处理

关键点：

同一个域名，解析出不同的 ip 地址，以便进行任务分配

大型互联网应用使用 DNS 负载均衡，再配置负载均衡服务器，实现两层负载均衡

优缺点：

实际情况是 DNS 服务器不会让用户每次都请求两次，第一次访问域名的时候，返回实际应该访问的 ip 地址，然后进行本地缓存，只要本地缓存未超时，之后的访问直接通过 IP 地址访问

应用服务器地址必须对外暴露，同样具有安全性的问题

四、反向代理负载均衡

反向代理服务器具有数据缓存的功能，用户访问反向代理服务器，如果反向代理服务器缓存具有用户的内容，则直接返回，否则，再去请求应用服务器

应用服务器数量较少（十几台服务器），加上一台反向代理负载均衡服务器，应用于规模不够大的系统，Nginx 是反向代理负载均衡典型中间件

缺点：

反向代理代理 HTTP 请求，需要转发整个 HTTP 请求，用户端发起 HTTP 请求，通过 TCP 协议，到达反向代理服务器，TCP 协议包逐一发送给反向代理服务器，只有完整 HTTP 的所有 TCP 协议包齐全了，才会转发 HTTP 请求（HTTP 运行于 TCP 之上）

同样，响应的时候，也是同样的原理，HTTP 协议包含的内容很多，内容很大很重，所以，反向代理服务器效率就显得很低

五、IP 负载均衡

基于反向代理负载均衡的缺点，不去构建 HTTP 的数据包，不解析 HTTP 协议，直接基于更底层的数据包，拿到数据包就直接进行请求转发

通过修改 IP 地址，实现负载均衡，用户发起 HTTP 请求，访问 IP 负载均衡服务器，一个 HTTP 请求包含多个 TCP/IP 协议包，一个 TCP/IP 协议包到达 IP 负载均衡服务器，IP 负载均衡服务器不管 TCP 协议包是属于哪个 HTTP，每一个 TCP 协议包都会包含请求的源地址和目标地址，源地址就是用户的 IP 地址，目标地址就是负载均衡服务器的地址，直接修改 TCP 协议包里请求的目标地址和源地址，目标地址改成应用服务器的 IP 地址，源地址改为 IP 负载均衡服务器的 IP 地址，随后，再重新转发出去，应用服务器检查请求的目标地址是自己的，就接收 TCP 协议包，多个协议包到达应用服务器，齐全之后，就把多个 IP 的数据包，构建出来一个 HTTP 的协议的数据包，最终进行 HTTP 请求的处理

响应则是请求的逆过程，响应也是反过来将源地址和目标地址变更，将应用服务器响应的源地址变为 IP 负载均衡的地址，将应用服务器响应的目标地址更改为用户请求的 IP 地址，IP 负载均衡服务器具有映射表，能够将用户的 HTTP 请求和应用服务器的响应地址映射正确

相对于反向代理负载均衡服务器，性能更好，压力更小，源于需要处理的数据包小，不需要构建完整 HTTP 请求后转发，这样就可以处理更大规模的应用服务器集群

缺点：

请求的数据包往往不会很大，而响应的数据包会非常大，会包含图片、页面、文字等等内容，包含的协议包会有几百个，极有可能因为带宽的问题，导致负载均衡服务器性能下降

六、数据链路层负载均衡

为了解决 IP 负载均衡响应数据包过大造成的问题，提出了改进方案，就是数据链路层负载均衡服务器

TCP/IP 协议分为四层，最上层为 TCP，其次为 IP，再次为数据链路层，最后则是物理层。数据链路层，主要记录网卡的 MAC 地址

通过修改 mac 地址，实现负载均衡，负载均衡服务器和应用服务器使用了同一个虚拟的 IP 地址，差异在于唯一的 MAC 地址不同，故，直接修改 MAC 地址，可以实现负载均衡

原理就是请求分发，响应则是直接返回给用户，减少了负载均衡服务器处理响应的过程，又叫三角模式

大型互联网应用主要使用链路层负载均衡，实践中用的最多，性能也是最好

单机性能痛点

痛点

单服务器的性能始终有一个天花板，无论如何优化，都无法突破这个性能瓶颈，通常而言，根据不同服务器的性能差别，支持的并发量范围大约从百级别到万级别

解决方案

为了提高系统整体的处理性能，需要设计高性能集群服务器，通过增加更多的服务器提升系统整体的性能

关键点

计算特点：无论哪台服务器，相同输入，经过逻辑处理，得到相同的输出

高性能集群服务器的关键点就落在了如何设计一个任务分配器，如何选择一个合适的任务分配算法，将计算任务分配到多台服务器之上

负载均衡

一、负载均衡

为了提高系统性能，应对高并发的情况，负载均衡是必然要做的选择。

第一点，进行技术选型，如何选择合适的负载均衡，在 DNS 负载均衡、硬件负载均衡、软件负载均衡中权衡

基于用户并发量不够大，QPS 小于 5 万，故直接选型 Nginx

二、安装运行

（1）直接学习安装教程

大多数的 Linux 环境，都需要先安装 PCRE、C++、SSL 等软件，安装 PCRE 等过程，就需要把其他的软件一并安装，然后才能进行编译安装 Nginx 程序

1）安装编译工具及库文件

yum -y install make zlib zlib-devel gcc-c++ libtool openssl openssl-devel

yum 负责自动安装软件的指令

由于购买的是阿里云的服务，以为会自动安装了相应的软件，为了验证，是否安装，故学习了判断是否安装软件的 linux 指令

1、rpm 包安装的，可以用 rpm -qa 看到，如果要查找某软件包是否安装，用 rpm -qa | grep “软件或者包的名字”

2、以 deb 包安装的，可以用 dpkg -l 看到。如果是查找指定软件包，用 dpkg -l | grep “软件或者包的名字”

3、yum 方法安装的，可以用 yum list installed 查找，如果是查找指定包，用 yum list installed | grep “软件名或者包名”

以查看 yum 安装的 zlib 为例：

sudo 用于赋权给普通用户进行 linux 指令执行

sudo yum install -y gcc-c++

2）安装 Nginx

没有安装完全所有软件就直接安装 Nginx，输入指令./configure，便出现了以下错误

configure: error: Invalid C++ compiler or C++ compiler flags

在安装 PCRE 软件时可能会报这个错误，这是因为系统缺失 gcc-c++ 库。CentOS 下（我这里的环境是 CentOS 7）root 超级管理员用户执行以下命令，非 root 超级管理员前面加上 sudo 用以获取权限

执行。

这也就是为什么大多数的 Nginx 安装教程都会教人一开始先安装各种软件，包括 PCRE，这是用于 Nginx 重写功能

经过了安装对应预装软件之后，便对 Nginx 包解压，并配置、编译、安装，使用了指令 tar，这是因为 Nginx 包以 tar.gz

使用了最新的稳定版本，1.18

wget 指令获取下载文件

tar -zxvf ...tar.gz

解压在/usr/local/src/目录下

然后进行

./configure --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-pcre=/usr/local/src/pcre-8.44

./configure --sbin-path=/usr/local/nginx/nginx \

--conf-path=/usr/local/nginx/nginx.conf \

--pid-path=/usr/local/nginx/nginx.pid \

--with-http_gzip_static_module \

--with-http_stub_status_module \

--with-file-aio \

--with-http_realip_module \

--with-http_ssl_module \

--with-pcre=/usr/local/src/pcre-8.44 \

--with-zlib=/usr/local/src/zlib-1.2.11 \

--with-openssl=/usr/local/src/openssl-1.1.1g

prefix 是安装目录

with-pcre 是 pcre 的安装目录

由于采用 SSL 模式，故之前为什么要求安装 OpenSSL 软件

然后就是

make && make install

最后完成安装

如何判断安装是否成功，输入指令判断 Nginx 的版本就可以得出

/usr/local/nginx/sbin/nginx -v

[root@iZ8vb1u65wyksmkaxh8dflZ /]# /usr/local/nginx/sbin/nginx -v

nginx version: nginx/1.18.0

3）运行

只是为了先进行运行，所以，没有进行配置，直接跳过了这一步

直接进行启动，使用以下命令，也就是安装目录下的可执行文件启动

/usr/local/nginx/sbin/nginx

输入这个指令没有任何信息

为了验证是否真正运行，查看了系统是否运行 Nginx，使用如下命令

ps -ef | grep nginx

具有进程，说明正在运行

但是，无法远程访问，寻找各种原因

学习到了配置文件是否正确指令

/usr/local/webserver/nginx/sbin/nginx -t

[root@iZ8vb1u65wyksmkaxh8dflZ ~]# /usr/local/nginx/sbin/nginx -t

nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok

nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful

说明配置文件没有问题

又担心端口是不是默认的 80

故使用 vim 进行编辑查看

发现是 80

vim /usr/local/nginx/conf/nginx.conf

这里顺便学习了 vim 编辑器的快捷键

下一页：ctrl + f

上一页：ctrl + b

可以参考以下文章

https://www.runoob.com/linux/linux-vim.html

退出 vim，使用 Esc，然后加上“:”，如下

写入并退出：:wq

不写入退出：:q

强制写入并退出：:wq!

然后，查看是否防火墙开启，学了防火墙的指令

systemctl 是系统工具的指令

查看防火墙的状态

systemctl status firewalld

暂时关闭防火墙

systemctl stop firewalld

永久关闭防火墙

systemctl disable firewalld

查看防火墙状态

[root@iZ8vb1u65wyksmkaxh8dflZ ~]# systemctl status firewalld

● firewalld.service - firewalld - dynamic firewall daemon

Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)

Active: inactive (dead)

Docs: man:firewalld(1)

说明防火墙没有问题

然后，思考了以下，或许是没有为服务器开放端口，也就是没有加入安全组

然后，到阿里云控制台进行设备

最后，发现实际上，是已经加入了安全组，并且这个安全组的 80 端口是允许访问的

到了这里，再次进行远程访问，还是不行，没有出现 Nginx 正常访问的页面

然后，就去查看阿里云的帮助，查案是否端口被监控

netstat -an | grep 80

没有出现以下信息

tcp6 0 0 :::80 :::* LISTEN

说明端口没有被监听

然后又尝试远程访问

telnet 127.0.0.1 80

依然拒绝访问

这里需要说明

远程访问的指令

curl http://ip:80

通过浏览器输入地址，依然无法访问

依然拒绝访问

最后，实在想不出哪里出问题了

看了下机器，原来 nginx 部署在 5 服务器，但是我一直在 3 服务器上操作，以为安装在了 3 服务器上

然后，我把 IP 地址重新换成了 5 服务器的地址，一切就通了

到了这里，实际上，就是细心的问题，不要粗心大意

负载均衡典型架构

负载均衡典型架构

实际环境的负载均衡架构，基于 DNS 负载均衡、硬件负载均衡、软件负载均衡的优缺点，组合使用，组合原则如下：

DNS 负载均衡用于实现地理级别的负载均衡

硬件负载均衡用于实现集群级别的负载均衡

软件负载均衡用于实现机器级别的负载均衡

注意点

负载均衡架构基于组合原则，但也需要考虑实际情况，如果并发访问量并未达到百万以上，没有必要使用 DNS 负载均衡实现地理级别负载均衡以及硬件负载均衡实现集群级别负载均衡

架构示例

负载均衡分类

负载均衡分类

（1）DNS 负载均衡

作用：实现地理级别的负载均衡

实现原理：DNS 解析同一个域名，根据请求用户地址，返回不同的 IP 地址

（2）硬件负载均衡

通过单独的硬件设备来实现负载均衡功能

主要使用的负载均衡硬件设备有 F5、A10，支持百万级别并发量，F5 并发范围从 200 万/秒到 800 万/秒

（3）软件负载均衡

通过软件实现负载均衡，主要有 Nginx、LVS

Nginx 是软件的 7 层负载均衡，支持 HTTP、E-MAIL 等协议，Ngxin 支持万级并发，一般 Linux 服务器装一个 Nginx 大概支持 5 万/秒并发量

LVS 是 Linux 内核的 4 层负载均衡，与协议无关，所有应用都可以使用，LVS 支持十万级并发，可达 80 万/秒

负载均衡算法

负载均衡算法

（1）轮询

所有请求被依次分发到每个应用服务器上

适用场景：适合于所有服务器硬件都相同的场景

缺点：

只要服务器在运行，运行状态是不关注的

无法根据服务器的配置差异进行任务分配

（2）加权轮询

根据应用服务器硬件性能，在轮询的基础上，配置相应的权重，将请求分发到每个服务器上，高性能的服务器分配更多请求

目的：解决不同服务器处理能力有差异的问题

缺点：无法根据服务器的状态差异进行任务分配

（3）随机

请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用，因为好的随机数本身就很均衡。如果应用服务器硬件配置不同，也可以很容易的使用加权随机算法

（4）负载最低优先

负载均衡系统将任务分配给当前负载最低的服务器

负载指标

LVS 4 层网络负载均衡设备，以“连接数”来判断服务器的状态

Nginx 7 层网络负载系统，以“HTTP 请求数”来判断服务器状态

CPU 密集型系统，以“CPU 负载”来衡量系统压力

I/O 密集型，可以以“I/O 负载”来衡量系统压力

优点

能够感知服务器的状态

缺点

复杂度上升，算法设计本身好坏决定系统性能

（5）性能最优类

优先将任务分配给处理速度最快的服务器，通过这种方式达到最快响应客户端的目的

（6）Hash

负载均衡系统根据任务中的某些关键信息进行 Hash 运算，将相同 Hash 值的请求分配到同一台服务器上

分类

源地址 Hash、目标地址 Hash、session id hash、用户 ID Hash

问题集合

问题一

设计一个日活跃用户（DAU） 1000 万的论坛的负载均衡集群，你的方案是什么？设计理由是什么？

解决思路

（1）流量评估

1000 万 DAU，进而得出每秒并发请求量约等于 116

考虑每个用户的操作次数，假定次数为 10，进而得出 QPS 为 1160

考虑峰值是平均值的倍数，假定倍数为 10，进而得出 QPS 为 11600

考虑静态资源、图片资源、服务拆分等，流量放大，假定倍数为 10，进而得出 QPS 为 116000

（2）容量规划

考虑高可用和异地多活，放大 2 倍，得出 QPS 为 232000

考虑未来一段时间增长，方法 1.5 倍，得出 QPS 为 348000

（3）方案设计

负载均衡架构设计方案为二级导流

第一级，确定集群，扩展优先，选择 Haproxy/LVS，稳定性能并且预算支持可以选择 F5

第二级，确定机器，使用 Nginx + KeepAlived

扩展

DUA 日活跃用户转换为 PV，每个用户平均访问页面数，进而得出 PV 值

问题二

如何计算下一级设备数量？

解决思路

以 100W 并发量为例，使用一台 F5，下一级是 LVS，则相当于 1 F5 = 2 LVS，再往下一级，使用 Nginx，即 1 LVS = 10 Nginx，应用服务器相当于并发量 5000 QPS，故 1 Nginx = 10 应用服务器

问题三

响应时间能否决定并发量？

思路

计算充足的情况下，响应时间不受并发量影响，按照正常的应用系统业务处理 100ms 计算，应用系统处理业务需要消耗计算资源，即 CPU、内存等，这才是决定响应时间和并发量的关键。随着并发量不断增加，系统分配应用程序处理业务的计算资源增加，但未达到计算机瓶颈，故响应时间依旧维持 100ms。超过计算机瓶颈时，并发量增加，响应时间增长。

由此可见，并发量和响应时间最终是由计算机硬件资源决定的。

问题四

微信抢红包的高并发架构，应该采取什么样的负载均衡算法？谈谈你的分析和理解

解决思路

抢红包的业务过程主要分为发红包、抢红包

对于发红包而言，需要做到的就是快，那么，直接适用轮询算法即可，对于抢红包而言，需要根据红包 ID 明确不同的红包，故采用 Hash 算法的方式实现