共用方式為

服務匯流排中的進階訊息佇列通訊協定 (AMQP) 1.0 支援

  • 發行項

Azure 服務匯流排雲端服務會使用 AMQP 1.0 作為其主要通訊方式。 Microsoft 已與整個產業的合作夥伴合作，包括競爭傳訊代理程式的客戶和廠商，在過去十年內開發及發展 AMQP，並在 OASIS AMQP 技術委員會中開發新的延伸模組。 AMQP 1.0 是 ISO 和 IEC 標準 (ISO 19464:20149)。

透過廠商中立和實作中立的開放式標準通訊協定，AMQP 可讓您打造一個跨平台的混合式應用程式。 您可以透過使用不同語言和架構所建立，且在不同作業系統上執行的元件來建構應用程式。 所有這些元件都可以連線到服務匯流排，並有效地且不失真地順暢交換結構化的商業訊息。

簡介：何謂 AMQP 1.0 以及它為什麼很重要？

傳統上，訊息導向的中介軟體產品會採用專屬的通訊協定，以進行用戶端應用程式和代理程式之間的通訊。 這表示一旦選取特定的廠商訊息代理程式，您就必須使用該廠商的程式庫來連接用戶端應用程式與該代理程式。 結果便是您會一定程度地與該廠商相依，因為若要將應用程式移植到其他產品，將需要變更所有已連接應用程式的程式碼。 在 Java 社群中，Java 訊息服務 (JMS) 和 Spring Framework 抽象概念等語言特定 API 標準已減輕該痛點，但具有狹窄的功能範圍，並排除使用其他語言的開發人員。

此外，從不同廠商連接訊息代理程式有些麻煩。 通常需要應用程式層級的橋接功能，才能在不同系統間移動訊息，以及轉換成這些系統專屬的訊息格式。 舉例來說，在將新的統一介面提供給較舊的不同系統使用，或在合併公司之後欲整合 IT 系統時，便常常有這種需求。 AMQP 可讓您直接與代理程式互連連線，例如使用 Apache Qpid 分派路由器之類的路由器，或其中一個 RabbitMQ 之類的代理程式原生「shovels」。

軟體產業是門瞬息萬變的生意；有時還沒回應過來便又出現了新的程式設計語言和應用程式架構。 同樣的，IT 系統的需求也會隨著時間而進化，因此開發人員會想要充分利用最新的平台功能。 不過，選取的傳訊廠商有時並不支援這些平台。 如果傳訊通訊協定是專用的，其他人無法為這些新平台提供程式庫。 因此，您必須使用建置閘道或橋接器等方法，讓您得以繼續使用傳訊產品。

開發 進階訊息佇列通訊協定 (AMQP) 1.0 的動機就是為了處理這些問題。 AMQP 是 JP Morgan Chase 的發明，與大多數的金融服務公司一樣，JP Morgan Chase 是訊息導向中介軟體的重度使用者。 目的很簡單：建立一個開放式標準訊息通訊協定，讓透過使用不同語言、架構及作業系統所建置的元件能夠建置訊息架構應用程式，並且全都使用一組供應商所提供的最優質元件。

AMQP 1.0 技術功能

AMQP 1.0 是一個有效率且可靠的有線等級訊息通訊協定，可以用來建置強大的跨平台訊息應用程式。 此通訊協定有一個簡單目的︰就是在兩個用戶端間定義安全、可靠且有效率的訊息傳輸機制。 訊息本身是使用可攜式資料表示法來編碼，讓異質傳送者和接收者可透過百分之百臨場感來交換結構化的商業訊息。 以下摘要說明最重要的功能：

  • 效率：AMQP 1.0 是連線導向的通訊協定，可針對通訊協定指示和透過其傳輸的商業訊息使用二進位編碼。 其中包含精密的流程控制配置，可以將網路與連接的元件使用率最大化。 也就是說，此通訊協定的設計目的是在效率、彈性及交互操作性之間取得平衡。
  • 可靠：AMQP 1.0 通訊協定讓您能夠利用某個範圍的可靠性保證來交換訊息，從「射後不理」變成可靠且只認可一次的傳遞。
  • 彈性：AMQP 1.0 是一種有彈性的通訊協定，讓您可以用來支援不同的拓撲。 您可以使用相同的通訊協定，來進行用戶端對用戶端、用戶端對代理人的通訊，以及代理人對代理人的通訊。
  • 與訊息代理程式模型無關：AMQP 1.0 規格不會在訊息代理程式使用的訊息模型上強制執行任何需求。 這表示您能夠將 AMQP 1.0 支援新增至現有的訊息代理人。

AMQP 1.0 是一項標準 (Standard 的 S 為大寫)

AMQP 1.0 是由 ISO 與 IEC 核定為 ISO/IEC 19464:2014 的國際標準。

有一個由包含技術提供者及使用者公司在內超過 20 家公司所組成的核心群組，從 2008 年起就開始開發 AMQP 1.0。 在這段期間，使用者公司貢獻了他們的實際商業需求，而技術廠商逐步開發出此通訊協定來符合這些需求。 在整個過程中，廠商參與了他們共同合作的研討會，一起驗證他們實作間的交互操作性。

