訊息分配管理系統

menu icon

訊息分配管理系統

「訊息分配管理系統」是應用程式間的通訊技術,用於協助建置共用整合機制,以支援雲端原生、微服務型、無伺服器及混合雲架構。

何謂「訊息分配管理系統」?

「訊息分配管理系統」是一種軟體,其可讓應用程式、系統和服務彼此進行通訊並交換資訊。 訊息分配管理系統藉由在正規傳訊通訊協定之間轉換訊息完成前述任務。 這使得互相依存的服務可以彼此直接「交談」,即使使用不同語言撰寫或在不同平台上實作也無妨。

訊息分配管理系統是傳訊中介軟體或訊息導向中介軟體 (MOM) 解決方案中的軟體模組。 這類中介軟體提供標準化方法,以便開發人員處理應用程式元件之間的資料流,如此一來他們即可專注於其核心邏輯。 它可以做為分散式通訊層,以便讓跨越多個平台的應用程式能夠進行內部通訊。

訊息分配管理系統可以驗證、儲存、遞送訊息,並提供訊息給適當目的地。 它們在其他應用程式之間充當中介,允許傳送端在不知道接收端位置的情況下發出訊息,不限接收端是否在作用中或其中有多少接收端。 這可以促進系統內部流程和服務的取消連結。

為了提供可靠的訊息儲存和遞送保證,訊息分配管理系統通常依賴名為訊息佇列的子結構或元件來儲存與排序訊息,直到消費端應用程式能夠處理這些訊息為止。 在訊息佇列中,訊息會以確切的傳送順序進行儲存,並保留在佇列中直到確認接收為止。

非同步傳訊 (15:11) 是指訊息分配管理系統能夠進行的應用程式之間通訊類型。 它可防止遺失寶貴資料,並讓系統即使面對公用網路常見的間歇性連線或延遲問題仍可持續運作。 非同步傳訊保證會以相對於其他訊息的正確順序遞送訊息一次(且僅一次)。

訊息分配管理系統可能包含用來處理多個訊息佇列之間互動的佇列管理程式,以及提供資料遞送、訊息轉換、持續性及用戶端狀態管理功能的服務。

訊息分配管理系統的模式

訊息分配管理系統提供兩種基本訊息配送模式或傳訊樣式:

  • 點對點傳訊:此配送模式用於訊息傳送端與接收端之間具有一對一關係的訊息佇列。 佇列中的每一個訊息只會傳送給一個接收端,而且只會消費使用一次。 當訊息必須只處理一次時,才會採用點對點傳訊。 此傳訊樣式的合適使用案例範例包括薪資和財務交易處理。 在這些系統中,傳送端和接收端都需要保證每次付款只會傳送一次,而且僅此一次。
  • 發佈/訂閱傳訊:在此訊息配送模式,通常稱為「發佈/訂閱」,每一個訊息的生產者會將它發佈至某個主題,而眾多的訊息消費者則會訂閱他們想要從中接收訊息的主題。 發佈至某個主題的所有訊息都會配送至訂閱該主題的所有應用程式。 這是一種廣播樣式配送方法,其中在訊息發佈者與其消費者之間具有一對多關係。 例如,如果航空公司發佈航班著陸時間或延遲狀態更新,許多當事者可以運用這些資訊: 執行飛機維修和加油的地面工作人員、行李處理人員、為下一趟旅程做準備的空服員和駕駛員,以及負責通知大眾的視覺顯示畫面操作人員。 發佈/訂閱子傳訊樣式就很適合此情境使用。

雲端架構中的訊息分配管理系統

雲端原生應用程式是為了善用雲端運算的固有優勢而建置,包括彈性、可擴充性及快速部署。 這些應用程式是由名為微服務的小型離散式可重複使用元件所組成。 每一個微服務都會進行部署,而且可以彼此獨立執行。 這表示更新、擴充或重新啟動其中任何一個微服務,都不會影響系統中的其他微服務。 通常封裝在容器中的微服務會一起運作以構成整個應用程式,但每一個微服務都有自己的堆疊,包括可能彼此不同的的資料庫和資料模型。

微服務必須有相互溝通的方法,才能在彼此和諧運作。 訊息分配管理系統是它們用來建立此共用通訊骨幹的一種機制。

訊息分配管理系統通常用來在混合雲環境中管理內部部署系統與雲端元件之間的通訊。 使用訊息分配管理系統可增加對於服務之間通訊的控制,並確保資料在應用程式元件之間安全、可靠且有效率地傳送。 訊息分配管理系統可以在整合多雲環境時扮演類似角色,它可以讓位於不同平台的工作負載和執行時期彼此相互通訊。 它們也很適合在無伺服器運算中使用,其中會根據需求來隨需應變執行個別的雲端代管型服務。

訊息分配管理系統與 API

