分佈式消息中間件
“Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems.”——維基百科
維基百科給出的消息中間件的定義是支持在分佈式系統中發送和接受消息的硬件或軟件基礎設施（對我們這裡討論的範圍來說肯定就是軟件了）。
那麼分佈式消息中間件其實就是指消息中間件本身也是一個分佈式系統。
消息中間件能做什麼？
任何中間件必然都是要去解決特定領域的某個問題，消息中間件解決的就是分佈式系統之間消息傳遞的問題。消息傳遞是分佈式系統必然要面對的一個問題。
假設一個電商交易的場景，用戶下單之後調用庫存系統減庫存，然後需要調用物流系統進行發貨，如果交易、庫存、物流是屬於一個系統的，那麼就是接口調用。但是隨著系統的發展，各個模塊越來越龐大、業務邏輯越來越複雜，必然是要做服務化和業務拆分的。這個時候就需要考慮這些系統之間如何交互，第一反應就是RPC（Remote Procedure Call）。系統繼續發展，可能一筆交易後續需要調用幾十個接口來執行業務，比如還有風控系統、短信服務等等。這個時候就需要消息中間件登場來解決問題了。
筆者認為，RPC和消息中間件的場景的差異很大程度上在於就是“依賴”和“量”。比如短信通知服務並不是事交易環節必須的，並不影響下單流程，不是強依賴，所以交易系統不應該依賴短信服務。比如一些數據分析程序可能需要在拿到一天的總銷售量，這個就只需要銷售中心提供接口在需要時調用即可。
消息中間件出現以後對於交易場景可能是調用庫存中心等強依賴系統執行業務，之後發佈一條消息（這條消息存儲於消息中間件中）。像是短信通知服務、數據統計服務等等都是依賴於消息中間件去消費這條消息來完成自己的業務邏輯。
從以上的場景可以看出消息中間件其實就是對系統進行了解耦，同時帶來了異步化等好處。
簡單概括一下消息中間件的應用場景大致如下：
· 業務解耦：交易系統不需要知道短信通知服務的存在，只需要發佈消息
· 削峰填谷：比如上游系統的吞吐能力高於下游系統，在流量洪峰時可能會沖垮下游系統，消息中間件可以在峰值時堆積消息，而在峰值過去後下游系統慢慢消費消息解決流量洪峰的問題
· 事件驅動：系統與系統之間可以通過消息傳遞的形式驅動業務，以流式的模型處理
閱讀更多 IT碼將 的文章
