共用方式為


Azure API 管理 的可靠性

Azure API 管理。 是一項完全託管的服務,可幫助組織發布、保護、轉換、維護和監控 API。 作為 Azure 服務,API 管理 提供一系列功能來支援您的可靠性需求。

當您使用 Azure 時, 可靠性是共同的責任。 Microsoft 提供一系列功能來支援韌性和復原。 您有責任瞭解這些功能在您使用的所有服務中如何運作,並選取符合業務目標和正常運作時間目標所需的功能。

本文說明如何使 API 管理系統具有應對各種潛在中斷和問題的韌性,包括暫時性錯誤、可用性區域的中斷、區域性中斷和服務維護。 它也會說明如何使用備份從其他類型的問題復原,並醒目提示 API 管理 服務等級協定 (SLA) 的一些重要資訊。

可靠性架構概觀

APIM 會使用以縮放單位為基礎的結構來提供內建備援和可擴縮性。 當您部署 API 管理 執行個體時,您會設定一或多個 縮放單位單位。 每個單位都是容量的邏輯表示法,其中包含處理 API 請求所需的運算資源。

當您設定具有兩個或多個單位的執行個體時,可用單位會共同處理請求並提供自動負載平衡。 如果其中一個裝置無法使用,其餘裝置會繼續處理流量,但容量可能會減少。

為了取得更高層級的可靠性,API 管理服務支援在區域內的可用性區域以及跨多個區域的單位分佈。

APIM 服務層級提供不同層級的可靠性:

  • 進階 (傳統) 層:支援多個單位,可分散到可用性區域和區域,以達到最大的復原能力。 在進階層中,每個單位都包含兩個虛擬機器 (VM),可提供運算資源來處理 API 要求。

  • 基本 v2、標準版、標準 v2 和進階 v2 (預覽) 層:全都支援單一資料中心內的多個單位。 它們不支援可用性區域或多區域部署。

  • 開發人員層:僅支援單一單位,不提供可用性區域或多區域支援。 此層是針對開發和測試案例所設計。 它不適用於生產工作負載。

  • 取用層:具有內建的復原功能,並對單一 Azure 資料中心內的一系列故障情形具有復原性。 不過,取用層不提供對於可用性區域或多區域部署的支援。 若要了解使用量層 APIM 執行個體的預期可用時間,請檢閱服務等級協定 (SLA) (部分內容可能是機器或 AI 翻譯)。

執行個體內的單位會一起運作,以處理要求,並在可用單位之間自動進行負載平衡。 如果裝置無法使用,其餘裝置會繼續處理流量,但容量可能會減少。

備註

APIM 的開發人員和進階層支援自我裝載閘道 (部分內容可能是機器或 AI 翻譯),您可以在自己的基礎結構上執行。 當您使用自行托管閘道時,您負責設定它們以符合您的可靠性需求。 自我裝載閘道不在本文的範圍內。

生產部署建議

Azure Well-Architected Framework 提供可靠性、效能、安全性、成本和作業的建議。 若要瞭解這些區域如何彼此影響,並有助於可靠的 API 管理 解決方案,請參閱 API 管理 的架構最佳做法

對瞬態故障的彈性

暫時性錯誤是元件中的短暫間歇性失敗。 它們經常出現在雲端等分散式環境中,而且是作業的一般部分。 暫時性錯誤會在短時間內自行修正。 請務必讓您的應用程式能處理暫時性錯誤,這通常是透過重試受影響的要求來進行。

所有雲端裝載的應用程式在與任何雲端裝載的 API、資料庫和其他元件通訊時,都應該遵循 Azure 暫時性錯誤處理指引。 如需詳細資訊,請參閱 處理暫時性錯誤的建議

當您在 API 前面使用 APIM 時,您可能需要重試因暫時性錯誤而失敗的要求。 為了保護您的後端 API 免於因太多要求而不堪重負,API 管理 提供重試、速率限制和配額原則。 您也可以使用後端資源 (部分內容可能是機器或 AI 翻譯) 來設定負載平衡和斷路器功能。

對可用性區域故障的抵抗力

可用性區域 是 Azure 區域內物理上獨立的資料中心群組。 當某個區域發生故障時,服務可以切換至其他剩餘的區域。

