當(dāng)AI Agent遇上消息“煙囪”：要么融合，要么掉隊(duì)！

想象這樣一個場景：
你的IoT設(shè)備用MQTT說話，你的微服務(wù)用Kafka聽令，你的任務(wù)調(diào)度依賴RabbitMQ。它們各司其職，仿佛一個三權(quán)分立的數(shù)字王國。

但問題是，一旦數(shù)據(jù)需要跨越這些系統(tǒng)流動，噩夢就開始了：
設(shè)備上報的數(shù)據(jù)要進(jìn)入分析管道，業(yè)務(wù)告警要觸達(dá)千萬設(shè)備，AI Agent 還要同時感知和決策，以至于這些“語言不通”的系統(tǒng)之間，只能靠一層層脆弱的橋接程序來勉強(qiáng)溝通。

于是，工程團(tuán)隊(duì)的時間不再花在業(yè)務(wù)創(chuàng)新上，而是在為這些“翻譯官”的故障、延遲和運(yùn)維問題疲于奔命。

可以斷言，這不僅是技術(shù)架構(gòu)的煙囪化，更是企業(yè)效率與成本的黑洞。
那么，當(dāng)大模型和AI Agent正在涌入這個復(fù)雜體系時，一個問題變得愈發(fā)迫切：

下一代消息基礎(chǔ)設(shè)施，究竟應(yīng)該是什么樣子？

而這，正是 EMQ 映云科技即將給出的答案。（文末有驚喜哦）

消息系統(tǒng)煙囪化

當(dāng)我們回顧大多數(shù)企業(yè)的消息基礎(chǔ)設(shè)施演進(jìn)歷程，大概率會看到一個熟悉的模式：

• 需要接入 IoT 設(shè)備，增加了 MQTT Broker——因?yàn)?MQTT 是 IoT 領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，輕量、省電、支持海量長連接。

• 需要構(gòu)建事件流與日志管道，增加了 Kafka——因?yàn)?Kafka 的分區(qū)模型和持久化能力是大規(guī)模流處理的最佳選擇。

• 需要做業(yè)務(wù)異步與任務(wù)分發(fā)，增加了 RabbitMQ——因?yàn)?AMQP 協(xié)議的靈活路由和消息確認(rèn)機(jī)制天然適合工作隊(duì)列場景。

這些選擇在做出的時候都是合理的。不同場景、不同時期、不同團(tuán)隊(duì)，基于各自的需求做出了各自最優(yōu)的技術(shù)選型。

問題在于：隨著業(yè)務(wù)規(guī)模增長和系統(tǒng)復(fù)雜度上升，這些「各自最優(yōu)」的選擇疊加在一起，逐漸演變成了一座座技術(shù)煙囪——各團(tuán)隊(duì)自建、各自運(yùn)維、各自監(jiān)控、各自一套權(quán)限體系。

煙囪化帶來的四重痛點(diǎn)

當(dāng)消息系統(tǒng)煙囪化成為既成事實(shí)，一系列深層問題開始浮現(xiàn)。

數(shù)據(jù)孤島，跨系統(tǒng)互通困難

不同消息系統(tǒng)之間難以互通，跨系統(tǒng)的數(shù)據(jù)打通往往依賴復(fù)雜的配置和脆弱的同步管道。

最典型的場景：IoT 設(shè)備通過 MQTT 上報遙測數(shù)據(jù)，數(shù)據(jù)分析團(tuán)隊(duì)需要用 Kafka 消費(fèi)這些數(shù)據(jù)做分析處理。中間怎么辦？寫一個橋接程序，從 MQTT Broker 訂閱消息，轉(zhuǎn)發(fā)到 Kafka Topic。反過來，如果 Kafka 側(cè)產(chǎn)生了告警需要推送到設(shè)備端，又得再建一條反向鏈路。

每一條橋接鏈路都是一個需要開發(fā)、測試、部署、監(jiān)控、維護(hù)的程序。它們不創(chuàng)造業(yè)務(wù)價值，卻往往是很多問題之源，消耗著工程團(tuán)隊(duì)大量的時間和精力。

成本飆升

多套消息系統(tǒng)意味著多套集群、多套存儲、多倍跨可用區(qū)流量。

