深刻理解阿里分佈式消息中間件

什麼是分佈式消息中間件

什麼是分佈式消息中間件？

對於分佈式消息中間件，首先要了解兩個基礎的概念，即什麼是分佈式系統，什麼又是中間件。

分佈式系統：

「A distributed system is one in which components located at networked
computers communicate and coordinate their actions only by passing
messasges.」——《Distributed Systems Concepts and Design》

從上面這個解釋能夠獲得分佈式系統的兩個特色：

1. 組件分佈在網絡計算機上
2. 組件之間經過消息來協調行動

中間件：

Middleware is computer software that provides services to software
applications beyond those available from the operating system. It can
be described as "software glue". Middleware makes it easier for
software developers to implement communication and input/output, so
they can focus on the specific purpose of their application.——維基百科

中間件被描述爲爲應用程序提供操做系統所提供的服務以外的服務，簡化應用程序的通訊、輸入輸出的開發，使他們專一於本身的業務邏輯。

從維基百科上對中間件的解釋感受有點繞，其實能夠從「空間」的角度去理解中間件，即中間件是處於「中間層」的組件，是上層的應用程序和底層的服務之間的橋樑（好比DB中間件的上層是應用程序，底層是DB服務），也是應用與應用之間的橋樑（好比分佈式服務組件）。

分佈式消息中間件：

「Message-oriented middleware (MOM) is software or hardware
infrastructure supporting sending and receiving messages between
distributed systems.」——維基百科

維基百科給出的消息中間件的定義是支持在分佈式系統中發送和接受消息的硬件或軟件基礎設施（對咱們這裏討論的範圍來講確定就是軟件了）。

那麼分佈式消息中間件其實就是指消息中間件自己也是一個分佈式系統。

爲何要使用消息中間件

消息中間件就是能夠省去繁瑣的步驟，直達目的，怎麼講呢，就是好比你想不少人，知道你的動態，而知道的人可能手機沒電，可能手機信號很差，可能手機不在服務區，或者看的人比較忙，看的時間不固定，這樣的時候，你發送的消息怎麼會讓其看到呢，就是創建一個微信公衆號，能夠知足用戶隨時看到你想讓其看到的消息，這就是中間件的一種應用方式，生活中老師講課的黑板，家中的電視機都是中間件的一種體現方式。

消息中間件能作什麼？

任何中間件必然都是要去解決特定領域的某個問題，消息中間件解決的就是分佈式系統之間消息傳遞的問題。消息傳遞是分佈式系統必然要面對的一個問題。
假設一個電商交易的場景，用戶下單以後調用庫存系統減庫存，而後須要調用物流系統進行發貨，若是交易、庫存、物流是屬於一個系統的，那麼就是接口調用。可是隨着系統的發展，各個模塊愈來愈龐大、業務邏輯愈來愈複雜，必然是要作服務化和業務拆分的。這個時候就須要考慮這些系統之間如何交互，第一反應就是RPC（Remote Procedure Call）。系統繼續發展，可能一筆交易後續須要調用幾十個接口來執行業務，好比還有風控系統、短信服務等等。這個時候就須要消息中間件登場來解決問題了。

筆者認爲，RPC和消息中間件的場景的差別很大程度上在於就是「依賴」和「量」。好比短信通知服務並非事交易環節必須的，並不影響下單流程，不是強依賴，因此交易系統不該該依賴短信服務。好比一些數據分析程序可能須要在拿到一天的總銷售量，這個就只須要銷售中心提供接口在須要時調用便可。
消息中間件出現之後對於交易場景多是調用庫存中心等強依賴系統執行業務，以後發佈一條消息（這條消息存儲於消息中間件中）。像是短信通知服務、數據統計服務等等都是依賴於消息中間件去消費這條消息來完成本身的業務邏輯。

從以上的場景能夠看出消息中間件其實就是對系統進行了解耦，同時帶來了異步化等好處。
簡單歸納一下消息中間件的應用場景大體以下：

• 業務解耦：交易系統不須要知道短信通知服務的存在，只須要發佈消息
• 削峯填谷：好比上游系統的吞吐能力高於下游系統，在流量洪峯時可能會沖垮下游系統，消息中間件能夠在峯值時堆積消息，而在峯值過去後下游系統慢慢消費消息解決流量洪峯的問題
• 事件驅動：系統與系統之間能夠經過消息傳遞的形式驅動業務，以流式的模型處理

分佈式消息中間件圖

一個抽象的對分佈式消息中間件的認知大概是這樣：

• 有一個SDK，提供給業務系統發送、消費消息的接口
• 有一批Server節點用於接受和存儲消息，並在合適的時候發送給下游的系統進行消費

常見消息中間件對比

一、ActiveMQ
ActiveMQ是Apache出品,最流行的,能力強勁的開源消息總線. ActiveMQ是一個徹底支持JMS1.1和J2EE1.4規範的JMS Provider實現,儘管JMS規範出臺已是好久的事情了,可是JMS在當今的J2EE應用中間仍然扮演着特殊的地位.
ActiveMQ特性
（1）多種語言和協議編寫客戶端.語言:Java,C,C++,C#,Ruby,Perl,Python,PHP.
（2）應用協議:OpenWire、Stomp REST，WS Notification，XMPP，AMQP
（3）徹底支持JMS1.1和J2EE1.4規範(持久化,XA消息,事務)
（4）虛擬主題、組合目的、鏡像隊列
二、RabbitMQ
RabbitMQ是一個開源的AMQP實現，服務器端用Erlang語言編寫。用於在分佈式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。
RabbitMQ特性
(1)支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript等
(2)AMQP的完整實現(vhost、Exchange、Binding、Routing Key 等)
(3)事務支持/發佈確認
(4)消息持久化
三、Kafka
Kafka是一種高吞吐量的分佈式發佈訂閱消息系統,是一個分佈式的、分區的、可靠的分佈式日誌存儲服務。它經過一種獨一無二的設計提供了一個消息系統的功能。（不是個嚴格的中間件，主要是用於日誌轉存的）
Kafka特性：
（1）經過O（1） 的磁盤數據結構提供消息的持久化，這種結構對於即便數以TB的消息存儲也可以保持長時間的穩定性能。
（2）高吞吐量：即便是很是普通的硬件Kafka也能夠支持每秒數百萬的消息。
（3）Partition、Consumer Group
消息中間件綜合對比

若是你們想學習如下路線內容，在此我向你們推薦一個架構學習交流羣。交流學習羣號：478030634 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

注：關注做者微信公衆號，瞭解更多分佈式架構、微服務、netty、MySQL、spring、、性能優化、等知識點。公衆號：《Java爛豬皮》