銷售: 1-800-867-1380

Azure 佇列和服務匯流排佇列 - 異同比較

更新日期: 2014年10月

作者: Valery Mizonov、Seth Manheim 和 Abhishek Lal

參與者:Brad Calder、Jai Haridas、Jason Hogg、Jeff Irwin、Jaganathan Thangavelu、Kartik Paramasivam、Todd Holmquist-Sutherland 和 Ruppert Koch

本文將分析 Azure 目前所提供之兩種佇列類型之間的差異和相似性:Microsoft Azure 佇列和 Microsoft Azure 服務匯流排佇列。透過使用這項資訊,您可以比較和比對個別的技術,而且對於哪一種方案最符合您的需求,也能夠做出較明智的決定。

Microsoft Azure 支援兩種佇列機制:Azure 佇列服務匯流排佇列

Azure 佇列 (屬於 Azure 儲存體基礎結構的一部分) 具有簡單的 REST 架構 Get/Put/Peek 介面,而且能夠在服務內部與服務之間提供可靠且持續的訊息傳遞。

服務匯流排佇列是較廣泛之 Azure 訊息基礎結構的一部分,此基礎結構支援佇列處理以及發佈/訂閱、Web 服務遠端處理和整合模式。如需以下內容的詳細資訊服務匯流排佇列、主題/訂閱和轉送,請參閱服務匯流排訊息模式的概觀

雖然這兩種佇列技術同時存在,不過 Azure 佇列較早導入,做為建立在 Azure 儲存體服務之上的專屬佇列儲存機制。服務匯流排佇列則是建立在較廣泛的「代理訊息」基礎結構之上,此基礎結構的設計目的是要整合可能跨越多種通訊協定、資料合約、信任網域及/或網路環境的應用程式或應用程式元件。

本文會分別討論 Azure 所提供之兩種佇列技術的功能行為和實作差異,藉以進行比較。本文也會引導您選擇最符合應用程式開發需求的功能。

Azure 佇列和服務匯流排佇列都是 Microsoft Azure 目前所提供之訊息佇列服務的實作。每種佇列都有稍微不同的功能集,表示您可以根據特定方案的需求或正在解決的商務/技術問題選擇其中一種佇列,或是使用這兩種佇列。

在判斷哪一種佇列技術適合給定方案的目的時,方案架構設計人員和開發人員應該考慮下列建議。如需詳細資料,請參閱下一節。

身為方案架構設計人員/開發人員,您應該在下列情況中考慮使用 Azure 佇列

  • 您的應用程式必須在佇列中儲存超過 80 GB 的訊息,而且訊息的存留期短於 7 天。

  • 您的應用程式想要在佇列內部追蹤處理訊息的進度。如果處理訊息的工作者當機,這就很有用。後續工作者可以接著使用該項資訊,從先前工作者停止的地方繼續處理。

  • 您需要在伺服器端記錄針對佇列執行的所有交易。

身為方案架構設計人員/開發人員,您應該在下列情況中考慮使用服務匯流排佇列

  • 您的方案必須能夠接收訊息,而不需要輪詢佇列。使用服務匯流排時,您可以使用服務匯流排支援的 TCP 型通訊協定進行長期輪詢接收作業來達成此目的。

  • 您的方案需要使用佇列來提供保證的先進先出 (FIFO) 排序傳遞。

  • 您想要在 Azure 中和在 Windows Server (私人雲端) 上有相稱體驗。如需詳細資訊,請參閱<Service Bus for Windows Server>(英文)。

  • 您的方案必須能夠支援自動重複偵測。

  • 您想要讓應用程式將訊息當成長時間執行的平行資料流來處理 (訊息是透過訊息上的 SessionId 屬性與資料流相關聯)。在此模型中,取用端應用程式中的每個節點都會競爭取得資料流而不是訊息。將資料流提供給取用端節點時,節點可以檢查應用程式資料流使用交易的狀態。

  • 從佇列傳送或接收多個訊息時,您的方案需要交易行為和不可部分完成性。

  • 應用程式特有工作負載的存留時間 (TTL) 特性可能會超過 7 天的週期。

  • 您的應用程式所處理的訊息可能會超過 64 KB,但是不太可能會接近 256 KB 的限制。

  • 您需要提供以角色為基礎的存取模型給佇列,並且針對傳送者和接收者提供不同的權限。

  • 您的佇列大小不會成長超過 80 GB。

  • 您想要使用 AMQP 1.0 標準型訊息代理人。如需以下內容的詳細資訊 AMQP,請參閱服務匯流排 AMQP 概觀

  • 您可以預見最後會從佇列架構的點對點通訊移轉至允許緊密整合其他接收者 (訂戶) 的訊息交換模式,而且每個接收者都會接收傳送至佇列之部分或所有訊息的複本。後者是指服務匯流排原本提供的發佈/訂閱功能。

  • 您的訊息方案必須能夠支援「最多一次」傳遞保證,而不需要建置其他基礎結構元件。

  • 您想要能夠批次發佈及取用訊息。

  • 您需要與 Windows Communication Foundation (WCF) 中的 .NET Framework 通訊堆疊完全整合。