每套系統(tǒng)都需要獨(dú)立做高可用部署，都需要獨(dú)立的容量預(yù)留。尤其是 Kafka 這樣基于分區(qū)副本的系統(tǒng)，在多可用區(qū)部署場景下，跨 AZ 的數(shù)據(jù)復(fù)制流量本身就是一筆可觀的開支。再加上為應(yīng)對流量尖峰預(yù)留的冗余容量，實(shí)際的資源利用率往往遠(yuǎn)低于理想水平。

三套系統(tǒng)的成本，絕不只是一套系統(tǒng)的三倍——因?yàn)槊吭黾右惶紫到y(tǒng)，還會帶來額外的網(wǎng)絡(luò)互聯(lián)、數(shù)據(jù)同步和運(yùn)維人力成本。

交付速度變慢

當(dāng)一個新業(yè)務(wù)需要使用消息能力時，它面臨的不僅僅是「調(diào)一個 API」這么簡單。

它需要先完成技術(shù)選型（用哪套消息系統(tǒng)？），然后打通網(wǎng)絡(luò)、申請權(quán)限、配置監(jiān)控告警，最后才能開始寫業(yè)務(wù)代碼。如果涉及跨系統(tǒng)數(shù)據(jù)消費(fèi)，還要加上橋接程序的開發(fā)與聯(lián)調(diào)時間。

「發(fā)送和接收消息」這件本應(yīng)簡單的事情，被基礎(chǔ)設(shè)施的復(fù)雜度嚴(yán)重拖慢。

可靠性風(fēng)險增大

系統(tǒng)越多，故障域越多。鏈路越長，排障越難。

橋接程序和同步任務(wù)本身就是脆弱的環(huán)節(jié)——它們通常不像核心消息系統(tǒng)那樣有經(jīng)過詳盡測試的高可用保證，卻承載著關(guān)鍵的數(shù)據(jù)流轉(zhuǎn)。一旦橋接程序出現(xiàn)延遲或故障，上下游系統(tǒng)都會受到影響，而排查問題時要在多套系統(tǒng)之間來回切換，定位根因的成本極高。

行業(yè)趨勢：從「專用系統(tǒng)」到「融合平臺」

消息系統(tǒng)正在經(jīng)歷的變化，并不是孤例。回顧其它基礎(chǔ)設(shè)施領(lǐng)域的演進(jìn)，我們會發(fā)現(xiàn)一個共同的規(guī)律：從專用到融合統(tǒng)一，是基礎(chǔ)設(shè)施成熟化的必然方向。

• 數(shù)據(jù)庫領(lǐng)域：從早期的 OLTP 和 OLAP 嚴(yán)格分離，到 HTAP（混合事務(wù)與分析處理）數(shù)據(jù)庫的興起，一套系統(tǒng)同時承載事務(wù)處理和分析查詢已經(jīng)成為可能。

• 可觀測性領(lǐng)域：從日志系統(tǒng)（ELK）、指標(biāo)系統(tǒng)（Prometheus）、鏈路追蹤（Jaeger）各自獨(dú)立，到統(tǒng)一可觀測性平臺將三者整合，一套平臺覆蓋所有可觀測性需求正在成為主流。

• AI 領(lǐng)域：早期的文本、圖像、語音模型各自獨(dú)立發(fā)展，而如今前沿的基礎(chǔ)模型已經(jīng)走向多模態(tài)融合，一個模型同時具備文本、圖像、視頻、音頻的理解與生成能力。

消息系統(tǒng)也在經(jīng)歷同樣的演進(jìn)：從 MQTT、Kafka、RabbitMQ 等多種專用系統(tǒng)共存，走向一個融合平臺統(tǒng)一承載多種消息范式。

融合消息平臺應(yīng)該長什么樣？

如果我們從第一性原理出發(fā)，重新設(shè)計(jì)一個面向當(dāng)下和未來的消息平臺，它應(yīng)該具備哪些關(guān)鍵特質(zhì)？

它不僅要解決已有的 IoT、微服務(wù)、事件流等需求，還要能夠自然地接納 AI Agent 這類新型參與者。AI Agent 需要實(shí)時訂閱設(shè)備和業(yè)務(wù)數(shù)據(jù)來感知環(huán)境、做出決策，也需要將指令和結(jié)果投遞到設(shè)備和下游系統(tǒng)。如果為此再引入一套新的消息系統(tǒng)，只會讓煙囪化問題雪上加霜。這進(jìn)一步要求消息平臺具備統(tǒng)一的多模型、多協(xié)議能力。

多模消息引擎：一套系統(tǒng)，多種范式

