銷售: 1-800-867-1380

隔離服務匯流排應用程式以防止服務匯流排中斷和嚴重損壞的最佳作法

更新日期: 2014年4月

關鍵性應用程式必須持續作業,即使發生非預期的中斷或嚴重損壞亦然。本主題說明您可以用來保護應用程式,避免發生潛在的 Microsoft Azure 服務匯流排 中斷或嚴重損壞。

中斷的定義是暫時無法使用 Microsoft Azure 服務匯流排。中斷可能會影響 服務匯流排 的某些元件,例如訊息存放區或甚至是整個資料中心。問題解決之後,服務匯流排 會再次可用。通常中斷不會造成訊息或其他資料遺失。舉例來說,元件失敗是無法使用 Microsoft Azure Active Directory 存取控制服務 (也稱為「存取控制服務」或 ACS),或無法使用特定的訊息存放區。資料中心完全中斷的例子是資料中心停電,或有問題的資料中心網路切換。中斷可能持續數分鐘到數天。

嚴重損壞的定義是永久遺失 服務匯流排 擴充單元或資料中心。資料中心不一定可以再度恢復使用。通常嚴重損壞會造成部分或所有訊息或其他資料的遺失。火災、洪火或地震都是嚴重損壞的例子。

服務匯流排 使用多個訊息存放區來儲存傳送至佇列或主題的訊息。未進行磁碟分割的佇列或主題都會指派給一個訊息存放區。若此訊息存放區無法使用,該佇列或主題上的所有作業都會失敗。

所有 服務匯流排 訊息實體 (佇列、主題、轉送) 都位於 服務命名空間 中。相同的情況也會發生在 ACS,其會提供存取 服務匯流排 實體所需的權杖。服務命名空間 附屬於資料中心。服務匯流排 及 ACS 不會啟用資料的自動地理區域複寫,也不允許 服務命名空間 橫跨多個資料中心。

如果 ACS 無法使用,用戶端也無法取得權杖。沒有有效的權杖,這些用戶端就無法在任何 服務匯流排 實體上執行作業。在 ACS 無法使用時,擁有權杖的用戶端可以繼續使用 服務匯流排 直到權杖到期。預設權杖存留期為 3 小時。

為了不讓 ACS 中斷,請使用共用存取簽章 (SAS) 權杖。在這個情況下,用戶端會以私密金鑰簽署自行產生的權杖,以便直接驗證 服務匯流排。再也無需呼叫 ACS。如需以下內容的詳細資訊 SAS 權杖,請參閱服務匯流排驗證

未進行磁碟分割的佇列或主題都會指派給一個訊息存放區。若此訊息存放區無法使用,該佇列或主題上的所有作業都會失敗。此外,磁碟分割的佇列是由多個片段組成。每個片段都儲存在不同的訊息存放區中。當訊息傳送到分割的佇列或主題時,服務匯流排 會指派訊息給其中一個片段。如果無法使用相對應的訊息存放區,服務匯流排 可能會將訊息寫入不同的片段。如需以下內容的詳細資訊 磁碟分割實體,請參閱分割訊息實體

若要允許兩個資料中心之間進行容錯移轉,您可在每一個資料中心建立一個 服務匯流排 及一個 ACS 服務命名空間。例如,服務匯流排 服務命名空間 contosoPrimary.servicebus.windows.net 可能位於美國 (北部/中部) 地區,而 contosoSecondary.servicebus.windows.net 可能位於美國 (南部/中部) 地區。如果 服務匯流排 傳訊實體在發生資料中心中斷時仍須保持可存取,則您可以在這兩個 服務命名空間 中建立該實體。

轉送端點的地理區域複寫可讓顯示轉送端點的服務,可在發生 服務匯流排 中斷時與其聯繫。若要完成地理區域複寫,服務必須在不同的 服務命名空間 中建立兩個轉送端點。服務命名空間 兩者必須位於不同的資料中心,而且這兩個端點必須具有不同的名稱。例如,可在 contosoPrimary.servicebus.windows.net/myPrimaryService 下聯繫主要端點,同時可在 contosoSecondary.servicebus.windows.net/mySecondaryService 下聯繫其次要端點。

然後,服務可在這兩個端點上接聽,而且用戶端可以透過任一端點來呼叫服務。用戶端應用程式會隨機挑選其中一個轉送端點作為主要端點,並將其要求傳送至使用中端點。如果作業失敗並附有錯誤碼,則此失敗指出轉送端點無法使用。應用程式會開啟備份端點的通道,並重新發出要求。這時使用中端點與備份端點會互換角色:用戶端應用程式會將舊的使用中端點視為新的備份端點,並將舊的備份端點視為新的使用中端點。如果這兩個傳送作業都失敗,則兩個實體的角色會保持不變,並傳回錯誤。

