閱讀英文

共用方式為

將應用程式與服務匯流排中斷和災難隔絕的最佳做法

  • 發行項

關鍵任務應用程式必須持續作業，即使發生非預期的中斷或災害亦然。 許多企業必須能夠在資料處理資源的災難性中斷下恢復，在某些情況下，這甚至是產業法規的要求。 本文說明您可用來保護服務匯流排應用程式，避免潛在服務中斷或災害發生的技巧。

Azure 服務匯流排已將個別機器或甚至整個機架的重大失敗風險，分散到資料中心內跨多個失敗網域的叢集，還實作透明的失敗偵測和容錯移轉機制，讓服務在保證的服務等級內繼續運作，發生這類失敗時，通常也不會明顯中斷。

此外，中斷風險會進一步分散到三個位於不同實體位置的設備 (可用性區域)，而且服務會保留足夠的容量，立即應付徹底失去資料中心的重大事件。 失敗網域內的全作用中 Azure 服務匯流排叢集模型，以及可用性區域支援，在嚴重硬體失敗的復原能力，甚至是整個資料中心設施的嚴重遺失方面，優於任何內部部署訊息代理程式產品。 然而，還是可能有大規模實體損毀的嚴重情況，甚至連這些措施也難以防範。

服務匯流排異地災害復原和異地複寫功能旨在更輕鬆從如此重大災害中復原，並永久放棄失敗的 Azure 區域，而不需要變更應用程式設定。

中斷與災害

請務必注意「中斷」和「災害」之間的差異。

「中斷」是暫時無法使用 Azure 服務匯流排，而且會影響服務的某些元件，例如訊息存放區，或甚至整個資料中心。 不過，修正問題之後，服務匯流排就可再次使用。 中斷通常不會導致訊息或其他資料遺失。 元件失敗的範例是特定的訊息存放區無法使用。 資料中心全面中斷的範例是資料中心電源中斷、或錯誤的資料中心網路交換器。 中斷可能持續數分鐘到數天。 某些中斷只是因為暫時性或網路問題而造成的短暫連線中斷。

「災害」定義為永久或較長期遺失服務匯流排叢集、Azure 區域或資料中心。 區域或資料中心不一定能再次變成可用，也可能會關閉數小時或數天。 這類災害的範例包括火災、水災或地震。 會變成永久的災害可能會導致某些訊息、事件或其他資料遺失。 不過，在大部分情況下，應該不會遺失資料，而且在備份資料中心之後，就可以復原訊息。

防範中斷和災害

有兩項功能可在進階層的 Azure 服務匯流排提供異地災害復原。 首先，有異地災害復原 (中繼資料 DR) 可提供中繼資料 (實體、組態、屬性) 的複寫。 其次，有目前處於公開預覽狀態的異地複寫，可提供中繼資料和資料 (訊息資料和訊息屬性/狀態變更) 本身的複寫。 不應將兩個異地災害復原功能與可用性區域混淆。 不論其是否為中繼資料 DR 或異地複寫，兩種異地圖形復原功能都提供 Azure 區域 (例如美國東部和美國西部) 之間的復原能力。

可用性區域適用於所有服務匯流排層級，且支援可在特定地理區域內提供復原功能，例如美國東部。 如需 Microsoft Azure 中災害復原的詳細討論，請參閱本文。

「高可用性」和「災害復原」概念已直接內建於「Azure 服務匯流排進階層」中，不論是相同區域內 (透過「可用性區域」) 還是跨不同區域 (透過「異地災害復原」和「異地複寫」) 都適用。

異地災害復原選項

異地災害復原

「服務匯流排進階層」支援命名空間層級的異地災害復原。 如需詳細資訊，請參閱 Azure 服務匯流排異地災害復原。 異地災害復原功能僅適用於進階層，其會實作中繼資料災害復原，並依賴主要和次要命名空間。 使用異地災害復原時，只會複寫主要和次要命名空間之間實體的中繼資料。

異地複寫

「服務匯流排進階層」也支援命名空間層級的異地複寫。 如需詳細資訊，請參閱 Azure 服務匯流排異地複寫 (公開預覽版)。 異地複寫功能僅適用於進階層且目前處於公開預覽狀態，其會實作中繼資料和資料災害復原，並依賴主要和次要區域。 使用異地複寫時，實體的中繼資料和資料會在主要和次要區域之間複寫。

高階功能差異

異地災害復原 (中繼資料 DR) 功能會將命名空間的中繼資料從主要命名空間複寫到次要命名空間。 只支援一次容錯移轉到次要區域。 在客戶起始的容錯移轉期間，命名空間的別名名稱會重新指向次要命名空間，然後配對會中斷。 除了中繼資料以外，不會複寫任何資料，也不會複寫 RBAC 指派。

[異地複寫] 功能會將中繼資料和所有資料從主要區域複寫到一或多個次要區域。 客戶執行容錯移轉時，選取的次要區域會變成主要，而上一個主要區域會變成次要。 如有需要，使用者可以執行容錯移轉，回到原始的主要區域。

可用性區域