下列各節中的表格會提供佇列功能的邏輯群組,讓您一眼就能比較出 Azure 佇列和服務匯流排佇列所提供的功能。

本節將比較 Microsoft Azure 佇列和 Microsoft Azure 服務匯流排佇列所提供的一些基本佇列功能。

 

比較準則 Azure佇列 服務匯流排佇列

排序保證

如需詳細資訊,請參閱<其他資訊>一節的第一個附註。

是 - 先進先出 (FIFO)

(透過使用訊息工作階段)

傳遞保證

至少一次

至少一次

最多一次

交易支援

(透過使用本機交易)

接收行為

非封鎖

(如果找不到新的訊息,便立即完成)

含/不含逾時的封鎖

(提供長期輪詢,或稱為「Comet 技術」)

非封鎖

(僅限透過使用 .NET Managed 應用程式開發介面)

推送型 API

OnMessageOnMessage 工作階段管理的 (.NET) API。

接收模式

查看與租用

查看與鎖定

接收與刪除

獨佔存取模式

以租用為基礎

以鎖定為基礎

租用/鎖定持續時間

30 秒 (預設值)

7 天 (上限) (您可以使用 UpdateMessage API 更新或釋放訊息租用。)

60 秒 (預設值)

您可以使用 RenewLock API 來更新訊息鎖定。

租用/鎖定資料粒度

訊息層級

(每個訊息都可以具有不同逾時值,如此您就能在處理訊息時,視需要使用 UpdateMessageAPI 更新這個逾時值)

佇列層級

(每個佇列都有套用至所有訊息的鎖定資料粒度,但是您可以使用 RenewLock API 來更新鎖定)。

批次接收

(在擷取訊息時明確指定訊息計數,最多 32 個訊息)

(隱含啟用預先提取屬性或明確使用交易)

批次傳送

