Everything Will Flow：面向 AI 的新一代融合消息流平台 FlowMQ 正式发布
3 月 20 日的 EMQ Tech Day 2026 上，我们正式对外宣布了 EMQ 全新产品 FlowMQ 的发布。
FlowMQ 是 EMQ 从零开始打造的新一代融合消息产品。它在一个系统内提供包括 Subscription（实时推送）、Stream（数据流）和 Queue（队列）在内的多种消息能力，同时原生支持 MQTT、Kafka 和 AMQP 等主流消息协议接入，以及不同协议之间的直接互通。
为什么做 FlowMQ
EMQ 在消息系统领域已经深耕多年，打造了全球广受欢迎的 MQTT Broker——EMQX。但正是在服务大量企业客户的过程中，我们越来越清楚地看到一个结构性问题：每种消息能力都被锁死在特定的协议和系统里。
回顾消息系统的发展历程，每一次技术演进都在解决真实的问题，但也让整个生态变得越来越碎片化。早年 IBM MQ、TIBCO 统治企业消息，价格高昂且厂商锁定严重；JMS 统一了 Java API，却没有定义线协议（wire protocol），无法跨语言互通；AMQP 试图定义开放的消息标准，却因 0.9.1 与 1.0 的不兼容而自身走向分裂；MQTT 为 IoT 低带宽场景深度优化，成为设备连接的事实标准；Kafka 开辟了事件流这个全新品类，把消息从"投递即丢弃"变成了"持久化日志加回放"。
每一个系统和协议都有自己的适用场景，但结果是，在今天的企业内部：
- 设备接入用了 MQTT Broker
- 事件流与日志管道用了 Kafka
- 业务异步与任务分发用了 RabbitMQ
消息能力、协议、系统三者捆绑在一起——每多一种消息需求，企业得就多采购和部署一套对应的系统。
于是桥接程序越来越多，同步链路越来越长，权限和监控在每套系统里各做一遍。团队真正在维护的，早已不是业务本身，而是各种系统之间的错综复杂的关系。
行业不缺第 N 套 Broker，也不缺一个把几种协议粘在一起的中间件——真正缺的是一个从底层重新设计的平台，让消息能力不再被特定协议绑定，能够通过提供的基础消息原语，满足多种业务的消息需求，而不是去组合多套分布式消息系统。
这就是我们希望通过 FlowMQ 实现的目标：用一个平台统一多种消息模型与协议生态，显著降低企业实时基础设施的架构复杂度与运维成本。
FlowMQ：统一内核，无限协议
FlowMQ 的出发点不是「做一个支持多种协议的 Broker」，而是回到一个更根本的问题：企业所需要的消息的核心能力到底有哪些？
尽管各种消息系统层出不穷，但剥开协议和其它复杂的外壳，核心的消息模型始终万变不离其宗。FlowMQ 把它们提炼为三种原生能力——Subscription、Stream 和 Queue——作为平台的统一内核，再向上适配各种消息协议。
- Subscription 负责实时推送，消息到达即刻广播给所有订阅者，适合通知、告警、设备指令下发。
- Stream 负责数据流，支持消息持久化存储和历史回放，适合事件溯源、数据管道、审计日志。
- Queue 负责任务分发，支持竞争消费、ACK 确认和失败重试，适合异步处理和削峰填谷。
这些能力不是从某个协议的模型里改造出来的，而是作为平台自身的原生能力独立存在。需要什么能力，直接用，不需要为此引入一套新系统。
多种协议接入，用熟悉的方式连接。在这些能力之上，FlowMQ 支持 MQTT、Kafka 和 AMQP 协议接入。各协议的现有客户端和 SDK 无需任何改造即可直接连接。协议是进入平台的入口，不是平台的边界。
跨协议直接互通，不再需要复杂的桥接和集成。因为所有消息都在同一个 FlowMQ 内核里流转，跨协议互通就是自然而然的事情。MQTT 设备发布的遥测数据，可以直接进入 Stream 被 Kafka Consumer 消费；Kafka 下发的控制指令，MQTT 订阅者可以实时收到。过去需要专门开发和维护的桥接管道，现在是 FlowMQ 开箱即用的能力。
一套治理，覆盖所有协议和消息模式。认证、权限、配额、监控、审计——过去在多套系统之间重复做的事情，现在只需要在 FlowMQ 里做一遍。不管消息从哪个协议进来、以哪种模式交付，都在同一套治理体系下运行。
以对象存储为基座：大幅降低基础设施成本
传统消息系统依赖本地盘或块存储，随之而来的是一系列运维负担：容量要提前规划，副本要长期维护，扩容伴随着分区再平衡，长保留和多可用区的成本不断累积。
FlowMQ 从第一天起就做了一个不同的选择：把 S3 兼容对象存储（AWS S3、Ceph、MinIO 等）作为平台的核心数据层——不是归档，不是冷存储，而是系统日常运行的一级存储基座。这个选择带来了根本性的变化：
- 秒级弹性伸缩。由于数据全部存储在对象存储中，FlowMQ 的 Broker 节点完全无状态，可以随时增加、减少或替换。扩缩容在秒级完成，没有分区再平衡，没有副本追赶，没有数据迁移。
- 基础设施成本降低可达 10 倍以上。以 AWS 为例，传统消息系统使用 EBS 块存储（$0.08/GB/月），算上 3 副本和约 50% 的利用率，有效成本达到 $0.48/GB；而 S3 标准存储仅 $0.02/GB/月，持久性（11 nines）和跨可用区冗余已内含在价格中，无需额外副本，容量按需付费。仅存储一项，差距就超过 20 倍。再叠加无跨 AZ 复制流量、无容量预留、无状态节点带来的运维简化，整体基础设施成本可实现一个数量级的下降。
以下是在 AWS 上部署运行 Apache Kafka 和 FlowMQ 的基础设施成本对比(1GB/s 消息吞吐场景，3 副本，跨可用区部署)
原生多租户：一套平台服务多条业务线
当一个消息平台要同时服务 IoT 团队、后端团队和数据团队时，一个绕不开的问题是：怎么保证各业务线互不干扰？
FlowMQ 内建了多租户能力。每条业务线拥有独立的资源空间、独立的访问控制、独立的配额，吞吐量、连接数、存储容量各自设限。平台团队统一部署和运维，业务团队按需使用，互不影响。
不需要为每个团队单独部署一套集群，也不需要靠人工约定来维持秩序。一套 FlowMQ，服务整个企业。
应用场景
IoT 与车联网平台
百万设备或智能终端通过 MQTT 上报遥测数据，云端分析系统以 Kafka 协议消费同一份数据做实时处理，历史数据以 Stream 留存在对象存储中供回放与审计。一条数据链路，多种消费方式，无需桥接。
下一代事件流平台
FlowMQ 的 Stream 能力覆盖 Kafka 的核心场景——持久化事件流、顺序消费、历史回放。基于对象存储的底座，带来更低的存储成本、更简单的扩缩容和更少的运维负担。如果你正在评估 Kafka 的替代方案，FlowMQ 值得进入候选列表。
微服务事件总线
不同团队、不同消息需求——有的需要事件广播，有的需要任务队列，有的需要事件溯源。FlowMQ 在一套平台内同时提供这些能力，跨团队的消息流转是平台的默认能力，而不是需要额外建设的工程。
企业统一消息总线
将分散的 MQTT Broker、Kafka 集群、RabbitMQ 实例整合到一套平台。统一的安全策略、监控告警、配额管理和审计日志，大幅降低运维和合规成本。多租户隔离确保各业务线独立运行。
AI Agent 实时数据底座
AI Agent 需要实时订阅设备和业务数据来感知环境、做出决策，也需要将指令和结果投递到下游系统。FlowMQ 让 Agent 直接接入已有的数据流，而不是再搭一套专用管道。
结语：Everything Will Flow
过去几十年，消息系统的演进始终沿着同一条路径：每出现一种新的消息需求，就诞生一种新的协议和一套新的系统。FlowMQ 选择了一条不同的路——回到消息的本质，用少数几种核心原语覆盖多样化的消息需求，让协议回归它本来的角色：接入方式，而非能力边界。
当消息能力不再被协议锁定，当一个内核可以服务多种的消息需求，消息数据就不再需要在多种系统之间辗转腾挪。它可以在一个系统内自由地流动。这就是 FlowMQ 名字的含义，也是我们对消息基础设施未来的判断：Everything Will Flow。
今天的发布是起点。我们会持续拓展 FlowMQ 的能力边界：更多协议、更多场景、覆盖从边缘到云端的完整数据链路。
目前，FlowMQ 已通过首批客户的生产验证。如需了解产品详情或申请 PoC，欢迎直接联系我们或访问：FlowMQ - 融合 MQTT + Kafka 消息流平台