精講企業集成的消息傳遞模式

在優銳課的學習分享中，讓咱們看一下消息傳遞模式，例如數據類型通道，無效消息和無效消息，崩潰驗證和有保證的傳遞以及非消息客戶端。

前言

當兩個或多個應用程序要交換數據時，它們經過經過鏈接到其餘應用程序的通道發送數據來進行交換。發送數據的應用程序可能不知道哪一個應用程序將接收數據，可是經過選擇一個特定的通道來發送數據，發送方知道接收方將是經過在其上查找數據來查找此類數據的接收方渠道。

在設計應用程序時，開發人員必須知道在何處放置什麼類型的數據以與其餘應用程序共享該數據，一樣也要在哪裏尋找來自其餘應用程序的哪些類型的數據。這些通訊路徑沒法在運行時動態建立和發現。它們須要在設計時達成共識，以便應用程序知道其數據來自何處以及數據將到達何處。一個例外是請求-答覆中的答覆渠道。請求者能夠建立或得到應答者不知道的新通道，將其指定爲請求消息的返回地址，而後應答者可使用它。另外一個例外是支持分層通道的郵件系統實現。接收者能夠訂閱層次結構中的父對象，而後發送者能夠將接收者不知道的內容發佈到新的子頻道，訂閱者仍將接收消息。

首先，應用程序肯定消息傳遞系統將須要提供的渠道。後續的應用程序將嘗試在可用的通道周圍設計其通訊，可是，若是這不切實際，則將須要添加其餘通道。當一組應用程序已經使用了一組特定的通道，而新的應用程序但願加入時，它們也將使用現有的一組通道。現有應用程序添加新功能時，它們可能須要新渠道。

另外一個常見的混亂緣由是消息通道是單向仍是雙向。從技術上講，二者都不是；通道更像是一些應用程序向其中添加數據而其餘應用程序從中獲取數據的存儲桶。可是因爲數據是在從一個應用程序傳播到另外一個應用程序的消息中，因此給出了通道方向，使其成爲單向的。若是某個通道是雙向的，則意味着一個應用程序既會向同一通道發送消息，又會從同一通道接收消息，由於該應用程序傾向於繼續消耗本身的消息，而該消息本來應該發送給其餘應用程序。所以，出於全部實際目的，通道是單向的。結果，對於兩個應用程序進行雙向對話，它們將須要兩個通道，每一個方向一個。

所以，在消息傳遞系統中使用了不一樣類型的通道。消息通道是消息傳遞系統的基本體系結構模式，從根本上用於在應用程序之間交換數據。

一、一對一或一對多

當應用程序僅與一個其餘應用程序或對該數據感興趣的任何其餘應用程序共享數據時。 而後你可使用點對點通道。 這不能保證在該通道上發送的每條數據都一定會到達同一接收器，由於該通道可能有多個接收器。 但它確實確保僅其中一個應用程序能夠接收任何一條數據。

若是全部接收者都須要接收數據，請使用發佈-訂閱通道。 而後，數據被通道有效地複製，並將其傳遞到每一個接收器。 發送者簡單地將事件廣播給全部感興趣的接收者。

二、數據類型（數據類型通道）

郵件內容必須符合某種類型，以便接收者理解數據的結構。 數據類型通道是一個原則，通道上的全部數據必須具備相同的類型。 這是消息傳遞系統須要大量渠道的主要緣由。 若是數據能夠是任何類型，則消息傳遞系統在任何兩個應用程序之間僅須要一個通道（在每一個方向上）。

三、無效和無效的消息

消息系統能夠確保正確傳遞消息，可是不能保證接收方知道如何處理。 接收者對數據的類型和含義有指望。 可是，它能夠作的是將奇怪的消息放在專門指定的「無效消息通道」上，但願監視該通道的某些實用程序能夠提取該消息並弄清楚該如何處理。

許多消息傳遞系統具備相似的內置功能，即死信通道，用於成功發送但最終沒法成功傳遞的消息。 再次，但願一些監視該通道的實用程序將知道如何處理沒法傳遞的消息。

四、防撞證實

若是消息傳遞系統崩潰或爲了維護而關閉。 備份並運行時，這些消息仍將保留在其通道中。 默認狀況下，否； 通道將其消息存儲在內存中。 可是，``保證傳遞''使通道保持持久狀態，以便其消息存儲在磁盤上。 這會影響性能，但會使消息傳遞更加可靠。

五、非郵件客戶端

若是應用程序沒法鏈接到消息傳遞系統，但仍想參與消息傳遞。 可是，若是消息傳遞系統能夠經過其用戶界面，其業務服務API，數據庫或經過網絡鏈接（例如TCP / IP或HTTP）以某種方式鏈接到應用程序，則可使用消息傳遞系統上的``通道適配器''來 將一個通道（或一組通道）鏈接到應用程序，而無需修改應用程序，也沒必要在應用程序所在的同一臺計算機上運行消息傳遞客戶端。

有時，「非消息客戶端」其實是一個消息客戶端，僅用於其餘消息系統。 在這種狀況下，做爲兩個消息傳遞系統上的客戶端的應用程序能夠在二者之間創建一個消息傳遞橋，從而將它們有效地鏈接到一個複合消息傳遞系統中。

總結

文章寫到這裏，相信你們如今能有一個簡單的描述了。若有不足之處，歡迎補充評論。