Azure國際帳號購買 Azure CDN多源站負載均衡配置

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

談到 CDN，大家最熟悉的通常是「就近快取」：使用者在離你更近的區域命中快取，延遲自然更低。但當你的業務量上來，或你的起源站（Origin）本身承受壓力時，你會發現另一個問題會越來越明顯：就算有 CDN，仍然有一部分請求會回源。這些回源請求可能因為區域、網路品質、機器狀況或發佈節奏不同而出現差異。於是，多源站負載均衡就成了穩定性的關鍵。

多源站的價值主要體現在三個面向。

第一是容錯。單一回源站一旦異常，你不只會看到延遲上升，甚至可能產生大量 5xx 或超時。把起源拆成多個來源，並且讓 CDN 對不同來源做健康檢查與自動切換，整體可用性會大幅提高。

第二是容量與成本控制。當你把某些流量分擔到不同來源站，你就能避免單一站點成為瓶頸。配合快取策略，你還能把回源比例壓下來，讓整體架構更省。

第三是性能一致性。不同地區的使用者，回源時路徑並不相同。合理的路由策略可以讓請求更快命中品質較高的來源，讓體驗更穩。

Azure CDN 的多源站能力，適合用在需要「高可用」與「可控分流」的情境：例如跨區部署的應用、分散式儲存後端、甚至是不同網域/不同供應商的起源。接下來我們會以可落地的方式，講清楚如何配置與驗證。

第二章：開始前的架構與前提

在動手設定前，你需要先把「你到底要解決什麼」講清楚，否則容易在配置後發現症狀不對、路由策略也不對。

2.1 明確你的起源站類型

CDN 的起源站可以是不同類型的服務：Web App、VM、儲存服務、或其他能回應 HTTP/HTTPS 的端點。不同起源類型在以下方面會有差異：回應延遲、支援的協定、TLS 設定、以及是否會受地理位置影響。

你要先確認：各起源站是否使用同一套內容與版本邏輯？如果不一致，你還得處理快取一致性與回源一致性。否則流量分到不同來源，會出現同一網址內容不同步的情況。

2.2 確認內容一致性策略

多源站最常見的「踩雷」不是路由失敗，而是內容不一致。假設你的來源站是跨區部署的應用，理論上應該同步；但實際上可能因為：

1）發佈排程不一致：A 區先發，B 區後發；

2）快取失效策略不同步：某區更新後快取還在；

3）後端讀取的資料不一致：例如依賴區域性資料或同步延遲。

若你能確保內容是一致的（或至少在可接受窗口內一致），那麼多源站的收益會更大。

2.3 建立目標指標

在配置負載均衡前，先定義可衡量的成功標準，否則後續很難判斷到底有沒有變好。常見指標包括：

• 回源成功率（4xx/5xx/超時）

• P99 延遲（回源延遲與端到端延遲分開看）

• Cache hit rate（快取命中率）

• 健康探測狀態的切換頻率（避免因為探測不穩而頻繁切換）

第三章：多源站的核心設計思路

多源站負載均衡的關鍵在於「怎麼選擇來源」。你通常會面對兩層選擇：CDN 的回源選擇規則，以及健康狀態的判斷與故障切換。設計的好壞，最後都會反映在行為是否可預期。

3.1 來源分組：把複雜度降到可管理

Azure國際帳號購買 實務上你不太希望把所有起源站都混在同一個策略裡。較好的方式是先做來源分組，例如：

Azure國際帳號購買 • 地理分組：例如 East、West；

• 功能分組：例如 API 類、靜態檔案類；

• 版本分組：例如 v1、v2（用於逐步導流或回退）；

• 成本分組：例如高性能區、低成本區。

分組後，你的路由策略會更清晰，也更容易排查問題：你可以知道某次錯誤是否只集中在某個分組。

3.2 分流方式：平均、加權、或按條件路由

你可能會用到以下分流概念（具體實作方式依 Azure CDN 方案與規則能力而定，但邏輯是一樣的）：

• 均衡分流：把請求平均分到多個起源站。適合各起源性能與容量相近的情況。

• 加權分流：給某些起源更高權重。適合性能較佳或容量較大的來源。

• 條件路由：依 URL 路徑、查詢參數、請求標頭、或用戶特徵做路由。適合同一網域下混合 API 與靜態資源，或需要針對不同內容類型走不同來源。

要注意一點：如果你在同時使用快取策略，分流策略可能會影響快取命中與回源行為。比如某條規則把一部分請求導向另一來源，那個來源可能尚未有快取或快取策略不同，導致回源比例上升。

3.3 健康探測：不是「能回應」就算健康

健康探測是多源站穩定性的核心。你需要確保探測能反映真實服務狀態，而不是只檢查 TCP 或返回固定字串。

建議你：

• 探測路徑選擇能代表核心功能（例如簡單的 API ping 或輕量頁面）。

• 使用合理的超時與重試策略，避免短暫抖動被判定為故障。

• 針對不同起源站可能存在的冷啟動/初始化時間，設定足夠的容忍窗口。

