很多人第一次接觸“負載均衡”這個詞腦子里跳出來的第一反應(yīng)就是這不就是多買幾臺服務(wù)器把請求分開處理嘛。聽起來確實簡單就像餐廳客人多了多開幾個窗口一樣。但真到了生產(chǎn)環(huán)境你會發(fā)現(xiàn)事情遠沒有這么簡單——多加一臺服務(wù)器之后流量該怎么分某臺服務(wù)器悄悄掛了請求還會繼續(xù)往它那邊發(fā)嗎同一個用戶剛登錄完下一次請求卻被分到了另一臺機器Session 丟了怎么辦如果只是“加服務(wù)器”就能解決問題那互聯(lián)網(wǎng)公司就不需要專門養(yǎng)一個負責(zé)負載均衡和網(wǎng)關(guān)的團隊了。這篇文章想跟你認真聊一聊負載均衡它到底解決了什么問題核心原理是什么調(diào)度算法怎么選四層和七層有什么區(qū)別以及如何用 Nginx 和 HAProxy 快速搭出一套可用的負載均衡環(huán)境。文章會從概念講到配置再講驗證和排查盡量讓新手也能照著做同時讓有經(jīng)驗的讀者也能有所收獲。1. 負載均衡真正要解決的三個問題如果只給負載均衡下一個定義那就是把一組客戶端請求按照某種策略分發(fā)到多臺后端服務(wù)器上從而提高系統(tǒng)的整體處理能力、可用性和穩(wěn)定性。但這不是重點重點是它到底解決了什么原本讓你頭疼的問題。第一個問題單點壓力。一臺服務(wù)器的處理能力是有上限的。無論是 CPU、內(nèi)存、帶寬還是數(shù)據(jù)庫連接數(shù)總有一個指標會先到瓶頸。當并發(fā)請求超過閾值后響應(yīng)時間會快速惡化甚至直接拒絕服務(wù)。負載均衡把流量分散到多臺服務(wù)器讓每一臺機器都工作在合理水位這是最直觀的價值。第二個問題單點故障。一臺服務(wù)器如果宕機了整個應(yīng)用就不可用了。即便你做了 RAID 磁盤陣列、做了系統(tǒng)備份、做了數(shù)據(jù)定期快照機器硬件故障、機房網(wǎng)絡(luò)抖動、操作系統(tǒng)內(nèi)核異常這些問題依然無法完全避免。負載均衡配合健康檢查機制會自動把故障節(jié)點摘除把流量導(dǎo)到其他正常節(jié)點。用戶幾乎感知不到后端發(fā)生了什么。第三個問題彈性伸縮?；ヂ?lián)網(wǎng)業(yè)務(wù)的流量不是恒定的。上午十點和晚上八點的訪問量可能差好幾倍大促、活動、熱點事件帶來的流量峰值可能是平時的幾十倍。如果按照峰值去采購服務(wù)器平時大部分算力都在閑置如果按均值采購峰值一來就會被打垮。負載均衡讓你可以隨時增加或減少后端節(jié)點擴容時直接把新服務(wù)器加進集群即可縮容時摘除節(jié)點即可整個過程對調(diào)用方透明。所以“負載均衡不就是加臺服務(wù)器”這句話只看到了表面。加服務(wù)器解決的是容量問題負載均衡解決的是在有多臺服務(wù)器之后怎么把流量安全、穩(wěn)定、可控地分出去的問題。沒有負載均衡服務(wù)器加得越多管理成本和故障風(fēng)險反而越高。2. 核心概念與工作原理負載均衡體系里有幾個概念會反復(fù)出現(xiàn)先把它們理清楚。2.1 負載均衡器負載均衡器是流量的“總?cè)肟凇彼型獠空埱笙鹊竭_這里再由它轉(zhuǎn)發(fā)給后端服務(wù)器。它可以是一臺專門的硬件設(shè)備比如 F5 BIG-IP也可以是運行在普通服務(wù)器上的軟件比如 Nginx、HAProxy、LVS還可以是云平臺提供的托管服務(wù)比如阿里云的 SLB、騰訊云的 CLB。負載均衡器本身應(yīng)該是無狀態(tài)的它只負責(zé)轉(zhuǎn)發(fā)不負責(zé)保存業(yè)務(wù)數(shù)據(jù)。2.2 后端服務(wù)器池后端服務(wù)器池就是真正處理業(yè)務(wù)請求的一組服務(wù)器也叫真實服務(wù)器組。負載均衡器會維護一張后端節(jié)點列表根據(jù)調(diào)度算法從列表里選一臺服務(wù)器然后把請求轉(zhuǎn)發(fā)過去。在云環(huán)境里這些節(jié)點通常是云服務(wù)器 ECS在自建機房它們就是物理機或虛擬機。2.3 虛擬服務(wù)地址對外提供服務(wù)的統(tǒng)一入口地址通常是一個虛擬 IPVIP?？蛻舳酥恍枰L問這個地址不需要關(guān)心背后到底有多少臺服務(wù)器、這些服務(wù)器在哪個機房、IP 是什么。對于客戶端來說后端是一個黑盒它只知道訪問 VIP 就能獲得服務(wù)。2.4 健康檢查這是負載均衡最容易忽略、卻最關(guān)鍵的能力。如果某一臺后端服務(wù)器已經(jīng)宕機或者應(yīng)用進程掛掉了負載均衡器必須能發(fā)現(xiàn)并且不把新請求轉(zhuǎn)發(fā)過去。常見做法是定時向后端節(jié)點發(fā)送探測請求比如 TCP 端口探測、HTTP 接口探測連續(xù)失敗 N 次后標記為異常連續(xù)成功 M 次后再恢復(fù)。2.5 會話保持HTTP 協(xié)議本身是無狀態(tài)的但業(yè)務(wù)往往有狀態(tài)。用戶登錄后產(chǎn)生的 Session 在服務(wù)器 A 上如果下一次請求被轉(zhuǎn)發(fā)到服務(wù)器 BB 上找不到這個 Session用戶就會被踢回登錄頁。會話保持就是為了解決這個問題把同一個用戶的請求盡可能固定到同一臺后端節(jié)點上。2.6 四層與七層負載均衡這是面試?？碱}也是選型時必須搞清楚的問題。類型工作層級轉(zhuǎn)發(fā)依據(jù)典型代表性能能力四層負載均衡傳輸層基于 IP 和端口IP TCP/UDP 端口LVS、HAProxyTCP 模式、云 SLB 四層極高轉(zhuǎn)發(fā)延遲低不解析應(yīng)用層協(xié)議無法做域名、URL 路由七層負載均衡應(yīng)用層基于 HTTP 等協(xié)議內(nèi)容URL、域名、Header、Cookie 等Nginx、HAProxyHTTP 模式、云 SLB 七層相對四層略低可以做更精細的路由支持 SSL 卸載、緩存、重寫等從架構(gòu)發(fā)展來看很多大型系統(tǒng)會在不同層級同時使用兩種負載均衡最外層用四層做流量接入和分發(fā)負責(zé)扛大流量內(nèi)部再用七層做業(yè)務(wù)路由比如按域名或 URL 轉(zhuǎn)發(fā)到不同的微服務(wù)集群。3. 調(diào)度算法流量是怎么分出去的負載均衡器拿到一個請求后究竟該把它給誰這個決策規(guī)則就是調(diào)度算法。不同算法有不同適用場景沒有絕對的好壞只有合不合適。3.1 輪詢與加權(quán)輪詢輪詢是最基礎(chǔ)的算法請求輪流分給后端節(jié)點A → B → C → A → B → C。如果后端服務(wù)器配置一樣權(quán)重一樣輪詢能保證流量均勻。加權(quán)輪詢則給每臺服務(wù)器設(shè)置一個權(quán)重比如新買的機器性能好權(quán)重設(shè)為 3舊機器設(shè)為 1那么新機器分到的請求大約是舊機器的三倍。3.2 最小連接數(shù)負載均衡器會記錄每臺后端節(jié)點的當前連接數(shù)每次把請求分給連接數(shù)最少的節(jié)點。這種算法適合請求處理時間差異比較大的場景。如果一個請求要處理 5 秒另一個只要 10 毫秒按照輪詢硬分處理慢的那臺會不斷堆積請求而最小連接數(shù)可以動態(tài)避開繁忙節(jié)點。3.3 IP HASH 與一致性哈希IP HASH 根據(jù)客戶端 IP 計算哈希值同一個 IP 的請求總是落在同一臺后端節(jié)點上。這種算法可以天然實現(xiàn)會話保持但缺點是如果節(jié)點數(shù)量變化大量請求會被重新映射。一致性哈希則是將節(jié)點和請求都映射到同一個哈希環(huán)上節(jié)點增減時只會影響環(huán)上很小范圍內(nèi)的請求更適用于緩存類服務(wù)。3.4 調(diào)度算法選型建議場景推薦算法原因后端服務(wù)器配置相同請求處理時間接近輪詢簡單可靠流量均勻服務(wù)器性能不一致加權(quán)輪詢按性能比例分配流量請求處理時間差異大最小連接數(shù)避免請求堆積到慢節(jié)點有 Session 保存需求未做 Session 共享IP HASH同 IP 落到同節(jié)點緩存類、狀態(tài)類服務(wù)一致性哈希節(jié)點變化影響范圍小4. 負載均衡在真實架構(gòu)中的位置負載均衡不是一個孤立組件它往往貫穿整個請求鏈路。理解它在架構(gòu)里的位置才能明白不同層的負載均衡分別解決什么問題。在典型的分層架構(gòu)中最外層是 DNS 解析然后是負載均衡器再往后是應(yīng)用服務(wù)器集群最后是數(shù)據(jù)庫、緩存和消息隊列。DNS 本身也可以做最簡單的負載均衡也就是一個域名解析到多個 IP瀏覽器隨機選一個訪問。這種方式實現(xiàn)簡單但粒度太粗——DNS 服務(wù)器不知道哪臺后端機器掛了也不會根據(jù)負載情況動態(tài)調(diào)整解析結(jié)果。真正意義上的負載均衡要更精細。云上架構(gòu)最常用的是云負載均衡實例綁定多臺 ECS對公網(wǎng)暴露一個 VIP再通過 HTTP 監(jiān)聽器把請求轉(zhuǎn)發(fā)到后端的 Tomcat、Spring Boot、Nginx 或容器服務(wù)里。如果是 Kubernetes 環(huán)境Service 的 LoadBalancer 類型和 Ingress 控制器也在承擔(dān)不同層級的負載均衡職責(zé)。自建機房的老牌方案則更傾向于 LVS Nginx 的組合LVS 在最前面做四層轉(zhuǎn)發(fā)扛住海量并發(fā)Nginx 在后端做七層路由、SSL 卸載和靜態(tài)資源處理。再往后應(yīng)用服務(wù)之間如果有相互調(diào)用還會通過 RPC 框架自帶的負載均衡能力做服務(wù)發(fā)現(xiàn)和流量分配比如 Dubbo、Spring Cloud LoadBalancer這就是更上一層的客戶端負載均衡了。從“加服務(wù)器”往上走你會發(fā)現(xiàn)真正拉開系統(tǒng)吞吐量的恰恰是這套從 DNS 到四層、七層再到服務(wù)間的流量調(diào)度體系。5. 實操使用 Nginx 搭建七層負載均衡Nginx 是目前使用最廣泛的七層負載均衡軟件之一它既能當 Web 服務(wù)器也能做反向代理和負載均衡。下面用一個最小示例演示如何把請求分發(fā)到兩臺后端服務(wù)上。5.1 環(huán)境準備本文的操作在 Linux 環(huán)境下演示你可以在云服務(wù)器或本地虛擬機中完成。需要準備一臺安裝了 CentOS 7/8、Ubuntu 20.04/22.04 等系統(tǒng)的服務(wù)器作為負載均衡節(jié)點。兩臺后端服務(wù)節(jié)點可以用真實服務(wù)器也可以在本地用不同端口模擬。Nginx 版本建議使用官方主線版本或系統(tǒng)倉庫版本版本不是關(guān)鍵配置思路是通用的。如果你的系統(tǒng)沒有安裝 NginxCentOS 使用下面命令安裝sudo yum install -y nginxUbuntu 使用下面命令sudo apt update sudo apt install -y nginx檢查安裝是否成功nginx -v出現(xiàn)版本號即說明安裝成功。5.2 修改 Nginx 配置Nginx 的主配置文件位于/etc/nginx/nginx.conf也可以在/etc/nginx/conf.d/下新增獨立配置文件。推薦使用獨立文件的方式避免改動主配置帶來風(fēng)險。這里新增一個配置# 文件路徑/etc/nginx/conf.d/load_balance.conf upstream backend_servers { server 192.168.1.101:8080 weight1 max_fails2 fail_timeout10s; server 192.168.1.102:8080 weight1 max_fails2 fail_timeout10s; } server { listen 80; server_name demo.example.com; location / { proxy_pass http://backend_servers; 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; } }這段配置的核心是upstream塊。它定義了一個名為backend_servers的后端服務(wù)器組里面有兩臺后端節(jié)點。weight1表示權(quán)重相同max_fails2表示如果連續(xù)失敗 2 次將該節(jié)點標記為不可用fail_timeout10s表示在 10 秒內(nèi)統(tǒng)計失敗次數(shù)并且節(jié)點被標記為不可用后經(jīng)過 10 秒再重新探測。server塊則是定義 Nginx 監(jiān)聽 80 端口當請求的域名匹配demo.example.com時把請求反向代理到backend_servers這個服務(wù)器組。注意proxy_set_header這幾行它們把客戶端真實 IP 和原始協(xié)議信息傳遞給后端否則后端日志里看到的全是 Nginx 的 IP排查問題時會非常痛苦。5.3 檢查并重載配置修改完配置后一定要先檢查語法再重新加載配置。這一點很重要生產(chǎn)環(huán)境中因為配置錯誤直接重啟 Nginx 導(dǎo)致服務(wù)中斷的例子非常多。nginx -t看到syntax is ok和test is successful后執(zhí)行nginx -s reloadreload會平滑地重新加載配置不中斷已有連接。5.4 模擬后端服務(wù)驗證為了驗證負載均衡是否生效可以在兩臺后端節(jié)點上用簡單的 HTTP 服務(wù)來測試。假設(shè)后端節(jié)點 IP 分別為 192.168.1.101 和 192.168.1.102端口都是 8080它們分別返回不同的標識。在兩臺后端節(jié)點上分別執(zhí)行# 節(jié)點 1 while true; do echo -e HTTP/1.1 200 OK\nContent-Type: text/plain\nContent-Length: 7\n\nNode-101 | nc -l -p 8080; done# 節(jié)點 2 while true; do echo -e HTTP/1.1 200 OK\nContent-Type: text/plain\nContent-Length: 7\n\nNode-102 | nc -l -p 8080; done然后在負載均衡節(jié)點上多次請求curl http://127.0.0.1/連續(xù)執(zhí)行幾次如果看到輸出在Node-101和Node-102之間交替出現(xiàn)說明輪詢生效了。6. 實操使用 HAProxy 搭建四層負載均衡有些場景下你并不需要解析 HTTP 協(xié)議只想基于 TCP 做流量分發(fā)比如轉(zhuǎn)發(fā) MySQL、Redis、MQ 等中間件流量。這時 HAProxy 是一個很好的選擇它在四層轉(zhuǎn)發(fā)性能和穩(wěn)定性上都表現(xiàn)優(yōu)秀。6.1 安裝 HAProxyCentOS 安裝命令sudo yum install -y haproxyUbuntu 安裝命令sudo apt install -y haproxy查看版本haproxy -v6.2 配置 TCP 負載均衡HAProxy 的主配置位于/etc/haproxy/haproxy.cfg。修改配置前建議先備份原文件cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak下面是一個把 TCP 流量分發(fā)到兩臺 Redis 節(jié)點的示例# 文件路徑/etc/haproxy/haproxy.cfg global log /dev/log local0 maxconn 4096 user haproxy group haproxy daemon defaults log global mode tcp option tcplog option dontlognull retries 3 timeout connect 5000 timeout client 50000 timeout server 50000 frontend redis_front bind *:6379 default_backend redis_backend backend redis_backend balance roundrobin server redis1 192.168.1.201:6379 check inter 3s fall 3 rise 2 server redis2 192.168.1.202:6379 check inter 3s fall 3 rise 2這里的mode tcp表示 HAProxy 工作在四層不解析應(yīng)用層協(xié)議直接轉(zhuǎn)發(fā)原始 TCP 流量。frontend redis_front定義了外部入口監(jiān)聽所有網(wǎng)卡的 6379 端口。backend redis_backend定義后端節(jié)點池balance roundrobin表示采用輪詢算法。check表示啟用健康檢查inter 3s表示每 3 秒探測一次fall 3表示連續(xù) 3 次失敗后標記為下線rise 2表示連續(xù) 2 次成功后再恢復(fù)上線。6.3 啟動并驗證systemctl restart haproxy systemctl status haproxy確認狀態(tài)為active (running)后用 Redis 客戶端連接負載均衡入口進行驗證redis-cli -h 127.0.0.1 -p 6379 ping返回PONG說明轉(zhuǎn)發(fā)成功。為了確認流量確實分發(fā)到了兩臺后端可以分別在 redis1 和 redis2 上查看連接情況或者觀察 HAProxy 的統(tǒng)計頁面這個我們在下一節(jié)說明。6.4 開啟 HAProxy 監(jiān)控頁面HAProxy 內(nèi)置了一個監(jiān)控頁面可以通過網(wǎng)頁查看后端節(jié)點的健康狀態(tài)和連接數(shù)。在haproxy.cfg的defaults或單獨listen中添加listen stats bind *:8888 mode http stats enable stats uri /stats stats realm HAProxy\ Statistics stats auth admin:admin123 stats refresh 5s保存并重載配置haproxy -c -f /etc/haproxy/haproxy.cfg systemctl reload haproxy瀏覽器訪問http://負載均衡節(jié)點IP:8888/stats輸入用戶名admin、密碼admin123就能看到兩臺 Redis 后端節(jié)點的狀態(tài)、連接數(shù)、健康檢查結(jié)果等實時數(shù)據(jù)。這個頁面在排障時非常有用。7. 運行結(jié)果與效果驗證配置寫好了服務(wù)也啟動了接下來要驗證負載均衡真的按預(yù)期工作并且能正確應(yīng)對故障。7.1 驗證流量分發(fā)對于 Nginx 七層負載均衡可以通過循環(huán)請求觀察返回內(nèi)容來驗證輪詢效果for i in {1..10}; do curl -s http://127.0.0.1/; echo; done預(yù)期輸出會在后端兩個節(jié)點之間交替。如果始終只能訪問到某一個節(jié)點說明另一個節(jié)點沒有進入可用狀態(tài)首先檢查后端服務(wù)是否正常監(jiān)聽端口以及負載均衡器到后端節(jié)點之間的網(wǎng)絡(luò)是否連通。7.2 驗證健康檢查模擬后端故障是最重要的驗證手段。把某一臺后端節(jié)點上的服務(wù)停掉比如在節(jié)點 1 上停止剛才的 netcat 進程然后在負載均衡節(jié)點上繼續(xù)循環(huán)請求curl -s http://127.0.0.1/這時所有請求應(yīng)該都被轉(zhuǎn)發(fā)到節(jié)點 2不會出現(xiàn)請求失敗。再把節(jié)點 1 服務(wù)恢復(fù)一段時間后流量應(yīng)該自動恢復(fù)到兩臺節(jié)點。這里真正的價值在于故障切換是由負載均衡器自動完成的不需要人工修改任何配置。這也就是“加一臺服務(wù)器”之外負載均衡帶來的穩(wěn)定性收益。7.3 驗證會話保持如果使用ip_hash算法同一個客戶端 IP 的請求會固定落在同一臺后端節(jié)點上。在 Nginx 配置upstream中修改upstream backend_servers { ip_hash; server 192.168.1.101:8080; server 192.168.1.102:8080; }重載后再次請求你會發(fā)現(xiàn)所有請求都落在了同一臺節(jié)點上。這在 Session 沒有外置到 Redis/數(shù)據(jù)庫的場景下非常有用。8. 常見問題與排查思路負載均衡在實際使用中會遇到各種問題我把最常見的幾種整理成了一張排查表方便你對照處理。問題現(xiàn)象可能原因排查方式解決方案后端日志中拿不到客戶端真實 IP未設(shè)置 X-Forwarded-For 等 Header檢查 Nginx 配置中 proxy_set_header 字段補充 X-Real-IP、X-Forwarded-For 配置后端改為讀取對應(yīng) Header某個節(jié)點始終沒有流量節(jié)點被健康檢查標記為故障查看健康檢查狀態(tài)、檢查節(jié)點端口是否監(jiān)聽、應(yīng)用是否存活排查后端應(yīng)用和網(wǎng)絡(luò)恢復(fù)服務(wù)后等待自動拉回部分用戶登錄狀態(tài)丟失未配置會話保持或 Session 未共享檢查負載均衡算法和 Session 存儲位置短期用 ip_hash 解決長期建議 Session 外置到 Redis負載均衡器自身 CPU 飆升并發(fā)超出單機處理能力或 TLS 頻繁握手查看監(jiān)控指標、分析訪問日志擴展為多級負載均衡或啟用 SSL 會話復(fù)用、升級硬件出現(xiàn)請求超時后端響應(yīng)慢或超時時間配置過短查看后端應(yīng)用訪問日志和壓測報告適當增大 timeout檢查后端應(yīng)用是否存在慢查詢、死鎖配置重載后服務(wù)中斷配置語法錯誤導(dǎo)致重啟失敗先執(zhí)行 nginx -t / haproxy -c 檢查語法始終先檢查語法再 reload保留上一版可用配置后端節(jié)點頻繁被摘除又恢復(fù)健康檢查路徑設(shè)置錯誤或健康檢查頻率過高查看負載均衡日志和節(jié)點應(yīng)用日志正確配置健康檢查接口適當調(diào)整失敗/成功閾值加權(quán)輪詢不符合預(yù)期權(quán)重配置不合理或節(jié)點性能差異過大查看后端節(jié)點處理能力和負載情況基于壓測數(shù)據(jù)調(diào)整權(quán)重這里特別提醒一點排查問題時要先分清楚“入口通不通”和“后端通不通”。入口不通檢查負載均衡器的監(jiān)聽端口和防火墻后端不通檢查后端服務(wù)的監(jiān)聽狀態(tài)和負載均衡器到后端的網(wǎng)絡(luò)鏈路。不要一上來就懷疑配置先看鏈路再看配置效率會高很多。9. 最佳實踐與工程建議如果要把負載均衡真正用好在生產(chǎn)環(huán)境有幾個原則值得堅持。9.1 配置管理要謹慎所有變更都遵循“先備份 → 改配置 → 語法檢查 → 灰度加載 → 觀察日志 → 穩(wěn)定后全量生效”的流程。很多線上事故并非功能設(shè)計有問題而是變更時圖省事跳過了檢查步驟。在修改 Nginx 時nginx -t只需要一秒值得養(yǎng)成習(xí)慣。也可以用版本管理工具保存配置回滾時能快速切換到上一版本。9.2 健康檢查要講究不要簡單地依賴 TCP 端口探測因為端口通并不代表應(yīng)用可用。比如 Tomcat 可能端口還在監(jiān)聽但線程池已經(jīng)打滿此時請求進來依然會超時。更可靠的做法是通過健康檢查接口反饋應(yīng)用真實狀態(tài)例如/actuator/health或自定義的/health接口接口內(nèi)部檢查依賴的基礎(chǔ)設(shè)施數(shù)據(jù)庫連接、緩存連接、磁盤空間等再以 HTTP 狀態(tài)碼告知負載均衡器。健康檢查的頻率也不要太低3 秒一次比較常見具體頻率需要和業(yè)務(wù)容忍度做平衡。9.3 會話狀態(tài)盡量外置不要在應(yīng)用本地保存 Session而是統(tǒng)一放到 Redis 等外部存儲應(yīng)用節(jié)點保持無狀態(tài)。這樣即使任意一臺服務(wù)器宕機、即使負載均衡器把請求分到任意節(jié)點都能拿到同一份會話數(shù)據(jù)。真正做到無狀態(tài)之后擴容縮容才不受約束負載均衡的彈性價值才能真正發(fā)揮出來。9.4 日志和監(jiān)控不可缺失負載均衡器是流量的咽喉必須監(jiān)控它的連接數(shù)、轉(zhuǎn)發(fā)延遲、后端節(jié)點健康狀態(tài)、錯誤率等指標。至少要做到有統(tǒng)一的日志采集日志里能追蹤到客戶端 IP、轉(zhuǎn)發(fā)的后端節(jié)點、響應(yīng)狀態(tài)碼有基礎(chǔ)告警當某臺后端節(jié)點頻繁被摘除或整體錯誤率升高時能及時通知到人。沒有監(jiān)控的負載均衡出問題時就像在黑暗里找東西。9.5 容量規(guī)劃要留余量負載均衡器本身也有處理上限。一臺 Nginx 能扛住數(shù)萬并發(fā)但 TLS 握手、URL 路由、日志寫入都會消耗資源。線上建議讓負載均衡器的峰值負載不超過其能力的 50% 到 60%留出一半余量給突發(fā)流量和故障轉(zhuǎn)移場景。如果單機負載均衡器成為瓶頸優(yōu)先考慮云平臺自帶的負載均衡服務(wù)或者使用 LVS Nginx 的多級架構(gòu)。9.6 安全邊界要清晰負載均衡器是公網(wǎng)進入內(nèi)網(wǎng)的第一道關(guān)口必須收斂暴露面。管理端口不要對公網(wǎng)開放盡量只允許運維網(wǎng)段訪問。如果負載均衡器需要對外提供 HTTPS 服務(wù)證書管理要規(guī)范并配置合理的 TLS 版本。同時防止后端節(jié)點被公網(wǎng)直接訪問后端只允許負載均衡器的 IP 訪問這樣可以避免繞過負載均衡直接打到后端的風(fēng)險。文中使用 HAProxy 監(jiān)控頁時設(shè)置的密碼只是一個示例生產(chǎn)環(huán)境應(yīng)當使用強密碼并限制訪問來源不要直接暴露在公網(wǎng)。關(guān)于負載均衡的核心問題其實可以歸納成一句話它解決的不是“服務(wù)器不夠用”而是“有了多臺服務(wù)器之后怎么讓它們像一個整體一樣對外提供穩(wěn)定、高可用的服務(wù)”。理解了這一點再看各種算法和配置思路就會清晰很多。下一步建議你親手做一次實驗準備兩臺后端服務(wù)用一個負載均衡器把流量分出去然后手動停掉其中一臺觀察請求是否自動切換、恢復(fù)后是否自動收回。這個過程會把健康檢查、調(diào)度算法、會話保持的概念全部串起來比看十篇文章都管用。