Docker Nginx 负载均衡搭建（服务宕机-配置高可用） - 附（Python案例，其它语言同理）

本文主要是介绍Docker Nginx 负载均衡搭建（服务宕机-配置高可用） - 附（Python案例，其它语言同理），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一 . 概要

1. 什么是负载均衡

2. 负载均衡有哪些优势？

（1）应用程序可用性

（2）应用程序可扩展性

（3）应用程序安全

（4）应用程序性能

3 . Nginx负载均衡调度策略

二 . 搭建案例

1. 创建项目目录

2. 创建三个py文件，启动三个服务

3. 编写 Nginx.conf

4. 编写 Dockerfile

三 . 镜像打包运行

四 . 个人小结

一 . 概要

1. 什么是负载均衡

负载均衡是在支持应用程序的资源池中平均分配网络流量的一种方法。现代应用程序必须同时处理数百万用户，并以快速、可靠的方式将正确的文本、视频、图像和其他数据返回给每个用户。为了处理如此高的流量，大多数应用程序都有许多资源服务器，它们之间包含很多重复数据。负载均衡器是位于用户与服务器组之间的设备，充当不可见的协调者，确保均等使用所有资源服务器。

2. 负载均衡有哪些优势？

目的：提升吞吐率, 提升请求性能, 提⾼高容灾

负载均衡可以定向和控制应用程序服务器与其访客或客户端之间的互联网流量。因此，它可提高应用程序的可用性、可扩展性、安全性和性能。

（1）应用程序可用性

服务器故障或维护可能会增加应用程序停机时间，使访客无法访问您的应用程序。负载均衡器可以通过以下方式提高您的系统的容错能力：自动检测服务器问题并将客户端流量重定向到可用服务器。您可以使用负载均衡来简化以下任务：

运行应用程序服务器维护或升级而无需使应用程序停机
为备份站点提供自动灾难恢复
执行运行状况检查并防止出现可能导致停机的问题

（2）应用程序可扩展性

您可以使用负载均衡器在多个服务器之间智能地定向网络流量。您的应用程序可以处理数千个客户端请求，因为负载均衡会执行以下操作：

防止任何一台服务器出现流量瓶颈
预测应用程序流量，以便您可以在需要时添加或移除不同服务器
为您的系统增加冗余度，使您可以放心扩展

（3）应用程序安全

负载均衡器具有多项内置的安全功能，可为您的互联网应用程序的安全保驾护航。它们是应对分布式拒绝服务攻击的有用工具，在这种攻击中，攻击者会用数百万个并发请求淹没应用程序服务器，从而导致服务器故障。负载均衡器还可以执行以下操作：

监控流量并阻止恶意内容
将攻击流量自动重定向到多个后端服务器，以最大限度减少影响
通过一组网络防火墙路由流量，以提高安全性

（4）应用程序性能

负载均衡器通过增加响应时间和减少网络延迟来提高应用程序性能。它们可以执行诸如以下几项关键任务：

在服务器之间平均分配负载以提高应用程序性能
将客户端请求重定向到地理位置较近的服务器以减少延迟
确保物理和虚拟计算资源的可靠性和性能

3 . Nginx负载均衡调度策略

调度算法	概述
轮询	逐一轮询，默认方式
weight	加权轮询，weight越大，分配的几率越高
ip_hash	按照访问IP的hash结果分配，会导致来自同一IP的请求访问固定的一个后台服务器
fair	按后端服务器的响应时间来分配请求，响应时间短的优先分配。
url_hash	按照访问URL的hash结果分配

1、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。upstream backserver {server 192.168.0.14;server 192.168.0.15;
}

2、权重 weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。upstream backserver {server 192.168.0.14 weight=3;server 192.168.0.15 weight=7;
}

3、ip_hash（ IP绑定）
上述方式存在一个问题就是说，在负载均衡系统中，假如用户在某台服务器上登录了，那么该用户第二次请求的时候，因为我们是负载均衡系统，每次请求都会重新定位到服务器集群中的某一个，那么已经登录某一个服务器的用户再重新定位到另一个服务器，其登录信息将会丢失，这样显然是不妥的。我们可以采用ip_hash指令解决这个问题，如果客户已经访问了某个服务器，当用户再次访问时，会将该请求通过哈希算法，自动定位到该服务器。每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。upstream backserver {ip_hash;server 192.168.0.14:88;server 192.168.0.15:80;
}

4、fair（第三方插件）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。upstream backserver {server server1;server server2;fair;
}

5、url_hash（第三方插件）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。upstream backserver {server squid1:3128;server squid2:3128;hash $request_uri;hash_method crc32;
}

二 . 搭建案例

1. 创建项目目录

mkdir disaster_recovery

2. 创建三个py文件，启动三个服务

main1.py ，main2.py，main3.py 端口号分别为 4000,4001,4002