健康探測如果設得太敏感，可能會導致頻繁切換，反而讓延遲與錯誤率上升。

第四章：配置流程（端到端落地）

下面以一個典型情境說明整體流程：你有兩個或多個起源站（可跨區），內容大致一致，你希望 CDN 在健康狀態下分流，並在故障時自動切換。

4.1 準備起源端點與證書

先把每個起源站的可用端點整理好，包含：

• 起源主機名或 IP（建議主機名）

• HTTP/HTTPS 協定

Azure國際帳號購買 • 若走 HTTPS：需要確保 CDN 能正確驗證起源證書，或設定合適的憑證驗證方式（視方案能力）。

另外，確保每個起源站對相同的請求路徑能回應一致的內容類型與狀態碼邏輯。比如某起源對不存在資源回 404，而另一個回 200/自訂頁，這會讓排查變得非常痛苦。

4.2 建立多源設定與來源策略

在 CDN 的設定中，先建立「起源列表」並把各端點加入。接著配置「多源路由邏輯」。常見做法是：

1）先定義來源組合：例如 OriginGroup A（兩個起源）

2）設定路由/分流規則：例如加權或固定比例

Azure國際帳號購買 3）確認回源行為：例如是否允許回到多個來源，以及當其中一個不可用時是否跳到其他來源

如果你只做「故障切換」而不需要分流，仍建議你至少建立來源組，確保你能在故障時快速恢復。

4.3 設定健康探測參數

健康探測配置至少要包含：

• 探測協定與路徑

• 探測間隔

• 逾時閾值

• 判定條件（例如成功狀態碼範圍）

實務上，探測路徑最好是「穩定且輕量」。你不想讓探測本身成為負載來源。假如你有 /healthz 之類的端點，並且它能保證在正常狀況下回傳固定的成功碼，那就是很好的選擇。

4.4 配置快取行為與一致性

多源站與快取通常要一起考慮。因為 CDN 的快取是「面向使用者的」，而多源站是「面向回源的」。兩者疊加後，可能導致你看到以下現象：

• 某些請求命中快取，不會回源，因此你以為切換生效了，但實際上沒有發生回源

• 來源切換後，未命中的內容會在新來源重新回源並建立快取，因此短時間內可能出現回源峰值

因此你要定義快取策略：哪些路徑應長快取、哪些需要短快取或禁止快取；以及更新時如何清除快取。

若你的內容會頻繁更新，建議把更新頻率與快取 TTL 做匹配。並在發佈流程中加入「快取清除」或「版本化 URL」的策略。多源站不會替你解決內容一致性問題，它只提高可用性與分流能力。

4.5 加入安全與規則（WAF/URL 規則）

在負載均衡之外，你還應把安全規則與流量控制納入設計。至少考慮：

• 基於 URL 路徑的規則（例如 API 路徑走較嚴格的限制）

• 對敏感路徑的快取策略（例如不允許快取個人資料）

• 速率限制與異常偵測（避免單一來源承受攻擊）

當你開啟多源站後，攻擊流量可能會更平均地散到不同來源。這未必是壞事，但你必須確保所有來源的安全策略一致，否則其中某個來源可能成為弱點。

4.6 監控與驗證：別只看「設好了」

配置完成後，最重要的是驗證。驗證可以分為兩種層級：行為驗證與指標驗證。

行為驗證包括：

• 正常狀態下，請求是否真的分流（或至少能在多來源可用時依策略選擇）

• 健康探測失敗後，是否能在合理時間內切換

• 切換後錯誤率是否下降，延遲是否改善

指標驗證包括：

• 回源成功率、HTTP 狀態碼分佈

• 回源延遲 P99

• Cache hit rate 的變化趨勢

• 切換事件的頻度（避免抖動）

建議你在測試時，刻意製造來源站不可用（例如阻斷探測路徑或模擬高延遲），觀察 CDN 的切換是否符合你預期。

第五章：常見案例與取捨

多源站不是「加了就一定更好」。你需要根據實際狀況做取捨。下面用幾個常見案例幫你建立判斷框架。

5.1 兩區部署的 Web 應用

情境：你在 East US 與 West US 部署同一套應用，並把資源都放在同一資料來源（或有良好同步）。

建議：

• 探測路徑選擇能代表核心服務

• 分流策略可以先用均衡或輕加權（例如讓主區權重略高）

Azure國際帳號購買 • 快取策略以一致性為優先，更新時採取一致的清除流程

關鍵點：如果你兩區內容同步良好，多源站會顯著提升可用性；但如果同步延遲會造成「內容差異」，你需要縮短 TTL 或做版本化。

5.2 靜態資源與動態 API 混用

情境：同一個網域下，/static 長快取，/api 短快取或不快取。

Azure國際帳號購買 建議：

• 對靜態資源路徑使用更激進的快取 TTL，提高命中率

• 對 API 路徑使用更保守的快取設定（避免把個人資料快進 CDN）

