選擇使用佇列的訊息式傳遞

  • 8 分鐘

假設您正在規劃音樂分享應用程式的架構。 您想要確定音樂檔案已從行動應用程式可靠地上傳至 Web API。 您接著想要在演出者新增音樂至其集合時，將新歌曲的相關詳細資料直接傳遞至應用程式。 此案例適合使用以訊息為基礎的系統，而 Azure 針對此問題提供兩種解決方案：

  • Azure 佇列儲存體
  • Azure 服務匯流排

什麼是 Azure 佇列儲存體？

佇列儲存體 是使用 Azure 儲存體儲存大量訊息的服務，全球任何地方都可利用簡單的 REST 介面安全地存取這些訊息。 佇列可包含數百萬則訊息，僅受限於擁有佇列之儲存體帳戶的容量。

什麼是 Azure 服務匯流排佇列？

服務匯流排是適用於企業應用程式的訊息代理程式系統。 這些應用程式通常使用多種通訊協定、具有不同的資料合約、安全性需求較高，而且可同時包含雲端服務和內部部署服務。 服務匯流排建置在專為這些相同案例所設計的專用傳訊基礎結構之上。

這兩個服務都是以「佇列」的概念為基礎，佇列會保留已傳送的訊息，直到目標準備好接收訊息為止。

什麼是 Azure 服務匯流排主題？

Azure 服務匯流排主題與佇列類似，但可以有多個訂閱者。 當訊息傳送至主題而不是佇列時，可觸發多個元件以執行其工作。 假設使用者正在音樂分享應用程式中聆聽一首歌曲。 行動應用程式可能會傳送一則訊息到「已聆聽」主題。 該主題的 "UpdateUserListenHistory" 有一個訂用帳戶，而 "UpdateArtistsFanList" 有另一個訂用帳戶。 每一個函數都是由不同的元件處理，這些元件會收到它自己的訊息複本。

主題在內部會使用佇列。 當您張貼至主題時，訊息就會複製並放入每個訂用帳戶的佇列。 佇列表示即使處理該訂用帳戶的元件太過忙碌而無法跟上進度，仍可保留訊息複本待每個訂用帳戶分支處理。

佇列的優點

佇列基礎結構可支援許多進階功能，使其在下列方面很有用：

提高的穩定性

佇列可供分散式應用程式作為擱置傳遞到目的地元件訊息的暫存儲存體位置。 來源元件可以將訊息新增至佇列，而目的地元件可以擷取位於佇列前端的訊息以便處理。 佇列提高了訊息交換的可靠性，因為在需求高的時候，訊息可以等到目的地元件準備好進行處理。

訊息傳遞保證

佇列系統通常會保證將佇列中的每則訊息傳遞到目的地元件。 不過，這些保證可能會採用不同的方法：

  • 至少一次傳遞：使用這種方法，每則訊息會保證傳遞到至少其中一個從佇列擷取訊息的元件。 不過，要注意的是，在某些情況下，可能會多次傳遞相同訊息。 例如，如果有兩個 Web 應用程式執行個體從佇列擷取訊息，通常每則訊息只會傳送至其中一個執行個體。 不過，如果一個執行個體需要長時間來處理訊息，而逾時過期，訊息可能也會傳送到另一個執行個體。 您的 Web 應用程式程式碼設計時應該注意這種可能性。

  • 最多一次傳遞：使用這種方法，不會保證傳遞每則訊息，而且有很小的機會可能不會到達。 不過，與至少一次傳遞不同，訊息沒有機會傳遞兩次。 這有時候稱為「自動重複資料偵測」。

  • 先進先出 (FIFO)：在大部分的傳訊系統中，訊息通常會以新增的相同順序離開佇列，但您應該考慮是否保證此傳遞。 如果您的分散式應用程式需要精確地以正確順序處理訊息，則必須選擇包含 FIFO 保證的佇列系統。

交易式支援

群組中的一則訊息傳遞失敗時，某些密切相關的訊息群組可能會造成問題。

例如，請考慮使用電子商務應用程式。 當使用者選取 [購買] 按鈕時，可能會產生一連串訊息並將其送出至各種處理目的地：

  • 含有訂單詳細資料的訊息會傳送至物流中心
  • 含有總計和付款詳細資料的訊息會傳送至信用卡處理器
  • 含有收據資訊的訊息會傳送至資料庫來為客戶產生發票

在此情況下，我們想要確定「所有」訊息都經過處理，或完全不會處理。 如果沒有傳遞信用卡訊息，我們不會停留在交易程序中太久，而且所有訂單都會履行而無付款！ 您可以藉由將兩則訊息分組成一個交易，以避免這類的問題。 訊息交易會視為單一單位而成功或失敗 - 就像是資料庫世界一樣。 如果信用卡詳細資料訊息傳遞失敗，訂單詳細資料訊息也會失敗。

我該選取哪項服務？

了解此架構的通訊策略應該是訊息之後，您必須選擇要使用 Azure 儲存體佇列還是 Azure 服務匯流排。 您可以使用這兩種技術來儲存和傳遞您元件之間的訊息。 每種服務都有稍微不同的功能集，這表示您可以根據正在解決的問題選擇其中一種服務，或是同時使用兩種服務。

如果發生下列情況，請使用服務匯流排佇列：

  • 需要最多一次傳遞保證。
  • 需要 FIFO 保證。
  • 需要將訊息分組成交易。
  • 想要在不用輪詢佇列的情況下接收訊息。
  • 需要將角色型存取模型提供給佇列。
  • 需要處理大於 64 KB 但小於 100 MB 的訊息。 標準層支援的訊息大小上限為 256 KB，而進階層支援的訊息大小上限則為 100 MB。
  • 佇列大小不會增長到 1 TB 以上。 標準層的佇列大小上限為 80 GB，而進階層的佇列大小上限則為 1 TB。
  • 想要批次發佈及取用訊息。

如果發生下列情況，請使用服務匯流排主題：

  • 需要服務匯流排佇列提供的所有功能，此外還實作 pub-sub 模式，訊息可以在其中路由傳送至多個訂用帳戶之一，每個訂用帳戶都會有自己的獨立接收者

佇列儲存體的功能沒有那麼豐富，但如果您不需要上述任何功能，這可能是較簡單的選擇。 此外，如果您的應用程式具有下列任何需求，這會是最佳解決方案。

如果發生下列情況，請使用佇列儲存體：

  • 需要透過佇列傳遞的所有訊息稽核線索。
  • 預期佇列超過 1 TB 的大小。
  • 想要在佇列內部追蹤處理訊息的進度。

佇列是針對分散式應用程式元件之間所傳送訊息的簡單暫存儲存體位置。 您可以使用佇列來組織訊息，並適當地處理需求的意外激增。

當您想要簡單且容易編碼的佇列系統時，請使用儲存體佇列。 針對更進階的需求，請使用服務匯流排佇列。 如果單一訊息有多個目的地，但需要類似佇列的行為，請使用服務匯流排主題。