Azure國際帳號服務 香港微軟雲伺服器負載均衡設定：利用Azure Load Balancer應對高流量

第一章：為什麼香港的高流量更需要「穩定」而不只是「快」

在香港這種高密度網路環境下，企業上雲常見的成長路徑是：先把服務跑起來，再逐步把流量放大。問題在於，流量放大往往不是線性增長，而是伴隨活動、促銷、節假日、促發性新聞或外部平台轉介的「突刺」。當你只用單一虛擬機或缺乏合理分流策略，就會出現幾種很典型的痛點：延遲飆升、連線被重置、健康檢查誤判導致錯誤流量被導到不健康節點、或是重試風暴把系統拖進更深的故障循環。

負載均衡的價值不在於讓你「看到吞吐量很漂亮」，而在於把風險變成可控。當你把流量交給 Load Balancer，並且讓它用健康探測持續判斷後端節點狀態，你的系統就能在節點暫時故障或資源緊張時，仍保持服務可用性。這種可用性在高流量時段尤為重要，因為用戶體驗通常由「前幾百毫秒的反應」決定，任何中斷都會被迅速放大成投訴與流失。

本文聚焦在 Azure Load Balancer 的典型設定方式。讀完後，你應該能夠根據服務型態（HTTP/HTTPS 或其他協定）、流量模式（突刺或持續）、以及後端部署形式（VM、VMSS、容器或混合）來做出合理選擇，並落地到可運維的設定清單。

第二章：先釐清需求，再選擇正確的負載均衡類型

在開始設定之前，先做三個決策：你要不要對外提供服務？你的流量是 TCP 層還是需要應用層能力？你希望它支援公網入口還是僅內部網路？這些問題會直接影響你採用的 Load Balancer 類型與規則設計。

2.1 公網入口 vs 內部入口

如果你的服務需要被互聯網用戶直接訪問（例如網站、API 服務），通常會選擇面向公網的負載均衡。若你服務只需供內部系統呼叫，例如內部後台或內部微服務間通信，則偏向使用內部型負載均衡（ILB）。兩者在配置上最大差異通常在前端配置、路由方式以及配合的網路安全策略。

2.2 Basic Load Balancer 與 Standard Load Balancer 的取捨

Azure 生態裡常見的選擇是 Basic 與 Standard。實務上，你需要思考兩件事：功能與可運維性（例如健康探測行為、擴展能力、與更細的安全配置選項）以及與其他服務（例如 VM Scale Sets、Application Gateway 或防火牆）的整合路徑。若你的目標是「高流量下更穩定」而不是「先把流量導出去」，我會建議把重點放在 Standard，因為它能提供更一致的網路行為與更完整的安全考量空間。

2.3 你到底需要 L4 還是 L7

Load Balancer 主要是 L4 層（傳輸層）能力：依協定、埠號與連線資訊分配到後端。若你需要依照 URL 路徑、Host header、或做更複雜的應用層轉發與 WAF，通常會考慮 Application Gateway 或更上層方案。但即便是 L4，你仍可以透過正確的規則、健康探測與會話處理，達到高流量情境下很扎實的效果。

第三章：香港區域部署的網路現實：延遲、路由與可用性

既然標題聚焦「香港」，實際落地時你必須面對幾個現實：一是用戶來源可能跨境，二是你的後端服務可能依賴不同的資料庫或儲存服務，三是網路路徑與 DNS 解析可能帶來不可預期的抖動。

因此，在你設定 Load Balancer 之前，請先確保：虛擬網路（VNet）、子網（subnet）、路由表（UDR）、以及必要的 NAT 或防火牆規則都已合理。否則你很可能會遇到「Load Balancer 顯示健康，但實際連線到後端失敗」這類情況，根因往往不是均衡器本身，而是網路安全或路由。

此外，請把「健康探測能不能到達後端」與「用戶流量能不能到達後端」視為兩件不同的事。健康探測的來源 IP、埠號、以及 NSG 放行規則，必須確保與你的測試策略一致。很多設定看似正確，但健康探測其實因 NSG 或防火牆規則被擋掉，導致後端池永遠不進入可用狀態。

第四章：核心架構設計——前端、後端、探測與規則

要把 Azure Load Balancer 設定好，你可以用一個通用的心智模型：前端接收連線，後端池承接連線，健康探測決定哪些後端是可接收的，規則決定如何把前端的連線映射到後端的埠與協定。

4.1 前端（Frontend IP Configuration）怎麼選

