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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

成本飆升

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

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

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

交付速度變慢

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

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

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

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

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

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

行業(yè)趨勢(shì)：從「專(zhuān)用系統(tǒng)」到「融合平臺(tái)」

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

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

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

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

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

融合消息平臺(tái)應(yīng)該長(zhǎng)什么樣？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基于對(duì)象存儲(chǔ)的低成本持久化

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

隨著對(duì)象存儲(chǔ)技術(shù)的成熟和成本的持續(xù)下降，消息持久化應(yīng)該轉(zhuǎn)向?qū)ο蟠鎯?chǔ)。對(duì)象存儲(chǔ)容量按需擴(kuò)展、單價(jià)遠(yuǎn)低于塊存儲(chǔ)，天然適合消息數(shù)據(jù)的長(zhǎng)期保留與歷史回放，能夠大幅降低存儲(chǔ)成本。

原生多租戶(hù)

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

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

融合之后，能帶來(lái)什么？

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

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

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

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

• 打破數(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è)施的下一個(gè)十年

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

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

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

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

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

我們?cè)谇拔挠懻摰亩嗄Ｏ⒁?、原生跨協(xié)議互通、云原生彈性架構(gòu)、對(duì)象存儲(chǔ)持久化以及多租戶(hù)治理，并不是停留在概念層面的架構(gòu)設(shè)想，而是一套已經(jīng)完整落地、面向未來(lái)十年的消息平臺(tái)能力。

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

融合消息平臺(tái)的時(shí)代，正在開(kāi)啟。

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

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