華為雲國際企業帳號 華為雲國際站ECS伺服器如何配置負載均衡

第一章：為什麼需要負載均衡

只要你的服務開始變得「多人同時在用」，你遲早會遇到同一個問題：單一伺服器扛不住。CPU 飆高、記憶體壓力升溫、連線排隊、甚至超時回應，最後用戶體驗變差，商業風險也跟著上來。負載均衡的作用，就是把入口流量分散到多台可用的 ECS 伺服器，讓資源使用更均衡，並在其中一台異常時自動把流量轉走。

在華為雲國際站的實作中，你通常會把「入口」與「後端」拆開來看：入口負責接收外部請求，後端承接實際業務邏輯。你可以先從最常見的情況開始：HTTP/HTTPS 服務（例如網站、API）需要高可用與可擴展。當你把負載均衡做好，接下來的擴容就會變得更簡單：新增一台 ECS，把它加入後端，健康檢查通過後，流量自然就會分到它上面。

第二章：先釐清你的需求

在進入操作前，請你先回答幾個問題。這些問題看似瑣碎，但會直接影響你後續的設定方式，避免白做或反覆調參。

2.1 你要保護的是哪種流量？

華為雲國際企業帳號 多數情境是 HTTP/HTTPS。也可能是 WebSocket、gRPC、TCP 服務，甚至是非標準協定。不同協定對監聽器與轉發規則的設定方式不同。確定「協定類型」後，你才知道該選擇哪種監聽器與端口。

2.2 後端服務是什麼形式？

後端可能是：

• 純無狀態（Stateless）：例如前端網站、無需依賴本機記憶的 API。
• 有狀態（Stateful）：例如需要會話保持（Session）、或依賴本地快取。

若是無狀態，負載均衡通常可以直接採用輪詢或加權輪詢等策略；若是有狀態，你需要考慮會話保持，或把狀態放到共享存儲/快取中，避免不同 ECS 之間會話失效。

2.3 你期望的高可用程度？

最基本是「一台掛了，另一台立刻接手」。更進階的是跨可用區的容災，並搭配自動擴縮。若你暫時只做單區高可用，也要確保健康檢查與重試策略合理。

第三章：整體架構與關鍵元件

在華為雲國際站上，你可把負載均衡配置理解成三個核心元件：

• 監聽器（Listener）：外部請求進來後，用什麼協定、哪些端口接收。
• 後端池（Backend / Target）：你要把流量導向哪些 ECS 實例。
• 健康檢查（Health Check）：用固定方式判斷後端是否可用，決定流量是否導入。

華為雲國際企業帳號 再加上一些必要設定：轉發規則（Rule/Policy）、權重（若需要）、以及必要的安全與網路通訊（安全組、路由等）。

第四章：準備 ECS 實例與網路

負載均衡配置再漂亮，後端如果網路不通，整套系統也跑不起來。這一章先把底層基礎做好，後面才不會一直卡在「健康檢查失敗」或「轉發連不上」。

4.1 建議至少兩台 ECS

華為雲國際企業帳號 為了體驗真正的負載均衡效果，建議準備至少兩台後端 ECS，並且在同一虛擬私有雲（VPC）內。若你計畫做更高可用，也可考慮不同可用區，但前提是你的網路與負載均衡支援該拓撲。

4.2 確認後端服務已正常啟動

每台 ECS 上要確認以下項目：

• 應用服務已啟動並監聽正確的端口（例如 80 或 443、或自定義 8080）。
• 應用能回應健康檢查路徑（例如 /healthz）。
• 程式返回碼合理（2xx 為健康，或依你設定的判斷邏輯）。

如果你沒有現成的健康端點，先加一個簡單的 HTTP endpoint，回傳固定內容與狀態碼。不要用耗時操作或依賴外部服務太多，否則健康檢查會變得「假健康」或「不穩定」。

4.3 調整安全組（Security Group）規則

通常你需要允許：

• 負載均衡對後端的連線（例如負載均衡的來源到 ECS 的應用端口）。
• 若是私網轉發，確保 VPC 內路由允許。

很多人卡住是因為安全組規則只開了公網來源，卻沒放行負載均衡的內部來源。建議你在設計時就把「來源」與「目標端口」對齊，並記錄清楚需要哪些規則。

4.4 觀察後端端口連通性

你可以在負載均衡所在環境或同一 VPC 中的測試機上，嘗試對後端 ECS 的應用端口發送請求。若連不上，先修網路與安全組，再談健康檢查。

第五章：建立負載均衡實例（國際站操作思路）

接下來進入你真正需要的設定。由於介面可能隨平台版本略有調整，下文以「概念 + 你要填的內容」的方式描述，讓你即使在 UI 位置不同也能快速對應。

5.1 選擇負載均衡類型與網路範圍

你需要選擇負載均衡類型（常見為應用型 HTTP/HTTPS）。同時選擇部署的網路範圍，通常在 VPC 或子網（Subnet）中進行配置。若你希望對外提供服務，就要能連到公網入口或至少可被你的使用者路由到。

5.2 設定監聽器（Listener）

