热点 | Hot
终于！Rocket MQ迎来第五个大版本，深度解读“消息、事件、流”超融合处理平台
Rocket MQ是一个来自阿里巴巴的分布式消息中间件，于2012年开源，并在2017年正式成为Apache顶级项目。
2017年2月20日，Rocket MQ正式发布4.0版本。差不多5年之后，我们终于等来了5.0版本。
Rocket MQ 5.0专注于消息基础架构的云原生化演进，聚焦在消息领域的后处理场景，支持消息的流式处理和轻计算，帮助用户实现消息的就近计算和分析，并将全面拥抱Serverless和EDA。
据阿里云消息产品线负责人林清山介绍，这次发布的版本，因为进行了架构重塑，新增或者修改了超过60%的代码，但是对4.0的所有功能以及整体架构进行了无缝兼容，且没有引入任何外部依赖，保持了Rocket MQ极简架构、极低运维成本的特点。
去Zoo Keeper、存储计算分离：消息系统走向大一统？
Rocket MQ从设计之初就立足于在线交易链路，因此主要应用在大型在线系统的异步化处理。
历经十年发展，目前的大规模落地场景有：电商物流的交易系统、在线教育课程系统、大型游戏信令系统、以及银行交易系统，这些都大量使用了Rocket MQ来做异步解耦和削峰填谷；同时在非在线业务的场景里，大量车联网、电商网站基于Rocket MQ实现Io T边缘数据以及C端用户行为数据采集传输和集成。
开源至今，Rocket MQ的核心架构大约经历了四个重要的演进阶段：
第一代Rocket MQ其实是采用了推模式，数据存储采用关系型数据库。在这种模式下消息具有很低的延迟特性，并且很容易支持分布式事务。在阿里淘宝这种高频交易场景中，具有非常广泛的应用。
第二代Rocket MQ在服务于交易场景基础上开始探索自研存储引擎，这个版本采用了拉模式和自研的专有消息存储，在日志处理方面能够媲美Kafka的吞吐性能。
在前两代初步打磨了自研的存储引擎后，Rocket MQ 3.0的重构前瞻性地去除了Zoo Keeper等组件的外部依赖，并支持了单机海量Topic。而刚好在前不久，我们也报道过消息系统Kafka去除Zoo Keeper依赖。
第四代Rocket MQ在高可靠低延迟方面重点优化，构建了全新的低延迟存储引擎、新增了Raft多副本存储能力、提供了丰富的消息特性。
Rocket MQ架构演进的思考
目前社区开发者对Rocket MQ的诉求来自于三个方面：首先，Rocket MQ如何更方便地与云原生生态整合是开发者最为关心的问题；其次，在流计算场景里，社区对Rocket MQ的吞吐能力提出了更高的要求，企业客户也一直希望就近处理流转在Rock-et MQ系统中的如支付、交易等高价值的业务数据；还有一类则是在企业集成过程中，希望Rocket MQ能提供更多connector帮助用户构建企业数据流转中心。
伴随如今企业全面上云以及云原生的兴起，新一代基础架构必须朝着云原生化演进，Rocket MQ在5.0里面提供了可分可合的存储计算分离架构以顺应这一趋势。
通过可分可合的存储计算分离架构，用户可以同一进程启动存储和计算的功能，也可以将两者分开部署。分开部署后的计算节点可以做到“无状态”，一个接入点可代理所有流量，在云上结合新硬件内核旁路技术，可以降低分离部署带来的性能及延迟问题。而选择“存储计算一体化”架构，同时也能契合“就近计算”的趋势，也就是在最靠近数据的地方做计算。
林清山表示新版本在存储计算分离的架构选择上非常慎重：“首先我们认为在云上多租、多VPC、多种接入方式的场景下是非常有必要的，存储计算分离后能够避免后端存储服务直接暴露给客户端，便于实现流量的管控、隔离、调度、权限管理。”
但是有利必有弊，除了带来延迟的上升、成本的增加以外，存储计算分离也会给线上运维带来巨大挑战。在大多数场景下，用户更希望的还是存储计算一体化的架构，开箱即用、性能高、延迟低、运维轻松，尤其是在大数据场景下，能够极大降低机器及流量成本。其实这个问题本质上还是由消息产品的特性决定的，消息相比于数据库，计算逻辑相对简单，拆分后往往会沦为无计算场景可发挥、存储节点也得不到简化的状态，这个从Kafka的架构演进也可以得到印证。”
“存储计算分离只是适应了部分场景，架构的演进还是要回归到客户的真实场景。”
面向多场景的弹性架构
在4.0版本中，Rocket MQ主要由Name Server、Broker、Producer以及Consumer四部分构成。Producer和Consumer由用户进行分布式部署。Name Server以轻量级的方式提供服务发现和路由功能，每个Name Server存有全量的路由信息，提供对等的读写服务，支持快速扩缩容。Broker负责消息存储，以Topic为纬度支持轻量级的队列，单机可以支撑上万队列规模。
在5.0版本中，对系统中的不同服务进行了解耦，比如Nameserver和Broker，设计为以下架构：
图中借用了Service Mesh关于控制和数据面的划分思想以及x DS的概念来描述各个组件的职责。
•全新轻量级SDK，基于g RPC协议重新打造的一批多语言客户端，采取g RPC的主要考虑其在云原生时代的标准性、兼容性以及多语言传输层代码的生成能力。
•导航服务（Navigation Server），这是个可选组件，通过LB Group暴露给客户端。客户端通过导航服务获取数据面的接入点信息（Endpoint），随后通过计算集群CBroker的LB Group进行消息的收发。通过EDS暴露CBroker的接入点信息的方式比通过DNS解析的负载均衡更加智能且可以更精细实现流量控制等逻辑。
• Name Server，Rocket MQ原有的核心组件，主要提供SBroker的集群发现（CDS），存储单元Topic的路由发现（RDS）等，为运维控制台组件、用户控制台组件、计算集群CBroker提供x DS服务。
• Compute-Broker（CBroker），重构版本后抽象出的无状态计算集群，作为数据流量的入口，提供鉴权与签名、上层计量统计、资源管理、客户端连接管理、消费者管控治理、客户端RPC处理、消息编解码处理、流量控制、多协议支持等。
• Storage-Broker（SBroker），重构后下沉的存储节点，专注于提供极具竞争力的高性能、低延迟的存储服务。
• LB Group，根据用户的需求提供多样化的负载均衡接入能力。
但存储计算一体化在很多场景下依然是最佳选择，因此，Rocket MQ在5.0为存储计算分离架构提供了灵活的选择：可分可合。如上图所示，左边是一个分离部署的形态，右边是合并部署的形态，合并部署时计算节点可以作为存储节点的Side Car，采用网格的思想部署，也可以将计算和存储揉进同一个进程部署。
在云原生架构设计中，我们常听到要让基础设施完全解耦，这意味着可以让用户在任意的基础设施上部署交付。现在公有云、专有云、混合云、多云下的基础设施均不相同，以存储为例，可能有云盘，也有可能是本地盘；以网络为例，可能是经典网络，也有可能是多VPC网络… 这样的环境要求对于基础服务的云原生架构设计是一个非常大的挑战。所以，Rocket MQ 5.0架构的重塑，很重要的改变是在不同的应用场景下都能提供极致的弹性和统一的架构，“我们称之为场景多元化”，Rocket MQ创始人誓嘉表示。
举例来说，使用Rocket MQ可以自由选择私有化多副本部署方式或者利用公共云云盘的方式，后者既能提升性能又能降低硬件成本及运维成本，也带来了更高的弹性能力。在对一致性要求非常高且需要主从自动切换能力的场景，Raft又可以保证数据可靠性、业务可用性。同时，Rocket MQ还支持多元索引，可以基于一份原始数据构建多份索引来满足不同的业务场景，包括消费索引、查询索引、批索引、百万队列索引等，以便在同一套架构支撑着不同行业的各种差异化诉求。
融合“消息、事件、流”于一体
拥抱Flink生态的轻量级流处理平台
目前业界有两个发展态势，一个是不可阻挡的云原生改造趋势，另一个是流计算时代的全面兴起。因此，除提供对云原生的支持外，作为业界首个兼容Flink生态的消息产品，Rocket MQ 5.0这个大版本里面提供了rocketmq-streams实时计算框架，目前已经在Apache社区开源。
作为一套全新的流式处理框架，rocketmq-streams依赖少、部署简单，可任意横向扩展，利用Rocket MQ资源即可完成轻量级的数据处理和计算。除此以外，为了方便开发者让基于Rocket MQ的流式计算更容易，后续还会开源rsql DB，为开发者提供基于SQL的开发体验。
在Streaming领域，与Kafka只是作为Flink的上下游数据不同，Rocket MQ会全面拥抱Flink开源生态。Rocket MQ-flink connector将在近期从社区毕业，相比于Kafka-flink con-nector，Rocket MQ实现了最新的FLIP-27/FLIP-143接口，能够为开发者提供更一致的流批一体实时数据处理体验。
更为重要的是，与其他任何消息产品不同，rsql DB首创性地兼容了Flink/Blink SQL标准以及UDF/UDAF/UDTF，使得两个开源产品的生态可以更好地融合，开发者可以将Flink/Blink已有SQL计算任务迁移到Rocket MQ，在Rocket MQ内部完成轻量级的计算处理，在算力受限或者更大规模的场景下，同样可以将Rocket MQ的实时计算任务迁移到Flink，利用Flink的大数据计算能力满足业务诉求。
另外，Rocket MQ 4.x的设计里，用户的消息分布在Topic内的多个队列上，但这些队列都是和物理节点内的索引文件一一对应。这样的设计虽然能够保证单机范围内万级队列的高效读写，但也导致了运维不灵活的问题，即Rocket MQ的存储物理节点扩缩容时，用户Topic内的队列数量就会产生变化。众所周知，在流式数据处理过程中上层业务一般要求存储队列始终固定，同时还要求在底层节点运维过程中物理节点的变化对上层队列是透明的，只有这样才能保证流式数据处理的顺序性和完整性。
Rocket MQ 5.0将消息队列下沉为物理队列，上层重新抽象了逻辑队列。一个逻辑队列可以包含多个物理队列，各个物理队列都作为逻辑队列的一个片段，以此拼接出真正的流式队列。也因此可以做到更轻量，秒级扩缩，在物理节点发生变化时不涉及到存量数据复制迁移；实现数据存储的灵活调度，配合TTL实现无限存储能力。
Rocket MQ 5.0通过全新设计实现的Streaming计算框架以及对Streaming场景的逻辑队列存储优化，使得Rocket MQ快速具备了完善的流式数据计算能力和兼容Flink的SQL计算能力，所以这个版本绝对算得上是一次里程碑式的发布。
消息系统的未来：事件流
另一方面，“基于云厂商的视角，我们判断在企业全面上云的时代，事件驱动又会重新发挥作用”，林清山表示。
“我们发现在企业数字化转型进入深水区之后，企业系统的业务集成不再仅仅需要一个消息通道。用户的业务集成必然会涉及到复杂异构的Iaa S基础设施打通与连接；对信息的深层次解析和价值挖掘；低代码、弹性高效的完成业务开发与集成。而这些新的诉求都需要在消息通道的基础上重新定义事件标准、异构连接、低代码、无服务器等开发模式。因此可以简单地下一个断言，事件驱动将是消息驱动在业务集成领域的下一个演进阶段。”
基于上述判断，从Rocket MQ 5.0开始，云时代事件驱动的基础设施建设将成为下一阶段Rocket MQ预言演进的重中之重。从5.0开始，Rocket MQ会基于标准、开放的Cloud Events 1.0协议连接海量异构、复杂云环境，并配合Serverless运行时支撑上层事件驱动服务。这一计划当前正在公共云环境进行产品孵化。在阿里云上已经发布的Event Bridge正是这样的一款事件驱动运行时产品，用来承载海量云服务、自定义应用的事件集成和驱动处理。未来在完成初期孵化后，Event Bridge会贡献到开源Rocket MQ，进一步促进开源事件生态的集成。
总结来说，Rocket MQ 5.0的定位是云原生的"消息、事件、流"超融合处理平台，用以帮助用户更容易地构建下一代事件驱动和流处理应用。
未来发展路径路径
阿里的数据统计表明，Rocket MQ目前全球Contributors接近500人，并形成了包括内核、批、connect、streaming、多语言客户端、rocketmq-flink、operator、exporter，openschema等一系列兴趣小组。从最近的几个版本来看，越来越多的公司以及开发者参与了进来，阿里以外的公司贡献的代码已经超过60%。
Rocket MQ同时也正在积极联合阿里内部的云原生热点项目maintainer进行云原生生态建设，目前这一块已经取得了较大的进展。Rocket MQ与Kubernetes Operator、Prome-theus、Knative、Envoy、Dapr、Cloud Events等生态项目的整合已经被相关的顶级社区官方收录，可以提供开箱即用的用户体验。
未来的演进核心方向仍将继续围绕消息、事件和流三个核心场景开展：
“首先，消息架构本身必将继续朝着Serverless弹性、强容灾能力、可观测免运维的方向继续推进；其次，面向消息数据的就近处理，这一块将基于Streaming存储和框架为用户提供轻量级的计算能力，以适配Io T、边缘计算的场景诉求；最后，会面向未来的企业集成模式，消息驱动将演进到事件驱动的阶段，为用户提供低代码、无服务器的开发体验。”
除了上述几点以外，Rocket MQ也会有更多面向云原生、流计算的特性发布，社区正在进行如火如荼的开发，比如：轻量级客户端、g RPC协议支持、批量消息的发送存储消费、Open Schema、列读、原生KV支持等。
接下来一段时间，还会发布一些非常重磅且经过大规模云上生产验证的生态项目，比如Event Bridge、Serverless Runtime实现、Dapr/Envoy的集成、完全兼容Flink SQL的计算框架rsql DB、AMQP/MQTT协议支持等，用以帮助Rocket MQ快速构建完整强大的云原生生态。
开源地址：
https://github.com/apache/rocketmq/tree/5.0.0-preview
https://github.com/apache/rocketmq-streams
采访嘉宾简介：
王小瑞：花名誓嘉，阿里云资深技术专家，Apache Rocket MQ创始人、PMC Chair。
林清山：阿里云资深技术专家，阿里云消息产品线负责人。