實際上消息中間件的發展也是挺有意思的，我們知道任何一個技術的出現都是為了解決實際問題，這個問題是 通過一種通用的軟件“總線”也就是一種通信系統，解決應用程序之間繁重的信息通信工作。最早的小白鼠就是金融交易領域，因為在當時這個領域中，交易員需要通過不同的終端完成交易，每臺終端顯示不同的信息。如果接入消息總線，那么交易員只需要在一臺終端上操作，然后訂閱其他終端感興趣的消息。于是就誕生了發布訂閱模型（pubsub），同時誕生了世界上第一個現代消息隊列軟件（TIB）The information Bus, TIB允許開發者建立一系列規則去描述消息內容，只要消息按照這些規則發布出去，任何消費者應用都能訂閱感興趣的消息。隨著TIB帶來的甜頭被廣泛應用在各大領域，IBM也開始研究開發自己的消息中間件，3年后IBM的消息隊列IBM MQ產品系列發布，之后的一段時間MQ系列進化成了WebSphere MQ統治商業消息隊列平臺市場。

包括后期微軟也研發了自己的消息隊列（MSMQ）

各大廠商紛紛研究自己的MQ，但是他們是以商業化模式運營自己的MQ軟件，商業MQ想要解決的是應用互通的問題，而不是創建標準接口來允許不同MQ產品互通。所以有些大型的金融公司可能會使用來自多個供應商的MQ產品，來服務企業內部不同的應用。那么問題來了，如果應用已經訂閱了TIB MQ的消息然后突然需要消費IBM MQ的消息，那么整個實現過程會很麻煩。為了解決這個問題，在2001年誕生了 Java Message Service(JMS)，JMS通過提供公共的Java API方式，隱藏單獨MQ產品供應商的實現接口，從而跨越了不同MQ消費和解決互通問題。從技術層面來說，Java應用程序只需要針對JMS API編程，選擇合適的MQ驅動即可。JMS會處理其他部分。這種方案實際上是通過單獨標準化接口來整合很多不同的接口，效果還是不錯的，但是碰到了互用性的問題。兩套使用兩種不同編程語言的程序如何通過它們的異步消息傳遞機制相互通信呢。這個時候就需要定義一個異步消息傳遞的通用標準

所以AMQP（Advanced Message Queuing Protocol）高級消息隊列協議產生了，它使用了一套標準的底層協議，加入了許多其他特征來支持互用性，為現代應用豐富了消息傳遞需求，針對標準編碼的任何人都可以和任意AMQP供應商提供的MQ服務器進行交互。

除了JMS和AMQP規范以外，還有一種MQTT（Message Queueing Telemetry[特萊米缺]?Transport），它是專門為小設備設計的。因為計算性能不高的設備不能適應AMQP上的復雜操作，它們需要一種簡單而且可互用的方式進行通信。這是MQTT的基本要求，而如今，MQTT是物聯網（IOT）?生態系統中主要成分之一

今天要講解的Kafka，它并沒有遵循上面所說的協議規范，注重吞吐量，類似udp 和 tcp

?

總結

以上是生活随笔為你收集整理的消息中间件的发展过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。