當您在支援的區域中部署進階 (傳統) APIM 執行個體時,APIM 提供兩種類型的可用性區域支援:

  • 自動:當您未指定要使用的可用性區域時,APIM 會提供自動可用性區域支援。

  • 手動:當您明確指定要使用的可用性區域時,APIM 會提供手動可用性區域支援。

透過可用性區域支援,APIM 會跨區域複寫服務元件,以提供高可用性。 在主要區域中,這些元件包括閘道 (縮放單位)、管理平面和開發人員入口網站。 在次要區域中,只有閘道單元被複製。 如需次要區域的詳細資訊,請參閱全 區域失敗的復原能力

自動可用性區域支援

您可以使用自動可用性區域支援,選擇單一單位或多單位執行個體設定,以達成區域備援:

  • 多單位設定 (建議):如果您的執行個體有兩個以上的單位,APIM 會盡最大努力嘗試將執行個體的單位分散到區域的可用性區域。 無法判斷您的單位放置在哪些可用區域。 建議您至少部署兩個單元,這兩個單元可以分佈在兩個區域中。

    下圖顯示具有三個單元的 APIM 執行個體,其已針對自動可用性區域支援進行設定:

    顯示分散在可用性區域的三個 API 管理 單位以取得自動可用性區域支援的圖表。

    此圖顯示部署在 APIM 執行個體中的三個方塊,其標示為「單元 1」、「單元 2」與「單元 3」。 每個單元方塊都包含兩個代表 VM 的圖示。 三個較大的方塊標示為「可用性區域 1」、「可用性區域 2」與「可用性區域 3」。 區域 1 包含單元 1、區域 2 包含單元 2,而區域 3 包含單元 3。

  • 單一單位設定:如果您的執行個體有單一單位,該單位的基礎 VM 會分散到兩個可用性區域。 無法判斷單位的 VM 放置在哪些可用性區域中。

    圖表顯示分散在兩個可用性區域中的單一 API 管理 單位,以取得自動可用性區域支援。

    此圖顯示一個標示為部署在 APIM 執行個體中之單元 1 的方塊。 該單元方塊包含兩個代表 VM 的圖示。 三個較大的方塊標示為「可用性區域 1」、「可用性區域 2」與「可用性區域 3」。 單元 1 橫跨區域 1 與區域 2。 區域 3 是空的。

手動可用性區域支援

如果您想要明確選取要使用的可用性區域,您可以在區域備援和區域組態之間進行選擇:

  • 區域備援:在支援的區域中手動設定 APIM 執行個體的區域備援,以提供服務元件的備援。 當您選取兩個或多個可用性區域來使用時,Azure 會自動跨選取的區域複寫服務元件。

    圖表顯示分散在可用性區域中的三個 API 管理 單位,以進行手動區域備援。

    此圖顯示部署在 APIM 執行個體中的三個方塊,其標示為「單元 1」、「單元 2」與「單元 3」。 每個單元方塊都包含兩個代表 VM 的圖示。 三個較大的方塊標示為「可用性區域 1」、「可用性區域 2」與「可用性區域 3」。 區域 1 包含單元 1、區域 2 包含單元 2,而區域 3 包含單元 3。

  • 區域:APIM 元件會部署在您在 Azure 區域內選取的單一區域中。 所有單位都會放置在相同的可用性區域中。

    顯示在單一可用性區域中具有兩個單位的區域性 API 管理 部署的圖表。

    圖表:顯示部署在 APIM 執行個體中且標示為「單元 1」與「單元 2」的方塊。 每個單元方塊都包含兩個代表 VM 的圖示。 三個較大的方塊標示為「可用性區域 1」、「可用性區域 2」與「可用性區域 3」。 區域 1 包含單元 1 與單元 2 方塊。 區域 2 與區域 3 不包含任何單元。

    這很重要

    只有在跨區域延遲 (部分內容可能是機器或 AI 翻譯) 太高而無法滿足您的需求,且在您確認延遲不符合需求之後,才針對單一可用性區域。 區域執行個體本身不會提供可用性區域中斷的復原能力。 若要改善區域性 API 管理 部署的復原能力,您必須明確地將個別執行個體部署至多個可用性區域,並設定流量路由和容錯移轉。