監聽器要決定三件事：

• 協定：HTTP 或 HTTPS。
• 端口：例如 80/443 或自訂端口。
• 轉發行為：把請求導向哪個後端池、用什麼規則。

若你使用 HTTPS，通常你還需要憑證（Certificate）。你可使用平台提供的憑證管理，或是匯入你自己的憑證。注意：憑證配置錯誤會直接造成連線失敗或瀏覽器顯示風險。

5.3 建立後端池並加入 ECS 實例

後端池的重點是「目標地址與目標端口」。加入 ECS 時，你一般會填：

• 後端實例 ID 或其描述
• 後端服務端口（例如 80 或 8080）
• 權重（若你要用加權輪詢）

若你的應用只在某個端口提供服務，請務必保持一致。最常見的錯誤是：監聽器轉發到的後端端口與應用實際端口不一致，導致健康檢查失敗或偶發連線重置。

第六章：健康檢查怎麼設定才算「真的健康」

健康檢查是負載均衡能否穩定運作的關鍵。你可以把它想成：負載均衡每隔一段時間，會問後端一句話「你還行嗎？」後端若回答得不符合規則，就被暫停接收流量。

6.1 健康檢查使用什麼方式

常見有 HTTP（對特定路徑）、TCP（只要端口可連就算健康）、以及其他更細緻的探測方式。對於 Web 服務，建議使用 HTTP 健康檢查，因為 TCP 只檢查「能連上」不代表應用真正可用。

6.2 健康路徑與返回碼

華為雲國際企業帳號 你需要一個專用路徑，例如：

• /healthz（回傳 200）
• /ready（回傳 200 才算就緒）

你可以設定期望狀態碼（例如 200-399）。如果你的應用在某些情況會返回 503（例如依賴服務故障），健康檢查可以把它視為不健康，讓流量自動避開。

6.3 間隔、超時與容忍次數

這部分很多人直接用預設，結果是：後端偶爾重啟或短暫慢，負載均衡就把它判定為不健康，流量來回抖動。

建議你根據應用特性調整：

• 華為雲國際企業帳號 間隔（Interval）：越小越敏感，但可能產生更多探測流量。
• 超時（Timeout）：避免網路抖動導致誤判。
• 健康/不健康閾值（Healthy/Unhealthy threshold）：連續成功或失敗多少次才切換狀態。

如果你的應用啟動比較慢，可以適當放寬閾值，或在部署後先觀察再調整。

6.4 在部署階段避免「誤傷」

如果你正在發版，後端可能會短時間變慢或回 5xx。負載均衡會根據健康檢查結果做切換。更好的做法是：先準備健康端點具備「就緒判斷」，在應用尚未就緒前回傳非健康狀態；或採用灰度發布思路，把新版本部署到部分後端，避免全量抖動。

第七章：轉發規則與負載分配策略

健康檢查通過後，負載均衡還要決定「怎麼分」。這裡主要是負載均衡演算法與轉發規則。

7.1 常見分配策略

• 輪詢：請求依順序分配，最直觀。
• 加權輪詢：不同後端權重不同，適合實例規格不一致。
• 最少連線：偏向把請求導向當前壓力較低的後端。

若你的後端規格一致且應用是無狀態，輪詢通常就足夠。若有明顯差異（例如某台更快、或緩慢但暫時還在跑），加權輪詢或最少連線更合適。

7.2 轉發是否需要改寫路徑或保持原 Host

華為雲國際企業帳號 某些應用依賴 Host header 或特定路徑。例如後端需要知道是訪問哪個網域。你要確認負載均衡是否保持原始 Host，或需要你在轉發規則中調整 header。

華為雲國際企業帳號 另外，如果你使用多個服務共享同一入口，可能需要根據路徑（Path）或主機名（Host）做不同轉發。這時就會涉及到多條轉發規則（Rule）。設計時避免規則重疊與優先級混亂，否則容易出現「看似進了系統但卻被錯誤服務處理」。

第八章：會話與狀態處理（很多人忽略的坑）

一旦你的應用不是無狀態，負載均衡的「分配策略」就可能影響功能正確性。典型問題包括：登入後偶爾失效、上傳流程斷線、或只在特定請求序列可用。

8.1 如果應用依賴 Session

常見的做法是：

• 把 Session 存到共享位置（例如 Redis 或資料庫），讓任何後端都能讀到同一份狀態。
• 或使用會話保持（Sticky Session），讓同一用戶的請求盡量落在同一台 ECS。

如果你做的是中大型系統，我更推薦共享 Session 的方式，因為它在後端擴縮、故障切換時更穩定。Sticky Session 也能用，但要理解它對故障切換不一定友善：一台掛了，會話自然也得重建。

8.2 WebSocket 與長連線

對於 WebSocket，負載均衡需要能維持連線並正確處理超時。你要確認後端是否支持同一連線持續使用，並調整合理的 idle timeout。否則就會出現「連上了但很快斷」的惱人問題。

第九章：安全與權限不要只看功能

負載均衡通常是入口，一旦設定疏漏，風險會被放大。至少要做以下幾件事。