統(tǒng)一平臺的核心前提是在一個系統(tǒng)內(nèi)同時支持多種消息范式，例如：

• Pub/Sub：多訂閱者廣播，實(shí)時分發(fā)，適合實(shí)時通知、事件廣播等場景。

• Stream：事件流與日志管道，支持持久化存儲與回放消費(fèi)，適合數(shù)據(jù)管道、審計(jì)日志、事件溯源。

• Queue：競爭消費(fèi)，支持 ACK、重試與死信隊(duì)列，適合任務(wù)分發(fā)、削峰填谷。

更重要的是，平臺的消息引擎應(yīng)該是可擴(kuò)展的——隨著業(yè)務(wù)場景的演進(jìn)和 AI 等新需求的出現(xiàn)，能夠靈活引入新的消息范式，而不是固定在幾種模型上。

要實(shí)現(xiàn)這種多模型與可擴(kuò)展性，協(xié)議與消息模型必須解耦。用戶可以用自己熟悉的協(xié)議接入（無論是 MQTT、Kafka 還是 AMQP），平臺內(nèi)部按業(yè)務(wù)語義選擇最合適的消息模型。同一套治理能力——權(quán)限、配額、監(jiān)控、審計(jì)——覆蓋所有模式。

原生跨模型/協(xié)議互通

在當(dāng)前的多系統(tǒng)架構(gòu)下，要讓 MQTT 的數(shù)據(jù)流入 Kafka，或者讓 Kafka 的事件推送到 MQTT 設(shè)備，往往需要部署專門的橋接程序或同步管道，配置復(fù)雜、鏈路脆弱。

統(tǒng)一消息平臺應(yīng)該從根本上消除這種割裂：不同協(xié)議接入的消息，天然就能互通。MQTT 設(shè)備發(fā)布的數(shù)據(jù)，Kafka Consumer 可以直接消費(fèi)；Kafka 寫入的告警，MQTT 訂閱者可以實(shí)時接收；AI Agent 可以直接訂閱設(shè)備數(shù)據(jù)流進(jìn)行實(shí)時分析，并將決策結(jié)果推送到業(yè)務(wù)系統(tǒng)——無需橋接程序，無需同步任務(wù)，無需額外配置。

云原生彈性架構(gòu)

傳統(tǒng)消息系統(tǒng)大多采用有狀態(tài)分區(qū)架構(gòu)，擴(kuò)容或節(jié)點(diǎn)故障恢復(fù)時往往需要經(jīng)歷漫長的分區(qū)再平衡（Rebalance），運(yùn)維復(fù)雜度高，故障恢復(fù)不可預(yù)測。

面向云原生時代的統(tǒng)一消息平臺，計(jì)算層與存儲層應(yīng)該徹底分離、獨(dú)立擴(kuò)縮容。計(jì)算節(jié)點(diǎn)應(yīng)該是無狀態(tài)的，可以隨時增減和替換，做到秒級彈性伸縮和快速自愈，不再受限于分區(qū)遷移和數(shù)據(jù)再平衡。

基于對象存儲的低成本持久化

傳統(tǒng)消息系統(tǒng)通常依賴本地磁盤或塊存儲做消息持久化，容量需要提前規(guī)劃，單價較高，長期保留和歷史回放的成本壓力尤為突出。

隨著對象存儲技術(shù)的成熟和成本的持續(xù)下降，消息持久化應(yīng)該轉(zhuǎn)向?qū)ο蟠鎯Αο蟠鎯θ萘堪葱钄U(kuò)展、單價遠(yuǎn)低于塊存儲，天然適合消息數(shù)據(jù)的長期保留與歷史回放，能夠大幅降低存儲成本。

原生多租戶

企業(yè)級消息平臺通常需要服務(wù)多個團(tuán)隊(duì)和業(yè)務(wù)線。多租戶能力應(yīng)該是平臺的內(nèi)建特性，而非事后附加——每個租戶擁有獨(dú)立的資源空間、訪問控制和配額管理。平臺團(tuán)隊(duì)統(tǒng)一治理，業(yè)務(wù)團(tuán)隊(duì)按需自助使用，既保證安全隔離，又降低使用門檻。

隨著 AI Agent 大規(guī)模涌現(xiàn)，未來消息系統(tǒng)的使用者將不僅僅是當(dāng)前的人和應(yīng)用，還有大量自主運(yùn)行的 Agent，這讓多租戶隔離與治理能力變得尤為重要。