需求

  • 地區支援: API 管理 支援所有 支援可用性區域的 Azure 區域中,進階 (傳統) 層的可用性區域。

  • 等級要求: 您必須使用進階 (傳統) 層來設定可用性區域支援。 APIM 目前不支援傳統使用量、開發人員、基本和標準層或基本 v2、標準 v2 和進階 v2 層的可用性區域。 若要將執行個體升級至進階 (傳統) 層,請參閱 升級至進階層

備註

具有企業功能的進階 v2 層處於預覽狀態。 若要判斷您的設計是否應該依賴早期存取功能或正式運作的功能,請評估您的設計和實作時程表,以瞭解 Premium v2 版本和移轉路徑的可用資訊。

考慮事項

  • 區域備援執行個體的單位數: 如果您手動設定執行個體的區域備援,您也必須設定一些 API 管理 單位,這些單位可以平均散發到所有選取的可用性區域。 例如,如果您選取兩個區域,則必須至少配置兩個單元。 您可以改為配置四個單元,或兩個單元的另一個倍數。 如果您選取三個可用區域,則必須設定三個單位、六個單位或三個單位的另一個倍數。

    如果您使用自動可用性區域支援,就不需要使用特定數量的單位。 您部署的單位會以最佳方式分散在可用性區域之間。 為了達到最大區域備援,建議您至少使用兩個單元,以確保可用性區域中斷不會影響您的執行個體。

    若要判斷提供所需閘道效能的單位數目,請使用 容量指標 和您自己的測試。 如需縮放和升級服務執行個體的詳細資訊,請參閱升級和縮放 APIM 執行個體 (部分內容可能是機器或 AI 翻譯)。

  • 自動擴展: 如果您在設定具有自動擴展的 API 管理執行個體時手動配置可用性區域,則可能需要在配置完成後調整自動擴展的設置。 在此情況下,自動調整規則和限制中的 API 管理 單位數目必須是區域數目的倍數。 如果您使用自動可用性區域支援,就不需要調整自動縮放設定。

  • IP 位址需求:當您在部署於外部或內部虛擬網路的 APIM 執行個體上啟用可用性區域支援時,您必須指定要使用的執行個體公用 IP 位址資源。 在內部虛擬網路中,公用 IP 位址只會用於管理作業,而不會用於 API 要求。 如需詳細資訊,請參閱 APIM 中的 IP 位址 (部分內容可能是機器或 AI 翻譯)。

費用

無論您的可用性區域設定為何,如果您新增更多單位,就會產生更多成本。 如需詳細資訊,請參閱 API 管理 定價

設定可用性區域支援

本節說明如何設定 APIM 執行個體的可用性區域支援。

備註

當您選取要使用的可用性區域時,實際上會選取 邏輯可用性區域。 如果您在不同的 Azure 訂用帳戶中部署其他工作負載元件,他們可能會使用不同的邏輯可用性區域號碼來存取相同的實體可用性區域。 如需詳細資訊,請參閱實體和邏輯可用性區域

  • 建立支援可用性區域的 APIM 執行個體:當您在支援可用性區域的區域中建立進階 (傳統) APIM 執行個體時,執行個體預設支援可用性區域。 您可以選取自動可用性區域支援,或手動設定區域或區域備援支援。

  • 啟用或重新設定可用性區域支援: 您可以變更 API 管理 執行個體的可用性區域設定,包括新增可用性區域,以及在可用性區域之間移動區域執行個體。 若了解如何在 APIM 執行個體上設定可用性區域支援,請參閱在 APIM 執行個體上啟用可用性區域支援 (部分內容可能是機器或 AI 翻譯)。 各種設定選項均無停機需求。

    當您變更可用性區域設定時,變更可能需要 15 到 45 分鐘以上才能套用。 API 管理閘道可以繼續處理這段時間內的 API 要求。

    變更可用區域組態會觸發公用和私有 IP 位址變更

容量規劃和管理

在區域關閉案例中,無法保證另一個可用性區域中額外容量的要求會成功。 遺失單位的回填會以最佳方式進行。 如果您需要可用性區域失敗時的保證容量,則應該透過以下所有動作建立和設定 APIM 執行個體,以計算失去一個區域的情況:

  • 過度佈建 APIM 執行個體的單位。

  • 使用自動或區域備援可用性區域設定。