REST API 通常用於微服務之間的通訊。 「表示法狀態傳送 (REST)」定義一組原則和限制,讓開發人員在建置 Web 服務時可以遵循。 任何遵守這些規則的服務將可以透過一組統一共用的無狀態運算子與要求進行通訊。 「應用程式設計介面 (API)」表示基礎程式碼,如果它符合 REST 規則,則不同服務之間可以彼此交談。

REST API 使用「超文字傳送通訊協定 (HTTP)」來進行通訊。 HTTP 是公用網際網路的標準傳輸通訊協定,因此 REST API 廣為人知、常被使用且可廣泛交互作業。 不過, HTTP 是要求/回應通訊協定,因此最好是在呼叫同步要求/回覆的情況中使用。 這表示透過 REST API 發出要求的服務必須設計成預期立即回應。 如果接收回應的用戶端關閉,則傳送服務將會在等待回覆時遭到封鎖。 在這兩種服務中應建置失效接手和錯誤處理邏輯。

訊息分配管理系統在服務之間啟用非同步通訊,因此傳送服務不需要等待接收服務的回覆。 對於採用它們的系統來說,這可以提升其容錯和備援。 此外,使用訊息分配管理系統使系統有助於更輕鬆地擴充系統,因為發佈/訂閱傳訊模式可以隨時支援服務數目變更。 訊息分配管理系統還會追蹤消費者的狀態。

訊息分配管理系統與事件串流平台

而訊息分配管理系統可以支援兩個或更多的傳訊模式,其中包括訊息佇列和發佈/訂閱,而事件串流平台僅提供發佈/訂閱配送模式。 為了與大量訊息搭配使用而設計的事件串流平台可以輕易進行擴充。 它們能夠將記錄串流排序至名為主題的類別中,然後儲存它們直到符合預先定義的時間量。 不過,與訊息分配管理系統不同,事件串流平台無法保證訊息遞送或追蹤哪些消費者已接收訊息。

相較於訊息分配管理系統,事件串流平台提供較高的可擴充性但較少的確保容錯(例如訊息重新傳送)功能,此外,訊息遞送和佇列功能也比較有限。

進一步瞭解事件驅動型架構

訊息分配管理系統與 ESB(企業服務匯流排)

企業服務匯流排 (ESB) 是一種架構模式,有時用於在企業中實作的服務導向架構。 在 ESB 中,集中式軟體平台將通訊協定和資料格式結合成「通用語言」,以供架構中的所有服務和應用程式共用。 例如,它可以將收到的要求從某個通訊協定(例如 XML)轉換成另一種通訊協定(例如 JSON)。 ESB 使用自動化流程來轉換其訊息內容。 集中式軟體平台還可以處理其他的編排邏輯,例如連線功能、遞送及要求處理。

不過,ESB 基礎架構很複雜,而且可能難以整合且維護成本高昂。 當正式作業環境出現問題時難以進行疑難排解,它們不容易擴充而且更新也很麻煩。

訊息分配管理系統是 ESB 的「輕量型」替代方案,它提供一種讓服務之間相互通訊的機制,但更簡單成本也更低。 它們很適合用於微服務架構,且隨著 ESB 的失寵而變得越來越普遍。

訊息分配管理系統使用案例

實作訊息分配管理系統可以解決跨產業和不同企業運算環境中各種商業需求。 無論何時何地,只要需要可靠的應用程式間相互通訊和訊息傳遞保證,它們都會很有用。

訊息分配管理系統通常採用下列方式:

  • 金融交易和付款處理:確定付款一次而且只有一次是很重要的。 使用訊息分配管理系統來處理這些交易的資料,以保證付款資訊既不會遺失也不會意外複製,同時提供接收證明,並且在中介網路關閉時系統仍然能夠可靠地進行通訊。
  • 電子商務訂單處理與履行:如果你在網路上做生意,您的品牌聲譽高低取決於您網站和電商平台的可靠性。 訊息分配管理系統能夠提升容錯能力並保證訊息只使用一次,僅此一次使其成為處理線上訂單時的自然選擇。
  • 在資料待用和轉移時保護高度機密的資料:如果您的產業受到高度管制,或您的企業面臨重大安全風險,請選擇具有端對端加密功能的傳訊解決方案。

訊息分配管理系統與 IBM Cloud

對於在雲端旅程中進行應用程式現代化的組織而言,訊息分配管理系統正在佔據新的重要地位。 許多世界上最成功的企業,包括 85% 的 Fortune 100 大企業,都依賴 IBM 的訊息分配管理系統功能,這些功能是為了支援現今的敏捷開發環境、微服務架構、混合雲基礎架構,以及各式各樣的系統類型和連線需求。

進行下一步: 瞭解 IBM Cloud Pak for Integration,它是建基於 IBM MQ 核心功能的先進企業傳訊解決方案。

立即開始使用 IBM Cloud 帳戶