在 2011 年 10 月，開發工作移轉到資訊結構標準發展組織 (OASIS) 內的一個技術委員會，並在 2012 年 10 月發佈 OASIS AMQP 1.0 標準。 以下為在標準開發期間參與了該技術委員會的公司：

  • 技術廠商：Axway Software、Huawei Technologies、IIT Software、INETCO Systems、Kaazing、Microsoft、Mitre Corporation、Primeton Technologies、Progress Software、Red Hat、SITA、Software AG、Solace Systems、VMware、WSO2、Zenika。
  • 使用者公司：Bank of America、Credit Suisse、Deutsche Boerse、Goldman Sachs、JPMorgan Chase。

OASIS AMQP 技術委員會現任主席代表 Red Hat 和 Microsoft。

以下是一些關於開放標準之最常引用的優點：

  • 比較不會被廠商鎖定
  • 互通性
  • 可以廣泛使用程式庫與工具
  • 提供保護以免過時
  • 對於有經驗之員工的可用性
  • 較低且可管理的風險

AMQP 1.0 和服務匯流排

Azure 服務匯流排中的 AMQP 1.0 支援代表您現在能夠從一組平台中使用有效率的二進位通訊協定，來使用服務匯流排佇列與發佈/訂閱代理傳訊功能。 此外，您還可以建置使用混合語言、架構及作業系統所建置之元件所組成的應用程式。

下圖說明的是一個部署範例，其中的 Java 用戶端是在 Linux 上執行並使用標準的 Java 訊息服務 (JMS) API 撰寫而成，而 .NET 用戶端則是在 Windows 上執行並使用 AMQP 1.0 透過服務匯流排來交換訊息。

顯示一個 服務匯流排 與兩個 Linux 環境和兩個 Windows 環境交換訊息的圖表。

圖 1：範例部署案例示範使用服務匯流排和 AMQP 1.0 的跨平台訊息服務

所有支援的服務匯流排用戶端程式庫可使用 AMQP 1.0，透過 Azure SDK 來使用。

透過 WebSocket 的 AMQP 通訊協定選項會透過連接埠 TCP 443 (和 HTTP/REST API 一樣) 來執行，但在功能上與一般 AMQP 並無不同。 此選項的初始連線延遲較高 (因為會進行額外的交握來回行程)，額外負荷也會多一點 (以便能共用 HTTPS 連接埠)。 如果選取此模式，則 TCP 連接埠 443 就足供進行通訊。 下列選項可供選取 AMQP WebSocket 模式。

語言 選項
.NET (Azure.Messaging.ServiceBus) 使用採用 ServiceBusClientOptions 作為參數的建構函式建立 ServiceBusClient。 將 ServiceBusClientOptions.TransportType 設定為 ServiceBusTransportType.AmqpWebSockets
.NET (Microsoft.Azure.ServiceBus) 建立用戶端物件時，請使用採用 TransportType、ServiceBusConnection 或 ServiceBusConnectionStringBuilder 作為參數的建構函式。

針對採用 transportType 作為參數的建構，請將參數設定為 TransportType.AmqpWebSockets。

對於採用 ServiceBusConnection 作為參數的建構函式，請將 ServiceBusConnection.TransportType 設為 TransportType.AmqpWebSockets。

如果您使用 ServiceBusConnectionStringBuilder，請使用提供選項的建構函式來指定 transportType。
Java (com.azure.messaging.servicebus) 建立用戶端時，將 ServiceBusClientBuilder.transportType 設定為 AmqpTransportType.AMQP.AMQP_WEB_SOCKETS
Java (com.microsoft.azure.servicebus) 建立用戶端時，將 com.microsoft.azure.servicebus.ClientSettings 中的 transportType 設定為 com.microsoft.azure.servicebus.primitives.TransportType.AMQP_WEB_SOCKETS
JavaScript 建立服務匯流排用戶端物件時，請使用 ServiceBusClientOptions 中的 webSocketOptions 屬性。
Python 建立服務匯流排用戶端時，請將 ServiceBusClient.transport_type 設定為 TransportType.AmqpOverWebSocket

在 2026 年 9 月 30 日，我們將淘汰不符合 Azure SDK 準則的 Azure 服務匯流排 SDK 程式庫 WindowsAzure.ServiceBus、Microsoft.Azure.ServiceBus 和 com.microsoft.azure.servicebus。 我們也將結束 SBMP 通訊協定的支援，因此您將無法在 2026 年 9 月 30 日之後再使用此通訊協定。 請在該日期之前移轉至最新的 Azure SDK 程式庫，該程式庫提供重要的安全性更新和改進的功能。

雖然較舊的程式庫仍可在 2026 年 9 月 30 日之後使用，但它們將不再收到 Microsoft 的官方支援和更新。 如需詳細資訊，請參閱支援淘汰公告。

此外，您可以從任何符合 AMQP 1.0 規範的通訊協定堆疊使用服務匯流排：

語言 程式庫
Java Apache Qpid Proton-J
C/C++ Azure uAMQP C、Apache Qpid Proton-C
Python 適用於 Python 的 Azure uAMQP、 Apache Qpid Proton Python）
PHP 適用於 PHP 的Azure uAMQP
Ruby Apache Qpid Proton Ruby
Go Azure Go AMQP、Apache Qpid Proton Go
C#/F#/VB AMQP .NET Lite、Apache NMS AMQP
JavaScript/Node Rhea

相關內容

準備好進行深入了解嗎？ 請造訪下列連結：