如果你經(jīng)常看技術(shù)文章應(yīng)該聽(tīng)過(guò)「消息隊(duì)列」、「消息代理」和「消息中間件」這三個(gè)詞，它們有什么區(qū)別和聯(lián)系呢?希望這篇文章能告訴你答案。

[[271087]]

中間件(Middleware)

首先就要說(shuō)什么是中間件?我的理解是：

中間件是幫助應(yīng)用程序與其他應(yīng)用程序、網(wǎng)絡(luò)、硬件、操作系統(tǒng)交互或通信的軟件。

換句更簡(jiǎn)潔的話：「將具體業(yè)務(wù)和底層邏輯解耦的軟件」。其實(shí)符合中間件的軟件范疇非常寬，日常用的Redis、Nginx、Zookeeper、Memcached等等都是「中間件」。所謂的「中間」是相對(duì)于架構(gòu)體系內(nèi)的，它不涉及具體的業(yè)務(wù)邏輯也不涉及底層的硬件邏輯，用于用戶數(shù)據(jù)交換和管理，能夠起到「中介」的作用，這就是中間件。

那么問(wèn)題來(lái)了：為什么需要中間件的幫助(代理)，直接去和對(duì)應(yīng)的應(yīng)用程序、硬件、操作系統(tǒng)等交互/通信不好嘛?

回答問(wèn)題前，我們要明確一點(diǎn)：任何中間件必然是為了解決特定領(lǐng)域的某個(gè)(些)問(wèn)題而出現(xiàn)的。

我舉2個(gè)例子來(lái)幫助大家理解。

1. 數(shù)據(jù)庫(kù)中間件

當(dāng)項(xiàng)目很小的時(shí)候，直接使用編程語(yǔ)言下的數(shù)據(jù)庫(kù)驅(qū)動(dòng)操作數(shù)據(jù)庫(kù)就可以了，有些開發(fā)會(huì)用ORM的方式操作數(shù)據(jù)庫(kù)：這是夠用的。

但隨著業(yè)務(wù)發(fā)展，數(shù)據(jù)量和讀寫QPS越來(lái)越高，主從模式的MySQL實(shí)例壓力越來(lái)越大，單純的對(duì)服務(wù)器硬件升級(jí)已經(jīng)無(wú)法滿足生產(chǎn)環(huán)境的需要。在我司不成文的習(xí)慣是單表不要超過(guò)5千萬(wàn)條記錄，數(shù)據(jù)庫(kù)量大的時(shí)候就設(shè)計(jì)分庫(kù)分表，也就是「分而治之」，把QPS和數(shù)據(jù)量分片限定在一個(gè)范圍內(nèi)。

當(dāng)然還有很多其他相關(guān)的功能，如讀寫分離、路由策略、統(tǒng)計(jì)、管理、鑒權(quán)等等。這些是在業(yè)務(wù)邏輯之上的，不應(yīng)該在業(yè)務(wù)代碼中把這部分堆進(jìn)去，應(yīng)該抽象它們出來(lái)作為一個(gè)獨(dú)立的組件，這就是數(shù)據(jù)庫(kù)中間件。

[[271088]]

現(xiàn)在主流的開源數(shù)據(jù)庫(kù)中間件有Mycat、MySQL-proxy、Atlas等等，不過(guò)現(xiàn)在都不怎么維護(hù)了，另外還有Cetus ，作者是tcpcopy的作者，這個(gè)項(xiàng)目還在不斷維護(hù)，有同學(xué)有興趣的可以試試。當(dāng)然其實(shí)各大公司內(nèi)部都有自己的數(shù)據(jù)庫(kù)中間件產(chǎn)品，更多的貼近公司的業(yè)務(wù)產(chǎn)品和基礎(chǔ)設(shè)施。

2. Web框架中間件

一般Web框架都支持中間件，Web框架中間件的本質(zhì)是插件系統(tǒng)，是一系列的框架鉤子，在收到請(qǐng)求和返回響應(yīng)這個(gè)過(guò)程里面去做一些額外的事情。中間件種類很多，舉例一些：

• 響應(yīng)壓縮
• 記錄日志
• 支持會(huì)話Session
• CSRF保護(hù)
• 驗(yàn)證/身份鑒別
• 訪問(wèn)控制
• 資源使用檢查(如內(nèi)存占用)
• 請(qǐng)求指標(biāo)
• 健康檢查
• 靜態(tài)資源管理 …

這些中間件將業(yè)務(wù)和非業(yè)務(wù)代碼功能進(jìn)行解耦：

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

Web視圖中不需要手寫中間件邏輯，按約定好的用法框架會(huì)在對(duì)應(yīng)的生命周期中按照約定的順序去執(zhí)行這些中間件邏輯

PS：Golang語(yǔ)言中最知名的Web框架Gin支持中間件，而且還官網(wǎng)搞了個(gè)叫g(shù)in-gonic/contrib的項(xiàng)目搜集社區(qū)里面的中間件。

消息隊(duì)列(Message Queue)