如需詳細資訊,請參閱 使用過度布建來管理容量

使用容量計量和您自己的測試來判斷提供所需閘道效能的單位數目。 如需如何縮放和升級服務執行個體的詳細資訊,請參閱升級和縮放 APIM 執行個體 (部分內容可能是機器或 AI 翻譯)。

所有區域都狀況良好時的行為

本節說明當 APIM 執行個體設定為可用性區域支援,且所有可用性區域皆可運作的情況。

  • 區域之間的流量路由: 在正常作業期間,流量會在所有選取的可用性區域的所有可用 API 管理 單位之間路由傳送。

  • 區域之間的資料複寫:APIM 會儲存並複寫下列資料。

    • 閘道設定,例如 API 和原則定義,會在您為執行個體選取的可用性區域之間定期同步處理。 可用性區域之間的更新傳播通常需要不到 10 秒的時間。

    • 內部快取中的資料,如果您使用 APIM 所提供的內部快取。 快取項目會分散於可用性區域。 內部快取是變動性的,而且不保證資料會保存。 如果您需要保存快取的資料,請考慮使用外部快取。

    • 速率限制計數器,如果您使用 APIM 所提供的速率限制功能。 速率限制計數器會在您為執行個體選取的可用性區域之間以非同步方式複寫。

區域失敗期間的行為

本節說明當 APIM 執行個體設定為可用性區域支援,且可用性區出現中斷時的預期情況。

  • 偵測和回應:偵測和回應的責任取決於您執行個體使用的可用性區域設定。

    • 自動和區域備援:針對設定為使用自動可用性區域支援或手動設定為使用區域備援的執行個體,APIM 平台會負責偵測可用性區域中的失敗並回應。 您不需要執行任何動作即可起始區域容錯移轉。

    • 區域: 針對設定為區域性的執行個體,您必須偵測可用性區域遺失,並起始容錯移轉至您在另一個可用性區域中建立的次要執行個體。

  • 作用中請求: 當可用性區域無法使用時,連線到錯誤可用性區域中 API 管理 單位的任何進行中要求都會終止,而且需要重試。

  • 預期的資料遺失:APIM 會儲存下列資料。

    • 閘道組態變更,會在大約 10 秒內複寫至每個選取的可用區域。 如果可用性區域中斷,您可能會遺失未複寫的設定變更。

    • 內部快取中的資料 (如果您使用內部快取功能)。 內部快取是變動性的,而且不保證資料會保存。 在可用性區域中斷期間,您可能會遺失部分或所有快取的資料。 如果您需要保存快取的資料,請考慮使用外部快取。

    • 速率限制計數器 (如果您使用速率限制功能)。 在可用性區域中斷期間,倖存區域中的速率限制計數器可能不是最新的。

  • 預期的停機:預期的停機取決於執行個體使用的可用性區域設定。

    • 自動:您可以預期使用自動可用性區域支援的執行個體在可用性區域中斷期間不會停機。 未受影響區域或區域中的單位繼續工作。

      您也可以預期,即使是使用自動可用性區域支援但僅有單一單位的執行個體,也不會發生停機。 在此情況下,API 管理 會將單位的基礎 VM 散發至兩個區域。 未受影響區域中的虛擬機器會繼續運作。

    • 區域備援:您可以預期在可用性區域中斷期間,區域備援執行個體不會停機。

    • 區域: 對於區域執行個體,當區域無法使用時,您的執行個體將無法使用,直到可用區域復原為止。

  • 交通重新路由: 流量重新路由行為取決於執行個體使用的可用區域組態。

    • 自動和區域備援:針對設定為使用自動可用性區域支援或手動設定為使用區域備援的執行個體,當區域無法使用時,受影響區域中的任何單位也無法使用。 您可以選擇擴展執行個體以新增更多單位。

    • 區域:若為區域性執行個體,當區域無法使用時,您的執行個體將無法使用。 如果您在另一個可用區域中有次要執行個體,則您負責將流量重新路由至該次要執行個體。

區域復原

區域復原行為取決於執行個體使用的可用區域組態。

  • 自動和區域備援:針對設定為使用自動可用性區域支援或手動設定為使用區域備援的執行個體,當可用性區域復原時,APIM 會自動還原可用性區域中的單位,並正常重新路由傳送單位之間的流量。

  • 區域性: 對於區域性執行個體,在可用區域復原後,您負責將流量重新導向回原本可用區域中的該執行個體。

