Azure SignalR 中的異地複寫

尋求本機存在或需要強固容錯移轉系統的公司，通常會選擇跨多個 Azure 區域部署服務。 透過在 Azure SignalR 中整合異地複寫，管理多區域案例會變得相當容易。

使用異地複寫的優點

• 區域中斷更具彈性：如果發生區域中斷，Azure SignalR DNS 會解析為其他區域中狀況良好的複本。
• 跨區域通訊。 不同的複本可以彼此通訊，就像是相同的執行個體一樣。
• 增強的網路速度：異地分散的用戶端會連線到最近的複本。 這些複本會透過 Azure 全球網路骨幹進行通訊，確保網路快速且穩定。
• 共用組態。 所有複本都會保留主要 Azure SignalR Service 資源的組態。

必要條件

• 進階層中的 Azure SignalR Service。

使用案例範例

Contoso 是一家社交媒體公司，其客戶群遍佈美國和加拿大。 為了服務這些客戶並讓他們彼此通訊，Contoso 在美國中部執行其服務。 Azure SignalR Service 可用來處理使用者連線，並協助使用者之間的通訊。 Contoso 的終端使用者大多是電話使用者。 由於地理位置距離較長，加拿大的終端使用者可能會遇到高延遲和網路品質不佳的情況。

在異地複寫功能出現之前，Contoso 可以在加拿大中部設定另一個 Azure SignalR Service，為加拿大使用者提供服務。 藉由設定地理位置更接近的 Azure SignalR Service，終端用戶現在擁有更好的網路品質和較低的延遲。

不過，管理多個 Azure SignalR Services 會帶來一些挑戰：

1. 需要跨區域通訊機制，來實現加拿大和美國使用者之間的交談。
2. 開發小組需要管理兩個個別的 Azure SignalR Services，每個資源都有不同的網域和連接字串。
3. 如果發生區域中斷，則必須將流量切換至另一個區域。

利用異地複寫

透過新的異地複寫功能，Contoso 現在可以在加拿大中部建立複本，有效地克服上述挑戰。

建立 SignalR 複本

@description('The name for your SignalR service')
param primaryName string = 'contoso'

@description('The region in which to create your SignalR service')
param primaryLocation string = 'eastus'

@description('Unit count of your SignalR service')
param primaryCapacity int = 1

resource primary 'Microsoft.SignalRService/signalr@2023-08-01-preview' = {
  name: primaryName
  location: primaryLocation
  sku: {
    capacity: primaryCapacity
    name: 'Premium_P1'
  }
  properties: {
  }
}

@description('The name for your SignalR replica')
param replicaName string = 'contoso-westus'

@description('The region in which to create the SignalR replica')
param replicaLocation string = 'westus'

@description('Unit count of the SignalR replica')
param replicaCapacity int = 1

@description('Whether to enable region endpoint for the replica')
param regionEndpointEnabled string = 'Enabled'

resource replica 'Microsoft.SignalRService/signalr/replicas@2023-08-01-preview' = {
  parent: primary
  name: replicaName
  location: replicaLocation
  sku: {
    capacity: replicaCapacity
    name: 'Premium_P1'
  }
  properties: {
    regionEndpointEnabled: regionEndpointEnabled
  }
}

az group create --name MyResourceGroup --location eastus
az deployment group create --resource-group MyResourceGroup --template-file main.bicep

定價和資源單位

每個複本都有自己的 unit 和 autoscale settings。

複本是 Azure SignalR Service 進階層的功能。 每個複本都會根據自己的單位和輸出流量個別計費。 免費的訊息配額也會個別計算。

在上述範例中，Contoso 已在加拿大中部新增了一個複本。 Contoso 會根據複本在 Premium 價格中的單位和訊息來支付加拿大中部的複本費用。

會針對跨區域輸出流量來收取輸出費用。 如果訊息跨複本傳輸並在傳輸後成功傳送至用戶端或伺服器，則該訊息會按輸出訊息計費。

刪除複本

