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