消息傳遞做爲基本通訊機制已經在全世界成功運用。不管是人與人、機器與人仍是機器與機器之間,消息傳遞一直都是惟一經常使用的通訊方式。在雙方(或更多)之間交換消息有兩種基本機制。編程
同步消息傳遞緩存
異步消息傳遞安全
同步消息傳遞在這種狀況下使用,當消息發送者但願在某個時間範圍內收到響應,而後再進行下一個任務。基本上就是他在收到響應前一直處於「阻塞」狀態。服務器
異步消息意味着發送者並不要求當即收到響應,並且也不會阻塞整個流程。響應無關緊要,發送者總會執行剩下的任務。網絡
上面提到的技術,當兩臺計算機上的程序相互通訊的時候,就普遍使用了異步消息傳遞。隨着微服務架構的興起,很明顯咱們須要使用異步消息傳遞模型來構建服務。架構
這一直是軟件工程中的基本問題,並且不一樣的人和組織機構會提出不一樣的方法。我將介紹在企業IT系統中普遍使用的三種最成功的異步消息傳遞技術。異步
Java消息傳遞服務(Java Messaging Service (JMS))編程語言
JMS是最成功的異步消息傳遞技術之一。隨着Java在許多大型企業應用中的使用,JMS就成爲了企業系統的首選。它定義了構建消息傳遞系統的API。分佈式
圖片來源於網絡微服務
下面是JMS的主要特性:
面向Java平臺的標準消息傳遞API
在Java或JVM語言好比Scala、Groovy中具備互用性
無需擔憂底層協議
有queues和topics兩種消息傳遞模型
支持事務
可以定義消息格式(消息頭、屬性和內容)
高級消息隊列協議(Advanced Message Queueing Protocol (AMQP))
JMS很是棒並且人們也很是樂意使用它。微軟開發了NMS(.NET消息傳遞服務)來支持他們的平臺和編程語言,它效果還不錯。可是碰到了互用性的問題。兩套使用兩種不一樣編程語言的程序如何經過它們的異步消息傳遞機制相互通訊呢。此時就須要定義一個異步消息傳遞的通用標準。JMS或者NMS都沒有標準的底層協議。它們能夠在任何底層協議上運行,可是API是與編程語言綁定的。AMQP解決了這個問題,它使用了一套標準的底層協議,加入了許多其餘特徵來支持互用性,爲現代應用豐富了消息傳遞需求。
圖片來源於網絡
下面是AMQP的主要特性:
獨立於平臺的底層消息傳遞協議
消費者驅動消息傳遞
跨語言和平臺的互用性
它是底層協議的
有5種交換類型direct,fanout,topic,headers,system
面向緩存的
可實現高性能
支持長週期消息傳遞
支持經典的消息隊列,循環,存儲和轉發
支持事務(跨消息隊列)
支持分佈式事務(XA,X/OPEN,MS DTC)
使用SASL和TLS確保安全性
支持代理安全服務器
元數據能夠控制消息流
不支持LVQ
客戶端和服務端對等
可擴展
消息隊列遙測傳輸(Message Queueing Telemetry Transport (MQTT))
如今咱們已經有了面向基於Java的企業應用的JMS和麪向全部其餘應用需求的AMQP。爲何咱們還須要第三種技術?它是專門爲小設備設計的。計算性能不高的設備不能適應AMQP上的複雜操做,它們須要一種簡單並且可互用的方式進行通訊。這是MQTT的基本要求,而現在,MQTT是物聯網(IOT)生態系統中主要成分之一。
圖片來源於網絡
下面是MQTT的主要特性:
面向流,內存佔用低
爲小型無聲設備之間經過低帶寬發送短消息而設計
不支持長週期存儲和轉發
不容許分段消息(很難發送長消息)
支持主題發佈-訂閱
不支持事務(僅基本確認)
消息其實是短暫的(短週期)
簡單用戶名和密碼,基於沒有足夠信息熵的安全
不支持安全鏈接
消息不透明
Topic是全局的(一個全局的命名空間)
支持最新值隊列(Last Value Queue (LVQ) )
客戶端和服務端不對稱
不能擴展 原文:Comparison of Asynchronous Messaging Technologies: JMS, AMQP, and MQTT