(透過使用交易或用戶端批次)

  • Azure 佇列中的訊息通常是先進先出,但有時也不按順序。舉例來說,訊息的可見性逾時期間到期 (例如,處理期間因為用戶端應用程式當機而導致)。當可見性逾時到期時,訊息會再次出現在佇列上,以便其他工作者從佇列中清除此訊息。此時,佇列中可能放入最新出現的訊息 (等待再次清除佇列),而且是最初在它之後才加入佇列的訊息後面。

  • 如果您已使用 Azure Storage Blob 或資料表,而且開始使用佇列,則保證您可獲得 99.9% 的可用性。如果您將 Blob 或資料表搭配服務匯流排佇列使用,則您將獲得較低的可用性。

  • 服務匯流排佇列中的保證 FIFO 模式需要使用訊息工作階段。如果應用程式在處理以 Peek & Lock 模式所接收的訊息時當機,下一次佇列接收者接受訊息工作階段時,將會在存留時間 (TTL) 期限到期之後,從失敗的訊息開始處理。

  • Azure 佇列是設計來支援標準佇列案例,例如使應用程式元件脫鉤以增加延展性及容錯能力、進行負載均衡,以及建置程序工作流程。

  • 服務匯流排佇列支援「至少一次」(At-Least-Once) 傳遞保證。此外,也可支援「最多一次」(At-Most-Once) 語意,方法是使用工作階段狀態來儲存應用程式狀態,並且使用交易以不可部分完成的方式接收訊息並更新工作階段狀態。Azure 工作流程服務會使用這項技術來保證「最多一次」(At-Most-Once) 傳遞。

  • Azure 佇列提供跨佇列、資料表和 BLOB 的統一、一致程式設計模型,對於開發人員和作業團隊皆適用。

  • 服務匯流排佇列會在單一佇列的內容中提供本機交易的支援。

  • 服務匯流排所支援的「接收與刪除」(Receive and Delete) 可讓您降低訊息作業計數 (以及相關聯的成本),但是也會降低傳遞保證。

  • Azure 佇列可讓租用功能延長訊息的租用。這可讓工作者維持短期的訊息租用。因此,如果某個工作者當機,就可以由另一個工作者快速地重新處理訊息。此外,如果工作者需要的處理時間超過目前的租用時間,也可以延長訊息的租用。

  • Azure 佇列會提供一種可讓您在佇列或取消佇列訊息時設定的可見性逾時。此外,您可以在執行階段使用不同的租用值來更新訊息,並且在相同佇列的訊息之間更新不同的值。服務匯流排鎖定逾時定義於佇列中繼資料內;不過,您可以透過呼叫 RenewLock 方法,更新鎖定。

  • 在 服務匯流排 佇列中,封鎖接收作業的最大逾時值是 24 天。但是,以 REST 為基礎的逾時最大值為 55 秒。

  • 服務匯流排所提供的用戶端批次允許佇列用戶端將多個訊息批次處理成單一傳送作業。批次處理僅適用於非同步傳送作業。

  • Azure 佇列的 200TB 上限 (當您虛擬化帳戶時則更多) 和無限佇列等功能,使它成為 SaaS 提供者的理想平台。

  • Azure 佇列提供彈性、高效能的委派存取控制機制。

本節將比較 Azure 佇列和服務匯流排佇列所提供的進階功能。

 

比較準則 Azure佇列 服務匯流排佇列

排程傳遞

自動處理無效信件

增加佇列存留時間值

(經由可見性逾時的就地更新)

(經由專屬的應用程式開發介面函數提供)

有害訊息支援

就地更新

伺服器端交易記錄

儲存體度量資訊

