關于nginx，負載均衡是什么？它能給我們的業務帶來什么？怎么去配置它？

User
關于nginx，我還想知道，負載均衡是什么？它能為我的業務帶來什么？怎么去配置它？

Assistant
負載均衡是 Nginx 另一個非常強大的功能，也是構建高可用、高性能應用的關鍵技術之一。我們來詳細了解一下。

1. 什么是負載均衡 (Load Balancing)？

想象一下一個超市只有一個收銀臺，高峰期肯定會排起長隊。負載均衡就像是超市增開了多個收銀臺，并有一個調度員指揮顧客去當前最空閑或下一個可用的收銀臺結賬。

在網絡世界里：

負載均衡 是一種將網絡請求（比如來自用戶瀏覽器的 HTTP 請求）分發到多個后端服務器上的技術。
這些后端服務器都運行著相同的應用程序或服務（比如你的 FastAPI 應用）。
Nginx 可以扮演這個“調度員”的角色，接收所有進來的請求，然后根據一定的策略（算法）將請求轉發給后端服務器集群（也稱為“上游服務器組”或 “Upstream”）中的某一臺服務器。

核心目的：

防止單點過載： 避免所有請求都壓在單一服務器上，導致其性能下降甚至崩潰。
提高處理能力： 多個服務器協同工作，可以處理比單個服務器大得多的并發請求量。
提升可用性： 如果后端集群中的某臺服務器發生故障，負載均衡器可以檢測到并停止向其發送請求，將請求轉發給其他健康的服務器，從而保證服務的持續可用。

2. 負載均衡能為你的業務帶來什么？

為你的 Vue + FastAPI 項目引入 Nginx 負載均衡，可以帶來顯著的好處：

高可用性 (High Availability):
- 這是最重要的好處之一。如果你的 FastAPI 應用部署在多臺服務器上（或者同一臺服務器的多個端口上運行多個實例），當其中一個實例因為維護、更新或意外崩潰而宕機時，Nginx 會自動將新的請求發送給其他健康的實例。用戶幾乎不會察覺到服務中斷（或者中斷時間極短），大大提高了應用的穩定性和可靠性。
提升性能和響應速度:
- 通過將請求分散到多個后端服務器，減輕了單個服務器的壓力。每臺服務器可以更快地處理分配給它的請求，從而縮短用戶的等待時間，提升整體體驗。
更好的可伸縮性 (Scalability):
- 當你的用戶量增長，請求壓力增大時，你不需要去升級單臺服務器的硬件（垂直擴展，成本高且有上限）。你可以簡單地在后端集群中增加更多的應用實例（水平擴展），然后在 Nginx 的 upstream 配置中添加這些新實例即可。Nginx 會自動將負載分配到這些新加入的服務器上，輕松應對流量增長。
簡化維護:
- 你需要更新后端應用版本或進行服務器維護時，可以先將某臺服務器從 Nginx 的負載均衡池中平滑移除（或標記為 down），Nginx 不再向其發送新請求。等現有請求處理完畢后，你就可以安全地對其進行操作，完成后再加回池中。整個過程對用戶是透明的，服務不中斷。

3. 如何配置 Nginx 負載均衡？

配置 Nginx 負載均衡主要涉及兩個部分：upstream 塊和修改 location 塊中的 proxy_pass。

步驟：

準備多個后端實例: 首先，你需要確保你的后端服務（FastAPI 應用）有多個正在運行的實例。這些實例可以：
- 在同一臺服務器的不同端口上運行（例如：127.0.0.1:8080, 127.0.0.1:8081, 127.0.0.1:8082）。
- 在不同的服務器上運行（例如：192.168.1.10:8080, 192.168.1.11:8080）。

定義 upstream 塊:

在 Nginx 配置文件 (nginx.conf 或相關的虛擬主機配置文件) 的 http 上下文內（通常在 server 塊之前），定義一個 upstream 塊。這個塊用來列出所有提供相同服務的后端服務器。
給這個 upstream 塊起一個名字，比如 my_backend_servers 或 api_cluster。

http {# ... 其他 http 配置 ...# 定義后端 API 服務器集群upstream backend_api_servers {# Nginx 會輪流將請求發往這些服務器 (默認 Round Robin 策略)server 120.78.7.226:8080;       # 你的第一個 FastAPI 實例# 假設你在同一臺機器的 8081 端口啟動了第二個實例server 120.78.7.226:8081;# 如果有第三個實例...# server 120.78.7.226:8082;# 如果實例在其他機器上...# server backend_server_ip_2:8080;}server {listen 80;server_name 120.78.7.226 _;root /www/wwwroot/dist;index index.html index.htm;# ... 其他 server 配置 ...# API 請求的 location 塊location /api/ {# 將 proxy_pass 指向 upstream 塊的名稱proxy_pass http://backend_api_servers/; # 注意這里的名稱和 upstream 塊一致，末尾斜杠用于去除 /api/ 前綴# 其他代理設置保持不變或按需添加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 60s;proxy_send_timeout 60s;proxy_read_timeout 60s;}# ... 其他 location 塊 ...}
}

修改 location 塊的 proxy_pass:
- 找到之前處理 API 請求的 location /api/ 塊。
- 將 proxy_pass 指令的值，從指向單個后端服務器地址 (http://120.78.7.226:8080/) 修改為指向你剛剛定義的 upstream 塊的名稱 (http://backend_api_servers/)。 注意： 這里的 http:// 不能省略，并且如果你想讓 Nginx 去掉 /api/ 前綴，目標 upstream 名稱后面仍然需要加上斜杠 /。
選擇負載均衡策略 (可選):
- Nginx 默認使用輪詢 (Round Robin) 策略：按順序將請求依次分配給后端服務器。
- 你可以在 upstream 塊中指定其他策略：
  - least_conn;: 將請求分配給當前活動連接數最少的服務器。適合處理耗時不同的請求。
  - ip_hash;: 根據客戶端的 IP 地址進行哈希計算，確保來自同一客戶端的請求總是被發送到同一臺后端服務器。這對于需要保持會話狀態（Session）但又沒有使用共享 Session 機制的應用很有用。但可能導致負載不均。
  - hash $request_uri consistent; (需要 Nginx 1.7.2+): 基于某個 key (如請求 URI) 進行哈希，consistent 參數保證后端服務器增減時，只有少量 key 的映射會改變。
```
upstream backend_api_servers {least_conn; # 使用最少連接策略server 120.78.7.226:8080;server 120.78.7.226:8081;
}
```
配置健康檢查 (可選但推薦):
- 為了讓 Nginx 能夠自動剔除故障服務器，可以在 server 指令后面添加參數：
  - max_fails=number: 在 fail_timeout 時間內，嘗試連接后端服務器失敗多少次后，就認為該服務器宕機。默認為 1。
  - fail_timeout=time: 服務器被標記為宕機后，多長時間內 Nginx 不會再嘗試向其發送請求。同時也是 max_fails 的統計時間窗口。默認 10 秒。
- Nginx 開源版本只提供被動的健康檢查（即請求失敗時才發現）。Nginx Plus（商業版）或使用第三方模塊可以實現主動健康檢查（定期發送探測請求）。
```
upstream backend_api_servers {server 120.78.7.226:8080 max_fails=3 fail_timeout=30s; # 30秒內失敗3次則標記為宕機30秒server 120.78.7.226:8081 max_fails=3 fail_timeout=30s;
}
```
測試并重載配置:
- 修改完配置后，務必先用 nginx -t 測試語法是否正確。
- 如果測試通過，使用 nginx -s reload (或在寶塔面板點擊重載/重啟) 使新配置生效。