from flask_cors import CORS
from flask import Response, jsonify, Flask, request# 建立flask实例
app = Flask(__name__)
# 注册CORS, "/*" 允许访问所有api
CORS(app, resources=r'/*')# 获取 Flask 应用的根路径
root_path = app.root_path# 解决中文乱码
app.config['JSON_AS_ASCII'] = False@app.route('/', methods=['GET', 'POST', 'DELETE', 'PUT', 'CATCH'])
def Start():print('启动成功！')return jsonify({'code': 200,'msg':'测试'})@app.route('/start1', methods=['GET', 'POST', 'DELETE', 'PUT', 'CATCH'])
def Start1():print('启动成功Start1！')return jsonify({'code': 200,'msg':'测试'})# 调用实例对象
if __name__ == '__main__':app.run(debug=True,host='0.0.0.0', port=4000)

3. 编写 Nginx.conf

这里Nginx监听80端口，反向代理到本地系统（也可以使用其他服务器ip及端口）的4000，4001，4002端口

这里我们使用负载均衡方案：权重，如果有其他需求，可以按照其他的方案进行修改：

events {worker_connections 1024;
}http {upstream servers_list {server 192.168.14.93:4000 weight=3;server 192.168.14.93:4001 weight=5;server 192.168.14.93:4002 weight=2;}server {listen 80;location / {proxy_pass http://servers_list;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Proto $scheme;# 服务宕机-配置proxy_connect_timeout 1;}}
}# worker_connections，单个工作进程可以允许同时建立外部连接的数量  数字越大，能同时处理的连接越多
# 1.默认：worker_connections: 1024
# 2.调大：worker_connections: 100000，（调大到10万连接）
# upstream servers_list { ... }: 定义了一个名为backend的上游服务器组，包含了要负载均衡的后端服务器列表。
# server { ... }: 定义了一个NGINX服务器块。
# listen 80;: 监听80端口。
# location / { ... }: 定义了一个用于处理所有请求的位置块。
# proxy_pass http://servers_list;: 将请求转发到名为backend的上游服务器组中定义的服务器上，实现负载均衡。
# proxy_set_header: 设置HTTP请求头，确保后端服务器能够获取到客户端的真实IP等信息。
# 在这个配置中，NGINX会将来自客户端的请求负载均衡地转发到backend1.example.com、backend2.example.com和backend3.example.com中的一个。

proxy_connect_timeout 1;

nginx提供了宕机容错机制，当一个后端服务器由于服务器故障、网络问题等原因不能提供服务时， nginx可以通过配置超时，超过超时时间以后，则跳过当前服务器，请求下一台服务器
在nginx.conf文件中配置 proxy_connect_timeout 1 连接超过1s 则跳过当前轮询

4. 编写 Dockerfile

FROM yankovg/python3.8.2-ubuntu18.04# 设置时区为中国标准时间
ENV TZ=Asia/Shanghai# 安装NGINX
RUN apt-get update && apt-get install -y nginx# 配置NGINX
COPY nginx.conf /etc/nginx/nginx.conf# 暴露端口
EXPOSE 80# 启动NGINX
CMD ["nginx", "-g", "daemon off;"]

这里基础镜像选择预装了Python3.8的Ubuntu18，兼具了小体积和可扩展的特性，添加apt-get的安装源后，安装Nginx。

最后，将nginx.conf拷贝到对应的配置路径中，启动Nginx服务。

三 . 镜像打包运行

在项目根目录的终端内运行命令打包镜像：

docker build -t . disaster_recovery_task

首次编译等待小会，进行下载

[+] Building 0.5s (8/8) FINISHED                                                                         docker:default=> [internal] load .dockerignore                                                                                  0.0s=> => transferring context: 2B                                                                                    0.0s=> [internal] load build definition from Dockerfile                                                               0.0s=> => transferring dockerfile: 1.25kB                                                                             0.0s=> [internal] load metadata for docker.io/yankovg/python3.8.2-ubuntu18.04:latest                                  0.5s=> [1/3] FROM docker.io/yankovg/python3.8.2-ubuntu18.04@sha256:811ad1ba536c1bd2854a42b5d6655fa9609dce1370a6b6d48  0.0s=> [internal] load build context                                                                                  0.0s=> => transferring context: 1.58kB                                                                                0.0s=> CACHED [2/3] RUN apt-get update && apt-get install -y nginx                                                    0.0s=> [3/3] COPY nginx.conf /etc/nginx/nginx.conf                                                                    0.0s=> exporting to image                                                                                             0.0s=> => exporting layers                                                                                            0.0s=> => writing image sha256:72c9a8f86c0c14d77a51d5542b7877c2d5e8b12c72a12a4b7708f7e15263ed05                       0.0s=> => naming to docker.io/library/disaster_recovery_task                                                          0.0sWhat's Next?View summary of image vulnerabilities and recommendations → docker scout quickview

打包成功后，运行命令查看镜像信息：

docker images

可以看到镜像总大小不到1g:

REPOSITORY                          TAG              IMAGE ID       CREATED              SIZE
disaster_recovery_task              latest           72c9a8f86c0c   About a minute ago   784MB

接着让我们来启动容器

docker run  -d  -p 81:80 --name disaster_recovery_task  disaster_recovery_task

显示正在运行

CONTAINER ID   IMAGE                         COMMAND                   CREATED          STATUS          PORTSNAMES
2925cdd6a0f8   disaster_recovery_task        "nginx -g 'daemon of…"   33 seconds ago   Up 32 seconds   0.0.0.0:81->80/tcp       disaster_recovery_task

此时我们打开浏览器访问 http://127.0.0.1:81