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