測試區域失敗

測試區域失敗的選項取決於您執行個體所使用的可用性區域設定。

  • 自動和區域備援:針對設定為使用自動可用性區域支援或手動設定為使用區域備援的執行個體,APIM 平台會管理流量路由傳送、容錯移轉和容錯回復。 此功能完全受控,因此您不需要起始或驗證可用性區域失敗程序。

  • 區域:對於區域執行個體,沒有任何方法可以模擬包含 APIM 執行個體的可用性區域中斷。 不過,您可以手動設定上游閘道或負載平衡器,以將流量重新導向至不同可用區域中的不同執行個體。

對區域範圍故障的復原能力

透過多區域部署,您可以將區域 API 閘道新增至一或多個支援的 Azure 區域中的現有 API 管理 執行個體。 多區域部署有助於減少地理上分散的 API 取用者所感知的任何請求延遲。 如果一個區域離線,多區域部署也會提高服務可用性。

Microsoft 管理的多區域部署

APIM 僅支援進階 (傳統) 層中的多區域部署。 它不支援使用量、開發人員、基本、基本 v2、標準、標準 v2 和進階 v2 (預覽) 層中的多區域部署。 如需詳細資訊,請參閱 需求

當您新增區域時,您可以設定:

需求

  • 地區支援: 您可以使用任何支援 API 管理 的 Azure 區域,在進階 (傳統) 層中建立多區域部署。 若要查看哪些區域支援多區域部署,請參閱各區域的產品供應情形 (英文)。

  • 等級要求: 您必須使用進階 (傳統) 層來設定多區域支援。 若要將執行個體升級至進階 (傳統) 層,請參閱 升級至進階層

備註

具有企業功能的進階 v2 層為預覽版。 若要判斷您的設計是否應該依賴早期存取功能或正式運作的功能,請評估您的設計和實作時程表,以瞭解 Premium v2 版本和移轉路徑的可用資訊。

考慮事項

  • 僅限閘道: 只有 API 管理 實例的閘道元件會複寫至多個區域。 執行個體的管理平面和開發人員入口網站只會裝載在您最初部署服務的主要區域中。

  • 網路需求:如果您想要在虛擬網路中部署 APIM 執行個體時設定次要位置,虛擬網路和子網路區域應該符合您設定的次要位置。 如果您新增、移除或啟用主要區域中的可用性區域,或變更主要區域的子網路,則 APIM 執行個體的虛擬 IP (VIP) 位址會變更。 如需詳細資訊,請參閱 IP 位址的變更 (部分內容可能是機器或 AI 翻譯)。 不過,如果要新增次要區域,則主要區域的 VIP 不會變更,因為每個區域都有自己的私人 VIP。

  • 網域名稱系統 (DNS) 名稱:每個區域 (包括主要區域) 中的閘道都有遵循 https://<service-name>-<region>-01.regional.azure-api.net URL 模式的區域 DNS 名稱,例如 https://contoso-westus2-01.regional.azure-api.net

費用

新增區域會產生成本。 如需詳細資訊,請參閱 API 管理 定價

設定多區域支援

若要在 APIM 執行個體上設定多區域支援,請參閱將 APIM 執行個體部署到多個 Azure 區域 (部分內容可能是機器或 AI 翻譯)。

若要從 APIM 執行個體移除區域,請參閱移除 APIM 服務區域 (部分內容可能是機器或 AI 翻譯)。

容量規劃和管理

在區域關閉案例中,無法保證另一個區域中額外容量的要求會成功。 如果您需要在一個區域失敗時保證容量,您應該建立和設定 APIM 執行個體,以計算失去一個區域的情況。 您可以透過過度佈建 APIM 執行個體的容量來執行此動作。 若想進一步了解過度佈建的原則,請參閱 使用過度佈建管理容量

在多區域部署中,自動縮放僅適用於主要區域。 次要區域需要手動調整縮放或由您掌控的自訂工具。

當所有區域都正常時的行為

