编辑 | Tina
本文是 “2021 InfoQ 年度技术盘点与展望” 系列文章之一，由 InfoQ 编辑部制作呈现，重点聚焦中间件领域在 2021 年的重要进展、动态，希望能帮助你准确把握 2021 年中间件领域的核心发展脉络，在行业内始终保持足够的技术敏锐度。 “InfoQ 年度技术盘点与展望”是 InfoQ 全年最重要的内容选题之一，将涵盖架构、AI、大数据、大前端、云计算、数据库、中间件、操作系统、开源、编程语言十大领域，后续将聚合延展成专题、迷你书、直播周、合集页面，在 InfoQ 媒体矩阵陆续放出，欢迎大家持续关注。 同时在此特别感谢胡伟琪（白慕）、林清山（隆基）、许文强、翟佳、周子博（按姓名首字母排序）几位大佬对本文的贡献，他们的真知灼见，是本文能与大家见面的关键。
在基础软件领域，中间件与操作系统、数据库并列为三大基础软件。
中间件（Middleware）是处于操作系统和应用程序之间的软件，用来屏蔽底层的技术细节，以自身的复杂性换来了应用程序开发的简单。广义中间件的定义是非常广泛的，比如消息、注册配置中心、网关、数据库访问、集成平台等等，都属于中间件的范畴。
在企业中间件领域，特别值得一提的一件事情是淘宝的技术架构组在 2008 年前后演变成了阿里巴巴中间件事业部。这也意味着“中间件”和“架构”两者关系密切，但中间件团队又比架构团队更为独立，从业务认知程度上相对比较容易被忽略，所以有吐槽说：“中间件是阿里技术的核心，也是系统稳如泰山的保障。但要哪一天中间件这个部门不在了，相信整个公司也没人能发现。”
1 处于变革之中的行业：被云、开源、商业所驱动
以前，全球应用程序基础架构和中间件市场由 IBM 这类企业所领导。近年来，随着云应用基础设施的不断成熟，以及物联网需求不断的增长，进一步推动着中间件市场的增长，来自开源、云提供商和其他挑战者的竞争日益激烈。据相关调查机构的报告预测，目前中间件市场约三分之一的支出来自中小型企业，大型企业作为昔日的市场领导者正在失去他们的份额。
而在这一年，投资机构也显示出对中间件创业公司的极大兴趣（不完全统计）：
- 2021 年 2 月，网关中间件 Apache APISIX 背后的开源商业化公司“支流科技”宣布完成百万美元 Pre-A 轮融资
- 2021 年 5 月，数据库中间件 ShardingSphere 团队成员组建的商业公司“SphereEx”完成数百万美元天使轮融资。
- 同月，数据中间件产品“DataPipeline”宣布完成 B 轮数千万人民币融资。
- 2021 年 6 月，消息系统 Apache Kafka 背后的公司 Confluent 在纳斯达克上市。Confluent 在 2020 年 4 月的最后一轮风险投资中估值为 45 亿美元，一年后在上市首日估值超过 100 亿美元。
- 2021 年 10 月，基于 Apache Pulsar 的初创企业 StreamNative 宣布获得 2300 万美元 A 轮融资。
- 2021 年 11 月，面向 IoT 与 5G 场景消息与流处理的开源基础软件供应商 EMQ 宣布完成 1.5 亿人民币的 B 轮融资。
- 同月，数据编排中间件 Alluxio 宣布完成 5000 万美元 C 轮融资。
随着云服务的发展，开源社区与商业化企业之间关系愈加紧密。一方面，这些企业都是围绕开源软件构建的，以 Confluent 为例，它以 Apache Kafka 作为自己的护城河，而 Kafka 本身是最成功的开源项目之一，拥有庞大的开发者社区，包含来自 200 多家组织的 6000 多名社区成员；另一方面，类似 AWS、阿里云、腾讯云等大型云竞争对手提供与 Kafka 类似的消息托管服务。中间件在各细分领域会逐渐基于开源推进相应标准，开源标准的推进会反推商业产品的出现，同时云服务商会提供越来越多的标准化的中间件产品和服务，但最终受益的还是广大的中间件开发者和使用者。
2 以“消息系统”为例，看中间件发展到了哪一阶段
过去这几年，随着云计算和云原生技术生态的高速发展，中间件技术也在顺应这个大趋势向前演进。
回溯历史：从 80 年代走到今天
以典型的中间件“消息系统”为例来看整体发展历程的话，阿里云消息产品线负责人林清山（隆基）将这 30 年的发展分为了四个阶段：
第一个阶段，2000 年之前，80 年代诞生了第一款消息队列是 The Information Bus，第一次提出发布订阅模式来解决软件之间的通信问题；到了 90 年代，则是国际商业软件巨头的时代，IBM、Oracle、Microsoft 纷纷推出了自己的 MQ，其中最具代表性的是 IBM MQ，价格昂贵，面向高端企业，如大型金融、电信等企业；这类商业 MQ 一般采用高端硬件，软硬件一体机交付，MQ 本身的架构是单机架构。
第二阶段，2000~2007 年，初代开源消息队列崛起，诞生了 JMS、AMQP 两大标准，与之对应的两个实现分别为 ActiveMQ、RabbitMQ，开源极大的促进了消息队列的流行度，降低了使用门槛，逐渐成为了企业级架构的标配。相比于今天而言，这类 MQ 主要还是面向传统企业级应用，面向小流量场景，横向扩展能力比较弱。
第三阶段，2007~2018 年，PC 互联网、移动互联网爆发式发展，由于传统的消息队列无法承受亿级用户的访问流量和海量数据传输，诞生了互联网消息中间件，核心能力是全面采用分布式架构、具备很强的横向扩展能力，开源典型代表有 Kafka、RocketMQ，还有淘宝的 Notify。Kafka 的诞生还将消息中间件从 Messaging 领域延伸到了 Streaming 领域，从分布式应用的异步解耦场景延伸到大数据领域的流存储和流计算场景。
第四阶段，2014~ 至今，IoT、云计算、云原生引领了新的技术趋势。面向 IoT 的场景，消息队列开始从云内服务端应用通信，延伸到边缘机房和物联网终端设备，支持 MQTT 等物联网标准协议也成了各大消息队列的标配。随着云计算的普及，云原生的理念深入人心，各种云原生代表技术层出不穷，包括容器、微服务、Serverless、Service Mesh、事件驱动等。云原生的核心问题是如何重新设计应用，才能充分释放云计算的技术红利，实现业务成功最短路径。
虽然最近这个阶段整体来看就是云原生化，但是阿里云中间件技术负责人胡伟琪（白慕）认为这里面其实包含了两层含义：
- 首先是中间件自身架构和运行时的云原生化。我们知道中件间基本上都是有状态的应用，在整个 IT 架构中承担了非常核心的作用，对于 IO、性能、稳定性的要求都非常高，所以一直以来中间件的容量管理、交付、运维、容灾都是业界的难题，但是随着云原生技术体系的逐渐成熟，现在的中间件都在云原生化，借助云原生技术，首先解决了自身的弹性和韧性问题，其次基于以 Kubernetes 容器的运行底座，解决了中间件的运维、交付问题。
- 其次是开发者使用中间件方式的云原生化。现在的云原生中间件，通常以 BaaS 或 SaaS 的形态出现，帮助使用者屏蔽了底层的运行环境差异和运维复杂度，使用者通过标准化的 API 就可以完成对中间件的调用，这种形态的好处在于让中间件逐渐基础设施化，开发者可以更关注业务的开发，从而提升企业整体的开发和运维效率。
胡伟琪（白慕）表示，基于云原生重构中间件能带来性能上的飞跃。例如在 2021 年 6 月份阿里云发布了开源注册配置中心 Nacos 2.0，结合云原生理念设计的全新 2.0 架构，将性能大幅提升 10 倍，内核进行了分层抽象，实现插件扩展机制，支持 10w 级实例规模，并支持服务网格生态。另一方面，软件的不断迭代，配合新硬件特性，是释放技术红利的最高效路径，在云上基于软硬件协同优化能为消息中间件 MQ 整体带来 20% 的综合性能提升，在网关和 Service Mesh 的部分场景中，对请求的处理效率则能提升高达 260%。
2021 年，被云原生重塑的消息系统
消息系统的大趋势可以用四个词来概括：云原生、连接、轻量化计算、Serverless。
从消息队列本身来看，最原始的诉求都是：大家都想做更多的事情，以满足更多的场景，抓住更多的用户。
腾讯云 Kafka 产品研发负责人许文强认为，消息系统的整体发展趋势可以分为两个方面：技术架构和业务场景丰富度。
从技术架构上来看，“云原生”是消息队列架构的基本发展趋势，在其架构上衍生出多租户、计算存储分离、按量计费、极速无感知扩缩容等功能特性。以 Apache Pulsar 和 Apache RocketMQ 为代表，都是往这个方向走。从整体的角度来说，这块主要满足的还是消息队列本身的基础职能。
消息队列作为数据流转的核心组件，承担的是消息的收发、存储的中转功能，从商业化上来看场景较为单一，无法形成完整生态，而其往外拓展的一个很好的方向就是计算，即数据的连接和处理。
“连接”指的的连接更多的数据源，方便数据的快速接入、流出，从而拓展消息队列在业务架构中的价值。这一点 Apache Kafka 的商业化公司 Confluent 做的就非常好，其官网支持数百种数据源。在数据流转的过程中，无法避免的一步就是数据的处理，就是经常说的数据清洗 (ETL)。Apache Kafka Stream、Apache Pulsar Function、Apache RocketMQ Stream 都想做这个事情：即轻量化计算。在一些简单的场景下，用轻量化计算满足用户的数据处理需求，让用户避免花精力去学习、运维复杂的流式处理系统。
而随着 Serverless 架构的成熟，其在轻量化计算的场景下，具有天然的优势。最核心的优势是：多语言函数化编程、免运维、弹性扩缩容、按量计费。从开发成本和实际运营成本两方面来看，相对流式计算引擎以及上述的消息队列自带的 Stream 组件，都是具有非常大的优势的。
消息系统是现代化应用架构的刚需，市面上有不同厂商主导的各种消息中间件，用户拥有非常多的选择，但这也导致了一些风险：未来部分竞争失利的消息队列会进入停滞期、下线期，用户的应用就会面临迁移大改造和稳定性风险。所以在 InfoQ 的采访中，专家建议大家在满足自身业务需求的情况下，尽可能选择标准接口、协议的方式接入，或者直接使用业界事实标准的消息队列。
从几个热点项目看技术如何落地
Apache Kafka
2021 年 9 月，Apache Kafka 3.0.0 发布，这是一个重要的版本更新，为 Kafka 彻底去掉 ZooKeeper 铺平了道路。
在 InfoQ 的采访中，Confluent 曾表示消息系统必须是要适应云原生的大趋势的，实现计算和存储分离的功能也是 Kafka 下一步的策略。Confluent 在 KIP-405 版本中，实现了一个分层式的存储模式，利用在云架构下多种存储介质的实际情况，将计算层和存储层分离，将“冷数据”和“热数据”分离，使得 Kafka 的分区扩容、缩容、迁移等等操作更加高效和低耗，同时也使 Kafka 可以在理论上长时间保留数据流。
作为 Kafka 产品的提供者之一，腾讯云 Kafka 产品技术过去的一年里主要在云原生、容灾、连接、轻量化计算四个方向上发力，以满足客户对于隔离性、数据接入 / 处理、集群高可用 / 容灾的业务诉求。社区贡献方面主要参与了 Apache Kafka 去 ZooKeeper 特性的部分开发工作。
腾讯云 Kafka 产品研发负责人许文强将去年的具体技术进展概括为以下几点:a. 实现了技术架构上整体上云，推出了独占型专业版实例和共享型 (多租户) 的标准版实例；b. 推出数据连接产品 DataHub，实现多种数据源的接入、处理、流出；c. 联合腾讯云 SCF 实现云上轻量化的数据处理方案；d. 对内部客户推出去 ZooKeeper 架构 Apache Kakfa 3.0 版本的灰度试用。
在适配云原生方面，腾讯云 Kafka 主要实现了以下几个特性：Kafka 多租户的实现、集群自动负载调度、数据的分层存储、多网络环境的适配。整体来讲，各款消息队列的云原生路径上都是比较相似的，首先是架构上云、Kubernetes 化、Serverless 化，主要解决弹性、隔离、低成本等几方面问题。
消息队列本质上是一款存储型产品，适应云原生首先需要解决的就是隔离性和弹性扩缩容。以 Kafka 举例，因为其架构的限制，扩缩容都需要触发 Rebalance，扩缩容速度会受到原始的节点负载、数据堆积等的影响，导致扩缩容无法利用到 Kubenetes 的弹性。另外在计算和连接层面，大家都推出了 Stream、Connector 等功能，以满足连接、计算等场景。
在未来演进方向上，腾讯云 Kafka 将继续集中在五个方向：跨云 / 混合云容灾、数据连接、轻量化数据处理、去 ZooKeeper 架构的 Apache Kafka 的现网运营、云原生架构的完善。从生态的角度，准备在跨云、混合云实现打通，实现跨云 / 跨地域的数据容灾。并在多云和混合云实现数据的无障碍流转，满足汽车、快递等行业的数据安全性和云的便捷性的双向融合需求。
当数据进入 Kafka 后，数据的处理和计算目前主要依赖于开源组件 (如 Flume、LogStash) 和流式引擎 (Flink、Spark)，有一定的学习和运维成本。所以准备提供基于 Serverless 架构实现数据的简单处理和计算，在二八法则的原则下，满足一部分客户的数据处理计算的业务场景。
另外去掉 ZooKeeper 的 Kafka 在集群规模和运维成本上降的非常低，在边缘计算、IoT、私有云的场景下有非常大的应用场景，但是整体还没经过现网大规模客户验证，稳定性有待加强，未来希望能够推动这方面的完善。
许文强认为，消息队列作为一个架构中核心的基础组件，在基础架构、金融、边缘计算、IoT 等场景都是必不可少的，未来发展空间很大。但如果从理论层面上看，消息队列并没有看到特别需要解决的问题。消息队列的问题主要在工程层面，如果希望打造一款低成本、高 SLA、易用、特性丰富、能满足所有场景的消息队列，还有非常长的路要走。每一个点，每一行代码、每一个功能特性等都需要投入大量人力物力仔细打磨并得以大规模验证。
Apache RocketMQ
在 2021 年里，RocketMQ 发布了 5.0 版本。RocketMQ 在这一年里的主要演进是往一体化架构和云原生架构发展。
随着数字化转型的深入，客户的业务往往同时涉及交叉场景，比如来自物联网设备的消息、或者微服务系统产生的业务消息要进行实时计算，如果是引入多套系统，会带来额外的机器、运维、学习等成本。在过去“分”往往是技术实现的妥协，而现在“合”才是用户的真正需求。
RocketMQ 5.0 基于统一 Commitlog 扩展多元化索引，包括时间索引、百万队列索引、事务索引、KV 索引、批量索引、逻辑队列等技术。在场景上同时支撑了 RabbitMQ、Kafka、MQTT、边缘轻量计算等产品能力，实现了“消息、事件、流”，“云边端”一体化架构。
阿里云以 RocketMQ 作为统一内核，打造兼容 MQTT、Kafka、RabbitMQ 等协议的一站式消息服务平台。林清山（隆基）认为，云原生架构是指云上原生的架构，云计算是云原生的“源动力”，脱离了云计算谈云原生如同纸上谈兵。RocketMQ 过去几年立足于阿里云，从生产实践的经验中吸取养分，从而完成互联网消息中间件到云原生消息中间件的进化，“实践出来的云原生架构”是 RocketMQ 和其他消息中间件最大的区别。
RocketMQ 是 2011 年诞生于淘宝核心电商系统，一开始是定位于服务集团业务，面向单一超大规模互联网企业设计。原来的架构并不能很好的满足云计算的场景，有不少的痛点，比如重型 SDK，客户端逻辑复杂、多语言 sdk 开发成本高、商业特性迭代慢；弹性能力差，计算存储耦合、客户端和物理队列数耦合、队列数无法扩展到百万级、千万级；而其他主流的开源消息项目也同样未进行云原生架构的转型，比如 RabbitMQ 单队列能力无法横向扩展、Kafka 弹性扩容会面临大量的数据拷贝均衡等，都不适用于在公共云为大规模客户提供弹性服务。
为此，在云原生适配上，RocketMQ 5.0 面向云计算的场景进行重新设计，期望从架构层面解决根本性问题，对客户端、Broker 到存储引擎全面升级：
客户端轻量化。RocketMQ 5.0 SDK 把大量逻辑下沉到服务端，代码行数精简三分之二，开发维护多语言 SDK 的成本大幅度降低；轻量的 sdk 更容易被 Service Mesh、Dapr 等云原生代表技术集成。
可分可合的存算分离架构。用户根据不同的场景诉求，既可以同一进程启动存储和计算的功能，也可以将两者分开部署。分开部署后的计算节点可以做到“无状态”，一个接入点可代理所有流量，在云上结合新硬件内核旁路技术，可以降低分离部署带来的性能及延迟问题。而选择“存储计算一体化”架构，则具备“就近计算”的优势，性能更优。在云上多租、多 VPC 复杂网络、多协议接入方式的场景下，采用存储计算分离模式能够避免后端存储服务直接暴露给客户端，便于实现流量的管控、隔离、调度、权限管理、协议转换等。
但是有利必有弊，存算分离也同时带来了链路变长、延迟增大、机器成本上升等问题，运维也没得到简化，除了要运维有状态存储节点外，还要多运维无状态计算节点。其实在大多数简单消息收发场景，数据链路基本上就是写 Log、读 Log，无复杂计算逻辑（计算逻辑和数据库相比太简单），这个时候优选存储计算一体化架构，简单够用、性能高、延迟低。特别是在大数据传输场景下，存算一体能够极大降低机器及流量成本，这个从 Kafka 的架构演进也可以得到印证。总的来说不要为了存算分离而分离，还是要回归客户、业务场景的本质诉求。
弹性存储引擎。面向 IoT 海量设备、云上大规模小客户场景，引入了 LSM 的 KV 索引，实现单机海量队列的能力，队列数量可以无限扩展；利用云存储的能力，实现分级存储，消息存储时长从 3 天提高到月、年级别，存储空间可以无限扩展，同时还分离了冷热数据，冷数据存储成本降低了 80%。
Serverless 化。消息队列本身作为云计算的 PaaS 服务之一，要进一步发挥“解耦”的能力，帮助业务构建现代化应用，这里最关键的一个能力演进是 Eventing 的演进。通过将“消息”升华为“事件”，提供面向标准 CloudEvent 的编排过滤、发布订阅等能力构建更大范围的解耦，包括云服务事件和业务应用的解耦、跨组织 SaaS 业务事件的解耦、遗留应用和现代化应用的解耦等，同时事件驱动也是天然符合云计算 Serverless 函数计算的范式，是应用 Serverless 化演进的催化剂。
云原生对于消息中间件而言，还有另一层含义就是消息队列自身架构的云原生化演进，如何充分发挥云的弹性计算、存储、网络，让自己获得更强的技术指标和 Serverless 弹性能力。
在老架构里面，客户感知物理队列，物理队列绑定固定存储节点，强状态。Broker、客户端、物理队列的扩缩容互相耦合，负载均衡粒度是队列级，对 Serverless 的技术演进很不友好。为了实现极致弹性 Serverless，RocketMQ 5.0 对逻辑资源和物理资源做进一步的解耦。
在 Messaging/ 无序消息的场景，客户指定 Topic 进行消息无序收发，新架构对客户端屏蔽队列概念，只暴露逻辑资源 Topic。负载均衡粒度从队列级到消息级，实现了客户端的无状态化，客户端、服务端弹性伸缩解耦。在 Streaming/ 顺序消息的场景，客户端需要指定 Topic 下的某个队列（也称分区）进行消息顺序收发。在新架构里，对客户端屏蔽物理队列，引入逻辑队列概念，一个逻辑队列通过横向分片和纵向分段，分散在不同的物理存储节点。横向分片解决了高可用问题，同一个逻辑队列的多个分片多点随机可写，基于 Happen before 的原理保序，秒级 Failover，无需主备切换；纵向分段，解决逻辑队列的扩容问题，通过多级队列映射，实现 0 数据迁移的秒级扩容，逻辑资源和物理资源的弹性伸缩解耦。
Apache Pulsar
2021 年，Apache Pulsar 有几个里程碑。
第一个就是在年初 2.7.0 版本添加对事务（transaction）的支持，支持事件流应用程序实现原子操作，同时实现消费、处理、生产消息。
第二个是在 Pulsar 2.8.0 版本中完善事务特性，实现了一个里程碑式功能：Exactly-once（精确一次）语义。随着 Pulsar 2.8.0 的发布，利用事务 API 可以在跨 Topic 的场景下保证消息生产和确认的原子性操作。
第三个里程碑是 StreamNative 开发并开源了 Pulsar Flink Connector。目前，Pulsar Flink Connector 已合并进 Flink 代码仓库，并在 Flink 1.14.0 版本中发布。这次发布为以批流一体的方式处理数据提供了理想的解决方案。
Pulsar 一开始就选择了存储计算分离的架构，本身就带有云原生的优势，并能兼顾消息与流两种场景。同时，Pulsar 也开发了一些企业级特性，比如：
- 支持大集群多租户、支持百万级 Topic；
- 支持分层存储，充分利用如 AWS S3 等云原生存储，降低数据存储成本；
- 支持跨区域数据复制，满足跨云数据多备的需求；
- 在很早版本引入轻量化函数计算框架 Pulsar Functions，类似 AWS Lambda 平台，引入 FaaS/Serverless 理念，可以让数据得到就近处理，价值得到即时挖掘。
为了适应企业在云原生环境下的业务需求，StreamNative 开发了比如 Pulsar Flink Connector 的云原生解决方案，并在开源后捐献给 Apache Flink，为用户提供云原生批流融合的解决方案；开源了 Function Mesh，可以处理多条 Pulsar Function 以完成更复杂的处理任务等。
另外也在努力更加贴近大数据管道场景，和 Flink 社区探讨如何将 Pulsar 应用在批流融合的场景下，充分发挥 Pulsar 存储计算分离的云原生架构优势，并将完善和丰富对各种消息协议解析。StreamNative 还将继续打造 Pulsar 生态，与上下游系统集成，比如数据湖连接器等等。Pulsar 主项目也会有很多技术进展，比如去 ZooKeeper、Watermarking 等等。
EMQ X
EMQ X 是一款物联网消息中间件。EMQ X 团队在 2021 年的 5.0 版本中（目前尚未正式发布）进行了比较大的架构和实现改进。
随着 IoT 设备数量增加，设备产生的数据量持续激增，数据类型也从交易事务型数据发展为稳定持续产生的实时分析型流数据，导致 IT 基础架构需要处理的数据规模从 TB 级一跃到了 PB 甚至 EB 级，这对物联网消息中间件的架构模型和基础能力都产生了非常深远的影响。
首先是数据类型的变化，使得流式计算将在 IoT 领域逐渐成为数据基础设施中的主导计算范式。其次是架构模型将从 Schema on Write 逐渐演变到 Schema on Read，后者可以有效保证海量、高并发且持续的 IoT 数据稳定可靠地写入磁盘，并且能够适应业务需要的快速迭代与变化。此后一段时间内，如何解决 Schema on Read 的分析实效性问题，将是一个重要课题。
此外，设备量与数据量的极速扩张，也使得物联网消息中间件向云原生的转型显得尤为重要，依靠云原生带来的极致弹性、故障自愈、规模复制等优点，能极大地帮助企业提升效能，可以认为云原生将是物联网消息中间件的标准发展趋势。
在 5.0 版本中，EMQ X 研发团队设计并实现了异步 Mnesia 数据库复制项目 Mria，该扩展项目在提供集群最终一致性保障的同时，极大提升大规模集群的写入性能，并且大幅度增强集群的自动伸缩性能，这也为 EMQ X 未来支持数十上百节点的超大规模集群提供了底层支撑。
此外，EMQ X 实现了分布式的配置管理，无需类似 ZooKeeper 这种集中式的配置管理工具，它以异步的方式复制配置更改，并且提供了可靠的回滚或故障处理机制，以确保最终集群中的所有节点都安全可靠地应用相同的配置。轻量化计算方面，EMQ X 规则引擎中的 SQL 查询语句允许用户以低代码方式完成实时数据处理。
在适配云原生方面，还提供了 EMQ X Kubernetes Operator 来帮助用户在 Kubernetes 的环境上快速创建、配置和管理 EMQ X Enterprise 集群， 它可以大大简化部署和管理 EMQ X 集群的流程。此外还支持 Terraform 工具，允许用户将 EMQ X 集群部署在各大公有云的基础设施上。在应用层面，EMQ 也做了很多工作，例如 Zone 的概念，后续将持续改进，提供集群内实现多租户的方案。
随着云平台技术的成熟和完善，未来消息系统的部署和运维可能会越来越相似，但是各消息系统适用的应用场景专注度划分会愈加明显。EMQ X 将会持续专注在 IoT 场景，提供多协议、大并发的接入能力，低延时高吞吐的处理能力，以及持续完善与其他数据库以及消息系统的对接能力。
EMQ 认为面向物联网架构的数据基础设施应当具有以下功能特点：持续稳定地支撑海量超高并发连接、提供全链路端到端双向多 QoS 支持、支持超低延时的有状态流式处理和分析、支持数据流虚拟化与 Schema 多租户，以上也是 EMQ X 目前的发展方向。
3 展望中间件的未来
随着 IoT、5G 网络的持续发展，数据量增速达到 28%，预计到 2025 年物联网设备将达到 400 亿台，进入万物互联的时代。物联网时代的数据存储量和计算量会爆发式增长，导致一个重要的趋势是边缘计算，Gartner 预计到 2025 年，75% 的数据将在传统数据中心或云环境之外进行处理。
在分布式云和无边界计算的大趋势下，中间件也在加速向不同的环境输出，比如不同的 CPU 架构平台，过去中间件主要运行于 x86 架构上，但是现在 ARM 架构的快速发展，现在大量中间件已经可以支持运行 ARM 架构之上。中间件也需要开始适用于不同的计算场所，比如边缘计算，尤其在更细分的现场和区域边缘领域。
因此，对于未来发展，胡伟琪（白慕）认为中间件需要不断推陈出新：
新场景：随着越来越多样化的计算负载和数据被搬到云上，尤其是最近发展迅速的大数据、流计算、AI 等新场景，势必会对中间件提出新的要求；
新边界：据 Gartner 预测，到 2025 年，将有 50% 的企业使用分布式云。在此背景下，多云、混合云、云边一体化应用交付将成为核心诉求，一方面中间件需要具备自身在分布式云场景下的交付部署的能力，另一方面，中间件需要解决分布式云场景下业务连续性保障和数据流转通畅的问题；
新形态：Serverless 将成为下一代云计算的主流形态，在这样的趋势下，中间件也将会由现在的 BaaS 和 SaaS 形态，逐渐向 Serverless 形态演进。
新场景、新边界、新形态，也意味着新的机遇。如前所述，在大数据、云计算和物联网时代之前，IBM 和甲骨文是中间件市场的主导者，而现在，这些快速发展的初创公司正在用新技术构建能处理这些新场景下的中间件。创立于 2014 年但价值已超百亿的 Confluent 就是一个很好的例子，而云原生领域里充满了这样的机遇。
采访嘉宾介绍（按姓名首字母排序）：
胡伟琪（花名：白慕），阿里云资深技术专家，中间件技术负责人，在阿里巴巴先后负责过电商资源调度系统、资源弹性伸缩系统、中间件容器项目、边缘容器服务等。
林清山（花名：隆基），阿里云资深技术专家，阿里云消息产品线负责人。国际消息领域专家，致力于消息、实时计算、事件驱动等方向的研究与探索，推进 RocketMQ 云原生架构、超融合架构的演进。
许文强 (loboxu)，腾讯云 Kafka 产品研发负责人，腾讯高级工程师，Apache Kafka Contributor。
翟佳，Apache Pulsar PMC 成员与 Committer，StreamNative 联合创始人。在此之前任职于 EMC，主要从事实时计算和分布式存储系统的相关开发，在开源项目 Apache BookKeeper、Apache Pulsar 等项目中持续贡献代码，目前是 Pulsar 和 BookKeeper 开源项目 PMC 成员。
周子博，EMQ 映云科技 EMQ X Broker 产品研发负责人，多年从事物联网和消息中间件领域的研发，在高吞吐、高可用的分布式架构系统领域有丰富的经验。
如果你对中间件的发展有其他观察和看法，欢迎在文末留言，或加入 InfoQ 写作平台话题讨论:https://xie.infoq.cn/article/2b890228e7b642b4026a5a261。
