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