前端配置決定用戶流量進來的地址與類型。若是公網入口，你通常會選擇使用公網 IP，並配合 DNS 做指向。若是內部入口，你則需要確定內部 IP 分配方式與路由可達性。

一個常見誤區是以為「只要有公網 IP 就一定可用」，但實務中你還需要同步確認：子網是否有正確的網路策略、NSG 是否放行所需埠、以及是否存在不合預期的路由回程問題（尤其當你的後端位於特定子網並連到額外網路設備時）。

4.2 後端池（Backend pool）放哪些節點

後端池可以包含單一 VM 或 VM Scale Sets 中的實例。若你希望能隨流量自動伸縮，VMSS 是更自然的選擇。你需要留意的是，後端池中的節點必須在網路上可被負載均衡器存取，並且應用服務在目標埠上能正確回應。

Azure國際帳號服務 如果你採用多埠服務（例如同時提供 80 與 443），你可以建立對應的規則與探測；如果只提供單一協定與埠，就能把設定簡化。但無論如何，你要避免一種情況：後端節點健康探測用的是 80，實際用戶透過 443 連線，而 443 實際上因憑證或服務未啟動導致失敗。這會讓你以為均衡器沒問題，但用戶仍覺得服務不穩。

4.3 健康探測（Health Probe）是穩定性的核心

健康探測的目的不是「判斷服務是否存在」，而是「判斷服務是否能承接新流量」。因此你需要讓探測邏輯貼近實際服務。例如 Web 服務就可以用 HTTP 探測到某個輕量 endpoint（如 /healthz），並確保它回應狀態碼與內容在預期範圍。

探測的幾個關鍵參數是：探測協定（HTTP/TCP）、埠號、間隔（interval）、以及容許失敗次數（unhealthy threshold）。這些參數的目標是「在節點真的故障時能迅速摘除」，同時「在短暫抖動時不要誤判」。對高流量系統而言，過於激進的探測可能造成節點被頻繁上下線；過於保守則會導致故障期間仍把流量導到不可靠節點。

因此你要結合實際環境調整：例如後端偶發 GC 暫停導致探測延遲上升，你就應該用更合理的超時與閾值，或讓探測 endpoint 更輕量、避免與主業務共用資源。

4.4 負載均衡規則（Load Balancing Rules）怎麼設

規則負責映射前端埠到後端埠，並決定連線如何被分配。你通常會為 HTTP 與 HTTPS 建立不同規則，或至少不同埠。若是純 TCP 服務，則可以直接用 TCP 規則搭配 TCP 探測。

關於會話維持（Session Persistence），你需要根據應用特性決策。若你的後端服務是無狀態（stateless），或把 session 存在集中式存儲（例如 Redis），一般可以關閉或不依賴會話維持，這樣擴展與容錯更簡潔。若應用依賴長連線或黏著會話（例如部分舊系統或特定連線型應用），你就需要考慮 session persistence，並設計好逾時策略避免「連到不該連的節點」或「連線維持太久導致資源耗盡」。

第五章：以實務為核心的設定流程（可照著做的落地順序）

下面提供一個偏向實務落地的順序。你可以依照這個流程建立並驗證，每一步都做最小可用測試，避免最後整體才一次性排錯。

5.1 建立網路與子網：先讓路通

首先確認：VNet、子網、以及後端 VM 所在子網已配置正確。接著檢查是否有必要的路由表（例如企業環境要經由防火牆或 NAT 出口）。如果你有使用 Azure Firewall 或第三方設備，確認負載均衡器到後端的路徑與回程路徑都在預期。

接下來設定 NSG。這一步很多人會跳過或延後，但我建議你在建立 Load Balancer 前先完成「網路允許」。至少你要確認：探測所需埠、以及用戶實際進入的前端埠與到後端的通訊埠都在放行範圍內。

Azure國際帳號服務 5.2 佈署後端服務：先確保回應能正常

把後端 VM 或 VMSS 先佈署完成，確保服務在目標埠上能回應。這裡的要點是：不要等到負載均衡器設定完才去驗證後端。你應該先用內部測試工具從同一個網段或跳板機對後端直接發起請求，確認回應狀態正常、TLS 憑證正常、以及認證/跳轉邏輯不會導致健康探測失敗。

特別是 HTTPS：如果你使用自簽或憑證鏈不完整，可能導致探測與實際用戶行為不一致。建議至少先用標準工具測試一次，確保憑證與協定都符合預期。

5.3 建立 Load Balancer：從前端到後端池