建立 Azure SignalR Service 的複本之後，如果不再需要，您可以隨時刪除它。

若要在 Azure 入口網站中刪除複本：

1. 瀏覽至您的 Azure SignalR Service，然後選取 [複本] 刀鋒視窗。 按一下您要刪除的複本。
2. 按一下 [複本概觀] 刀鋒視窗上的 [刪除] 按鈕。

了解 SignalR 複本的運作方式

下圖提供 SignalR 複本功能的簡短圖例：

1. 用戶端會與應用程式伺服器交涉，並接收 Azure SignalR Service 的重新導向。 然後，它會解析 SignalR 服務的完整網域名稱 (FQDN) — contoso.service.signalr.net。 此 FQDN 會指向流量管理員，而該流量管理員會傳回最接近的區域 SignalR 執行個體的 Canonical 名稱 (CNAME)。
2. 透過此 CNAME，用戶端會與區域執行個體 (複本) 建立一個連線。
3. 兩個複本會彼此同步資料。 如有必要，傳送至一個複本的訊息會傳輸到其他複本。
4. 如果複本未通過流量管理員 (TM) 所執行的健康情況檢查，則 TM 會從其網域解析程序中排除失敗執行個體的端點。 如需詳細資料，請參閱下面的復原和災害復原

復原和災害復原

Azure SignalR Service 會利用流量管理員來對其複本進行健康情況檢查和 DNS 解析。 在正常情況下，當所有複本都正常運作時，用戶端會被導向到最接近的複本。 例如：

• 靠近 eastus 的用戶端會被導向到位於 eastus 的複本。
• 同樣地，靠近 westus 的用戶端會被導向到位於 westus 的複本。

如果美國東部發生區域性中斷 (如下圖所示)，則流量管理員會偵測到該區域的健康情況檢查失敗。 然後，此失效複本的 DNS 會從流量管理員的 DNS 解析結果中排除。 在 DNS 存留時間 (TTL) 持續時間 (設定為 90 秒) 之後，eastus 的用戶端會被重新導向來與 westus 的複本連線。

一旦 eastus 的問題被解決且該區域重新上線之後，健康情況檢查就會成功。 然後，eastus 的用戶端會再次被導向到其所在區域的複本。 此轉換是平順的，因為在關閉現有的連線之前，連線的用戶端都不會受到影響。

此容錯移轉和復原程序是自動的，不需要手動介入。

針對伺服器連線，容錯移轉和復原的運作方式與用戶端連線的運作方式相同。

停用或啟用複本端點

設定複本時，您可以選擇啟用或停用其端點。 如果停用，則主要 FQDN 的 DNS 解析不會包含複本，因此不會將流量導向至該複本。

您也可以在建立端點之後啟用或停用該端點。 在主要資源的 [複本] 刀鋒視窗上，按一下複本右側的省略符號按鈕，然後選擇 [啟用端點] 或 [停用端點]：

刪除複寫之前，請考慮先停用其端點。 一段時間之後，現有的連線都將中斷。 由於沒有新的連線到來，因此複寫最後會變成閑置的狀態。 這可確保順暢的刪除過程。

此功能對於解決區域問題也很有幫助。

新增複本之後對效能的影響

啟用複本之後，用戶端自然會根據其地理位置進行分散。 雖然 SignalR 會負責在這些複本之間進行資料同步，但您會很高興地知道，對於最常見的使用案例，伺服器負載的相關額外負荷是最小的。

具體而言，如果您的應用程式通常是向較大的群組 (大小 > 10) 或單一連線進行訊息廣播，則對同步效能的影響幾乎可以忽略不計。 如果您是向小型的群組 (大小 < 10) 或個別使用者傳送訊息，您可能會注意到同步的額外負荷稍多。

為了確保有效的容錯移轉管理作業，建議您設定每個複本的單位大小以處理所有的流量。 或者，您也可以啟用自動調整功能來管理這項作業。

如需效能評估的相關資訊，請參閱效能。