本節說明當 APIM 執行個體設定為多區域支援,且所有區域均可運作時的預期情況。

  • 區域之間的流量路由傳送:APIM 會自動將輸入要求路由傳送至區域閘道。 要求會路由傳送至用戶端延遲最低的區域閘道。 如果您需要使用不同的路由方法,您可以使用自訂路由規則來設定您自己的流量管理員。 如需詳細資訊,請參閱 使用自訂路由至 API 管理 區域閘道

    當要求到達 APIM 區域閘道時,除非原則直接從閘道傳回回應,例如快取的回應或錯誤碼,否則它會路由傳送至後端 API。 在多區域解決方案中,您必須謹慎將路由導向至符合效能需求的後端 API 執行個體。 如需詳細資訊,請參閱 將 API 呼叫路由至區域後端服務

  • 區域之間的資料複寫: 閘道組態 (例如 API 和原則定義) 會在您新增的主要區域和次要區域之間定期同步處理。 將更新傳播至區域閘道通常需要不到 10 秒的時間。

    內部快取中的速率限制計數器和資料是區域特定的,因此不會在區域之間複寫。

區域失敗期間的行為

本節將說明當 APIM 執行個體設定為多區域支援,而您使用的其中一個區域發生中斷時,該如何處理。

  • 偵測和回應:APIM 會負責偵測區域中的失敗,並自動容錯移轉至其中一個您設定的其他區域中的閘道。

  • 作用中要求:在錯誤區域中處理的任何作用中要求可能會遭到捨棄,而且應該由用戶端重試。

  • 預期的資料遺失:除了設定、快取和速率限制計數器之外,APIM 不會儲存資料。

    組態變更會在大約 10 秒內複寫到每個區域。 如果主要區域發生中斷,您可能會遺失未複寫的設定變更。

    內部快取中的速率限制計數器和資料是區域特定的,因此不會在區域之間複寫。

  • 預期的停機:預期閘道不會停機。

    若主要區域離線,則 APIM 管理平面與開發人員入口網站會變得無法使用,但次要區域會繼續使用最新的閘道設定來提供 API 要求的服務。

  • 交通重新路由: 如果區域離線,API 請求會自動繞過失敗的區域路由到下一個最近的閘道。

區域復原

當主要區域復原時,APIM 會自動還原區域中的單位,並在您的單位之間重新路由傳送流量。

區域故障測試

為了準備好應對意外的區域停機,我們建議您定期測試您對區域故障的回應。 您可以藉由停用路由至區域閘道來模擬區域失敗的某些層面。

備份與還原

APIM 不會儲存大部分的執行階段資料。 不過,您可以備份 APIM 服務設定。 您也可以使用備份與還原作業,在作業環境之間複寫 APIM 服務設定,例如開發和暫存。

這很重要

在備份程序中,會包含執行時期資料,例如使用者和訂閱,這可能不一定是理想的。

開發人員、基本、標準和進階層支援備份。

如需詳細資訊,請參閱如何在 APIM 中使用服務備份與還原實作災害復原 (部分內容可能是機器或 AI 翻譯)。

針對某些服務元件或資源的備份或還原,您也可以考慮客戶管理的選項,例如 APIOps 工具 (部分內容可能是機器或 AI 翻譯) 和基礎結構即程式碼 (IaC) 解決方案。

服務維護的韌性

APIM 會執行一般服務升級和其他形式的維修。

在 Basic、Standard 和 Premium (傳統) 方案中,您可以自訂執行個體在更新程序中何時收到更新。 如果您需要驗證升級對工作負載的影響,請考慮將測試執行個體設定為在更新週期的早期接收更新,並將生產執行個體設定為在週期後期接收更新。 您也可以指定維護視窗,也就是希望執行個體套用服務更新的時間。

如需詳細資訊,請參閱設定 APIM 執行個體的服務更新設定 (部分內容可能是機器或 AI 翻譯)。

服務等級協定

Azure 服務的服務等級協定 (SLA) 描述服務的預期可用性,以及解決方案必須符合才能達到該可用性預期的條件。 如需詳細資訊,請參閱 在線服務的 SLA

當您在多個可用性區域或區域中部署 API 管理 執行個體時,SLA 中定義的正常運行時間百分比會增加。

此服務提供自己的 SLA,但您也需要考慮其他工作負載元件 (例如 API 後端) 的預期可靠性。