目錄
系統通訊方式有哪些?
RPC調用
RPC 全稱 Remote Procedure Call——遠程過程調用，它是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的方式。
RPC 調用分類 通訊協議層面 基於 HTTP 協議的 RPC；基於二進制協議的 RPC；基於 TCP 協議的 RPC 是否跨平臺 單語言 RPC，如 RMI, Remoting；跨平臺 RPC，如 google protobuffer, restful json，http XML。 調用過程 同步通信RPC和異步通信RPC 消息隊列
消息隊列”是在消息的傳輸過程中保存消息的容器。
消息隊列的應用場景
異步處理
有些業務不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，在需要的時候進行處理;例如用戶註冊的時候發送驗證郵件可以通過異步處理的方式在另外一個線程內完成發送郵件操作.
解耦
在應用開發過程中隨着需求的增加各個模塊進行過度耦合,各模塊之間形成相互調用的關係,我們可以利用消息隊列形成中間層進行解耦.
流量削峯
在應用某一時段會發生大流量的請求,例如雙十一會造成大量請求數據庫,數據庫很快就會形成瓶頸.我們可將數據請求持久化在消息隊列中,進行逐步處理.
日誌收集
在項目開發和運維的心中日誌是一個很重要的部分,如果儘可能全面而又有效的收集日誌進行分析是一個勢在必得的任務,我們可以使用消息隊列來構建統一日誌處理平臺.
事務最終一致
在行業中使用消息隊列來保證一個事務的最終一致性也是常見分佈式事務的解決方案.
消息隊列通訊模型
一個最基本的消息隊列應該具有消息發送者,消息處理中心,消息消費者三個功能.
在MQ中消息隊列主要有兩種通訊模型分別是PTP點對點和Pub/Sub發佈訂閱
常見的消息協議
消息協議是指用於實現消息隊列功能時雙方通信的一個約定, 例如 如何區分客戶端是生產消息還是消費消息? 客戶端向消息處理中心發送
"發送: I am a Javaer"字符串,那麼我們根據xxx約定字符中包含發送的代表生產消息,那麼我們就可以知道該客戶端要發送消息內容是" I am a Javaer",常見的消息協議有AMQP,MQTT,STOMP,XMPP等
AMQP
AMQP即Advanced Message Queuing Protocol，高級消息隊列協議，是面向消息中間件設計的應用層協議的一個開放標準。 它的主要特點是面向消息、隊列、路由(包括點對點和發佈/訂閱)]、可靠性和安全。
AMQP允許來自不同供應商的消息生產者和消費者實現真正的互操作擴展，就如同SMTP、HTTP、FTP等協議採用的方式一樣。而此前對於消息中間件的標準化努力則集中在API層面上(比如JMS)，且沒有提供互操作性的途徑。不同於JMS的僅僅定義API，AMQP是一個線路級的協議——它描述了通過網絡傳輸的字節流的數據格式。因此，遵從這個協議的任何語言編寫的工具均可以操作AMQP消息。
AMQP模型圖
Exchange即交換器，用來接收Producer發佈的消息，並通過設定的路由規則將消息路由給服務器中的Queue。
Binding即綁定器，可以理解爲路由規則。它的作用就是把Exchange和Queue按照路由規則綁定起來。
Binding Key即綁定關鍵字，Exchange視自身類型來決定Binding的路由行爲。
Routing Key即消息的路由關鍵字，Exchange根據這個關鍵字決定如何路由某條消息。
MQTT
MQTT 最初由 IBM 於上世紀 90 年代晚期發明和開發。它最初的用途是將石油管道上的傳感器與衛星相鏈接。顧名思義，它是一種支持在各方之間異步通信的消息協議。異步消息協議在空間和時間上將消息發送者與接收者分離，因此可以在不可靠的網絡環境中進行擴展。雖然叫做消息隊列遙測傳輸，但它與消息隊列毫無關係，而是使用了一個發佈和訂閱的模型。在 2014 年末，它正式成爲了一種 OASIS 開放標準，而且在一些流行的編程語言中受到支持（通過使用多種開源實現）。
MQTT模型圖
ATOMP
STOMP，Streaming Text Orientated Message Protocol，是流文本定向消息協議，是一種爲MOM(Message Oriented Middleware，面向消息的中間件)設計的簡單文本協議。它提供了一個可互操作的連接格式，允許STOMP客戶端與任意STOMP消息代理(Broker)進行交互。由於其設計簡單，很容易開發客戶端，因此在多種語言和多種平臺上得到廣泛應用。其中最流行的STOMP消息代理是Apache ActiveMQ。
ATOMP模型圖
JMS
注意: JMS不是消息隊列協議的一種，更不是消息隊列產品!
注意: JMS不是消息隊列協議的一種，更不是消息隊列產品!
注意: JMS不是消息隊列協議的一種，更不是消息隊列產品!
關於JMS你需要了解一點有趣的歷史.
消息隊列（Message Queue）起源於一位來自 MIT 的硬件設計教育工作者 Vivek Ranadivé 設想了一種通用軟件總線，就像主板上的總線那樣，供其他應用程序接入。Vivek在1983年成立了 Teknekron，高盛等公司作爲第一批用戶再金融交易中採用了 Teknekron的軟件，同時還誕生了第一代消息隊列軟件：Teknekron 的 The Information Bus（TIB）。
Teknekron 的 TIB 允許應用開發者建立一系列規則去描述消息內容，只要消息按照這些規則發佈出去，任何消費者應用都可以訂閱感興趣的內容，信息的生產者和消費者完全解耦，並且可以再傳輸過程中靈活混合。這個特性引起了電信特別是新聞機構的注意。1994年路透社收購了 Teknekron 。
由於消息隊列再金融交易中應用的反響，BIM 在1990年也開始研發自己的消息隊列軟件（BIM MQ），並且逐步演化成 WebSphere MQ 並統治着商業消息隊列平臺市場。同時微軟開發了Microsoft Message Queue（MSMQ）。然而這些商業MQ問題在供應商壁壘，各個廠商的 MQ 之間無法互通。爲了解決這個問題，Java Message Service（JMS）在2001年誕生了，試圖通過提供公共 Java API的方式隱藏MQ各個供應商提供的實際接口，從而跨越壁壘和解決互通問題，但是由於使用單獨的標準化接口來膠合衆多不同的接口使應用程序反而變得更加脆弱。
爲了解決各個MQ在各個生產商之間的通訊問題，Java Message Service（JMS）在2001年誕生了，試圖通過提供公共 Java API的方式隱藏MQ各個供應商提供的實際接口.是Java面向消息中間件的一套規範的Java API接口.
在JMS誕生之前大多數產品都支持點對點和發佈/訂閱兩種方式的通訊模型.所以JMS就將這兩種消息模型抽象成兩類規範,由MQ廠商選擇實現. 所以我們可以使用JMS的Java API在Java語言上操作具體的MQ產品.
小結
下一章節我們開始進入正式學習MQ消息通訊具體相關產品了,定個小目標,寫個簡單的MQ