融合之后，能帶來什么？

當(dāng)消息基礎(chǔ)設(shè)施從多套技術(shù)煙囪整合為一個統(tǒng)一平臺，企業(yè)將在四個維度獲得顯著收益。

• 更低的 TCO：降本來自三個方面的協(xié)同——彈性架構(gòu)減少容量預(yù)留（架構(gòu)降本）；低成本存儲降低持久化開支（存儲降本）；一套平臺替代多套集群，統(tǒng)一治理（運(yùn)維降本）。

• 更簡單的架構(gòu)：一套平臺覆蓋 Pub/Sub、Queue、Stream 等多種消息需求。團(tuán)隊(duì)用熟悉的協(xié)議接入，跨協(xié)議互通無需膠水代碼和橋接程序。新業(yè)務(wù)對接消息能力的路徑從「選型 - 打通 - 運(yùn)維」縮短為「接入即用」。

• 更強(qiáng)的彈性與可靠性：云原生架構(gòu)帶來秒級擴(kuò)縮容能力，節(jié)點(diǎn)故障快速自愈，故障恢復(fù)路徑更短、更可預(yù)測。

• 打破數(shù)據(jù)孤島：IoT 數(shù)據(jù)可以直接進(jìn)入事件流處理管道，不再需要中間的搬運(yùn)環(huán)節(jié)。業(yè)務(wù)事件可以被分析系統(tǒng)、告警系統(tǒng)、審計(jì)系統(tǒng)直接訂閱消費(fèi)。跨系統(tǒng)集成從「搬運(yùn)數(shù)據(jù)」變?yōu)椤钢苯佑嗛啞埂?/p>

消息基礎(chǔ)設(shè)施的下一個十年

隨著 IoT、微服務(wù)、實(shí)時數(shù)據(jù)處理等場景的爆發(fā)，以及 AI Agent 作為新一類消息參與者的快速崛起，企業(yè)對消息系統(tǒng)的依賴越來越深，場景越來越多樣。而在這個過程中，我們也積累了大量的技術(shù)債——多套系統(tǒng)并存、數(shù)據(jù)孤島林立、運(yùn)維成本居高不下。

好消息是，云原生架構(gòu)的成熟、存儲技術(shù)的演進(jìn)、以及行業(yè)對平臺化治理的共識，讓統(tǒng)一消息平臺從愿景變?yōu)楝F(xiàn)實(shí)。消息基礎(chǔ)設(shè)施正在迎來一次范式躍遷：從「多套工具各司其職」走向「一個平臺統(tǒng)一承載」。

這不僅僅是技術(shù)架構(gòu)的演進(jìn)，更是企業(yè)數(shù)據(jù)流通與智能化能力的質(zhì)變——讓團(tuán)隊(duì)把時間用在業(yè)務(wù)創(chuàng)新上，而不是「打通消息系統(tǒng)」上；讓 AI Agent 能夠直接接入統(tǒng)一的數(shù)據(jù)流，實(shí)時感知、自主決策、即時行動。

3 月 20 日，見證一次關(guān)鍵發(fā)布

如果說過去十年，消息系統(tǒng)解決的是「連接萬物」的問題；那么下一個十年，真正的挑戰(zhàn)是：如何在一個融合的平臺上，讓萬物、應(yīng)用與 AI 協(xié)同流動。

我們在前文討論的多模消息引擎、原生跨協(xié)議互通、云原生彈性架構(gòu)、對象存儲持久化以及多租戶治理，并不是停留在概念層面的架構(gòu)設(shè)想，而是一套已經(jīng)完整落地、面向未來十年的消息平臺能力。

3 月 20 日，在杭州舉辦的 EMQ Tech Day 上，我們將首次對外完整展示這一全新消息平臺的設(shè)計(jì)理念、核心架構(gòu)與關(guān)鍵能力。如果你正在面臨多套消息系統(tǒng)并存的復(fù)雜架構(gòu)，如果你正在為跨協(xié)議數(shù)據(jù)流轉(zhuǎn)和橋接鏈路所困擾，或者你正在思考如何讓 AI 能力更自然地融入實(shí)時數(shù)據(jù)體系，這場活動值得你到場參與。

融合消息平臺的時代，正在開啟。

歡迎報名，掃描下面二維碼，與我們一起，見證消息基礎(chǔ)設(shè)施的下一次躍遷。

完整嘉賓陣容與最新議程：