所有服務匯流排層都支援可用性區域，並在同個 Azure 區域內提供錯誤隔離位置。 服務匯流排管理三個傳訊存放區複本 (1 個主要和 2 個次要)。 服務匯流排會針對資料和管理作業，將三個複本都保持同步。 如果主要複本失敗，其中一個次要複本會升階為主要複本，不會察覺到停機。 如果應用程式看到暫時性與服務匯流排中斷連線，SDK 中的重試邏輯會自動重新連線至服務匯流排。

使用可用性區域時，中繼資料和資料 (訊息) 都會複寫至可用性區域中的資料中心。

注意

只有在具有可用性區域的 Azure 區域中，才支援可用性區域。

當您建立命名空間時，會自動為命名空間啟用可用性區域的支援 (如果在選取的區域中可用的話)。 使用這項功能沒有額外成本，且您無法在建立命名空間之後停用或啟用此功能。

注意

先前需要將 zoneRedundant 屬性設定為 true 才能啟用可用性區域，不過，此行為已變更為預設啟用可用性區域。 現有的命名空間會移轉至可能的可用性區域，且屬性 zoneRedundant 已被取代。 zoneRedundant 屬性可能仍會顯示為 false，即使已啟用可用性區域也一樣。 移轉的現有命名空間：

  • 目前尚未啟用可用性區域。
  • 請確定此區域 支援 可用性區域。
  • 區域具有足夠的可用性區域容量。

防範災害 - 標準層

若要使用服務匯流排標準層達到災害的復原能力，您可以使用主動或被動複寫。 無論使用哪個方法，如果特定佇列或主題必須在資料中心發生中斷時保持可存取狀態，您可以在這兩個命名空間建立該佇列或主題。 這兩個實體可以具有相同的名稱。 比方說，主要佇列在 contosoPrimary.servicebus.windows.net/myQueue 之下達到，而其次要的對應項目可以在 contosoSecondary.servicebus.windows.net/myQueue 之下達到。

注意

主動複寫和被動複寫設定是一般用途解決方案，不是「服務匯流排」的特定功能。 複寫邏輯 (傳送至 2 個不同的命名空間) 位於傳送者應用程式中，而接收者必須有自訂邏輯來偵測重複項。

如果應用程式不需要永久的傳送者至接收者通訊，應用程式可以實作持續的用戶端佇列，以防止訊息遺失並避免傳送者發生任何暫時性服務匯流排錯誤。

主動式複寫

主動複寫會針對每個作業使用兩個命名空間中的實體。 傳送訊息的任何用戶端會傳送相同訊息的兩個複本。 第一個複本傳送至主要實體 (例如 contosoPrimary.servicebus.windows.net/sales)，而訊息的第二個複本傳送至次要實體 (例如 contosoSecondary.servicebus.windows.net/sales)。

用戶端會從這兩個佇列接收訊息。 接收者會處理訊息的第一個複本，並隱藏第二個複本。 若要隱藏重複的訊息，傳送者必須利用唯一的識別碼標記每個訊息。 訊息的兩個複本必須以相同的識別碼標記。 您可以使用 ServiceBusMessage.MessageId 或 ServiceBusMessage.Subject 屬性或自訂屬性來標記訊息。 接收者必須維護其已收到的訊息清單。

注意

主動複寫方法會讓作業數目加倍，因此這個方法會導致更高的成本。

被動式複寫

在沒有錯誤的情況下，被動複寫只會使用兩個訊息實體的其中之一。 用戶端會傳送訊息至作用中的實體。 如果作用中實體上的作業失敗，並出現錯誤碼指出裝載作用中實體的資料中心可能會無法使用，用戶端會傳送訊息的複本至備份實體。 此時主動和備份實體會互換角色。 傳送用戶端會將舊的主動實體視為新的備份實體，並將舊的備份實體視為新的主動實體。 如果這兩個傳送作業都失敗，兩個實體的角色會保持不變並傳回錯誤。

用戶端會從這兩個佇列接收訊息。 因為接收者可能會收到相同訊息的兩個複本，所以接收者必須隱藏重複的訊息。 您可以主動複寫所描述的相同方式隱藏重複訊息。

一般而言，被動複寫比主動複寫更具經濟效益，因為大部分的情形只會執行一項作業。 延遲、輸送量和成本與非複寫案例相同。

當您使用被動複寫時，訊息可能會在下列案例中遺失或收到兩次：

  • 訊息延遲或遺失：假設傳送者成功傳送訊息 m1 至主要佇列，佇列在接收者收到 m1 之前無法使用。 傳送者會將後續的訊息 m2 傳送至次要佇列。 如果主要佇列暫時無法使用，接收者會在佇列可再次使用之後收到 m1。 發生災害時，接收者可能永遠不會收到 m1。
  • 重複接收：假設傳送者傳送訊息 m 到主要佇列。 服務匯流排已成功處理 m 但無法傳送回應。 傳送作業逾時之後，傳送者會將 m 的相同複本傳送至次要佇列。 如果接收者可以在主要佇列無法使用之前收到 m 的第一個複本，接收者會幾乎同時接收 m 的兩個複本。 如果接收者無法在主要佇列無法使用之前收到 m 的第一個複本，接收者一開始只會收到 m 的第二個複本，但會接著在主要佇列可以使用時會收到 m 的第二個複本。

使用 .NET Core 的 Azure 傳訊複寫工作範例示範命名空間之間的訊息複寫。

下一步

若要深入了解災害復原，請參閱這些文章：