消息隊(duì)列就是Message+Queue。其實(shí)消息可以說(shuō)是一個(gè)數(shù)據(jù)傳輸單位，它包含了創(chuàng)建時(shí)間、通道/主題信息、輸入?yún)?shù)等全部數(shù)據(jù);隊(duì)列(Queue)是一種FIFO(先進(jìn)先出)的數(shù)據(jù)結(jié)構(gòu)，編程語(yǔ)言一般都內(nèi)置(內(nèi)存中的)隊(duì)列實(shí)現(xiàn)，可以作為進(jìn)程間通訊(IPC)的方法。使用隊(duì)列最常見(jiàn)的場(chǎng)景就是生產(chǎn)者/消費(fèi)者模式：生產(chǎn)者生產(chǎn)消息放到隊(duì)列中，消費(fèi)者從隊(duì)列里面獲取消息消費(fèi)。

準(zhǔn)確的說(shuō)，消息隊(duì)列(以下簡(jiǎn)稱MQ**是一種能實(shí)現(xiàn)生產(chǎn)者到消費(fèi)者單向通信的通信模型，而一般大家說(shuō)MQ是指實(shí)現(xiàn)了這個(gè)模型的中間件，比如RabbitMQ、RocketMQ、Kafka等。

設(shè)想一個(gè)訂單場(chǎng)景，當(dāng)你付款成功之后要做什么：

• 通知/提醒系統(tǒng)。通知商家有人買了Ta的商品，通知買家你購(gòu)買成功(相當(dāng)于確認(rèn)訂單)。通知/提醒的方式很多，如郵件、短信、App內(nèi)消息等等
• 會(huì)員系統(tǒng)。更新用戶的積分、等級(jí)等
• 日志系統(tǒng)。訂單這么重要的服務(wù)需要有日志可以用于未來(lái)回溯問(wèn)題
• 推薦系統(tǒng)。更新用戶畫像，重新給用戶推薦他可能感興趣的商品 ..

這就出現(xiàn)了一些問(wèn)題：

• 響應(yīng)耗時(shí)。事實(shí)上做的比這要多得多，每一項(xiàng)都需要有開銷，增加響應(yīng)時(shí)間。如果這些邏輯是同步執(zhí)行的，用戶要等多久?這種體驗(yàn)是完全不可以接受的!所以呢，需要一種異步消費(fèi)的機(jī)制
• 過(guò)度耦合。本來(lái)僅僅是一個(gè)訂單系統(tǒng)，結(jié)果上述的那些東西都要堆進(jìn)來(lái)，這就成了一個(gè)巨無(wú)霸應(yīng)用，未來(lái)開發(fā)、維護(hù)都是問(wèn)題
• 錯(cuò)誤丟失。假如這些后續(xù)的行為中某個(gè)(些)服務(wù)正好出現(xiàn)了故障執(zhí)行失敗或者驗(yàn)證超時(shí)，但是付款成功的確認(rèn)是必須完成的，那么需要有個(gè)地方存這些還沒(méi)有被正確消費(fèi)的部分
• 需要組(廣)播。就像上面的訂單場(chǎng)景，付款成功這個(gè)消息被發(fā)送給多個(gè)子系統(tǒng)，相當(dāng)于組播。未來(lái)如果要新增刪減訂閱源，怎么便捷的實(shí)現(xiàn)呢?

當(dāng)然還有其他的問(wèn)題：

• 秒殺場(chǎng)景下并發(fā)可能會(huì)很高的，非常有可能出現(xiàn)出現(xiàn)遠(yuǎn)超現(xiàn)有服務(wù)器處理能力的情況，這就容易把系統(tǒng)搞崩了，如果出現(xiàn)這種問(wèn)題時(shí)把未處理的放進(jìn)消息隊(duì)列，這就達(dá)到了「削峰」和「限流」的作用。
• 某些場(chǎng)景下需要有消息的優(yōu)先級(jí) …

而消息中間件就是解決上述問(wèn)題的，雖然不同的中間件的實(shí)現(xiàn)方案不同，但都具備以下特點(diǎn)：

• 分布式。其實(shí)消息中間件解決的就是分布式系統(tǒng)之間消息傳遞的問(wèn)題，消費(fèi)者可以分布在多臺(tái)服務(wù)器上，一方面降低了由于單點(diǎn)故障引起的消息隊(duì)列阻塞的風(fēng)險(xiǎn)，另外一方面也非常容易橫向擴(kuò)展。
• 持久可靠。消息隊(duì)列一般會(huì)把接收到的消息存儲(chǔ)到本地硬盤上，保證消息不會(huì)在未消息前莫名丟失。
• 高性能和高吞吐量。例如RocketMQ有億級(jí)消息堆積能力，廣泛應(yīng)用在阿里系的各種高并發(fā)場(chǎng)景下;而Kafka在實(shí)時(shí)計(jì)算、日志采集等場(chǎng)景下算是業(yè)界的標(biāo)準(zhǔn)。

可以說(shuō)，消息中間件是現(xiàn)在企業(yè)架構(gòu)中不可或缺的組合部分，用了都說(shuō)好。

消息代理(Message Broker)

消息代理是一種架構(gòu)模式，用于消息驗(yàn)證、變換、路由。雖然不同的消息中間件架構(gòu)和實(shí)現(xiàn)各不相同，但是大部分都實(shí)現(xiàn)了Broker：其實(shí)就是消息中間件服務(wù)器，它是中間件的核心。

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

在一些地方其實(shí)說(shuō)消息代理就是指消息中間件，如Python語(yǔ)言知名的分布式任務(wù)隊(duì)列框架Celery中就這么稱呼的(所謂的「任務(wù)」其實(shí)就是一個(gè)包含了任務(wù)全部數(shù)據(jù)的消息)。