9.1 憑證與 TLS 版本

如果你提供 HTTPS，憑證要確保有效且域名匹配。TLS 版本與加密套件要符合你的合規需求，避免使用老舊或容易被拒的配置。

9.2 限制管理面與健康檢查來源

華為雲國際企業帳號 管理介面通常不應該暴露到公網。健康檢查的來源也最好限定在負載均衡所用的內部網段或特定來源規則。

9.3 後端最小權限

如果你的 ECS 需要存取資料庫、物件儲存或其他資源，請使用最小權限的 IAM 設定。不要因為「先跑起來」就把權限放到過寬，等流量上來才發現資安問題。

第十章：上線前的驗證清單

很多事故不是出在設定本身，而是出在沒有做驗證。你可以照下面的順序快速自測。

10.1 後端逐台驗證

• 直接訪問每台 ECS 的應用端口與健康端點。
• 華為雲國際企業帳號 確認回應狀態碼符合負載均衡健康檢查條件。

10.2 負載均衡驗證健康狀態

• 確認每台後端是否被標記為 Healthy。
• 若顯示 Unhealthy，先看健康檢查失敗原因（路徑、端口、超時、回應碼）。

10.3 模擬故障

你可以有計畫地暫停其中一台後端服務（或讓健康端點回非健康碼），觀察：

• 負載均衡是否會在閾值時間後把它移出。
• 其他後端是否承接流量。
• 恢復後是否能重新加入。

10.4 壓測與觀察指標

不要只測「能不能打開」，還要測「能撐多久」。在壓測期間觀察：

• 後端 CPU/記憶體是否暴衝。
• 錯誤率是否上升（5xx、超時）。
• 連線是否有明顯飄移或重置。

如果你的應用在高負載下回應時間拉長，健康檢查也可能需要重新調整，避免把其錯誤判定為不健康。

第十一章：常見問題與排查思路

下面列一些在 ECS + 負載均衡場景最常見的問題。你遇到類似現象時，不要急著猜，按邏輯逐步排查。

11.1 健康檢查一直失敗（Unhealthy）

可能原因：

• 健康檢查路徑不存在或回應碼不符合預期。
• 後端服務端口不一致（負載均衡轉發到錯端口）。
• 安全組未放行負載均衡來源。
• 後端回應太慢，超時造成誤判。

排查順序建議：

• 逐台 ECS 直接測健康路徑與端口。
• 檢查安全組來源與目標。
• 查看健康檢查的 timeout/threshold 參數。

11.2 可以健康檢查，但外部仍無法訪問

這種情況通常是入口到監聽器設定有問題：

• 監聽器端口與你實際訪問的端口不同。
• HTTPS 憑證與域名不匹配。
• 轉發規則優先級錯誤，導致請求被導到非預期後端或錯誤路徑。

你可以先在瀏覽器或測試工具確認：實際連線用的是哪個協定、哪個端口。再檢查監聽器與規則。

11.3 流量沒有分散到多台後端

可能原因：

• 只有一台後端是 Healthy，其餘都被判定不健康。
• 負載分配策略或權重設定不合理。
• 應用層需要會話保持，造成固定落點，但你誤以為沒有分散。

建議：先確認健康狀態，再用應用日誌或後端識別信息觀察請求分布。

11.4 偶發超時或 502/504

可能原因：

• 後端忙碌導致回應時間超出負載均衡容忍。
• 應用依賴外部服務（例如資料庫）延遲，造成鏈路拖慢。
• DNS 或內部解析異常（若你的後端有額外依賴）。

處理方式通常是：先針對後端性能與錯誤率定位，再調整超時參數或優化應用。

第十二章：把配置做成可擴展的流程

負載均衡的價值不只是「分流」，更是「讓你後續可以快速擴容」。如果你的流程每次加機都要重做一遍設定，那擴展就會變得痛苦。你可以用更工程化的方式管理：

• 建立一致的 ECS 配置模板（同樣的作業系統基線、同樣的部署方式）。
• 把健康端點固定命名，保證每台後端都能被同一套健康檢查探測。
• 應用層盡量做到無狀態，或把狀態放到共享元件。
• 記錄轉發規則與端口映射，避免人為失誤。

當你遵循這些原則，下一次增加兩台 ECS，只需要把它們加入後端池並等待健康檢查通過即可。整體服務的擴展效率就會顯著提升。

結語：把「能用」變成「穩定」

在華為雲國際站上用 ECS 配置負載均衡，本質上是把入口、後端與健康判斷串成一套閉環。當你把健康檢查路徑、端口映射、安全組規則與監聽器轉發規則一次對齊，系統就會以可預期的方式工作。後續你只要持續關注應用回應時間、錯誤率與資源飽和度，就能讓負載均衡的「穩定」變成真正的穩定。

如果你願意，下一步你可以告訴我你的具體場景：你是 HTTP 還是 HTTPS？後端應用在哪個端口？有沒有需要會話保持？我可以依照你的情況把監聽器、健康檢查與轉發規則的建議參數整理成一份可直接照做的清單。