對於分佈式消息中間件,首先要了解兩個基礎的概念,即什麼是分佈式系統,什麼又是中間件。數據庫
分佈式系統服務器
「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》網絡
從上面這個解釋能夠獲得分佈式系統的兩個特色:架構
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.——維基百科併發
中間件被描述爲爲應用程序提供操做系統所提供的服務以外的服務,簡化應用程序的通訊、輸入輸出的開發,使他們專一於本身的業務邏輯。app
從維基百科上對中間件的解釋感受有點繞,其實能夠從「空間」的角度去理解中間件,即中間件是處於「中間層」的組件,是上層的應用程序和底層的服務之間的橋樑(好比DB中間件的上層是應用程序,底層是DB服務),也是應用與應用之間的橋樑(好比分佈式服務組件)。負載均衡
「Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems.」——維基百科異步
維基百科給出的消息中間件的定義是支持在分佈式系統中發送和接受消息的硬件或軟件基礎設施(對咱們這裏討論的範圍來講確定就是軟件了)。分佈式
那麼分佈式消息中間件其實就是指消息中間件自己也是一個分佈式系統。ide
消息中間件能作什麼?
任何中間件必然都是要去解決特定領域的某個問題,消息中間件解決的就是分佈式系統之間消息傳遞的問題。消息傳遞是分佈式系統必然要面對的一個問題。
假設一個電商交易的場景,用戶下單以後調用庫存系統減庫存,而後須要調用物流系統進行發貨,若是交易、庫存、物流是屬於一個系統的,那麼就是接口調用。可是隨着系統的發展,各個模塊愈來愈龐大、業務邏輯愈來愈複雜,必然是要作服務化和業務拆分的。這個時候就須要考慮這些系統之間如何交互,第一反應就是RPC(Remote Procedure Call)。系統繼續發展,可能一筆交易後續須要調用幾十個接口來執行業務,好比還有風控系統、短信服務等等。這個時候就須要消息中間件登場來解決問題了。
筆者認爲,RPC和消息中間件的場景的差別很大程度上在於就是「依賴」和「量」。好比短信通知服務並非事交易環節必須的,並不影響下單流程,不是強依賴,因此交易系統不該該依賴短信服務。好比一些數據分析程序可能須要在拿到一天的總銷售量,這個就只須要銷售中心提供接口在須要時調用便可。
消息中間件出現之後對於交易場景多是調用庫存中心等強依賴系統執行業務,以後發佈一條消息(這條消息存儲於消息中間件中)。像是短信通知服務、數據統計服務等等都是依賴於消息中間件去消費這條消息來完成本身的業務邏輯。
從以上的場景能夠看出消息中間件其實就是對系統進行了解耦,同時帶來了異步化等好處。
簡單歸納一下消息中間件的應用場景大體以下:
分佈式消息中間件長什麼樣?
一個抽象的對分佈式消息中間件的認知大概是這樣:
關於分佈式消息中間件詳細內容:
(阿里雲消息隊列MQ(Message Queue)是企業級互聯網架構的核心產品,服務於整個阿里巴巴集團已超過8年,通過阿里巴巴交易核心鏈路反覆打磨與歷年雙十一嚴苛考驗,是一個真正具有低延遲、高併發、高可用、高可靠,可支撐萬億級數據洪峯的分佈式消息中間件。)
內容介紹:
課時1:MQ 快速入門 02:19
課時2:MQ 介紹 15:02
課時3:MQ 資源報表使用指南 01:00
課時4:MQ 消息查詢 02:16
更多精品課程:
阿里雲大學官網(阿里雲大學 - 官方網站,雲生態下的創新人才工場)