Azure Functions 中的可靠性
本文說明 Azure Functions 的可靠性支援，並涵蓋可用性區域的區域內復原能力，以及跨區域復原和商務持續性。 如需更多關於 Azure 可靠性準則的詳細概觀，請參閱 Azure 可靠性。
進階方案 (Elastic Premium) 和專用方案 (App Service) 提供 Azure Functions 的可用性區域支援。 本文著重於進階方案的區域備援支援。 如需專用方案的區域備援，請參閱將 App Service 移轉至可用性區域支援。
可用性區域支援
可用性區域是每個 Azure 區域內的數據中心實體分隔群組。 當某個區域失敗時，服務可以故障轉移至其中一個其餘區域。
如需 Azure 中可用性區域的詳細資訊，請參閱 什麼是可用性區域？。
Azure Functions 支援區域備援部署。
當您將 Functions 設定為區域備援時，平台會自動將函式應用程式執行個體分散到所選地區中的三個區域。
即使應用程式的規模縮減或擴增，透過區域備援部署進行散佈的執行個體仍是由以下規則決定的：
- 最小的函式應用程式執行個體數為三個。
- 當您指定的容量大於 3 時，只有在容量是 3 的倍數時，執行個體才會平均分散。
- 針對超過 3*N 的容量值，額外的執行個體會分散到其餘的一個或兩個區域。
重要
Azure Functions 可在 Azure App Service 平台上執行。 在 App Service 平台中，裝載進階 (Premium) 方案函式應用程式的方案稱為彈性進階 (Elastic Premium) 方案，其 SKU 名稱如 EP1。 如果您選擇在進階方案執行函數應用程式，請務必使用以「E」開頭的 SKU 名稱來建立方案，例如 EP1。 以「P」開頭的 App Service 方案 SKU 名稱，例如 P1V2 (進階 V2 小型方案)，實際上是專用主控方案。 因為是專用而非彈性進階方案，因此 SKU 名稱開頭為「P」的方案不會動態調整，而且可能會增加您的成本。
區域可用性
區域備援進階方案可在下列區域中使用：
| 美洲 | 歐洲 | 中東 | 非洲 | 亞太地區 |
|---|---|---|---|---|
| 巴西南部 | 法國中部 | 以色列中部 | 南非北部 | 澳大利亞東部 |
| 加拿大中部 | 德國中西部 | 卡達中部 | 印度中部 | |
| 美國中部 | 義大利北部 | 阿拉伯聯合大公國北部 | 中國北部 3 | |
| 美國東部 | 北歐 | 東亞 | ||
| 美國東部 2 | 挪威東部 | 日本東部 | ||
| 美國中南部 | 瑞典中部 | 東南亞 | ||
| 美國西部 2 | 瑞士北部 | |||
| 美國西部 3 | 英國南部 | |||
| 西歐 |
必要條件
可用性區域支援是進階方案的屬性。 以下是啟用可用性區域的目前需求/限制：
- 只有在建立函數應用程式的進階方案時，您才能啟用可用性區域。 您無法將現有的進階方案轉換為使用可用性區域。
- 您必須針對函數應用程式的儲存體帳戶使用區域備援儲存體帳戶 (ZRS)。 如果您使用不同類型的儲存體帳戶，Functions 可能會在區域性中斷期間顯示非預期的行為。
- 支援 Windows 和 Linux。
- 必須裝載在 Elastic Premium 或專用裝載方案上。 若要了解如何搭配使用區域備援與專用方案，請參閱將 App Service 移轉至可用性區域支援。
- 可用性區域支援目前不適用於取用方案上的函數應用程式。
- 在進階方案上裝載的函數應用程式必須有至少三個隨時就緒的執行個體計數。
- 如果您指定少於三個執行個體計數，則平台會在幕後強制執行此最小計數。
- 如果您未使用進階方案或是支援可用性區域的縮放單位、位於不支援的區域，或不確定，則請參閱移轉指導。
定價
沒有與啟用可用性區域相關聯的額外成本。 區域備援進階方案的定價與單一區域進階 App Service 方案相同。 針對您所使用的每個 App Service 方案，會根據您所選擇的 SKU、您所指定的容量，以及您根據自動調整準則調整到的任何執行個體來向您收費。 如果您啟用可用性區域，但針對 App Service 方案指定的容量小於 3，則平台會針對該 App Service 方案強制執行三個執行個體的最小執行個體數，並向您收取這三個執行個體的費用。
建立區域備援進階方案和函式應用程式
目前有兩種方式可以部署區域備援進階方案和函數應用程式。 您可以使用 Azure 入口網站或 ARM 範本。
在 Azure 入口網站中，移至 [建立函數應用程式] 頁面。 如需在入口網站中建立函數應用程式的詳細資訊，請參閱建立函數應用程式。
選取 [Functions 進階]，然後選取 [選取] 按鈕。 本文會詳細說明如何在進階方案中建立區域備援應用程式。 目前在取用方案中無法使用區域備援。 如需 App Service 方案的區域備援資訊，請參閱 Azure App Service 的可靠性。
在 [建立函數應用程式 (Functions 進階)] 頁面的 [基本] 索引標籤上，輸入函數應用程式的設定。 請特別注意下表中的設定 (在下列螢幕擷取畫面中也醒目提示)，這些設定具有區域備援的特定需求。
設定 建議的值 區域備援注意事項 區域 您慣用的支援區域 將建立新函數應用程式的區域。 您必須挑選支援可用性區域的區域。 請參閱區域可用性清單。 定價方案 其中一個彈性進階方案。 如需詳細資訊，請參閱可用的執行個體 SKU。 本文會詳細說明如何在進階方案中建立區域備援應用程式。 目前在取用方案中無法使用區域備援。 如需 App Service 方案區域備援的資訊，請參閱 Azure App Service 的可靠性。 區域備援 已啟用 這個設定會指定您的應用程式是否為區域備援。 除非您已選擇支援區域備援的區域，否則您將無法選取 Enabled，如先前所述。![函數應用程式建立頁面 [基本] 索引標籤的螢幕擷取畫面。](../azure-functions/media/functions-az-redundancy/azure-functions-basics-az.png)
在 [儲存體] 索引標籤上，輸入函數應用程式儲存體帳戶的設定。 請特別注意下表中的設定，其具有區域備援的特定需求。
設定 建議的值 區域備援注意事項 儲存體帳戶 區域備援儲存體帳戶 如上述先決條件一節中所述，強烈建議您針對區域備援函數應用程式使用區域備援儲存體帳戶。 針對函數應用程式建立流程的其餘部分，請依正常方式建立函數應用程式。 建立流程的其餘部分沒有會影響區域備援的設定。
建立和部署區域備援方案之後，新方案上裝載的任何函數應用程式都會被視為區域備援。
可用性區域移轉
Azure Function Apps 目前不支援就地移轉現有的函式應用程式執行個體。 如需如何將公用多租用戶進階方案從非可用性區域移轉至可用性區域支援的相關資訊，請參閱將 App Service 移轉至可用性區域支援。
區域關閉體驗
區域備援函式應用程式的所有可用函式應用程式執行個體都會啟用並處理事件。 區域關閉時，Functions 會偵測遺失的執行個體，並在需要時自動嘗試尋找新的取代執行個體。 彈性調整行為仍然適用。 不過，在區域關閉案例中，不保證其他執行個體的要求可以成功，因為會以盡力而為的方式對遺失執行個體進行回填。 即使同一地區中的其他區域發生中斷，部署在啟用了進階方案的可用性區域中的應用程式也可以持續執行。 不過，可能仍然會因其他可用性區域中的中斷而影響非執行階段行為。 這些受影響的行為可以包括進階方案調整、應用程式建立、應用程式設定和應用程式發佈。 進階方案的區域備援只會保證已部署應用程式的持續運作。
Functions 將執行個體配置給區域備援進階方案時，會使用基礎 Azure 虛擬機器擴展集所提供的最佳區域平衡。 每個區域在進階方案所使用的所有其他區域中具有相同數目的 VM (± 1 個 VM) 時，會將進階方案視為「平衡」。
跨區域災害復原和商務持續性
災害復原 (DR)是指從重大影響事件中復原，例如自然災害或不成功的部署 (導致停機和資料遺失)。 無論原因為何，解決災害的最佳辦法是定義完善且經過測試的 DR 方案，以及主動支援 DR 的應用程式設計。 開始思考建立災害復原方案之前，請參閱設計災害復原策略的建議。
Microsoft 在災害復原方面採取共同責任模型。 在共同責任模型中，Microsoft 確保基準基礎結構和平台服務可供使用。 此時，許多 Azure 服務不會自動複寫資料，或從失敗區域回復為交叉複寫到另一個已啟用的區域。 針對這些服務，您必須負責設定適用於您工作負載的災害復原計劃。 在 Azure 平台即服務 (PaaS) 供應項目上執行的多數服務，都有提供支援災害復原的功能和指導，您可以使用特定服務功能復原，制定災害復原方案。
本節說明您可用來部署 Functions 以允許進行災害復原的一些策略。
如需 Durable Functions 的災害復原，請參閱 Azure Durable Functions 中的災害復原和地理分散。
多地區災害復原
因為沒有內建的備援可用，所以 Functions 會在特定 Azure 地區中的函式應用程式中執行。 若要避免在中斷期間遺失執行，您可以重複地將相同的函式部署至多個區域中的函數應用程式。 若要深入了解多區域部署，請參閱高可用性的多區域 Web 應用程式中的指引。
當您在多個地區中執行相同的函式程式碼時，有兩種模式需要考慮：主動-主動和主動-被動。
HTTP 觸發程序函式的主動-主動模式
透過主動-主動模式，兩個地區中的函式會以重複的方式或輪流的方式來主動執行和處理事件。 建議您將主動-主動模式與 Azure Front Door 結合使用以處理重要的 HTTP 觸發函式，這樣可以在多個地區中執行的函式之間路由傳送和循環輪詢 HTTP 要求。 Front Door 也可以定期檢查每個端點的健康情況。 當某個地區中的函式停止回應健康情況檢查時，Azure Front Door 會將其從輪替中取出，並且只會將流量轉送至其餘健康情況良好的函式。
如需範例，請參閱如何藉由將 API 部署至分散式 Azure 區域中的地理區域，以 實作地理特徵模式的範例。
重要
儘管如此，強烈建議您對非 HTTPS 觸發程序函式使用主動-被動模式。 您可以為非 HTTP 觸發函式建立主動-主動部署。 不過，您必須考量兩個主動區域如何彼此互動或協調。 當您將相同的函數應用程式部署到兩個區域，並在相同的服務匯流排佇列上觸發時，其會做為將該佇列取消佇列的競爭取用者。 雖然這表示每個訊息只會由其中一個執行個體處理，但也表示單一服務匯流排執行個體上仍有單一失敗點。
您可以改為部署兩個服務匯流排佇列，其中一個位於主要區域，一個則位於次要區域中。 在此情況下，您可以有兩個函數應用程式，每個應用程式都指向其區域中的主動服務匯流排佇列。 此拓撲的挑戰是佇列訊息在兩個區域之間的散發方式。 通常，這表示每個發行者都會嘗試將訊息發佈至這兩個區域，而且每個訊息都會由這兩個主動的函數應用程式進行處理。 雖然這會建立所需的主動/主動模式，但其也會針對計算重複和資料合併的時間或方式，建立其他挑戰。
非 HTTPS 觸發程序函式的主動-被動模式
建議您對事件驅動的非 HTTP 觸發函式 (例如服務匯流排和事件中樞觸發的函式) 使用主動-被動模式。
若要為非 HTTP 觸發程序函式建立備援，請使用主動-被動模式。 在主動-被動模式下，函式會在接收事件的地區中主動執行；而第二個地區中的相同函式會保持閒置的狀態。 主動-被動模式提供了一種僅使用單一函式來處理每個訊息的方法，同時提供了一種在災害中容錯移轉到次要地區的機制。 函數應用程式會使用合作夥伴服務的容錯移轉行為，例如 Azure 服務匯流排異地復原和 Azure 事件中樞異地復原。
請考慮使用 Azure 事件中樞觸發程序的範例拓撲。 在此情況下，主動/被動模式需要包含下列元件：
- 部署至主要和次要地區的 Azure 事件中樞。
- 已啟用異地災害，以配對主要和次要事件中樞。 這也會建立別名，讓您可用來連線到事件中樞，並從主要中樞切換至次要中樞，而不需變更連線資訊。
- 函數應用程式會部署至主要和次要 (容錯移轉) 區域，而次要區域中的應用程式基本上是閒置狀態，因為訊息不會在該處傳送。
- 函數應用程式會在其個別事件中樞的直接 (非別名) 連接字串上觸發。
- 事件中樞的發行者應該發佈至別名連接字串。
容錯移轉之前，發行者會傳送至主要事件中樞的共用別名路由。 主要函數應用程式會獨佔接聽主要事件中樞。 次要函數應用程式為被動和閒置。 一旦起始容錯移轉後，傳送至共用別名的發行者就會路由傳送至次要事件中樞。 次要函式應用程式現在會變成主動，並開始自動觸發。 有效的容錯移轉至次要區域可完全從事件中樞驅動，且只有在個別的事件中樞為主動時，函式才會變成主動。