傳訊網橋模式

本文說明傳訊網橋模式，這是一種技術，可用來整合以不同傳訊基礎結構為基礎的不同系統。

內容和問題

許多組織和工作負載可能會不小心擁有使用多個傳訊基礎結構的IT系統，例如Microsoft消息佇列（MSMQ）、RabbitMQ、Azure 服務匯流排 和 Amazon SQS。 由於合併、收購或將目前的內部部署系統擴充至雲端裝載的元件，以符合成本效益且易於維護，可能會發生此問題。

開發人員可藉由修改整合的系統，以使用 HTTP 型 Web 服務進行通訊，來解決這項挑戰。 不過，此方法有缺點，包括：

• 系統必須藉由在一端新增 HTTP 用戶端，另一端新增 HTTP 要求處理程式來修改系統。 然後必須重新測試並重新部署系統。
• HTTP 端點必須裝載，當您讓 Web 服務安全且高可用性時，這會增加複雜性。
• 需要自定義建置重試機制的常見網路連線問題。

解決方案

如果整合的系統是由透過交換訊息通訊的元件所組成，傳訊網橋模式可改善整合並降低缺點。

在此案例中，每個系統都會連線到一個傳訊基礎結構。 若要跨不同的傳訊基礎結構整合，請引進一個網橋元件，以同時連線到兩個或多個傳訊基礎結構。 網橋會從其中一個提取訊息，並將它們推送至另一個訊息，而不會變更承載。

整合的系統不需要辨識其他人或網橋。 傳送者系統設定為將特定訊息傳送至其原生傳訊基礎結構上的指定佇列。 網橋會挑選這些訊息，並將其轉送至不同傳訊基礎結構中的另一個佇列，而接收者系統會從中挑選它們。

福利

• 透過傳訊網橋整合的系統不需要修改。 在理想情況下，端點不會察覺到訊息已橋接。
• 相較於 HTTP 替代專案，整合更可靠，因為至少一次訊息傳遞機制保證。
• 移轉案例可以更有彈性。 例如，端點可以從一個傳訊基礎結構移轉至另一個傳訊基礎結構，因為排程允許，而不是一次全部移轉。

缺點

• 橋接路由上可能無法使用一或兩種傳訊技術的進階功能。
• 橋接路由必須考慮這兩種技術的限制。 例如，MSMQ 中訊息大小上限可能是 4 MB，但 Azure 儲存體 佇列中只有 64 KB。

問題和考量

實作傳訊網橋模式時，請考慮下列幾點：

• 如果其中一個整合式系統依賴分散式交易，例如Microsoft分散式交易協調器 （DTC），則您必須在網橋中實作重複數據刪除機制。

• 如果其中一個整合的系統未使用任何傳訊基礎結構且無法修改，您可以在其他系統和 SQL Server 模擬佇列所使用的基礎結構之間建立傳訊網橋。 舊版系統可以使用 SQL Server 的異動數據擷取功能，將其變更推送至專用佇列數據表來傳送訊息。 網橋可以將這些訊息轉送至實際的傳訊基礎結構。

• 您可以在每個傳訊基礎結構中使用單一佇列，指定為 橋接佇列。 在此拓撲中，將傳送系統設定為使用該特定佇列作為傳送至其他系統的訊息類型目的地。 您也可以在每個傳訊基礎結構中使用多個佇列組，讓傳送者不知道網橋。 系統會針對目的地系統傳訊基礎結構中的每個目的地佇列建立陰影佇列。 網橋會轉送陰影佇列與其對應專案之間的訊息。

• 若要符合所需的可用性服務等級協定 （SLA），您可能需要使用 競爭取用者 方法相應放大傳訊網橋。

• 一般訊息處理元件會使用 重試模式 來處理暫時性失敗。 重試計數器限制可讓元件偵測 有害 訊息，並從佇列中移除它們以解除封鎖處理。 如果發生基礎結構失敗，網橋可能需要不同的重試原則，以防止錯誤地將訊息識別為有害訊息。 您可以使用 斷路器 模式來暫停轉送。

使用此模式的時機

當您需要下列專案時，請使用傳訊網橋模式：

• 將現有的系統與修改所需的最少需求整合。
• 整合無法使用其他傳訊技術的舊版應用程式。
• 使用雲端裝載的元件擴充現有的內部部署應用程式。
• 當因特網連線不穩定時，連線到異地分散式系統。
• 將單一分散式系統從一個傳訊基礎結構以累加方式移轉至另一個，而不需要一心一意地移轉整個系統。

如果下列情況，此模式可能不適合：

• 至少涉及的其中一個系統依賴另一個訊息基礎結構中不存在的功能。
• 整合本質上是同步的，起始系統需要立即回應。
• 整合具有特定的功能或非功能需求，例如安全性或隱私權考慮。
• 整合的數據量超過傳訊系統的容量，或使傳訊成為問題的昂貴解決方案。

工作負載設計

架構設計人員應該評估如何在工作負載的設計中使用傳訊網橋模式，以解決 Azure 良好架構架構支柱中涵蓋的目標和原則。 例如：

如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。

範例

.NET Framework 中撰寫的應用程式可用來管理裝載於內部部署的員工排程。 應用程式結構良好，且具有透過 MSMQ 進行通訊的個別元件。 應用程式可運作，而工作負載小組無意重寫它。 排程數據的新取用者必須建置以符合商務需求，而 IT 策略要求將新軟體建置為雲端原生應用程式，以優化成本和傳遞時間。

過去針對工作負載小組運作的異步佇列架構，因此小組會使用相同的架構方法，但使用現代技術，服務匯流排。 工作負載小組不想在雲端與內部部署之間引入同步通訊，以減輕影響另一個部署的延遲或無法使用。

小組決定使用傳訊網橋模式來連線這兩個系統。 此模式包含兩個部分。 一個部分會接收來自現有 MSMQ 佇列的訊息，並將其轉送至 服務匯流排。 另一個部分會從 服務匯流排 取得訊息，並將其轉送至現有的 MSMQ 佇列。

當實作小組使用此方法時，他們會利用現有應用程式中的現有基礎結構來與新的元件整合。 現有的應用程式不知道新的元件裝載在 Azure 中。 同樣地，新元件會藉由傳送 服務匯流排 訊息，以與舊版應用程式通訊的方式與舊版應用程式通訊。 網橋會轉送兩個系統之間的訊息。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

• Rob Bagby |主體架構內容潛在客戶
• 凱爾·貝利 |軟體工程師
• Udi Dahan |特定軟體的創始人和首席執行官
• Chad Kittel | 首席軟體工程師
• 布萊恩·拉莫斯 |開發人員關係
• Szymon Pobiega |工程師

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

下一步

• 來自企業整合模式社群的傳訊網橋模式描述 。
• 瞭解如何在 Spring Java 架構中實 作傳訊網橋 。
• QPid 網橋 可用來橋接已啟用AMQP的傳訊技術。
• NServiceBus Messaging Bridge 是佇列對佇列網橋的 .NET 實作，可支援一系列傳訊基礎結構，包括 MSMQ、服務匯流排 和 Azure 佇列記憶體。
• NServiceBus.Router 是實作 Messaging Bridge 模式的開放原始碼專案。 它也允許在單一實例中橋接兩項以上的技術，並具有進階的訊息路由功能。

相關資源

• 競爭取 用者 模式可確保傳訊網橋的實作可以處理負載。
• 重試模式可讓傳訊網橋處理暫時性失敗。
• 當網橋任一端發生停機時，斷路器模式會節省資源。