Azure Functions 是一個事件驅動的運算服務，讓你能執行小區塊的程式碼（函式），而不必明確配置或管理基礎設施。 函式能回應 HTTP 請求、計時器、佇列訊息及其他 Azure 服務的變更，非常適合處理資料、整合系統及執行背景任務。
當您使用 Azure 時， 可靠性是共同的責任。 Microsoft 提供一系列功能來支援韌性和復原。 您有責任瞭解這些功能在您使用的所有服務中如何運作，並選取符合業務目標和正常運作時間目標所需的功能。
本文說明如何讓 Azure Functions 對各種潛在的中斷與問題具備韌性，包括暫時性故障、可用性區故障及區域性故障。 同時也強調了 Azure Functions 服務水準協議（SLA）的關鍵資訊。
生產部署建議
Azure Well-Architected Framework 提供可靠性、效能、安全性、成本和作業的建議。 欲了解這些領域如何相互影響並促成可靠的 Azure Functions 解決方案，請參閱 Azure Functions 架構最佳實務。
可靠性架構概觀
部署 Azure Functions 時，熟悉幾個概念非常重要：
主機方案： 方案代表你的功能應用程式的主機環境。 計畫決定可用的運算資源、定價模型及擴展行為。
儲存帳戶： 當你建立功能應用程式時，必須指定主機儲存帳號。 儲存帳號用於管理函式應用程式內部操作的各個面向，包括函式程式碼儲存、日誌記錄及並行管理（例如特定觸發類型的 blob 租約）。
你也可以用儲存帳號來部署。 這個儲存帳號可能和你的主機儲存帳號相同，也可能是不同的儲存帳號。
這很重要
儲存帳號是你 Azure Functions 可靠性架構中的關鍵部分，你應該將它們配置成符合函數應用程式韌性需求的條件。
觸發器與綁定：這些使你的函式能夠回應事件、接收並寫入其他服務的資料。
耐用功能： 持久函式是有狀態的函式，包括長期執行的協調和有狀態實體。
使用耐用函數時，你會設定一個 儲存提供者，該提供者會儲存狀態。 你需要評估你選擇的狀態儲存的可靠性特性，並設定它以符合你的韌性需求。
對瞬態故障的彈性
暫時性錯誤是元件中的短暫間歇性失敗。 它們經常出現在雲端等分散式環境中，而且是作業的一般部分。 暫時性錯誤會在短時間內自行修正。 請務必確保您的應用程式能妥善處理暫時性錯誤，通常透過重試受影響的請求來進行。
所有雲端託管應用程式在與任何雲端託管的 API、資料庫及其他元件通訊時，都應遵循 Azure 暫態故障處理指引。 如需詳細資訊，請參閱 處理暫時性錯誤的建議。
請參考以下處理功能應用暫態故障的建議：
觸發條件與綁定： Azure Functions 平台內建多種觸發器與綁定的暫態錯誤處理功能。 當支援的觸發器觸發或受支援的綁定正在讀寫資料時發生瞬態故障時，平台可以自動重試該操作。 這種內建的重試行為有助於確保暫時的連線問題或服務延遲不會阻礙你的功能執行。 欲了解更多資訊，請參閱 Azure Functions 錯誤處理與重試。
然而，這項保護僅涵蓋短暫故障。 持續失敗，例如連線字串設定錯誤或資源被刪除，則不會重試。
持續性失敗和反覆的暫態失敗會被視為錯誤，你可以設定日誌來捕捉函式執行錯誤的資訊。 更多資訊請參見 如何設定 Azure Functions 監控。
你的功能代碼： 在你的職能體系中，你負責處理撥打外部服務時的暫時性故障。 你應該在函式程式碼中對任何外部服務呼叫，適當地實作重試邏輯、時間限制和斷路器模式。 盡可能設計你的函式為冪能，避免重試產生重複副作用。
客戶： 任何以同步方式連接函式（例如透過 HTTP 連線）的用戶端應用程式，都應該能對暫時性錯誤具備韌性。
對可用性區域故障的抵抗力
可用性區域 是 Azure 區域內物理上獨立的資料中心群組。 當某個區域發生故障時，服務可以切換至其他剩餘的區域。
消費方案不支援可用性區。 如果您的工作負載需要區域冗餘，建議改用彈性消費方案、高級方案或專用（App Service）方案類型。
彈性消費方案支援區域冗餘部署。
高級方案支援區域冗餘部署。
啟用區域冗餘後，平台會自動將你的方案實例分散到所選區域內所有可用區域。 如果該區域的任何可用區域出現問題，你的功能仍會繼續在正常的可用區域的實例上執行。
你還必須在主機儲存帳號啟用區域冗餘儲存（ZRS），以確保它對區域中斷有韌性。
專用（App Service）計畫支援區域冗餘部署。 啟用區域冗餘後，平台會自動將你的實例分散到所選區域內所有可用區域。 你要在圖紙上設定區域冗餘。 關於 App Service 如何處理區域冗餘的完整細節，請參閱 Azure App Service 中的可靠性。
如果你沒有啟用區域冗餘，你的計畫就是 非區域 性或 區域性的，這表示計畫實例可能會被放置在區域內或同一區域內的任何可用區域，且它們無法抵抗可用性區域故障。 在這個地區的任何區域發生停電時，您的方案可能會遇到停機。
要求
- 區域支援： 區域冗餘彈性消耗計畫可部署至特定區域。 你可以使用 Azure CLI 取得目前支援的區域清單。 欲了解更多資訊，請參閱 「查看支援可用區域的區域」。
區域支援： 區域冗餘的高級方案可部署至以下區域：
美洲 歐洲 中東 Africa 亞太地區 巴西南部 法國中部 以色列中部 南非北部 Australia East 加拿大中部 德國中西部 卡達中部 印度中部 Central US 義大利北部 阿拉伯聯合大公國北部 中國北部 3 美國東部 北歐 東亞 美國東部 2 挪威東部 日本東部 美國中南部 瑞典中部 東南亞 美國西部 2 瑞士北部 美國西部 3 英國南部 西歐 作業系統： 支援 Windows 和 Linux 方案。
最低實例數： 啟用區域冗餘時，Premium 方案至少需有兩個隨時待命的實例。
- 主機儲存帳號：你必須設定功能應用程式的預設主機儲存帳號，使其使用區域冗餘儲存（ZRS）。 如果你使用的主機儲存帳號沒有設定 ZRS，應用程式在區域斷線時可能會出現意外行為。
- 部署容器儲存帳號： 如果你用獨立的儲存帳號來存放應用程式的部署容器，也應該更新成區域冗餘。
考慮事項
區域冗餘僅保證已部署應用程式的持續運作時間。 可用性區域中斷可能會影響 Azure Functions 的某些面向，即使應用程式仍在持續服務流量。 這些行為包括計畫擴展、應用程式建立、應用程式設定及應用程式發佈。
跨區域分佈的執行個體
當你將彈性消費方案應用程式設定為區域冗餘時，平台會自動將方案實例分散到所選區域的多個區域，並對隨時準備實例與按需實例有不同的規則：
隨時可用的實例 會輪流分配到至少兩個區域。
為確保區域韌性，平台自動為每個 函式縮放函數或群組維護至少兩個隨時準備的實例，無論應用程式的配置為何。 平台所建立的任何執行個體都是由平台管理、以隨時待命執行個體形式計費，而且不會變更隨時待命組態設定。
應用程式在擴展超出隨時可用實例數量時，因事件來源的變化而創建隨需實例。 按需實例以最佳努力基準分散在各可用性區域。 更重視快速擴展，而非區域間均勻分布。 平台試圖隨著時間推移讓分布趨於均衡。
當你將 Elastic Premium 功能應用方案設定為區域冗餘時，平台會自動將方案實例分散到所選區域的多個區域。 實例擴散遵循以下規則，即使應用程式會逐步擴展與縮小：
- 函式應用程式實例計數下限為兩個。
- 當您指定大於區域數目的容量時，只有當容量是區域數目的倍數時，實例才會平均分散。
- 對於容量值超過區域數乘以實例數，額外的實例會分散到剩餘的區域。
當 Functions 將實例分配給區域冗餘高級方案時，會使用底層 Azure 虛擬機縮放集所提供的 盡力而為區域平衡。 Premium 方案被視為 平衡 方案是指每個區域在 Premium 方案使用的其他所有區域中擁有相同數量的虛擬機，或者多一台或少一台虛擬機。
Cost
啟用區域冗餘不會帶來額外費用。 區域冗餘方案的定價與單區域方案相同。
然而，當你在一個應用程式中啟用可用性區域，且每個 函式縮放函數或群組的實例數少於兩個，平台會自動為每個函式縮放函數或群組建立兩個 「隨時準備就緒 」類型的實例。 這些新執行個體也會以隨時待命執行個體形式計費。
然而，如果你在一個實例少於兩個的方案啟用可用性區域，平台會強制該方案至少有兩個實例，並且你會被收取兩個實例的費用。
完整價格詳情請參見 Azure Functions 定價。
設定可用性區域支援
建立一個新的區域冗餘 Azure Functions 方案。 你可以在建立新計畫時啟用區域冗餘。 詳細步驟請參見 建立區域冗餘功能應用程式。
在現有計畫上啟用區域冗餘： 你可以更新現有的彈性消費方案以啟用區域冗餘。 詳細步驟請參閱「 現有計畫啟用區域冗餘」。
建立新的區域性冗餘 Azure Functions 計畫。 你可以在建立新計畫時啟用區域冗餘。 詳細步驟請參見 建立區域冗餘功能應用程式。
在現有計畫上啟用區域冗餘： 對於高級方案，你只能在建立方案時啟用區域冗餘。 你不能將現有的進階方案轉換成具區域冗餘的方案。 你必須透過在新的高級方案應用程式上建立並行部署來遷移你的應用程式。 欲了解更多資訊，請參閱 「現有計畫啟用區域冗餘」。
容量規劃和管理
即使區域內的區域出現故障，區域冗餘功能應用程式仍持續運行。
在區域中斷期間，Azure Functions 會偵測遺失的實例，並自動嘗試在健康區域中尋找或建立替代實例。 這個過程是盡力而為，並非保證成功。 如果你的工作負載必須有一定數量的實例才能維持預期的服務水準，那麼可以考慮 超額配置 持續可用的實例數量。 這種方法可讓解決方案容許某些容量遺失並繼續運作，而不會降低效能。 如需詳細資訊，請參閱使用超額佈建來管理容量。
所有區域都狀況良好時的行為
本節說明當計畫為區域冗餘、主機儲存帳號使用 ZRS 且所有可用區域皆正常運作時，應預期的情況。
跨區作業： 當你在 Azure Functions 設定區域冗餘時，請求會自動分散到每個可用區域的實例。 請求可以發送到任何可用區域的任意實例。
跨區域資料複製： Azure Functions 是一個無狀態的運算服務，所以沒有客戶資料需要在區域間複製。 該平台能自動複製跨區域的配置。
如果你的主機儲存帳號使用 ZRS，Azure Storage 會同步複製其資料到多個可用區域。
關於耐用功能，請檢視你的儲存服務供應商，了解它如何跨區域複製資料。
區域失敗期間的行為
本節說明當計畫區域冗餘、主機儲存帳號使用 ZRS 且出現可用性區中斷時，會發生什麼情況。
- 偵測與回應： Azure Functions 平台負責偵測可用性區域的故障。 您不需要執行任何動作即可起始區域容錯移轉。
- 通知：Microsoft 不會在區域關閉時自動通知您。 不過，你可以使用 Azure Resource Health 監控單一資源的健康狀況，並設定資源 健康警示 來通知你問題。 你也可以使用 Azure Service Health 來了解整體服務的健康狀況，包括任何區域故障，並設定 服務健康警示 來通知你問題。
目前的請求： 當可用區無法使用時，任何連接於故障可用區實例的進行請求都會被終止，並需重試。 確定您的應用程式已遵循暫時性錯誤處理指導來做好準備。
預期資料遺失： 區域故障通常不會導致資料遺失，因為 Azure Functions 是無狀態服務。
如果你的主機儲存帳號使用 ZRS，Azure Storage 則可確保區域故障不會造成資料遺失。
關於耐用功能，請檢視您的儲存供應商，了解區域故障時是否有可能資料遺失。
預期的停機時間： 在區域中斷期間，連線可能會短暫中斷，通常持續幾秒鐘，因為流量會重新分配。 確定您的應用程式已遵循暫時性錯誤處理指導來做好準備。
交通改道： Azure 函式會偵測該區域中遺失的實例，並嘗試尋找新的替代實例。 Azure 函式找到替代實例後，會根據需要將流量分配到新的實例。
這很重要
在區域關閉的案例中，Azure 不保證要求更多執行個體一定會成功。 平台會嘗試以最佳方式回填遺失的執行個體。 如果您需要在可用區失效時保證容量，請通過超額配置容量來建立並配置計畫，以應對區域損失。
非執行時行為： 區域冗餘功能應用程式計畫中的應用程式即使可用性區域發生故障，仍持續運行並服務流量。 不過，在可用性區域中斷期間，非執行階段行為仍會受到影響。 這些行為包括函式應用程式縮放、應用程式建立、應用程式設定及應用程式發佈。
區域復原
當可用區域恢復時，Azure Functions 會自動還原該區域內的實例，移除其他可用區域中建立的臨時實例，並照常在你的實例間重新路由流量。
測試區域失敗
Azure Functions 平台負責管理區域冗餘資源的流量路由、故障轉移及區域恢復。 您不需要開始任何事情。 由於此功能是完全管理的，您不需要驗證可用區的故障程序。
對區域範圍故障的復原能力
Azure Functions 是一個單一區域的服務。 如果區域無法使用，你的 Azure Functions 資源也會無法使用。
自訂多區域解決方案，以實現復原能力
若要避免在中斷期間遺失執行，您可以重複地將相同的函式部署至多個區域中的函數應用程式。
你負責：
- 將函式應用程式部署到多個區域
- 管理區域間的流量分配
- 實現故障轉移機制
- 確保跨區域資料一致性（如適用）
- 監控與管理跨區域部署
當你在多個區域執行相同的函式程式碼時，有兩種常用的模式可以考慮：主動-主動與主動-被動。 以下章節簡要介紹這些圖案，但不會提供詳細指引或配置步驟。
HTTP 觸發程序函式的主動-主動模式
透過主動-主動模式，兩個地區中的函式會以重複的方式或輪流的方式來主動執行和處理事件。 你應該搭配 Azure Front Door 使用主動-主動模式來處理重要的 HTTP 觸發函式，這些函式可以在多個區域中執行的函式之間進行路由和輪詢 HTTP 請求。 Azure Front Door 也能定期檢查每個端點的健康狀況。 如果某區域的函數停止回應健康狀態檢查，Azure Front Door 會將其從流量路由中移除，只會將流量轉發給剩餘的健康函數。
非 HTTP 觸發函式的主動-被動模式
對於事件驅動、非 HTTP 觸發函式（如服務匯流排和事件樞紐觸發函式），則使用主動-被動模式。 採用主動-被動模式時，函式會在接收事件的區域主動執行，而第二個區域的相同函式則保持閒置。 主動-被動模式提供一種只有單一函式處理每個訊息的方式，這對維持資料一致性非常重要，同時也提供了在災難（如區域中斷）時切換到次要區域的機制。
功能應用程式的故障轉移需要與其他服務的故障轉移行為一併考量，例如：
考慮一個以 Azure Event Hubs 觸發器為範例的拓撲結構，您的事件中心命名空間 (Namespace) 設定為地理災難復原。 在此情況下，主動-被動模式需要以下成分：
- 部署至主要和次要地區的 Azure 事件中樞。
- 地理災難復原可將 主事件中心與次要事件樞紐配對。 這也會建立一個 別名 ，讓你用來連接 Event Hubs 命名空間，並在不改變連線資訊的情況下從主節點切換到次節點。
- 功能應用程式部署在主要和次要（故障轉移）區域，次要區域的應用程式基本上處於閒置狀態，因為訊息無法傳送到那裡。
- 在其對應的事件中心命名空間中，函式應用程式會在 直接（非別名）連線字串上觸發。
- 發佈者應該將內容發佈到活動中心命名空間的「別名」連線字串。
容錯移轉之前，發行者會傳送至主要事件中樞的共用別名路由。 主要函數應用程式會獨佔接聽主要事件中樞。 次要函數應用程式為被動和閒置。
一旦起始容錯移轉後，傳送至共用別名的發行者就會路由傳送至次要事件中樞。 次要函式應用程式現在會變成主動，並開始自動觸發。 有效的容錯移轉至次要區域可完全從事件中樞驅動，且只有在個別的事件中樞為主動時，函式才會變成主動。
耐用功能
關於多區域的 Durable Functions 災難復原，請參見 Azure Durable Functions 中的災難復原與地理分布。
服務維護的韌性
Azure Functions 執行定期的服務升級及其他維護任務。
- 瞬態故障韌性： 在服務維護期間，執行你功能應用程式的實例可能會被重新啟動或暫時中斷。 確保任何與你功能應用程式互動的客戶端應用程式都能 對短暫故障具備韌性。
- 啟用區域冗餘： 當你在計畫中啟用區域冗餘時，也能提升平台更新時的韌性。 在你的計畫中部署多個實例並為你的計畫啟用區域冗餘，能在升級過程中實例或區域變得不健康時，增加額外的韌性。
為了維持升級時的預期容量，平台會在升級過程中自動新增額外的方案實例。
- 啟用區域冗餘： 當你在計畫中啟用區域冗餘時，也能提升平台更新時的韌性。 更新網域包含更新期間離線的 VM 集合，且它們會對應至可用性區域。 在你的計畫中部署多個實例並為你的計畫啟用區域冗餘，能在升級過程中實例或區域變得不健康時，增加額外的韌性。
應用服務環境： 如果你把函式應用程式架設在 App Service 環境上，可以自訂升級週期。 如果您需要驗證升級對工作負載的影響，請啟用手動升級。 此方法可讓您先在非生產執行個體上執行驗證和測試，再將其套用至生產執行個體。
如需維護喜好設定的詳細資訊，請參閱升級 App Service 環境計劃性維護的喜好設定。
對應用程式部署的韌性
應用程式部署會為生產環境帶來問題的風險。 如果更新造成問題，你應該準備好回滾。 你也應該控制更新的推出方式，以減少應用程式重啟帶來的干擾。
彈性消費方案支援 網站更新策略，提供多種方式部署應用程式更新，包括用於零停機部署的滾動更新。
Azure Functions 部署插槽可以實現您的函數應用程式零停機部署。 使用部署插槽，將部署和設定變更對使用者的影響降到最低。 部署位置也會降低應用程式重新啟動的可能性。 重新啟動應用程式會導致暫時性錯誤。
服務等級協定
Azure 服務的服務層級協議（SLA）描述了每項服務的預期可用性，以及您的解決方案必須符合的條件，以達成該可用性預期。 欲了解更多資訊，請參閱線上服務的服務等級協議。
Azure Functions 為消費型方案及其他方案類型提供不同的可用性 SLA。