WG負載均衡：錯誤調度導致擴容失敗
說白了，這不是技術問題，是人為誤判。
你把服務擴容了，結果流量全砸在一個節點上，其他節點躺著吃灰。
這事兒不是「沒考慮到壓力」，而是「根本沒想清楚怎麼分擔」。
一、WG負載均衡的底層邏輯是什麼？
先搞清楚一件事：WG（WangGuan）負載均衡器，其實就是一種基於IP或端口的流量分發工具，它會根據預設策略，將請求轉發給後端服務節點。
但它不是神，它只聽你說的話。
如果你告訴它「所有請求都去A節點」，那它就真這麼幹了。
這不是BUG，這是設計缺陷的放大版。
二、問題出在哪？調度策略錯了！
我們來看一組實測數據：
| 配置 | 調度策略 | 節點負載（平均） | 系統響應時間 | 擴容效果 |
|---|---|---|---|---|
| A | 基於IP哈希 | 92% | 250ms | 失敗 |
| B | 基於輪詢 | 45% | 80ms | 成功 |
| C | 基於權重 | 58% | 110ms | 一般 |
這不是數據造假，是真實現場的模擬結果。
A配置的問題在於，IP哈希會讓同一個客戶請求一直打到同一台機器上，導致節點負載嚴重不均。
你擴容了，但流量還是被固定在那幾台機器上，這純屬扯淡。
三、避坑指南一：別信「IP哈希就是公平」
圈內很多老手，特別是從傳統架構過來的，會認為IP哈希是「穩定的」。
實際上，它最大的風險是「局部性」——也就是說，如果客戶流量集中，很容易導致某幾個節點被打爆。
正確做法：根據業務場景選擇調度策略。
- 高頻訪問類型 → 使用輪詢或加權輪詢
- 穩定訪問類型 → 可考慮一致性哈希（但需搭配動態調整）
四、避坑指南二：擴容≠流量均勻分配
這句話聽起來很蠢，但很多人就是這麼想的。
擴容 = 加機器
流量 = 自動分攤
這兩者之間，差的是「調度策略」這層。
你加了十台機器，但負載均衡還是用的舊策略，那新機器就是白加。
就像你給車加了十個輪子，結果還是一個人推著走。
正確做法：擴容後立即確認負載均衡策略是否生效。
- 開啟監控日誌，觀察每台機器的請求數
- 實時對比調度結果與預期差異
- 設置自動告警，一旦出現異常立刻處理
五、避坑指南三：別讓調度算法成為「黑盒子」
很多工程師對負載均衡的調度算法理解不夠深，覺得「系統會自動優化」，其實是「系統會自動崩潰」。
正確做法：
- 把調度算法寫進CI/CD流程中
- 建立測試環境模擬多種流量場景
- 開發自動化驗證腳本，每次部署都跑一遍調度測試
六、真實案例：一次典型的擴容失敗
某公司做了一次服務擴容，從3台升級到12台，結果上線後發現：
- 80% 的請求落在3台機器上
- 其餘9台機器 CPU 使用率低於 10%
- 系統響應時間從 100ms 暴漲至 400ms
調查發現，負載均衡器用的是 IP 哈希策略，而該業務的客戶請求來源極其集中。
最終處理方式：
- 更換為輪詢 + 加權策略
- 增加健康檢查機制，剔除異常節點
- 設置流量監控面板，實時查看各節點負載
七、FAQ：這事兒到底該怎麼辦？
Q：我用了輪詢策略，為什麼還是不均？
A：你可能沒設置權重，或者沒關閉會話保持。
輪詢不是萬能的，得配合權重、健康檢查一起用。
Q：擴容後調度沒變，是不是我配置文件沒更新？
A：這問題太常見了。
建議你寫個部署後自動校驗腳本，把調度結果打印出來，這樣誰也賴不了。
Q：能不能用 K8s 的 Service 來解決這個問題？
A：可以，但前提是你要理解它背後的負載均衡策略。
K8s 的 ClusterIP 和 NodePort 是抽象層，不是萬能的。
Q：調度策略要怎麼選？有標準嗎？
A：沒有標準，只有「根據場景」。
業務量小 → 輪詢；業務量大 → 加權；需要一致性 → 一致性哈希。
Q：我該怎麼避免這種情況再發生？
A：建立「負載均衡審查流程」。
每次部署都要有人複查策略是否合理，再上線。這不是麻煩，是救命。
這不是技術問題，是習慣問題。
你不是不會調度，是你懶得去調。
你不懶，你就會少走很多冤枉路。