• 若你的 API 起源站在多區性能差異大，可以對 API 路徑使用加權路由

取捨：當你把不同內容類型混在同一來源策略裡，容易讓快取行為難以預測。把規則切清楚，反而能更簡單。

5.3 需要灰度發佈（逐步導流）

情境：你想在新版本上線時，先把少量流量導到新起源站，觀察指標正常後再擴大。

做法通常是把起源站按版本分組，例如 OriginGroup v1 與 OriginGroup v2，然後用條件路由或加權分流讓流量逐步增加。

注意：灰度發佈會放大內容一致性與行為一致性的要求。因為新版本可能在某些回應細節上不同（狀態碼、錯誤訊息、header）。你必須確保前端/客戶端能容忍這些差異，或把可見差異限制在可控範圍。

第六章：排查與優化（真正在現場會遇到的事）

很多團隊在上線後才發現問題。下面列的是最常見的現場狀況，以及你可以怎麼查。

6.1 看似「已切換」，但用戶體驗沒有改善

這通常不是 CDN 沒切換，而是你的測試沒有觸發回源。原因可能是：

• 快取命中率太高，回源比例很低

• 你測試的 URL 在 CDN 快取裡還是新鮮的

• 探測失敗時，實際上切換的是部分路徑，而你測試的是另一類路徑

Azure國際帳號購買 排查方向：先確認請求是否回源，並檢查路由規則是否覆蓋到你測試的路徑。

6.2 切換頻繁，延遲反而抖動

這多半是健康探測參數設得太激進，或探測路徑本身不穩。比如起源站偶發高延遲，探測逾時閾值太短，就會把健康判定當成故障，於是造成頻繁切換。

解法：

• 讓探測路徑更穩定、邏輯更輕量

• 調整超時與間隔，增加容忍

• 若來源站存在冷啟動，設定足夠的穩定期

你要的是「少切、快恢復」，不是「每次抖一下都切」。

6.3 內容不一致：同一網址不同地區顯示不同內容

多源站把流量導向不同起源站，你的內容一致性問題會被放大。常見原因包括：

• 發佈流程不是原子化：不同起源站更新不同步

• CDN 快取清除沒有覆蓋全部路徑

• 你的快取 key 沒把必要的變數包含進去（例如語言、版本、或部分 header）

解法：把內容版本化（例如 URL 帶版本號）或確保更新與快取清除流程一致；同時檢查快取鍵與規則覆蓋。

6.4 某一來源站誤判健康或誤判故障

如果探測判定條件用得不精準，可能會把「非核心故障」也當成故障，或者把「核心功能異常」偵測成健康。比如探測只檢查 200，而你的業務其實返回了錯誤內容但仍是 200。

建議：探測應該是業務可驗證的，至少要能反映核心功能可用性。必要時，你可以讓探測返回包含狀態的簡單內容，並用規則判斷是否符合。

第七章：上線後的運維策略

配置成功只是開始。多源站負載均衡牽涉多個起源站、快取策略、探測與路由規則，長期運維需要系統化。

7.1 建立告警：以「可用性」為核心

你應該對以下事件建立告警：

• 回源成功率下降

• 5xx/超時突然上升

• 健康探測狀態切換次數異常增多

• Cache hit rate 大幅下降（可能代表快取失效或回源比提高）

Azure國際帳號購買 告警門檻要結合你的業務流量特性，避免誤報讓人疲勞。

7.2 發佈流程與回退策略要與多源站對齊

如果你做灰度或跨區發佈，要把以下事項納入流程：

• 版本切換的時間窗口（哪些來源先更新、哪些後更新）

• 快取清除或版本化策略同步

Azure國際帳號購買 • 發佈失敗時如何回退：是把權重改回去，還是先暫停某來源探測

把策略寫成可執行的清單，而不是靠經驗臨場調參。

Azure國際帳號購買 7.3 定期回顧路由與權重

隨著系統規模變化，起源站性能可能改變。例如某區擴容了，或某區因維護降級。你需要定期回顧路由策略：權重是否需要調整、某些來源是否需要移除、探測路徑是否仍然代表核心可用性。

第八章：總結與建議

Azure CDN 多源站負載均衡配置的重點，不在於你設定了多少來源，而在於你把「選擇來源」與「判定健康」做得可預期、可驗證。只要你能做到：

• 起源站內容與行為一致性（或用版本化/快取策略把不一致控制在窗口內）

• 健康探測能反映核心服務可用性，而不是僅能回應

• 快取策略與路由策略協同，避免切換時回源壓力失控

• 上線後用指標和行為雙重驗證，並建立告警與回退機制

那麼多源站就能把 CDN 的「高性能」與「高可用」真正落到你的業務上。

最後給一個最實際的建議：在上線前，做一次「模擬故障」的測試，刻意讓其中一個起源站探測失敗或回應變慢。你會在那一刻看清楚：你的健康檢查是否合理、你的切換是否符合預期、以及你快取策略在真實回源情境下是否穩定。這種測試往往比任何文件描述更能降低風險。