消息系統本質論

煙霧信號、快遞服務、信鴿和信號量這些都是通信的一種方式，你可能會立馬想到消息。人類老是有相互聯繫的需求，同時老是去尋找新的通訊方式去打敗距離帶來的挑戰。現代的通信科技已經有了很大的進步，可是糾其本質，不過是發送者、接受者、和以消息爲核心構成的通信架構體系。

同步通訊模型

軟件應用也有一樣的需求，系統之間須要交換消息。他們一般須要確保消息必定可以送達目的地。他們有時候須要當即收到接受者的回覆，可是不老是這樣。在一些應用案例中，他們可能須要接收到多個回覆，都是基於不一樣的場景和不一樣的需求，也就衍生了不一樣形式的通信。

全部的這些均可以用下面的圖來表達：

上圖描述的請求-應答模式是最廣泛的一種模式，本地系統（client）與經過遠程系統（server）暴露的通訊終端進行同步通信。在形式上不管是遠程系統調用，仍是web service調用，或者是遠程資源的消費，這些在本質上都是一個模型，只是表現形式不一樣：本地系統向遠程系統發送消息，本地系統同步等待遠程系統返回應答，系統之間經過點對點的方式通信。

這種方式有優勢也優缺點，一方面，基於這種模型易於編程，程序工做的形式和單一的程序沒什麼區別。然而，另外一方面看，這種模型使得不一樣系統之間緊密耦合，存在在系統系統架構層面難以優化和擴展等等問題。

one way style模型

下面來看看one way style方式：

在one way style方式中，系統之間經過傳遞消息的方式異步交互，所謂異步也就是系統A在發送完消息以後不須要同步等待系統B的應答。這種模型一般依賴一個叫作消息經紀人（Broker）的第三方系統。在上面的圖中，咱們也能夠叫它消息隊列，系統扮演着消息的發送者（producer）和消息的接受者（consumer）角色。producer將消息發送給broker，producer依賴broker將消息送達consumer。若是producer須要獲得consumer的應答，那麼他們經過一樣的機制進行消息的交換，只是這個時候消息的發送者和消息的接受者調換個位置。

loosely coupled模型

使用消息方式給系統體系結構帶來的好處是它使得系統之間可以鬆散的耦合。系統之間不須要知道各自都在什麼地方，系統A想要與系統B通訊，只須要知道系統B的代號便可。而在消息經紀人的幫助下（broker），系統A可以確信消息必定可以被送達到系統B的手中，咱們能夠用下面的圖來表達：

上圖咱們能夠看出：

1. 系統之間不會由於由於某個系統癱瘓而相互影響。
   

2. 系統的單機性能不會影響其餘系統。
   

3. 經過增長和減小系統能夠擴展應用的總體負載。
   

4. 消息的發送者能夠不用關心消息的接受者在哪裏，用的是什麼技術。

這種體系結構給開發者帶來的影響是：在消息系統中，事情變得稍微複雜了些，開發者須要改變編程方式。

若是經過上面的介紹仍是有點模糊，咱們能夠用你們熟悉的簡單郵件傳輸協議（SMTP）來模擬一下。在這個協議中，郵件被投遞到SMTP服務器，拿到郵件的服務器會將郵件轉發到下一個SMTP服務器，直到郵件被送達接受者的SMTP服務器。這個時候，消息被放在指定郵箱的隊列中，等待消費者查看，一般是經過POP3協議或者是IMAP協議。經過SMTP服務，郵件的發送者不須要知道郵件何時被送達到郵件接受者手中，甚至不用關心郵件到底會不會被最終送達到郵件接受者的手中。當郵件送達失敗以後，郵件的發送者會收件送達失敗的消息。咱們可以確認的是，broker已經成功接受producer初始發送的消息。

若是消息的發送者須要獲得消息接受者的應答，消息會被以一樣的機制送達到消息發送者的手中，這個時候消息的發送者變成了後來的消息接收者，消息的接收者相反。咱們能夠用下面的圖來表示：

這篇文章翻譯自《RabbitMQ Essentials》，主要在介紹RabbitMQ依賴的AMQP協議以前先簡單介紹一下消息的本質概念。