分鐘度量:提供可用性、TPS、API 呼叫計數、錯誤計數等等的即時度量,全都即時 (每分鐘彙總一次並在生產環境中發生狀況的短短數分鐘內回報。如需詳細資訊,請參閱關於儲存體分析度量

(透過呼叫 GetQueues 來進行大量查詢)

狀態管理

Microsoft.ServiceBus.Messaging.EntityStatus.Active, Microsoft.ServiceBus.Messaging.EntityStatus.Disabled, Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled, Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabled

訊息自動轉送

清除佇列函數

訊息群組

(透過使用訊息工作階段)

每個訊息群組的應用程式狀態

重複偵測

(可在傳送者端設定)

WCF 整合

(提供現成的 WCF 繫結)

WF 整合

自訂

(需要建置自訂 WF 活動)

原生

(提供現成的 WF 活動)

瀏覽訊息群組

依 ID 擷取訊息工作階段

  • 這兩種佇列技術都可讓訊息排定在稍後傳遞。

  • 佇列自動轉送可讓數以千計的佇列將其訊息自動轉送至單一佇列,而接收端應用程式將從中取用訊息。您可以使用這個機制來達成安全性、控制流程,並在每個訊息發行者之間隔離儲存體。

  • Azure 佇列支援更新訊息內容。您可以使用這項功能,將狀態資訊和累加進度更新保存至訊息中,以便從最後已知的檢查點處理訊息,而不用從頭開始處理。使用服務匯流排佇列時,您則可以透過使用訊息工作階段來實現相同案例。工作階段可讓您使用 SetStateGetState 儲存和擷取應用程式處理狀態。

  • 只有服務匯流排佇列支援的無效信件處理可用於隔離接收端應用程式無法順利處理的訊息,或是由於存留時間 (TTL) 屬性過期而無法送達目的地的訊息。TTL 值會指定訊息保留在佇列中的時間長度。在服務匯流排中,當 TTL 期限到期時,訊息將會移至名為 $DeadLetterQueue 的特殊佇列。

  • 為了在 Azure 佇列中找出「有害」訊息,應用程式會在取消佇列訊息時檢查訊息的 DequeueCount 屬性。如果 DequeueCount 超過給定的臨界值,應用程式就會將訊息移至應用程式定義的「無效信件」佇列。

  • Azure 佇列可讓您取得針對佇列執行之所有交易的詳細記錄,以及彙總度量資訊。這兩個選項都有助於偵錯和了解應用程式的 Azure 佇列使用狀況。它們也有助於對您的應用程式進行效能微調以及降低使用佇列的成本。

  • 服務匯流排所支援之「訊息工作階段」的概念可讓屬於特定邏輯群組的訊息與給定的接收者產生關聯,進而在訊息與其個別的接收者之間建立類似工作階段的親近性。您可以在訊息上設定 SessionID 屬性,藉以在服務匯流排中實現這項進階功能。然後,接收者就可以接聽特定的工作階段識別碼,並且接收共用指定之工作階段識別碼的訊息。

  • 服務匯流排佇列所支援的重複偵測功能會根據 MessageID 屬性的值,自動移除傳送至佇列或主題的重複訊息。

本節將從可能適用之容量和配額的觀點來比較 Azure 佇列和服務匯流排佇列。

 

比較準則 Azure佇列 服務匯流排佇列

佇列大小上限

200 TB

(限制為單一儲存體帳戶容量)

1 GB 到 80 GB

(在建立佇列和啟用分割時定義)

訊息大小上限

64 KB

(使用 Base64 編碼時,則為 48 KB)

Azure 可以結合佇列和 blob 來支援大型訊息,因此您可以針對單一項目在佇列中最多放入 200GB。

256 KB

(包括標頭和主體,標頭大小上限:64 KB)

訊息 TTL 上限

7 天

無限制

佇列數目上限

無限制

10,000

(每個服務命名空間,可以增加)

並行用戶端數目上限

無限制

無限制

(100 個並行連接限制只適用於以 TCP 通訊協定為基礎的通訊)

  • 使用 Azure 佇列時,如果訊息的內容不是 XML 安全的訊息,則必須經過 Base64 編碼。如果您對訊息進行 Base64 編碼,使用者裝載最多可為 48 KB,而非 64 KB。

  • 使用服務匯流排佇列時,儲存在佇列中的每個訊息都包含兩個部分:標頭和主體。訊息大小總計不得超過 256 KB。

  • 當用戶端透過 TCP 通訊協定與 服務匯流排 佇列通訊時,單一 服務匯流排 佇列的並行連接數目上限會限制為 100。這個數目是在傳送者與接收者之間共用的。如果達到此配額,其他連接的後續要求將會遭到拒絕,而且呼叫端程式碼將會收到例外狀況。這項限制不會加諸於使用 REST 架構應用程式開發介面連接至佇列的用戶端。

  • 服務匯流排會強制執行佇列大小限制。佇列大小上限是在建立佇列時指定的,而且可以具有 1 到 80 GB 之間的值。如果達到在建立佇列時所設定的佇列大小值,其他內送訊息將會遭到拒絕,而且呼叫端程式碼將會收到例外狀況。如需以下內容的詳細資訊服務匯流排中的配額,請參閱 Service Bus 配額

  • 如果您的單一服務匯流排服務命名空間需要超過 10,000 個佇列,您可以連絡 Azure 支援團隊並要求增加。若要讓服務匯流排擴充到超過 10,000 個佇列,您也可以使用 Microsoft Azure 管理入口網站來建立其他服務命名空間。

本節將比較 Azure 佇列和服務匯流排佇列所提供的管理功能。

 

比較準則 Azure佇列 服務匯流排佇列

管理通訊協定

REST over HTTP/HTTPS

REST over HTTPS

執行階段通訊協定

REST over HTTP/HTTPS

REST over HTTPS

AMQP 1.0 標準 (TCP 加 TLS)

.NET Managed 應用程式開發介面

(.NET Managed 儲存體用戶端應用程式開發介面)

(.NET Managed 代理訊息應用程式開發介面)

Native C++

Java 應用程式開發介面

PHP 應用程式開發介面

Node.js 應用程式開發介面

任意中繼資料支援

佇列命名規則

長度最多可達 63 個字元

(佇列名稱的字母必須是小寫)

長度最多可達 260 個字元

(佇列名稱不區分大小寫)

取得佇列長度函數

(如果訊息過了 TTL 而到期卻未遭刪除,則為近似值)

(精確的時間點值)

查看函數

  • Azure 佇列支援可套用至佇列描述的任意屬性,格式為名稱/值組。

  • 這兩種佇列技術都提供不需要鎖定訊息即可查看訊息的功能,這項功能在實作佇列總管/瀏覽器工具時很有用。

  • 與 REST over HTTP 相較之下,服務匯流排 .NET 受管理代理訊息 API 會運用全雙工 TCP 連接來改善效能,而且可支援 AMQP 1.0 標準通訊協定。

  • Azure 佇列名稱可為 3 至 63 個字元長,而且可以包含小寫字母、數字和連字號。如需詳細資訊,請參閱為佇列和中繼資料命名

  • 服務匯流排佇列名稱的長度最多可達 260 個字元,而且命名規則的限制較少。服務匯流排佇列名稱可以包含字母、數字、句號 (.)、連字號 (-) 及底線 (_)。

本節將從效能的觀點來比較 Azure 佇列和服務匯流排佇列。

 

比較準則 Azure佇列 服務匯流排佇列

最大輸送量

每秒最多 2,000 個訊息

(以 1 KB 訊息為基準)

每秒最多 2,000 個訊息

(以 1 KB 訊息為基準)

平均延遲

10 毫秒

(在 TCP Nagle 停用時)

20 至 25 毫秒

節流行為

以 HTTP 503 代碼拒絕

(已節流的要求不會被視為可計費的要求)

以例外狀況/HTTP 503 拒絕

(已節流的要求不會被視為可計費的要求)

  • 單一 Azure 佇列每秒最多可以處理 2,000 筆交易。交易是指 PutGetDelete 作業。傳送單一訊息至佇列 (Put) 會計算為一筆交易,不過接收訊息通常是兩個步驟的程序,其中包含擷取 (Get),接著要求從佇列中移除訊息 (Delete)。因此,成功的取消佇列作業通常包含兩筆交易。以批次擷取多個訊息可以減少此情況的影響,因為您可在單一交易中最多 Get 32 個訊息,並針對每一個訊息,緊接著加上 Delete。如需更好的輸送量,您可以建立多個佇列 (儲存體帳戶可以具有無限個佇列)。

  • 當您的應用程式達到 Azure 佇列的最大輸送量時,佇列服務通常會傳回「HTTP 503 伺服器忙碌中」回應。發生這種狀況時,應用程式應該使用指數輪詢延遲來觸發重試邏輯。

  • 在處理與儲存體帳戶位於相同位置 (地區) 之託管服務傳來的小型訊息 (小於 10 KB) 時,Azure 佇列的平均延遲為 10 毫秒。

  • Azure 佇列和服務匯流排佇列都會拒絕對正受到節流的佇列發出的要求,藉以強制執行節流行為。不過,它們都不會將已節流的要求視為可計費的要求。

  • 對服務匯流排佇列進行的基準測試顯示,單一佇列可以達到每秒最多 2,000 個訊息的訊息輸送量 (訊息大小大約為 1 KB)。若要達到更高的輸送量,請使用多個佇列。如需有關使用服務匯流排達到效能最佳化的詳細資訊,請參閱使用 Service Bus 代理訊息改善效能的最佳作法

  • 達到服務匯流排佇列的最大輸送量時,ServerBusyException (使用 .NET Managed 代理訊息應用程式開發介面) 或 HTTP 503 (使用 REST 架構應用程式開發介面) 回應會傳回給佇列用戶端,表示佇列正在受到節流。

本節將討論 Azure 佇列和服務匯流排佇列所支援的驗證和授權功能。

 

比較準則 Azure佇列 服務匯流排佇列

驗證

對稱金鑰

對稱金鑰

存取控制模型

透過 SAS 權杖進行委派存取。

透過 ACS 進行 RBAC

識別提供者同盟

  • 針對其中一種佇列技術發出的每個要求都必須經過驗證。目前不支援具有匿名存取的公用佇列。使用 SAS 時,您可以發佈唯寫 SAS、唯讀 SAS 或甚至完整存取權 SAS 來滿足這個案例。

  • Azure 佇列所提供的驗證配置需要使用對稱金鑰,這個金鑰是雜湊式訊息驗證碼 (HMAC)、使用 SHA-256 演算法所計算並且編碼為 Base64 字串。如需以下內容的詳細資訊個別通訊協定,請參閱驗證對儲存體帳戶的存取權限。服務匯流排佇列支援一個使用對稱金鑰的類似模型。如需詳細資訊,請參閱 使用服務匯流排的共用存取簽章驗證.

  • 服務匯流排支援的 Microsoft Azure Active Directory 存取控制服務 (也稱為「存取控制服務」或 ACS) 提供三種不同角色:[管理員]、[傳送者] 和 [接收者] (Azure 佇列目前不支援)。

  • 由於服務匯流排會提供 ACS 整合,所以它可讓您與 Active Directory (透過使用 ADFS) 以及常見的 Web 識別提供者 (例如 Live ID、Google、Facebook 和 Yahoo) 組成同盟。

本節將從成本的觀點來比較 Azure 佇列和服務匯流排佇列。

 

比較準則 Azure佇列 服務匯流排佇列

佇列交易成本

$0.0005

(每 10,000 筆交易)

$0.01

(每 10,000 個訊息)

可計費的作業

全部

僅限傳送/接收

(其他作業免費)

閒置交易

計費

(查詢空的佇列會計算為一筆可計費的交易)

計費

(針對空的佇列進行接收會被視為一個可計費的訊息)

儲存成本

$0.07

(每個 GB/月)

$0.00

傳出資料傳輸成本

$0.12 - $0.19

(根據地理位置)

$0.12 - $0.19

(根據地理位置)

  • 資料傳輸的收費依據是在給定的計費週期內,經由網際網路離開 Azure 資料中心的資料量總計。

  • 位於相同地區之 Azure 服務之間的資料傳輸不另收費。

  • 在撰寫本文時,所有傳入的資料傳輸也不另收費。

  • 對服務匯流排佇列執行訊息傳遞作業時,ACS 交易的成本微不足道。服務匯流排會根據訊息傳遞 Factory 物件的每個單一執行個體各取得一個 ACS 權杖。然後,重複使用此 Token 直到它過期為止 (大約 20 分鐘之後)。因此,服務匯流排中的訊息傳遞作業量不會直接與支援這些交易所需的 ACS 交易數量成正比。

  • 由於支援長期輪詢,所以在需要低度延遲傳遞的情況下使用服務匯流排佇列可能會符合成本效益。

note附註
所有成本都可能會變更。上表僅反映撰寫本文時的目前定價,不包括目前可能適用的任何促銷優惠方案。如需最新的定價資訊,請參閱<定價概觀>頁面。

關於何時應該使用 Azure 佇列或服務匯流排佇列的決定明顯取決於許多因素。這些因素可能主要取決於應用程式及其架構的個別需求。如果您的應用程式已經使用 Microsoft Azure 的核心功能,您可能會想要選擇 Azure 佇列,尤其是需要服務之間的基本通訊和訊息傳遞或是需要大小可超過 80 GB 的佇列時。

因為服務匯流排佇列會提供許多進階功能 (例如工作階段、交易、重複偵測、自動處理無效信件和持久的發佈/訂用功能),所以如果您要建置混合應用程式或者您的應用程式額外需要這些功能,這種佇列可能是首選。

本文一開始摘要說明了規範建議事項,然後列出並比較 Azure 目前所提供之每項佇列技術的功能。本主題依照功能群組列出各項功能,藉以呈現具有視覺吸引力的並存分析,這樣應該有助於您了解 Azure 佇列和服務匯流排佇列之間的相似性與差異。透過更深入地了解這兩項技術,對於佇列技術的使用時機,您將能夠做出較明智的決定。

另請參閱

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