使用服務匯流排轉送的訊息進行地理區域複寫範例示範如何複寫轉送。

為了可在使用代理的傳訊時完成對資料中心中斷的恢復,服務匯流排 支援兩種方法:主動與被動複寫。對於每一種方法,如果提供的佇列或主題在發生資料中心中斷時仍須保持可存取,則您可以在這兩個 服務命名空間 中建立它。這兩個實體可以具有相同的名稱。例如,可在 contosoPrimary.servicebus.windows.net/myQueue 下聯繫主要佇列,同時可在 contosoSecondary.servicebus.windows.net/myQueue 下聯繫其次要佇列。

如果應用程式不需要傳送端對接收端的永久通訊,應用程式可以實作長期的用戶端佇列,不但可防止訊息遺失,也可讓傳送端避開暫時性的 服務匯流排 錯誤。

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

用戶端會從這兩個佇列接收訊息。接收端會處理第一個訊息複本,而第二個複本則會遭到抑制。若要抑制重複的訊息,傳送端必須使用唯一的識別碼來標示每一則訊息。必須使用相同的識別碼標示這兩個訊息複本。您可以使用 MessageIdLabel 或自訂內容來標示訊息。接收端必須維護其已收到的訊息清單。

使用服務匯流排轉送的訊息進行地理區域複寫範例示範如何主動複寫傳訊實體。

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

在無錯誤的情況下,被動複寫只會使用兩個傳訊實體的其中一個。用戶端會傳送訊息至使用中實體。如果使用中實體上的作業失敗,錯誤碼指出管理使用中實體的資料中心可能無法使用,則用戶端會傳送訊息複本至備份實體。這時使用中端點與備份實體會互換角色:傳送用戶端會將舊的使用中實體視為新的備份實體,而且舊的備份實體將成為新的使用中實體。如果這兩個傳送作業都失敗,則兩個實體的角色會保持不變,並傳回錯誤。

用戶端會從這兩個佇列接收訊息。因為接收端有機會收到兩個相同的訊息複本,所以接收端必須抑制重複的訊息。您可以使用針對主動複寫所描述的同一方法來抑制重複。

通常,被動複寫比主動複寫更為經濟,因為在大部份情況下,只會執行一個作業。延遲、輸送量、財務成本與非複寫的案例相同。

當使用被動複寫時,可能失去或收到兩次下列案例訊息:

  • 訊息延遲或遺失:假設傳送端已順利傳送訊息 m1 至主要佇列,而在接收端收到 m1 前佇列變成無法使用。傳送端會傳送後續的訊息 m2 至次要佇列。如果主要佇列暫時無法使用,接收端會在佇列恢復使用後收到 m1。在嚴重損壞的情況下,接收端可能永遠收不到 m1

  • 重複接收:假設傳送端傳送訊息 m 至主要佇列。服務匯流排 已順利處理 m,但無法傳送回應。在傳送作業逾時之後,傳送端會傳送相同的 m 複本至次要佇列。如果接收端能夠在主要佇列變成無法使用之前收到第一個 m 複本,則接收端會在大約相同的時間收到兩個 m 複本。如果接收端無法在主要佇列變成無法使用之前收到第一個 m 複本,則接收端最初只會收到第二個 m 複本,但是接收端隨後會在主要佇列變成可用時收到第二個 m 複本。

使用服務匯流排轉送的訊息進行地理區域複寫範例示範如何被動複寫傳訊實體。

如果應用程式可以容許 服務匯流排 實體暫時無法使用,但前提是訊息不會遺失,傳送端可以採用長期用戶端佇列,這些佇列可以本機儲存所有無法傳送到 服務匯流排 的訊息。一旦 服務匯流排 實體再度恢復使用,就會將所有緩衝的訊息傳送給實體。長期訊息傳送端 範例在 MSMQ 幫助下實作這類佇列。或者,可將訊息寫入本機磁碟。

長期用戶端佇列會保存較舊的訊息,並讓用戶端應用程式在 服務匯流排 實體無法使用時避開例外狀況。長期用戶端佇列可用於簡單、分散的交易。

另請參閱

本文對您有任何幫助嗎?
(剩餘 1500 個字元)
感謝您提供意見
顯示:
© 2014 Microsoft