Azure國際帳號服務 建立 Load Balancer 後，先設定前端 IP。若是公網入口，配置 public IP；若是內部入口，指定內部位址。確認選擇的區域（香港）與你的資源組一致，避免跨區引發的遷移成本。

接著建立後端池，將 VM 或 VMSS 的實例加入。若是 VMSS，通常會用自動成員機制，確保伸縮時後端池能同步更新。

5.4 設定健康探測：讓探測貼近真實可用性

為每個服務建立健康探測。常見做法：HTTP probe 使用 /healthz 或 /status 之類的輕量 endpoint；TCP probe 則測試服務端埠是否接受連線。建議把 health endpoint 做到以下特性：

• 回應快：避免依賴昂貴的外部呼叫。
• 語意清楚：回傳狀態碼能直接反映服務是否可承接流量。
• 避免副作用：探測不應觸發重操作。

然後調整 interval 與閾值。對高流量系統而言，健康探測太頻繁會增加額外負載；太慢會延遲故障摘除。你可以先用合理預設，再依觀測結果微調。

5.5 建立負載均衡規則：映射埠與處理連線

建立規則時，確保前端埠與後端埠一致（或符合你的需求映射）。同時檢查協定型態（TCP/UDP）與連線超時行為。若你的服務為 HTTP/HTTPS，建議把規則的行為與應用端的連線設定協同。

Azure國際帳號服務 若需要會話維持，確認你的應用是否依賴黏著會話，以及 session 的有效期策略是否與 Load Balancer timeout 協調。否則你可能遇到「看似均衡器有維持，但應用仍判斷 session 過期」的困擾。

5.6 安全策略最後再「補齊」，但要即時驗證

在 Load Balancer 建好、健康探測顯示可用後，再逐步補齊防火牆與 NSG 規則。尤其注意探測來源與方向。你要做的是：用實際流程驗證——外部或內部從正確來源發起請求，並觀察後端是否真正承接，健康狀態是否與實際一致。

這一步也要測失敗情境：例如暫時停止某台後端服務，確認健康探測會把它標成不健康，且新連線不再送到該節點；再恢復服務，確認它能重新進入輪轉。

第六章：高流量的細節：會話、連線耗盡與超時

高流量下的穩定性，不只取決於均衡分發，還取決於連線生命週期的管理。許多事故不是因為流量太大，而是因為連線管理不合理導致資源耗盡。

6.1 連線超時（Idle timeout）與應用端策略

當你的使用者行為包含長輪詢、WebSocket、或是某些需要較長保持的連線，Idle timeout 不當會導致連線被關閉。即使負載均衡器把流量分到了正確後端，如果應用端對連線維持設定不對，也會出現間歇性錯誤。

因此你要確認：應用程式的 session/keep-alive 設定，與 Load Balancer 的連線逾時設計相互一致。若你提供的是標準 HTTP/HTTPS request-response，通常會相對簡單；若你提供長連線服務，就要把這件事當成設計的一部分，而不是部署後才補。

6.2 會話維持不等於永遠粘住：要看你要解決什麼

會話維持的本意是讓同一使用者的請求更可能落在同一後端，從而降低狀態一致性問題。但若你的後端已經是無狀態，會話維持反而可能降低伸縮與故障切換的效率，因為一旦某節點摘除，黏著會話仍需重新建立與恢復。

因此在設計上，你可以考慮：把狀態集中到可用的外部儲存，讓應用本身維持無狀態，這樣負載均衡器的角色就能充分發揮。

6.3 觀察連線分佈：確保流量真的在後端平均

高流量下最怕的是「均衡器看起來運作，但實際分佈不均」。造成不均的原因可能有：規則與探測對應不一致、後端節點健康狀態頻繁抖動、或某些節點在應用層回應較慢導致連線更容易失敗。

你需要在監控中加入分佈觀察：每個後端節點的請求量、失敗率、平均回應時間與重試次數。當某台節點異常時，不要只看均衡器的總體指標，而要快速定位到後端應用層的瓶頸。

第七章：NSG 與安全性：把開放的範圍縮到剛好

負載均衡常被視為「網路轉發」，安全性卻是整個架構的底盤。若你過度放寬 NSG，很可能在高流量時段把不必要的探測與攻擊也一起放進來；若你過度收緊，則會讓探測或用戶連線失敗，造成自動摘除後端，最後形成「看似流量太大，其實是安全規則擋住」的錯誤結論。

