服務間通訊方式【MQ在分佈式系統中的使用場景】

解決的問題

一項技術的產生必然是爲了解決問題而生，瞭解了一項技術解決的問題，就可以很輕鬆的理解這項技術的設計根本，從而更好地理解與使用這項技術。


消息中間件和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主要起到的做用有兩點

1. 採用異步方式提升了事務請求的性能及併發量，若是採用同步方式調用的事務請求而且事物的調用鏈很是長則會致使用戶等待時間極長，並下降系統的併發量及可用性
2. 提供了消費方接收消息的重試機制，消費方可以處理該事務的前提是可以接收該事務，MQ更多的保證了不會因消費方宕機，網絡超時等等緣由的消費失敗。
   
   

本文簡單的說了一下消息中間件的優點和使用場景，在接下來的文章將更詳細的介紹每種消息中間件的優劣及其原理，以及使用RPC框架相較於消息中間件的優點所在及使用場景，但願你們可以支持：）


如若發現文章中有哪些紕漏或問題，請及時指出，或對文章有哪些不懂的問題也歡迎在評論區留言提問，我會盡量的給予你們進行解答：）