解決的問題
一項技術的產生必然是爲了解決問題而生，瞭解了一項技術解決的問題，就能夠很輕鬆的理解這項技術的設計根本，從而更好地理解與使用這項技術。 消息中間件和RPC從根本上來說都是爲了解決分佈式系統的服務間通信問題，我們的服務從最初的單體應用發展到SOA架構到現在的微服務架構，必不可少的就是服務間通信，但從最初的設想，服務間通信僅僅就是一次請求響應調用而已，爲什麼發展出如此多的消息中間件與RPC技術，我們是否真的需要學習這麼多的消息中間件技術？ 答案是肯定的，接下來我們將分析我們爲什麼要了解及使用如此多的服務間通信技術，以及他們究竟都解決了哪些問題，在什麼場景下他們是必不可少的。
消息中間件 VS RPC
首先來說一下什麼是消息中間件和RPC，簡單來說，他們最主要的區別是，完成一次服務間通信需要的組件數量，本篇文章我們先來討論一下消息中間件的優勢與使用場景
RPC
消息中間件
從上面兩幅圖可以清晰地看出消息中間件比RPC要多了一個組件，那就是消息中間件本身，從而我們也能想到，使用消息中間件通信時，相較於使用RPC通信，會有更多的組件運維成本，也會增加一次通信的通信延遲，那麼我們爲什麼要使用消息中間件？一個很重要的原因就是，他爲我們增加了消息堆積能力，而這個能力提供給我們了很重要的流量削峯，高可用以及廣播等問題的解決方案。
流量削峯
流量削峯是指在發生突發性流量增長時，並不會讓上游服務（接收請求的服務）出現超負荷併發從而導致宕機等風險，MQ（消息隊列）的解決方案是將流量暫緩存至自己的Queue中，將穩定的持續的將流量發送給消費者。
(在發生流量突增時，上游服務的實時消息處理量，RPC（上），MQ（下）) 上面的圖展示的是不同時間段上游服務的請求量曲線，可以看出，通過RPC進行請求的上游服務在短時間內會接收大量超出最高負載的請求，從而可能引發大量的請求超時和CPU 100%導致的服務宕機等情況。而通過MQ進行通信時，若MQ發現接收到的請求超出消費者的最大負載時，則會將請求暫存至消息隊列中，並將請求保持在一個持續穩定的量發送給消費者（上游服務），從而保證了系統的穩定。 流量削峯在面對例如秒殺等場景就顯得尤爲重要，例如淘寶的雙十一整點秒殺，12306的整點放票等活動，消息隊列均起到的重要作用，我們也就可以很好地理解，爲什麼12306在推出排隊系統後，服務宕機的概率被大大減小了（雖然體驗依舊是一團糟...?）。 推薦中間件：RabbitMQ
使用消息中間件提高服務的可用性
可用性是指服務在某個時間段內正常運行的時間，提高可用性就是指減少服務的故障停機時間，那麼MQ是如何提高服務的可用性的呢。
（當Service B宕機時的MQ（上）與RPC（下）） 當上游出現問題時，將無法接收下游服務給予的請求，這時上游服務會因上游服務不能完成請求而報錯，從而導致這個請求無法完成，導致整個系統不能接收更多的請求，用戶就會感知到，服務掛掉了... 而消息中間件的處理方式是，上游服務出現宕機時，將消息緩存至消息隊列中，等待上游服務恢復正常時，在繼續處理請求。當然這裏你應該也會發現，在該場景下，消息中間件更適合處理一些無需立即處理，也就是異步的請求，例如日誌，數據持久化等操作，他們是並不需要返回或立即返回處理結果給用戶的。 推薦中間件：Kafka
使用MQ實現事務的最終一致性
分佈式事務是個極其複雜的話題，本文不展開討論，這裏主要討論一下MQ在分佈式事務中所起到的作用。 最終一致性簡單地說就是弱一致性的一種，允許存在一定的不一致窗口，但要求在有限的時間內關閉不一致窗口並讓所有系統最終一致。
（圖片出處：http://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html） 上圖描述了一個基於MQ實現最終一致性的一種解決方案（異步確保模式）。 主要描述的是DB A和DB B分屬兩個不同的數據中心要進行數據同步，消息發送方會將數據寫入至MQ中並在本地記錄消息標識（已發送的消息），當消息接收方接收到該消息並處理後會告知發送方處理結果（成功/失敗），消息發送方對接收方的處理結果進行處理，如若處理失敗則進行補償操作。 （關於更多相關細節不在本文中過多討論...） MQ主要起到的作用有兩點：
- 採用異步方式提高了事務請求的性能及併發量，如果採用同步方式調用的事務請求並且事物的調用鏈非常長則會導致用戶等待時間極長，並降低系統的併發量及可用性
- 提供了消費方接收消息的重試機制，消費方能夠處理該事務的前提是能夠接收該事務，MQ更多的保證了不會因消費方宕機，網絡超時等等原因的消費失敗。
本文簡單的說了一下消息中間件的優勢和使用場景，在接下來的文章將更詳細的介紹每種消息中間件的優劣及其原理，以及使用RPC框架相較於消息中間件的優勢所在及使用場景，希望大家能夠支持：）