中軟國際哈爾濱ETC：消息隊列消息代理和消息中間件的區別聯繫

如果你經常看技術文章應該聽過「消息隊列」、「消息代理」和「消息中間件」這三個詞，它們有什麼區別和聯繫呢?希望這篇文章能告訴你答案。

中間件(Middleware)

首先就要說什麼是中間件?我的理解是：

中間件是幫助應用程序與其他應用程序、網路、硬體、操作系統交互或通信的軟體。

換句更簡潔的話：「將具體業務和底層邏輯解耦的軟體」。其實符合中間件的軟體範疇非常寬，日常用的Redis、Nginx、Zookeeper、Memcached等等都是「中間件」。所謂的「中間」是相對於架構體系內的，它不涉及具體的業務邏輯也不涉及底層的硬體邏輯，用於用戶數據交換和管理，能夠起到「中介」的作用，這就是中間件。

那麼問題來了：為什麼需要中間件的幫助(代理)，直接去和對應的應用程序、硬體、操作系統等交互/通信不好嘛?

回答問題前，我們要明確一點：任何中間件必然是為了解決特定領域的某個(些)問題而出現的。

我舉2個例子來幫助大家理解。

1. 資料庫中間件

當項目很小的時候，直接使用編程語言下的資料庫驅動操作資料庫就可以了，有些開發會用ORM的方式操作資料庫：這是夠用的。

但隨著業務發展，數據量和讀寫QPS越來越高，主從模式的MySQL實例壓力越來越大，單純的對伺服器硬體升級已經無法滿足生產環境的需要。在我司不成文的習慣是單表不要超過5千萬條記錄，資料庫量大的時候就設計分庫分表，也就是「分而治之」，把QPS和數據量分片限定在一個範圍內。

當然還有很多其他相關的功能，如讀寫分離、路由策略、統計、管理、鑒權等等。這些是在業務邏輯之上的，不應該在業務代碼中把這部分堆進去，應該抽象它們出來作為一個獨立的組件，這就是資料庫中間件。

現在主流的開源資料庫中間件有Mycat、MySQL-proxy、Atlas等等，不過現在都不怎麼維護了，另外還有Cetus ，作者是tcpcopy的作者，這個項目還在不斷維護，有同學有興趣的可以試試。當然其實各大公司內部都有自己的資料庫中間件產品，更多的貼近公司的業務產品和基礎設施。

2. Web框架中間件

一般Web框架都支持中間件，Web框架中間件的本質是插件系統，是一系列的框架鉤子，在收到請求和返迴響應這個過程裡面去做一些額外的事情。中間件種類很多，舉例一些：

· 響應壓縮

· 記錄日誌

· 支持會話Session

· CSRF保護

· 驗證/身份鑒別

· 訪問控制

· 資源使用檢查(如內存佔用)

· 請求指標

· 健康檢查

· 靜態資源管理 …

這些中間件將業務和非業務代碼功能進行解耦：

框架裡面可能內置了一些常用的中間件，也可能只是內置中間件支持。你可以配置使用某個(些)，也能方便的自定義中間件

Web視圖中不需要手寫中間件邏輯，按約定好的用法框架會在對應的生命周期中按照約定的順序去執行這些中間件邏輯

PS：Golang語言中最知名的Web框架Gin支持中間件，而且還官網搞了個叫gin-gonic/contrib的項目搜集社區裡面的中間件。

消息隊列(Message Queue)

消息隊列就是Message Queue。其實消息可以說是一個數據傳輸單位，它包含了創建時間、通道/主題信息、輸入參數等全部數據;隊列(Queue)是一種FIFO(先進先出)的數據結構，編程語言一般都內置(內存中的)隊列實現，可以作為進程間通訊(IPC)的方法。使用隊列最常見的場景就是生產者/消費者模式：生產者生產消息放到隊列中，消費者從隊列裡面獲取消息消費。

準確的說，消息隊列(以下簡稱MQ**是一種能實現生產者到消費者單向通信的通信模型，而一般大家說MQ是指實現了這個模型的中間件，比如RabbitMQ、RocketMQ、Kafka等。

設想一個訂單場景，當你付款成功之後要做什麼：

· 通知/提醒系統。通知商家有人買了Ta的商品，通知買家你購買成功(相當於確認訂單)。通知/提醒的方式很多，如郵件、簡訊、App內消息等等

· 會員系統。更新用戶的積分、等級等

· 日誌系統。訂單這麼重要的服務需要有日誌可以用於未來回溯問題

· 推薦系統。更新用戶畫像，重新給用戶推薦他可能感興趣的商品 ..

這就出現了一些問題：

· 響應耗時。事實上做的比這要多得多，每一項都需要有開銷，增加響應時間。如果這些邏輯是同步執行的，用戶要等多久?這種體驗是完全不可以接受的!所以呢，需要一種非同步消費的機制

· 過度耦合。本來僅僅是一個訂單系統，結果上述的那些東西都要堆進來，這就成了一個巨無霸應用，未來開發、維護都是問題

· 錯誤丟失。假如這些後續的行為中某個(些)服務正好出現了故障執行失敗或者驗證超時，但是付款成功的確認是必須完成的，那麼需要有個地方存這些還沒有被正確消費的部分

· 需要組(廣)播。就像上面的訂單場景，付款成功這個消息被發送給多個子系統，相當於組播。未來如果要新增刪減訂閱源，怎麼便捷的實現呢?

當然還有其他的問題：

· 秒殺場景下並發可能會很高的，非常有可能出現出現遠超現有伺服器處理能力的情況，這就容易把系統搞崩了，如果出現這種問題時把未處理的放進消息隊列，這就達到了「削峰」和「限流」的作用。

· 某些場景下需要有消息的優先順序 …

而消息中間件就是解決上述問題的，雖然不同的中間件的實現方案不同，但都具備以下特點：

· 分散式。其實消息中間件解決的就是分散式系統之間消息傳遞的問題，消費者可以分布在多台伺服器上，一方面降低了由於單點故障引起的消息隊列阻塞的風險，另外一方面也非常容易橫向擴展。

· 持久可靠。消息隊列一般會把接收到的消息存儲到本地硬碟上，保證消息不會在未消息前莫名丟失。

· 高性能和高吞吐量。例如RocketMQ有億級消息堆積能力，廣泛應用在阿里系的各種高並發場景下;而Kafka在實時計算、日誌採集等場景下算是業界的標準。

可以說，消息中間件是現在企業架構中不可或缺的組合部分，用了都說好。

消息代理(Message Broker)

消息代理是一種架構模式，用於消息驗證、變換、路由。雖然不同的消息中間件架構和實現各不相同，但是大部分都實現了Broker：其實就是消息中間件伺服器，它是中間件的核心。

注意:RabbitMQ、Kafka、RocketMQ等都有消息代理，但是注意，不是所有中間件都這麼選，例如ZeroMQ，它用了套接字風格的API。

在一些地方其實說消息代理就是指消息中間件，如Python語言知名的分散式任務隊列框架Celery中就這麼稱呼的(所謂的「任務」其實就是一個包含了任務全部數據的消息)。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！