Azure Event Grid 是一項完全受管理的訊息服務，能實現服務與應用程式間的事件式通訊。 它常用於建構事件驅動架構以及將 Azure 服務與自訂應用程式整合。
當您使用 Azure 時， 可靠性是共同的責任。 Microsoft 提供一系列功能來支援韌性和復原。 您有責任瞭解這些功能在您使用的所有服務中如何運作，並選取符合業務目標和正常運作時間目標所需的功能。
本文說明如何讓 Azure Event Grid 對各種潛在的中斷與問題具備韌性，包括暫時性故障、可用性區域故障及區域性故障。 同時也強調了關於 Azure Event Grid 服務水準協議（SLA）的關鍵資訊。
生產部署建議
Azure Well-Architected Framework 提供關於可靠性、安全性、成本、營運與效能的建議。 欲了解這些領域如何相互影響並促成可靠的 Azure 事件網格解決方案，請參閱 Azure Well-Architected Framework 的 Azure 事件網格指引。
可靠性架構概觀
本節說明服務運作中從可靠性角度來看最為重要的部分。 本節介紹邏輯架構，包含你部署和使用的部分資源與功能。 它還討論了物理架構，其中提供了有關服務如何在幕後工作的詳細信息。
邏輯架構
Azure Event Grid 將事件從 事件發佈者 路由到事件 消費者。 它被客戶應用程式和 Azure 服務用來發送和消耗事件，例如資源建立、更新或刪除時的通知。
Event Grid 支援多種資源類型與部署模式：
主題 是接收並儲存事件的主要實體。
系統主題 由 Azure 服務自動建立，以發出特定 Azure 資源類型的事件。 自訂主題 由你建立和管理。
主題可以同時支援 推送和拉式傳送。
事件領域將 多個自訂主題集中於單一端點，簡化事件發布。 如需詳細資訊，請參閱 瞭解管理事件方格主題的事件網域。
命名空間 與標準層一起使用，並提供多個事件網格資源的容器。 欲了解更多資訊，請參閱 Azure 事件網格命名空間概念。
Event Grid 支援多個層級，包括基本層級與標準層級。 這些層級提供不同的功能，且在資源的部署和管理方式上有所不同。 欲了解更多資訊，請參閱 「為您的解決方案選擇合適的事件網格層級」。
實體架構
Azure Event Grid 是一個完全受控的服務。 Microsoft 管理底層基礎設施，包括運算與儲存資源。 在支援的區域中，事件網格 會自動將資源分配到可用區域 ，以提供內建區域冗餘。
對瞬態故障的彈性
暫時性錯誤是元件中的短暫間歇性失敗。 它們經常出現在雲端等分散式環境中，而且是作業的一般部分。 暫時性錯誤會在短時間內自行修正。 請務必確保您的應用程式能妥善處理暫時性錯誤，通常透過重試受影響的請求來進行。
所有雲端託管應用程式在與任何雲端託管的 API、資料庫及其他元件通訊時，都應遵循 Azure 暫態故障處理指引。 如需詳細資訊，請參閱 處理暫時性錯誤的建議。
使用事件網格時，請考慮以下做法，以確保您的解決方案對短暫故障具韌性：
活動出版商： 當客戶端應用程式將事件發佈到事件網格時，它負責處理暫時性故障。 應用程式在發佈事件時應實作重試邏輯。 欲了解更多資訊，請參閱 「故障排除暫態連線問題」。
我們建議您使用 Event Grid 資料平面 SDK，這些 SDK 會自動提供瞬態故障處理。
活動消費者： Event Grid 將事件傳送到已設定的目的地。 對於這些外撥連線，你要在事件訂閱上設定重試策略。 這些政策定義了事件網格在發生故障（包括暫時性故障）時，重試傳送的頻率與時間長短。 更多資訊請參閱 命名空間主題中的訊息推送與重試
冪等性： 設計事件架構時導入冪等性（idempotency）是一個好方法，這表示事件可以被安全地多次接收和處理。 例如，若應用程式處理事件時發生暫態故障或其他問題，冪等方法則表示應用程式可以重新處理訊息並恢復。
你負責設計你的事件架構和應用程式，以支援冪등性。 一般資訊請參見冪性。
死信： Event Grid 支援無法送達事件的 死信機制 ，有助於在事件消費者出現長時間故障時保留資料。 欲了解更多資訊，請參閱 Azure Event Grid 中關於命名空間主題事件訂閱的死字母部分。
對可用性區域故障的抵抗力
可用性區域 是 Azure 區域內物理上獨立的資料中心群組。 當某個區域發生故障時，服務可以切換至其他剩餘的區域。
Azure Event Grid 資源在支援可用性區域的區域中具有區域冗餘性。 區域冗餘意味著即使某個可用區域出現問題，你的事件網格資源仍能透過其他區域的基礎設施繼續運作。 事件資料會自動在三個可用區域複製，以提升區域內韌性，且事件網格在區域性中斷時自我修復。 你不需要啟用或設定這個功能。
要求
區域支援： 區域冗餘在 所有支援可用性區域的 Azure 區域皆可用。
Cost
區域冗餘不會有額外成本。 你無法啟用或關閉這個功能;在支援的地區預設就包含了。
設定可用性區域支援
不需要設定。 所有支援區域內的事件網格資源自動為區域冗餘。
所有區域都狀況良好時的行為
本節說明當事件網格資源為區域冗餘且所有區域皆可運作時，應預期的情況。
跨區作業： Event Grid 採用跨可用區域的主動-主動模式運作。 用戶端連線會自動在區域間負載平衡，服務會將操作路由到可用的訊息基礎設施，不論區域。
跨區域資料複製： Event Grid 會自動在可用區域間複製元資料與事件資料，以維持韌性。
區域失敗期間的行為
本節說明當事件網格資源在區域中冗餘，且某區域發生故障時，會發生什麼情況。
- 偵測與回應： Event Grid 會自動偵測區域故障並啟動故障轉移至健康區域。 您不需要執行任何動作即可起始區域容錯移轉。
- 通知： Microsoft 不會在區域關閉時自動通知您。 不過，你可以使用 Azure Service Health 來了解服務整體健康狀況，包括任何區域故障，並且可以設定 Service Health 警示來通知你問題。
目前的請求： 在區域發生故障時，事件網格可能會丟棄正在處理中的請求。 若客戶適當處理暫時 性故障 ，例如短時間後重試，通常可避免重大影響。
預期資料遺失： 事件網格區域冗餘模型旨在以最小影響實現區域故障的韌性。 然而，在區域故障期間，存在資料遺失的可能。
如果你需要確保應用程式即使在區域故障期間不會遺失資料，你應該：
- 設計你的事件生產者與消費者，讓他們遵循短暫性故障處理建議，包括重試與冪等性。
- 在事件來源或在持久性事件存儲中為事件持久性進行規劃。
預期停機時間： 區域故障可能會導致幾秒鐘的停機時間。 若客戶適當處理暫時 性故障 ，例如短時間後重試，通常可避免重大影響。
交通改道： Event Grid 偵測該區域的遺失，並自動將新請求重新導向到健康可用區域中的基礎設施。
區域復原
當受影響區域恢復時，Event Grid 會自動將其重新整合到服務中，無需客戶操作。 恢復的區域接著接受新的連線，並與其他區域一同處理訊息。 在中斷期間複製到存活區域的資料仍然完整，且所有區域的正常複製恢復。 你不需要為區域恢復或重新整合採取行動。
測試區域失敗
Event Grid 管理流量路由、故障轉移及區域故障恢復，因此您無需驗證可用性區域故障流程或提供更多輸入。
對區域範圍故障的復原能力
事件網格資源部署於單一區域。 如果整個區域都失敗，你的事件網格資源將無法使用。
在 成對的 Azure 區域中，事件網格為你的事件網格資源的元資料提供有限的地理災後復原功能。 你也可以設計並建置自己的多區域解決方案，以支持你的災難復原規劃。 下表展示了不同事件網格資源類型如何支援每種模型：
| 事件方格資源 | 支援地理災難復原 | 支援自訂解決方案 |
|---|---|---|
| 自訂主題 | 支持 | 支持 |
| 系統主題 | 自動啟用 | 不支援 |
| 網域 | 支持 | 支持 |
| 命名空間 | 不支援 | 支持 |
| 合作夥伴命名空間 | 不支援 | 支持 |
地質災害復原
地理災難復原會將事件網格的元資料複製到你主要區域的配對區域，以支援支援資源。 事件資料不會被複製。
地理災難復原被設計為一種由 Microsoft 管理的盡力而為的備援方案，主要針對嚴重區域性故障，並不旨在提供快速或可預測的復原時間。 Microsoft 啟動的容錯移轉會在極少數情況下由 Microsoft 執行，用以將事件網格資源從受影響的區域容錯移轉至對應的地理配對區域。 Microsoft 有權決定執行此選項的時機。 此機制在流量發生故障切換前，不需要客戶的同意。
這很重要
Microsoft 會觸發 Microsoft 管理的容錯移轉。 這較可能在重大延遲之後發生，並盡最大努力完成。 Event Grid 資源的故障轉移時間可能與其他 Azure 服務不同。
如果您需要對區域中斷進行復原，請考慮使用其中一個 自訂多區域解決方案來復原。
你可以選擇關閉地理災難復原，改用符合你在區域選擇、故障轉移時間等需求的 自訂多區域解決方案 。 當你停用地理災難復原時，Microsoft 不會將事件資料複製到其他區域。
這個功能在沒有配對區域的地區無法使用。
要求
區域支援： 地理災難復原僅在有配對區域的 Azure 區域中提供。
資源類型： 自訂主題與網域支援地理災難復原。 系統主題已啟用，可自動進行地理災害復原。 其他資源類型，如命名空間和夥伴命名空間，則不被支援。
Cost
地理災難復原沒有額外成本。
設定多區域支援
在支援的區域中，系統主題會自動設定用於地理災難復原。 關於其他事件網格資源類型：
要啟用地理災害復原： 更新你的主題或網域設定，並選擇 跨地理 （預設）。
要停用地理資料恢復： 更新你的主題或領域的設定，並選擇 區域性。
當所有區域都正常時的行為
本節說明當事件網格資源配置為地理災害復原且所有區域運作正常時，應預期的情況。
跨區域作業： 所有流量皆導向主要區域。
跨區域資料複寫： 元資料會同步複製到配對區域。 事件資料不會被複製。
區域失敗期間的行為
本節說明當事件網格資源被設定為地理災難復原，且主要區域發生故障時，應預期的情況。
- 偵測與回應： Microsoft 偵測區域故障，並決定是否及何時啟動故障轉移。
- 通知： Microsoft 不會自動通知你區域失效。 不過，你可以使用 Azure Service Health 來了解整體服務的健康狀況，包括任何區域故障，並且可以設定 服務健康警示 來通知你問題。
目前的請求： 對主要區域的主動請求會被終止。 客戶端應用程式在故障轉移完成後必須重新嘗試這些請求。
預期資料遺失：
元資料： Event Grid 在故障轉移期間會保留元資料。 由於所有元資料變更皆同步複製，因此預期不會遺失元資料。
活動資料： 主要區域的事件資料無法取得，若無法恢復，可能會遺失。
故障轉移發生後，會從配對區域處理新資料。 未處理的事件會在中斷解決後立即從主要區域傳送出。 若主要區域的恢復時間超過 事件設定的存活時間值，則主要區域的資料可能會被丟棄。 為減少資料遺失，我們建議您 為活動訂閱設定死信目的地。
如果受影響的區域遺失且無法復原，則會遺失一些資料。 在最佳情況下，消費者能跟上發佈速度，且只會損失幾秒的資料。 最糟的情況是當消費者沒有積極處理事件，且最長壽命為 24 小時，資料遺失可能長達 24 小時。
備註
Event Grid 無法保證區域中斷時的資料保留。 如果你需要保證保留，就需要設計你的應用程式，讓事件能持久地儲存在另一個資料庫中。
預期的停機時間： 停機時間取決於故障嚴重程度以及 Microsoft 評估並啟動故障轉移所需的時間。 你應該預期停機時間至少會是一個小時，甚至更久。
故障轉移啟動後，五分鐘內，Event Grid 開始接受主題與訂閱流量，包括建立、更新與刪除操作。
重新劃分： 故障轉移完成後，流量會自動路由到次要區域。
區域復原
Microsoft 負責區域復原，復原流程取決於具體的中斷情境。 一般來說，故障轉移通常被視為是單向的操作。
區域故障測試
Azure Event Grid 管理地理災難復原的流量路由、故障轉移與復原。 您不需要開始任何事情。 由於此功能是完全管理的，因此您不需要驗證區域故障流程。
自訂多區域解決方案，以實現復原能力
你可能出於任何以下原因而想停用或不依賴由 Microsoft 發起的故障轉移：
- 你需要事件資料能跨區域複製，而不只是元資料。
- 您需要確保特定的故障轉移時間或策略。 Microsoft 起始的容錯移轉會在力所能及的基礎上完成。
- 你的區域沒有和其他 Azure 區域配對。
- 你所在地區的配對不符合你組織的資料駐留要求。
為了更高層次的控制與可預測性，你可以實作自訂的多區域架構。 此方法涉及在多個區域部署獨立的事件網格資源，並在應用程式層級管理故障轉移。 使用此模式時，你負責部署、配置及維持跨區域資源同步。
設計多區域解決方案時，請考慮以下因素：
複製： 你應該實作自訂流程來複製你的事件網格資源及其在主區域與次要區域之間的設定。 記得複製用戶端身份、CA 憑證、用戶端群組、主題空間及權限綁定（如適用）。 你可以決定是實施手動或自動化複製。
備援策略： 你可以選擇設計主動-主動或主動-被動架構：
- 主動-主動解決方案可透過複製元資料並在命名空間間平衡負載來實現。
- 主動被動解決方案可透過複製元資料來維持次級命名空間的準備，當主命名空間無法使用時，流量可被導向次級命名空間。
健康監測： 你可以使用Event Grid內建的健康API來監控主題的健康狀況。
您的客戶端應用程式必須偵測某區域的故障，並將事件導向其他適當區域。
或者，您可以實作一種
，透過對主或次端點的健康狀況檢查，將客戶導向他們的主題或命名空間的適當端點。 禮賓服務可以是透過 DNS 重定向技術或 Azure Traffic Manager 等服務進行地理複製並保持可存取的網頁應用程式。
關於一種方法的更多資訊，包括範例程式碼，請參閱 Azure Event Grid 中的客戶端故障轉移實作。
備份與還原
Event Grid 主要是事件路由服務，沒有原生備份或還原功能。
如果您需要實作備份功能，或有長期保留需求，我們建議您在應用程式中進行歸檔。 為此，你應該建立邏輯，將事件路由或複製到耐用儲存庫，例如 Azure Blob Storage，並與主要傳遞路徑並行。 如果下游系統無法使用，你的應用程式可以使用該檔案庫來重播事件。
服務維護的韌性
Microsoft 定期執行服務更新及其他維護。 Azure 平台自動處理這些活動，確保維護過程對您來說無縫且透明。 除非你透過 Azure Service Health 獲得計畫性維護通知，否則維護事件期間不會有停機。
服務等級協定
Azure 服務的服務層級協議（SLA）描述了每項服務的預期可用性，以及您的解決方案必須符合的條件，以達成該可用性預期。 欲了解更多資訊，請參閱線上服務的服務等級協議。
事件網格可用性服務標準涵蓋事件發布。