建議的思路是：以最小權限原則放行必要流量。至少你要明確：哪些來源需要訪問（公網或特定內網）、哪些目的埠需要開放、健康探測所需的埠與協定是否已放行，以及後端之間是否需要額外通訊。

此外，如果你的服務包含管理端（例如 SSH/RDP），應避免把它暴露給公網，應使用跳板或 VPN/堡壘機模型。把攻擊面縮小，才能讓你在面對突刺流量時同時具備韌性。

第八章：監控與告警：你要在事故前幾分鐘看到苗頭

Load Balancer 本身運作良好並不等於整體服務穩定。高流量事故的常見特徵是：先是延遲上升、失敗率上升、健康狀態開始抖動，最後才是用戶完全不可用。

Azure國際帳號服務 8.1 建立三層監控：均衡器、後端、應用

• 均衡器層：前端連線數、後端池健康狀態變化、探測成功/失敗趨勢。
• Azure國際帳號服務 後端層：CPU、記憶體、網路收發、端口監聽狀態、以及應用進程健康。
• 應用層：回應碼分佈（2xx/4xx/5xx）、平均與 P95/P99 延遲、錯誤堆疊、外部依賴（資料庫/第三方 API）失敗率。

當你能在「均衡器開始把更多流量導向特定節點」的初期就看到，處理會容易得多；否則等到所有節點一起失穩，復原就會變得更痛。

8.2 告警策略：避免告警疲勞

告警不是越多越好。你需要針對行動制定閾值。例如：

• 健康探測失敗連續達到某閾值：觸發「摘除/擴容」相關處置流程。
• 後端失敗率（5xx）在短時間內超過某比例：觸發「檢查應用資源與外部依賴」。
• 延遲 P95 持續上升：觸發「擴容或降級」策略。

告警疲勞會讓你在真正危急的時刻反應慢。以可執行的處置為導向設計告警，能顯著提高團隊效率。

第九章：常見陷阱與排錯思路：少走彎路

即使設定照抄，仍然可能出現問題。以下是幾個在實務中最常見、也最容易花時間的陷阱，以及我建議的排錯順序。

9.1 健康探測顯示不健康，但你以為服務正常

常見原因：探測 endpoint 沒有放行、NSG 擋掉、埠號錯誤、或 health 檢查邏輯太依賴外部服務導致偶發失敗。排錯順序建議：

• 先確認健康探測配置的協定、埠、路徑是否與後端一致。
• 從後端節點本機或同網段用戶端測試健康 endpoint 回應。
• 檢查 NSG/防火牆是否允許探測來源到目標埠。
• 在健康 endpoint 裡加上清楚的錯誤原因（例如返回內容或日誌），避免你只看到「失敗」卻不知道為什麼。

9.2 均衡器顯示健康，但外部用戶仍回應失敗

可能原因是前端到後端的規則映射錯誤、TLS/憑證問題、或回程路由/安全規則只對探測放行但未對用戶流量放行。排錯順序建議：

• 確認前端規則的埠號與用戶訪問的埠一致。
• 檢查後端服務是否同時在目標埠運行且回應正常。
• 針對 HTTPS，確認憑證鏈完整、SNI/協定版本是否符合。
• 檢查 NSG 是否允許「用戶流量來源」到後端。

9.3 服務在流量突刺時雪崩，但健康探測沒明顯變化

這類通常表示健康探測太「寬鬆」或太「輕量」，沒有反映真實可承接流量的狀態。比如 health endpoint 不需要拿鎖、不需要查資料庫、就能快速回應，但真實業務在突刺時被資料庫慢查拖垮。解法是讓 health endpoint 的語意更貼近「承接能力」，至少把最關鍵的依賴狀態（例如資料庫連線可用性）納入判斷，並用合理的超時避免健康檢查本身造成雪上加霜。

第十章：結語——把負載均衡當成工程能力，而不是設定任務

在香港做高流量服務，Azure Load Balancer 能提供一個穩定的基礎：把流量分配到健康的後端池，並在節點故障時自動縮減風險。真正拉開差距的不是「是否有負載均衡」，而是你對健康探測的嚴謹程度、對規則與埠映射的精準程度、對安全策略的最小權限設計、以及你是否建立能在事故前及時發現的監控告警。

當你把上述元素都處理好，負載均衡就不只是工具，而是你整套架構的韌性來源。下一次遇到突刺流量，你會更快定位問題，並在最短時間內把服務恢復到可承接的狀態。這才是高流量場景真正需要的「穩定」。