Azure Web PubSub 服務中的復原和災害復原

文章
04/11/2024

復原和災害復原是線上系統的常見需求。 Azure Web PubSub 服務已保證有 99.9% 的可用性，但仍是一項區域性服務。發生全區域中斷時，服務必須繼續處理不同區域中的即時訊息。

針對區域性災害復原，我們建議使用下列兩種方法：

啟用異地複寫 (簡單方式)。此功能會自動為您處理區域性容錯移轉。啟用後，只會保留一個 Azure SignalR 執行個體，而且不會引入任何程式碼變更。如需詳細資訊，請參閱異地複寫。
利用多個端點。您將在本文件中了解如何這麼做。

Web PubSub 服務的高可用性架構

使用 Web PubSub 服務有兩個典型的模式：

其中一個是用戶端-伺服器模式：用戶端將事件傳送至伺服器以及伺服器將訊息推送至用戶端。
另一個是用戶端-用戶端模式：用戶端透過 Web PubSub 服務發佈/訂閱訊息至其他用戶端。

以下各節說明這兩種模式執行災害復原的不同方式

用戶端-伺服器模式的高度可用架構

為了讓 Web PubSub 服務能跨區域進行復原，您需要在不同區域中設定多個服務執行個體。這樣一來，當某個區域的服務中斷時，其他區域就可用來當做備份。

針對區域案例，其中一個標準設定是有兩組 (含) 以上的 Web PubSub 服務執行個體和應用程式伺服器。

在每一組配對中，應用程式伺服器和 Web PubSub 服務會位在相同區域中，而 Web PubSub 服務會將事件處理常式上游設定為相同區域中的應用程式伺服器。

為了更清楚地說明架構，在相同配對中，我們會將主要服務 Web PubSub 服務呼叫至應用程式伺服器。此外，我們會在其他配對中呼叫 Web PubSub 服務，作為應用程式伺服器的次要服務。

應用程式伺服器可以使用服務健康情況檢查 API 來偵測其主要和次要服務狀態是否良好。例如，針對名為 demo 的 Web PubSub 服務，當服務狀況良好，端點 https://demo.webpubsub.azure.com/api/health 會傳回 200。應用程式伺服器可以定期呼叫端點，或視需要呼叫端點，以檢查端點狀況是否良好。 WebSocket 用戶端通常會先與其應用程式伺服器交涉，以取得連線到 Web PubSub 服務的 URL，而應用程式會使用此交涉步驟來將用戶端容錯移轉至其他狀況良好的次要服務。詳細步驟如下：

當用戶端與應用程式伺服器交涉，應用程式伺服器「應」只傳回主要 Web PubSub 服務端點，因此在一般情況下，用戶端只會連線到主要端點。
當主要執行個體關閉，交涉「應」會傳回狀況良好的次要端點，讓用戶端仍然可以進行連線，而用戶端會連線到次要端點。
當主要實例啟動，交涉應該會傳回狀況良好的主要端點，讓用戶端可以連線到主要端點
當應用程式伺服器廣播訊息，應該會將訊息廣播到所有狀況良好的端點，包括主要和次要端點。
應用程式伺服器可以關閉連線到次要端點的連線，以強制用戶端重新連線到狀況良好的主要端點。

在此拓撲中，來自一部伺服器的訊息仍然可以傳遞至所有用戶端，因為所有應用程式伺服器和 Web PubSub 服務執行個體都會互相連線。

我們尚未將策略整合到 SDK 中，因此應用程式現在必須自行實作此策略。

總而言之，應用程式端需實作的內容如下：

健康情況檢查。應用程式可以使用服務健康情況檢查 API，定期在背景或視需要檢查每個交涉呼叫，以檢查服務是否狀況良好。
交涉邏輯。應用程式預設會傳回狀況良好的主要端點。當主要端點關閉，應用程式會傳回狀況良好的次要端點。
廣播邏輯。當傳送訊息至多個用戶端時，應用程式必須確定訊息將廣播到所有狀況良好的端點。

以下是說明這類拓撲的圖示：

Diagram shows two regions each with an app server and a Web PubSub service, where each server is associated with the Web PubSub service in its region as primary and with the service in the other region as secondary.

容錯移轉順序和最佳做法

現在您已設定正確的系統拓撲。每當有一個 Web PubSub 服務執行個體停止運作，線上流量就會路由至其他執行個體。以下是主要執行個體停止運作 (並在稍後復原) 時發生的狀況：

主要服務執行個體停止運作時，所有與此執行個體連線的用戶端連線皆會遭到中斷。
新的用戶端或重新連線用戶端與應用程式伺服器進行交涉
應用程式伺服器偵測到主要服務執行個體已關閉，交涉會停止傳回此端點，並開始傳回狀況良好的次要端點。
用戶端會連線到次要執行個體。
現在，次要執行個體會接收所有線上流量。所有來自伺服器的訊息仍可傳遞到用戶端，因為次要執行個體會連線到所有應用程式伺服器。但是從用戶端傳送到伺服器的事件訊息只會傳送至相同區域中的上游應用程式伺服器。
在主要執行個體復原並重新上線之後，應用程式伺服器會偵測到主要執行個體已恢復良好狀況。交涉現在會再次傳回主要端點，讓新的用戶端連線到主要執行個體。但現有的用戶端不會遭到捨棄，而且會繼續連線至次要區域，直到這些用戶端自行中斷為止。

以下圖示說明如何進行容錯移轉：

圖 1 容錯移轉前 Before Failover

圖 2 容錯移轉後 After Failover

圖 3 主要復原後不久 Short time after primary recovers

在正常的情況下，您只會看到主要應用程式伺服器及 Web PubSub 服務有線上流量 (藍色)。

容錯移轉之後，次要應用程式伺服器與 Web PubSub 服務也會開始作用。主要 Web PubSub 服務恢復上線後，新的用戶端將會連線到主要 Web PubSub。但現有的用戶端仍是連線至次要執行個體，因此兩個執行個體都有流量。

在所有現有的用戶端都中斷連線後，系統就會回到正常情況 (圖 1)。

實作跨區域的高可用性架構有兩個主要模式：

第一個模式是讓一組應用程式伺服器和 Web PubSub 服務執行個體接收所有線上流量，並將另一組當作備份 (稱為主動/被動，如圖 1 所示)。
另一個模式是有兩組 (或兩組以上) 應用程式伺服器和 Web PubSub 服務執行個體，每一組都接收部分線上流量及作為其他組的備份 (稱為主動/主動，類似圖 3)。

Web PubSub 服務可支援這兩種模式，主要差異在於您如何實作應用程式伺服器。如果應用程式伺服器為主動/被動，Web PubSub 服務也會是主動/被動 (因為主要應用程式伺服器只會傳回其主要的 Web PubSub 服務執行個體)。如果應用程式伺服器為主動/主動，Web PubSub 服務也會是主動/主動 (因為所有應用程式伺服器會傳回自己的主要 Web PubSub 執行個體，因此所有執行個體都可以接收流量)。

請注意，無論您選擇使用哪一個模式，您都必須將每個 Web PubSub 服務執行個體連線到設為主要的應用程式伺服器。

也因為 WebSocket 連線的本質 (很長的連線)，用戶端會在發生災害和容錯移轉時遇到連線中斷。您必須在用戶端處理這類情況，讓終端客戶了解此情況。例如，在連線關閉後重新連線。