引言：在分布式系统调用场景中存在这样一个通用问题，即在执行一个核心业务逻辑的同时，还需要调用多个下游做业务处理，而且要求多个下游业务和当前核心业务必须同时成功或者同时失败，进而避免部分成功和失败的不一致情况出现。简单来说，消息队列中的“事务”，主要解决的是消息生产者和消费者的数据一致性问题。本篇文章通过拆解 RocketMQ 事务消息的使用场景、基本原理、实现细节和实战使用，帮助大家更好的理解和使用 RocketMQ 的事务消息。 点击下方链接，查看视频讲解： 场景：为什么需要事务消息 以电商交易场景为例，用户支付订单这一核心操作的同时会涉及到下游物流发货、积分变更、购物车状态清空等多个子系统的变更。当前业务的处理分支包括： 主分支订单系统状态更新：由未支付变更为支付成功； 物流系统状态新增：新增待发货物流记录，创建订单物流记录； 积分系统状态变更：变更用户积分，更新用户积分表； 购物车系统状态变更：清空购物车，更新用户购物车记录。  分布式系统调用的特点是：一个核心业务逻辑的执行，同时需要调用多个下游业务进行处理。因此，如何保证核心业务和多个下游业务的执行结果完全一致，是分布式事务需要解决的主要问题。 传统 XA 事务方案：性能不足 为了保证上述四个分支的执行结果一致性，典型方案是基于XA协议的分布式事务系统来实现。将四个调用分支封装成包含四个独立事务分支的大事务，基于XA分布式事务的方案可以满足业务处理结果的正确性，但最大的缺点是多分支环境下资源锁定范围大，并发度低，随着下游分支的增加，系统性能会越来越差。 基于普通消息方案：一致性保障困难 将上述基于 XA 事务的方案进行简化，将订单系统变更作为本地事务，剩下的系统变更作为普通消息的下游来执行，事务分支简化成普通消息+订单表事务，充分利用消息异步化的能力缩短链路，提高并发度。 该方案中消息下游分支和订单系统变更的主分支很容易出现不一致的现象，例如： 消息发送成功，订单没有执行成功，需要回滚整个事务； 订单执行成功，消息没有发送成功，需要额外补偿才能发现不一致； 消息发送超时未知，此时无法判断需要回滚订单还是提交订单变更。 基于RocketMQ分布式事务消息：支持最终一致性 上述普通消息方案中，普通消息和订单事务无法保证一致的本质原因是普通消息无法像单机数据库事务一样，具备提交、回滚和统一协调的能力。 而基于消息队列 RocketMQ 版实现的分布式事务消息功能，在普通消息基础上，支持二阶段的提交能力。将二阶段提交和本地事务绑定，实现全局提交结果的一致性。 消息队列 RocketMQ 版事务消息的方案，具备高性能、可扩展、业务开发简单的优势。 基本原理 概念介绍 事务消息：RocketMQ 提供类似 XA 或 Open XA 的分布式事务功能，通过 RocketMQ 事务消息能达到分布式事务的最终一致；  半事务消息：暂不能投递的消息，生产者已经成功地将消息发送到了 RocketMQ 服务端，但是 RocketMQ 服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半事务消息；  消息回查：由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，RocketMQ 服务端通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit 或是 Rollback），该询问过程即消息回查。 事务消息生命周期 初始化：半事务消息被生产者构建并完成初始化，待发送到服务端的状态；  事务待提交：半事务消息被发送到服务端，和普通消息不同，并不会直接被服务端持久化，而是会被单独存储到事务存储系统中，等待第二阶段本地事务返回执行结果后再提交。此时消息对下游消费者不可见；  消息回滚：第二阶段如果事务执行结果明确为回滚，服务端会将半事务消息回滚，该事务消息流程终止；  提交待消费：第二阶段如果事务执行结果明确为提交，服务端会将半事务消息重新存储到普通存储系统中，此时消息对下游消费者可见，等待被消费者获取并消费；  消费中：消息被消费者获取，并按照消费者本地的业务逻辑进行处理的过程。此时服务端会等待消费者完成消费并提交消费结果，如果一定时间后没有收到消费者的响应，RocketMQ 会对消息进行重试处理。具体信息，请参见消息重试；  消费提交：消费者完成消费处理，并向服务端提交消费结果，服务端标记当前消息已经被处理（包括消费成功和失败）；RocketMQ 默认支持保留所有消息，此时消息数据并不会立即被删除，只是逻辑标记已消费。消息在保存时间到期或存储空间不足被删除前，消费者仍然可以回溯消息重新消费。  消息删除：当消息存储时长到期或存储空间不足时，RocketMQ 会按照滚动机制清理最早保存的消息数据，将消息从物理文件中删除。 事务消息基本流程 事务消息交互流程如下图所示： 1. 生产者将消息发送至 RocketMQ 服务端；  2. RocketMQ 服务端将消息持久化成功之后，向生产者返回 Ack 确认消息已经发送成功，此时消息被标记为“暂不能投递”，这种状态下的消息即为半事务消息；  3. 生产者开始执行本地事务逻辑；  4. 生产者根据本地事务执行结果向服务端提交二次确认结果（Commit 或是 Rollback），服务端收到确认结果后处理逻辑如下： 二次确认结果为 Commit：服务端将半事务消息标记为可投递，并投递给消费者； 二次确认结果为 Rollback：服务端将回滚事务，不会将半事务消息投递给消费者。  5. 在断网或者是生产者应用重启的特殊情况下，若服务端未收到发送者提交的二次确认结果，或服务端收到的二次确认结果为Unknown未知状态，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查；   6. 生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果；  7. 生产者根据检查到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤 4 对半事务消息进行处理。 实现细节：RocketMQ 事务消息如何实现 根据发送事务消息的基本流程的需要，实现分为三个主要流程：接收处理 Half 消息、Commit 或 Rollback 命令处理、事务消息 check。 处理 Half 消息 发送方第一阶段发送 Half 消息到 Broker 后，Broker 处理 Half 消息。Broker 流程参考下图： 具体流程是首先把消息转换 Topic 为 RMQ_SYS_TRANS_HALF_TOPIC，其余消息内容不变，写入 Half 队列。具体实现参考 SendMessageProcessor 的逻辑处理。 Commit 或 Rollback 命令处理 发送方完成本地事务后，继续发送 Commit 或 Rollback 到 Broker。由于当前事务已经完结，Broker 需要删除原有的 Half 消息，由于 RocketMQ 的 appendOnly 特性，Broker通过 OP 消息实现标记删除。Broker 流程参考下图： Commit。Broker 写入 OP 消息，OP 消息的 body 指定 Commit 消息的 queueOffset，标记之前 Half 消息已被删除；同时，Broker 读取原 Half 消息，把 Topic 还原，重新写入 CommitLog，消费者则可以拉取消费；  Rollback。Broker 同样写入 OP 消息，流程和 Commit 一样。但后续不会读取和还原 Half 消息。这样消费者就不会消费到该消息。  具体实现在 EndTransactionProcessor 中。 事务消息 check 如果发送端事务时间执行过程，发送 UNKNOWN 命令，或者 Broker/发送端重启发布等原因，流程 2 的标记删除的 OP 消息可能会缺失，因此增加了事务消息 check 流程，该流程是在异步线程定期执行（transactionCheckInterval 默认 30s 间隔），针对这些缺失 OP 消息的 Half 消息进行 check 状态。具体参考下图： 事务消息 check 流程扫描当前的 OP 消息队列，读取已经被标记删除的 Half 消息的 queueOffset。如果发现某个 Half 消息没有 OP 消息对应标记，并且已经超时（transactionTimeOut 默认 6 秒），则读取该 Half 消息重新写入 half 队列，并且发送 check 命令到原发送方检查事务状态；如果没有超时，则会等待后读取 OP 消息队列，获取新的 OP 消息。 另外，为了避免发送方的异常导致长期无法确定事务状态，如果某个 Half 消息的 bornTime 超过最大保留时间（transactionCheckMaxTimeInMs 默认 12 小时），则会自动跳过此消息，不再 check。 具体实现参考： TransactionalMessageServiceImplcheck 方法。 实战：使用事务消息 了解了 RocketMQ 事务消息的原理后，我们看下如何使用事务。首先，我们需要创建一个 “事务消息” 类型的 Topic，可以使用控制台或者 CLi 命令创建。 事务消息相比普通消息发送时需要修改以下几点： 发送事务消息前，需要开启事务并关联本地的事务执行。 为保证事务一致性，在构建生产者时，必须设置事务检查器和预绑定事务消息发送的主题列表，客户端内置的事务检查器会对绑定的事务主题做异常状态恢复。  当事务消息 commit 之后，这条消息其实就是一条投递到用户 Topic 的普通消息而已。所以对于消费者来说，和普通消息的消费没有区别。 注意： 1. 避免大量未决事务导致超时：在事务提交阶段异常的情况下发起事务回查，保证事务一致性；但生产者应该尽量避免本地事务返回未知结果；大量的事务检查会导致系统性能受损，容易导致事务处理延迟； 2. 事务消息的 Group ID 不能与其他类型消息的 Group ID 共用:与其他类型的消息不同，事务消息有回查机制，回查时服务端会根据 Group ID 去查询生产者客户端； 3. 事务超时机制：半事务消息被生产者发送服务端后，如果在指定时间内服务端无法确认提交或者回滚状态，则消息默认会被回滚。 

引言 Apache RocketMQ 诞生至今，历经十余年大规模业务稳定性打磨，服务了 100% 阿里集团内部业务以及阿里云数以万计的企业客户。作为金融级可靠的业务消息方案，RocketMQ 从创建之初就一直专注于业务集成领域的异步通信能力构建。 本篇将继续业务消息集成的场景，从使用场景、应用案例、功能原理以及最佳实践等角度介绍 RocketMQ 的定时消息功能。 点击下方链接，查看直播讲解： 概念：什么是定时消息 在业务消息集成场景中，定时消息是，生产者将一条消息发送到消息队列后并不期望这条消息马上会被消费者消费到，而是期望到了指定的时间，消费者才可以消费到。 相似地，延迟消息其实是对于定时消息的另外一种解释，指的是生产者期望消息延迟一定时间，消费者才可以消费到。可以理解为定时到当前时间加上一定的延迟时间。 对比一下定时消息和普通消息的流程。普通消息，可以粗略的分为消息发送，消息存储和消息消费三个过程。当一条消息发送到 Topic 之后，那么这条消息就可以马上处于等待消费者消费的状态了。 而对于定时/延时消息来说，其可以理解为在普通消息的基础上叠加了定时投递到消费者的特性。生产者发送了一条定时消息之后，消息并不会马上进入用户真正的Topic里面，而是会被 RocketMQ 暂存到一个系统 Topic 里面，当到了设定的时间之后，RocketMQ 才会将这条消息投递到真正的 Topic 里面，让消费者可以消费到。 场景：为什么需要使用定时消息 在分布式定时调度触发、任务超时处理等场景，需要实现精准、可靠的定时事件触发。往往这类定时事件触发都会存在以下诉求： 高性能吞吐：需要大量事件触发，不能有性能瓶颈。 高可靠可重试：不能丢失事件触发。 分布式可扩展：定时调度不能是单机系统，需要能够均衡的调度到多个服务负载。  传统的定时调度方案，往往基于数据库的任务表扫描机制来实现。大概的思路就是将需要定时触发的任务放到数据库，然后微服务应用定时触发扫描数据库的操作，实现任务捞取处理。 这类方案虽然可以实现定时调度，但往往存在很多不足之处： 重复扫描：在分布式微服务架构下，每个微服务节点都需要去扫描数据库，带来大量冗余的任务处理，需要做去重处理。 定时间隔不准确：基于定时扫描的机制无法实现任意时间精度的延时调度。 横向扩展性差：为规避重复扫描的问题，数据库扫表的方案里往往会按照服务节点拆分表，但每个数据表只能被单节点处理，这样会产生性能瓶颈。 在这类定时调度类场景中，使用 RocketMQ 的定时消息可以简化定时调度任务的开发逻辑，实现高性能、可扩展、高可靠的定时触发能力。 精度高、开发门槛低：基于消息通知方式不存在定时阶梯间隔。可以轻松实现任意精度事件触发，无需业务去重。 高性能可扩展：传统的数据库扫描方式较为复杂，需要频繁调用接口扫描，容易产生性能瓶颈。消息队列 RocketMQ 版的定时消息具有高并发和水平扩展的能力。 案例：使用定时消息实现金融支付超时需求 利用定时消息可以实现在一定的时间之后才进行某些操作而业务系统不用管理定时的状态。下面介绍一个典型的案例场景：金融支付超时。现在有一个订单系统，希望在用户下单 30 分钟后检查用户的订单状态，如果用户还没有支付，那么就自动取消这笔订单。 基于 RocketMQ 定时消息，我们可以在用户下单之后发送一条定时到 30 分钟之后的定时消息。同时，我们可以使用将订单 ID 设置为 MessageKey。当 30 分钟之后，订单系统收到消息之后，就可以通过订单 ID 检查订单的状态。如果用户超时未支付，那么就自动的将这笔订单关闭。 原理：RocketMQ 定时消息如何实现 固定间隔定时消息 如前文介绍，定时消息的核心是如何在特定的时间把处于系统定时 Topic 里面的消息转移到用户的 Topic 里面去。 Apache RocketMQ 4.x 的版本的定时消息是先将定时消息放到按照 DelayLevel 放到 SCHEDULE_TOPIC_XXXX 这个系统的不同 Queue 里面，然后为每一个 Queue 启动一个定时任务，定时的拉取消息并将到了时间的消息转投到用户的 Topic 里面去。这样虽然实现简单，但也导致只能支持特定 DelayLevel 的定时消息。 当下，支持定时到任意秒级时间的定时消息的实现的 pr 提出到了社区，下面简单的介绍一下其基本的实现原理。 时间轮算法 在介绍具体的实现原理之前，先介绍一下经典的时间轮算法，这是定时消息实现的核心算法。 如上所示，这是一个一圈定时为 7 秒的时间轮，定时的最小精度的为秒。同时，时间轮上面会有一个指向当前时间的指针，其会定时的移向下一个刻度。 现在我们想定时到 1 秒以后，那么就将数据放到 “1” 这个刻度里面，同时如果有多个数据需要定时到同一个时间， 那么会以链表的方式添加到后面。当时间轮转到 “1” 这个刻度之后，就会将其读取并从链表出队。那如果想定到超过时间轮一圈的时间怎么处理呢？例如我们想定时到 14 秒，由于一圈的时间是 7 秒，那么我们将其放在“6”这个刻度里面。当第一次时间轮转到“6” 时，发现当前时间小于期望的时间，那么忽略这条数据。当第二次时间轮转到“6”时，这个时候就会发现已经到了我们期望的 14 秒了。 任意秒级定时消息 在 RocketMQ 中，使用 TimerWheel 对于时间轮进行描述和存储，同时使用一个 AppendOnly 的 TimerLog 记录时间轮上面每一个刻度所对应的所有的消息。 TimerLog 记录了一条定时消息的一些重要的元数据，用于后面定时的时间到了之后，将消息转移到用户的 Topic 里面去。其中几个重要的属性如下： 对于 TimerWheel 来说，可以抽象的认为是一个定长的数组，数组中的每一格代表时间轮上面的一个“刻度”。TimerWheel 的一个“刻度”拥有以下属性。 TimerWheel 和 TimerLog 直接的关系如下图所示： TimerWheel 中的每一格代表着一个时间刻度，同时会有一个 firstPos 指向这个刻度下所有定时消息的首条 TimerLog 记录的地址，一个 lastPos 指向这个刻度下所有定时消息最后一条 TimerLog 的记录的地址。并且，对于所处于同一个刻度的的消息，其 TimerLog 会通过 prevPos 串联成一个链表。 当需要新增一条记录的时候，例如现在我们要新增一个 “14”。那么就将新记录的 prevPos 指向当前的 lastPos，即 “13”，然后修改 lastPos 指向 “14”。这样就将同一个刻度上面的 TimerLog 记录全都串起来了。 有了 TimerWheel 和 TimerLog 之后，我们再来看一下一条定时消息从发送到 RocketMQ 之后是怎么最终投递给用户的。 首先，当发现用户发送的是一个定时消息过后，RocketMQ 实际上会将这条消息发送到一个专门用于处理定时消息的系统 Topic 里面去 然后在 TimerMessageStore 中会有五个 Service 进行分工合作，但整体可以分为两个阶段：入时间轮和出时间轮 对于入时间轮： TimerEnqueueGetService 负责从系统定时 Topic 里面拉取消息放入 enqueuePutQueue 等待 TimerEnqueuePutService 的处理 TimerEnqueuePutService 负责构建 TimerLog 记录，并将其放入时间轮的对应的刻度中  对于出时间轮： TimerDequeueGetService 负责转动时间轮，并取出当前时间刻度的所有 TimerLog 记录放入 dequeueGetQueue TimerDequeueGetMessageService 负责根据 TimerLog 记录，从 CommitLog 中读取消息 TimerDequeuePutMessageService 负责判断队列中的消息是否已经到期，如果已经到期了，那么将其投入用户的 Topic 中，等待消费消费；如果还没有到期，那么重新投入系统定时 Topic，等待重新进入时间轮。  实战：使用定时消息 了解了 RocketMQ 秒级定时消息的原理后，我们看下如何使用定时消息。首先，我们需要创建一个 “定时/延时消息” 类型的 Topic，可以使用控制台或者 CLi 命令创建。 从前面可以看出，对于定时消息来说，是在发送消息的时候 “做文章”。所以，对于生产者，相对于发送普通消息，我们可以在发送的时候设置期望的投递时间。 当定时的时间到了之后，这条消息其实就是一条投递到用户 Topic 的普通消息而已。所以对于消费者来说，和普通消息的消费没有区别。 注意：定时消息的实现逻辑需要先经过定时存储等待触发，定时时间到达后才会被投递给消费者。因此，如果将大量定时消息的定时时间设置为同一时刻，则到达该时刻后会有大量消息同时需要被处理，会造成系统压力过大。所以一般建议尽量不要设置大量相同触发时刻的消息。

引言 CDC（Change Data Capture）指的是监听上游数据变更，并将变更信息同步到下游业务以供进一步处理的一种应用场景。近年来事件驱动架构（EDA）热度逐步上升，日渐成为项目架构设计者的第一选择。EDA 天然契合 CDC 的底层基础架构，其将数据变更作为事件，各个服务通过监听自己感兴趣的事件来完成一些列业务驱动。阿里云 EventBridge 是阿里云推出的一款无服务器事件总线服务，能够帮助用户轻松快捷地搭建基于 EDA 架构的应用。近期，EventBridge 事件流已经支持了基于阿里云 DTS[1]服务的 CDC 能力。本文将从 CDC、CDC 在 EventBridge 上的应用以及若干最佳实践场景等方面，为大家介绍如何利用 EventBridge 轻松构建 CDC 应用。 CDC 概述 基本原理与应用场景 CDC 从源数据库捕获增量的数据以及数据模式变更，以高可靠、低延时的数据传输将这些变更有序地同步到目标数据库、数据湖或者其他数据分析服务。目前业界主流的开源 CDC 工具包括 Debezium[2]、Canal[3] 以及 Maxwell[4]。 图片来源： 目前业界主要有以下几类 CDC 的实现： 1. 基于时间戳或版本号 基于时间戳的方式要求数据库表有一个字段代表更新时间戳，当存在数据插入或更新时，对应时间戳字段就会随之更新。CDC 组件周期性检索更新时间大于上次同步时间的数据记录，即可捕获本周期内数据的变更。基于版本号跟踪和基于时间戳跟踪原理基本一致，要求开发者变更数据时必须更新数据的版本号。 2. 基于快照 基于快照的 CDC 实现在存储层面使用到了数据源 3 份副本，分别是原始数据、先前快照和当前快照。通过对比 2 次快照之间的差异来获取这之间的数据变更内容。 3. 基于触发器 基于触发器的 CDC 实现方式事实上是在源表上建立触发器将对数据的变更操作（INSERT、UPDATE、DELETE）记录存储下来。例如专门建立一张表记录用户的变更操作，随后创建 INSERT、UPDATE、DELETE 三种类型的触发器将用户变更同步到此表。 4. 基于日志 以上三种方式都对源数据库存在一定侵入性，而基于日志的方式则是一种非侵入性的 CDC 方式。数据库利用事务日志实现灾备，例如 MySQL 的 binlog 就记录了用户对数据库的所有变更操作。基于日志的 CDC 通过持续监听事务日志来实时获取数据库的变化情况。 CDC 的应用场景广泛，包括但不限于这些方面：异地机房数据库同步、异构数据库数据同步、微服务解耦、缓存更新与 CQRS 等。 基于阿里云的 CDC 解决方案：DTS 数据传输服务 DTS（Data Transmission Service）是阿里云提供的实时数据流服务，支持关系型数据库（RDBMS）、非关系型的数据库（NoSQL）、数据多维分析（OLAP）等数据源间的数据交互，集数据同步、迁移、订阅、集成、加工于一体。其中，DTS 数据订阅[5]功能可以帮助用户获取自建 MySQL、RDS MySQL、Oracle 等数据库的实时增量数据。 CDC 在EventBrige上的应用 阿里云 EventBridge 提供了事件总线[6]与事件流[7] 2 款不同应用场景的事件路由服务。 事件总线底层拥有事件的持久化能力，可以按照需要将事件路由到多个事件目标中。 事件流适用于端到端的流式数据处理场景，对源端产生的事件实时抽取、转换和分析并加载至目标端，无需创建事件总线，端到端转储效率更高，使用更轻便。 为了更好地支持用户在 CDC 场景下的需求，EventBridge 在事件流源端支持了阿里云 DTS 的数据订阅功能，用户仅需简单配置，即可将数据库变更信息同步到 EventBridge 事件流。 EventBridge 定制了基于 DTS sdk 的 DTS Source Connector。当用户配置事件提供方为 DTS 的事件流时，source connector 会实时地从 DTS 服务端拉取 DTS record 数据。数据拉取到本地后，会进行一定的结构封装，保留 id、operationType、topicPartition、beforeImage、afterImage 等数据，同时增加 streaming event 所需要的一些系统属性。 DTS Event 样例可参考 EventBridge 官方文档 EventBridge Streaming 保证了 DTS 事件的顺序性，但存在事件重复投递的可能性，EventId 在保证了和每条 DTS record 的一一映射关系，用户可依据此字段来对事件做幂等处理。 创建源为 DTS 的 EventBridge 事件流 下面展示如何在 EventBridge 控制台创建源为 DTS 的事件流 前期准备   1. 开通 EventBridge 服务； 2. 创建 DTS 数据订阅任务； 3. 创建用于消费订阅数据的消费组账号信息。 创建事件流   1. 登陆 EventBridge 控制台，点击左侧导航栏，选择“事件流”，在事件流列表页点击“创建事件流”； 2. “基本信息”中“事件流名称”与“描述”按照需要填写即可； 3. 在创建事件流，选择事件提供方时，下拉框选择“数据库 DTS”； 4. 在“数据订阅任务”一栏中选择已创建的 DTS 数据订阅任务。在消费组一栏，选择要使用哪个消费组消费订阅数据，同时填写消费组密码与初始消费时间。 5. 事件流规则与目标按照需要填写，保存启动即可创建以 DTS 数据订阅为事件源的事件流。 注意事项 使用时有以下几点需要注意： 1. EventBridge 使用的是 SUBSCRIBE 消费模式[8]，所以请保证当前 DTS 消费组没有其他客户端实例在运行。如果设置的消费组在之前有运行，则传入的位点失效，会基于此消费组上次消费过的位点继续消费； 2. 创建 DTS 事件源时传入的位点仅在新消费组第一次运行时起效，后续任务重启后会基于上次消费位点继续消费； 3. EventBridge 事件流订阅 OperationType 为 INSERT、DELETE、UPDATE、DDL 类型的 DTS 数据； 4. 使用 DTS  事件源可能会有消息重复，即保证消息不丢，但无法保证仅投递一次，建议用户做好幂等处理； 5.用户如果需要保证顺序消费，则需要将异常容忍策略设置为“NONE”，即不容忍异常。在这种情况下，如果事件流目标端消费消息异常，整个事件流将暂停，直至恢复目标端正常。 最佳实践示例 基于EventBridge 实现 CQRS 在 CQRS（Command Query Responsibility Segregation）模型中，命令模型用于执行写以及更新操作，查询模型用于支持高效的读操作。读操作和写操作使用的数据模型存在一定区别，需要使用一定方式保证数据的同步，基于 EventBridge 事件流的 CDC 可以满足这样的需求。 基于云上服务，用户可以使用如下方式轻松构建基于 EventBridge 的 CQRS： 1. 命令模型操作数据库进行变更，查询模型读取 elasticsearch 获取数据； 2. 开启 DTS 数据订阅任务，捕获 DB 变更内容； 3.配置 EventBridge 事件流，事件提供方为 DTS 数据订阅任务，事件接收方为函数计算 FC； 4. FC 中的服务即为更新 elasticsearch 数据操作。 微服务解耦 CDC 也可以用于微服务解耦。例如下文是一个电商平台的订单处理系统，当有新建的未付款订单产生时，数据库会有一条 INSERT 操作，而当某笔订单状态由“未付款”变为“已付款”时，数据库会有一条 UPDATE 操作。根据订单状态变化的不同，后端会有不同的微服务来对此进行处理。 1. 用户下单/付款，订单系统进行业务处理，将数据变更写入 DB； 2. 新建 DTS 订阅任务捕获 DB 数据变更； 3. 搭建 EventBridge 事件流。事件提供方为 DTS 数据订阅任务，事件接收方为 RocketMQ； 4. 在消费 RocketMQ 数据时，同一个 topic 下启用 3 个 group 代表不同的业务消费逻辑； a. GroupA 将捕获到的 DB 变更用户缓存更新，便于用户查询订单状态； b. GroupB 下游关联财务系统，仅处理新建订单，即处理 DB 操作类型为 INSERT 的事件，丢弃其余类型事件； c. GroupC 仅关心订单状态由“未付款”变为“已付款”的事件，当有符合条件事件到达时，调用下游物流、仓储系统，对订单进行进一步处理。 如果采用接口调用方式，那么用户在下单之后订单系统将分别需要调用缓存更新接口、新建订单接口以及订单付款接口，业务耦合性过高。除此之外，这种模式使得数据消费端不用担心上游订单处理接口返回内容的语义信息，在存储模型不变的情况下，直接从数据层面判断此次数据变更是否需要处理以及需要怎样的处理。同时，消息队列天然的消息堆积能力也可以帮助用户在订单峰值到来时实现业务削峰填谷。 事实上，目前 EventBridge Streaming 支持的消息产品还包括 RabbitMQ、Kafka、MNS 等，在实际操作中用户可以根据自己的需要进行选择。 数据库备份&异构数据库同步 数据库灾备和异构数据库数据同步也是 CDC 重要的应用场景。使用阿里云 EventBridge 亦可以快速搭建此类应用。 1. 新建 DTS 数据订阅任务，捕获用户 MySQL 数据库变更； 2. 搭建 EventBridge 事件流，事件提供方为 DTS 数据订阅任务； 3. 使用 EventBridge 在目的数据库执行指定 sql，实现数据库备份； 4. 数据变更事件投递到函数计算，用户业务根据数据变化内容更新对应异构数据库。 自建 SQL 审计 对于用户有自建 SQL 审计的需求，使用 EventBridge 也可以轻松实现。 1. 新建 DTS 数据订阅任务，捕获数据库变更； 2. 搭建 EventBridge 事件流，事件提供方为 DTS，事件接收方为日志服务 SLS； 3. 用户需要对 SQL 进行审计时，通过查询 SLS 进行。 总结 本文介绍了 CDC 的一些概念、CDC 在 EventBridge 上的应用以及若干最佳实践场景。随着支持产品的不断增加，EventBridge 所承载的生态版图也不断扩大，从消息生态到数据库生态，从日志生态到大数据生态，EventBridge 不断扩大其适用领域，巩固云上事件枢纽的地位，此后也将按照这个方向继续发展，技术做深，生态做广。 _参考链接：_ _[1] DTS：_ _[2] Debezium：_ _[3] Canal：_ _[4] Maxwell：_ _[5] DTS 数据订阅：_ _[6] 事件总线：_ _[7] 事件流：_ _[8] SUBSCRIBE 消费模式：_

周末的晚上，张大胖照例要去 Hello World 咖啡馆，没想到在这里碰到了好几个老伙计。

点击查看科普小视频～ 作为 Gartner 定义的十大战略技术趋势之一，事件驱动架构（EDA）逐渐成为主流技术架构。根据 Gartner 的预估，在新型数字化商业的解决方案中，将有 60% 使用 EDA，在商业组织参与的技术栈中，EDA 有一半的占比。 当下比较成功的企业已然认识到，要想最大限度提升运营效率和客户体验，务必要将业务和技术两方面的举措紧密结合起来。事件或业务形势的变化是时下众多企业关注的焦点，这些变化能够为企业领导者带来切实有用的信息，而架构设计的主旨恰恰是从客户联系人、交易、运营等方面的信息中获取洞见，两者相辅相成。传统技术历来对企业从事件中获取洞见的速度有着诸多限制，比如用于记录、收集和处理此类事件的批处理 ETL（提取、转换、加载）等。基于以上背景，阿里云 EventBridge 应运而生，通过事件的标准化和广泛的事件集成能力，帮助开发者轻松构建松耦合、分布式的事件驱动架构。同时阿里云 EventBridge 即将开源，敬请期待！ 想要了解更多 EventBridge 相关信息，扫描下方二维码加入钉钉群～

引言 EventBridge 作为构建 EDA 架构的基础设施，通过一些核心概念和特性提供了灵活丰富的事件收集、处理和路由的能力。对于不少用户来说，通过控制台里的便捷的引导来使用 EventBridge 应该是最快的上手方式。此外，也有很多用户面临着大量的云产品的管理，使用控制台管理每一个资源的方式变成了沉重的手工操作负担。 为了解决这个问题，现在已经能够通过 OpenAPI、terraform 等方式将 EventBridge 的能力方便快捷的带给用户。本文将重点介绍 EventBridge 和 IaC 的重点概念和特性，然后演示如何应用 IaC 理念自动化部署 EventBridge 来使用这些概念和特性。 EventBridge 概述 事件驱动架构 事件驱动架构是一种松耦合、分布式的驱动架构，收集到某应用产生的事件后实时对事件采取必要的处理，紧接着路由至下游系统，无需等待系统响应。使用事件总线 EventBridge 可以构建各种简单或复杂的事件驱动架构，以标准化的 CloudEvents 1.0 协议连接云产品和应用、应用和应用等。 事件驱动架构体系架构具备以下三个能力： 事件收集：负责收集各种应用发生的事件，如新建订单，退换货订单等其他状态变更； 事件处理：对事件进行脱敏处理，并对事件进行初步的过滤和筛选； 事件路由：分析事件内容并将事件路由分发至下游产品。 事件驱动架构具有以下优势： 降低耦合：降低事件生产者和订阅者的耦合性。事件生产者只需关注事件的发生，无需关注事件如何处理以及被分发给哪些订阅者；任何一个环节出现故障，都不会影响其他业务正常运行； 异步执行：事件驱动架构适用于异步场景，即便是需求高峰期，收集各种来源的事件后保留在事件总线中，然后逐步分发传递事件，不会造成系统拥塞或资源过剩的情况； 可扩展性：事件驱动架构中路由和过滤能力支持划分服务，便于扩展和路由分发； 敏捷性：事件驱动架构支持与各种阿里云产品和应用集成，支持事件路由至任何系统服务，提供各种敏捷高效的部署方案。 使用 EventBridge 构建 EDA 架构 事件总线 EventBridge 是阿里云提供的一款无服务器事件总线服务。EventBridge 提供的几个核心概念，可以满足构建 EDA 架构的需要。 事件总线 EventBridge 支持以下事件源： 阿里云官方事件源 自定义事件源 事件总线 EventBridge 的事件总线包括以下类型： 云服务专用事件总线：一个无需创建且不可修改的内置事件总线，用于接收您的阿里云官方事件源的事件；阿里云官方事件源的事件只能发布到云服务专用总线； 自定义事件总线：需要您自行创建并管理的事件总线，用于接收自定义应用或存量消息数据的事件；自定义应用或存量消息数据的事件只能发布到自定义总线。 在 EventBridge 中，一个事件规则包含以下内容： 事件模式：用于过滤事件并将事件路由到事件目标； 事件目标：包括事件的转换和处理，负责消费事件。 EventBridge 提供了简洁的事件模式匹配语法，同时具备灵活的事件转换能力，后面将会通过演示来展示一些具体的例子。 此外，EventBridge 还提供了一些增强能力，这些能力使得 EDA 架构中流经的事件更加透明，具备了开箱即用的观测和分析能力： 事件追踪：可以查看发布到事件总线 EventBridge 的事件内容和处理轨迹； 事件分析：对发布到事件总线的各种事件进行查询分析处理和可视化图表展示，以便发现事件内在价值。 IaC 简介 在介绍完事件总线 EventBridge 的相关基础内容后，接下来一起了解下 IaC。在 DevOps 的实践中，IaC 是非常重要的部分，通过将基础设施代码化，版本化，便可以轻松的借助版本控制工具来提供 single source of truth、协调多人合作的变更、实施严格的 review、借助一些 CI/CD pipeline 工具（甚至 GitOps）来自动触发部署。软件系统的开发者仅付出很小的努力去描述需求，就可以在几分钟后得到所需的虚拟机、网络等云上的服务，极大的缩短了部署时间，同时还能够保证多个环境的配置一致性，通过减少人为操作也降低了引入错误的概率。 IaC的代码实践中一般有两种方式，命令式和声明式。 命令式：顾名思义，需要明确发出每一个动作的指令，描述的是 How，比如“创建一台 xx 规格的 ECS”。代码需要对每一步动作的顺序仔细编排，处理各种可能的错误，尤其要注意处理好每次变更对已经存在的资源的影响，否则稍有不慎就可能造成服务中断。举例来说，作为开发者可以通过自己熟悉的编程语言调用阿里云的 OpenAPI 来管理资源，因为这些 API 是类似 Create、Describe、Delete 等操作，这就是一种命令式的 IaC 实践。 声明式：意味着开发者仅描述自己的需求终态是什么样子，即描述 What，比如“一台 xx 规格的 ECS”。熟悉 Kubernetes 的同学应该对这个概念很熟悉了。IaC 工具可以通过描述资源之间的依赖关系自动编排顺序，如果有已经存在的资源，则比对期望的状态和实际状态的差异，并根据差异做出更新；如果不存在，需要进行创建。可以看出，声明式对开发者非常友好，极大的降低了开发者的心智负担。 IaC 带来的优势： 降低成本：有效管理资源，并减少为此投入的人力； 提升效率：加快资源交付和软件部署的速度； 风险控制： 减少错误； 提高基础架构一致性； 消除配置偏移 terraform 作为 IaC 领域的佼佼者，提供了强大的自动化管理基础设施的能力。生态丰富，很多云厂商都提供了官方插件，阿里云的大多数产品（包括 EventBridge）都对 terraform 做了很全面的支持，使得跨多云部署基础设施变得极其简单。既然是 IaC，terraform 提供了自己的语言 HCL（hashicorp configuration language），HCL 具有类似 json 的简洁的语法，通过声明式的资源描述，可以让开发者快速上手。 动手实践 准备工作 安装 terraform cli 工具，可以参见 的内容。 创建一个 tf 文件 terraform.tf，内容如下（需要替换<内的值） provider "alicloud" { access_key = "" secret_key = "" region = "" } 案例1：通过钉钉监控云上资源变化 假设一个用户使用了很多云上的资源作为生产环境，需要感知线上资源的变更操作，一个可行的方案是利用 EventBridge 将来自于 ActionTrail 的审计事件投递到用户的钉钉。 首先根据钉钉官方文档创建一个机器人，记下 webhook url 和加签的秘钥，接下来会用到。 创建一个 tf 文件 1_actiontrail2dingding.tf，内容如下（需要替换<内的值） 案例1：通过钉钉监控云上资源变化 目标： 熟悉部署使用EventBridge的default总线 熟悉EventBridge的事件模式匹配 熟悉EventBridge的事件转换配置 声明一个default总线上的规则 resource "alicloud_event_bridge_rule" "audit_notify" { default总线默认存在，所以这里可以直接使用 event_bus_name = "default" rule_name = "audit_notify" description = "demo" 通过后缀匹配的方式过滤来自所有云产品事件源的ActionTrail:ApiCall事件 其他更多模式匹配的介绍可以查阅文档：https://help.aliyun.com/document_detail/181432.html filter_pattern = jsonencode( { "type" : [ { "suffix" : ":ActionTrail:ApiCall" } ] } ) targets { target_id = "testtarget" endpoint = "" type的取值可以查阅文档：https://registry.terraform.io/providers/aliyun/alicloud/latest/docs/resources/event_bridge_ruletype type = "acs.dingtalk" 每个事件目标都有一组对应的param_list，具体可以查阅文档：https://help.aliyun.com/document_detail/185887.html 每一个param的form关系到事件转换的配置，可以查阅文档：https://help.aliyun.com/document_detail/181429.html param_list { resource_key = "URL" form = "CONSTANT" value = "" } param_list { resource_key = "SecretKey" form = "CONSTANT" value = "" } 这里展示了TEMPLATE类型的事件转换描述 value是使用jsonpath引用事件内容的字典，template则是模板内容，EventBridge最终会根据这两者结合事件本身渲染出这个参数的值 param_list { resource_key = "Body" form = "TEMPLATE" value = jsonencode( { "source": "$.source", "type": "$.type" "region": "$.data.acsRegion", "accountId" : "$.data.userIdentity.accountId", "eventName" : "$.data.eventName", } ) template = jsonencode( { "msgtype" : "text", "text" : { "content": "来自 {source} 的 {type} 审计事件：{accountId} 在 {region} 执行了 {eventName} 操作" } } ) } } } 在命令行窗口依次执行命令： 初始化 terraform init 预览变更 terraform plan 应用变更 terraform apply 在云产品控制台进行操作，这里以 KMS 为例 钉钉上收到消息通知 在 EventBridge 控制台查看事件轨迹 案例 2：自定义总线触发 FunctionCompute 假设一个用户的应用会产生一些事件，其中一个链路是通过 FunctionCompute 对这些事件进行弹性的处理。那么就可以通过 EventBridge 的自定义事件源和函数计算事件目标来实现这个方案。 创建一个模拟对事件进行处理的 python 脚本文件 src/index.py，内容如下： coding: utf8 import logging def handler(event, context): logger = logging.getLogger() logger.info('evt: ' + str(event)) return str(event) 创建一个 tf 文件 2_trigger_function.tf，内容如下（需要替换<内的值） 案例2：自定义总线触发FunctionCompute 目标： 熟悉部署使用EventBridge的自定义总线 熟悉"自定义应用"事件源配置 熟悉“FunctionCompute”事件目标配置 由于用户自己产生的事件需要投递到自定义总线，这里声明一个叫demo_event_bus的自定义总线 resource "alicloud_event_bridge_event_bus" "demo_event_bus" { event_bus_name = "demo_event_bus" description = "demo" } 声明一个在demo_event_bus总线上的自定义事件源，用于通过sdk或者控制台向EventBridge投递事件 resource "alicloud_event_bridge_event_source" "demo_event_source" { event_bus_name = alicloud_event_bridge_event_bus.demo_event_bus.event_bus_name event_source_name = "demo_event_source" description = "demo" linked_external_source = false } 声明一个叫fc_service的函数计算服务，publish=true意味着会立即部署上传的函数代码。 resource "alicloud_fc_service" "fc_service" { name = "ebfcservice" description = "demo" publish = true } 将前面准备的python脚本文件打包成zip用于部署到函数计算 data "archive_file" "code" { type = "zip" source_file = "{path.module}/src/index.py" output_path = "{path.module}/code.zip" } 声明一个fc_service服务中的函数，其中filename引用了上面描述的zip包，会将这个代码包上传。 resource "alicloud_fc_function" "fc_function" { service = alicloud_fc_service.fc_service.name name = "ebfcfunction" description = "demo" filename = data.archive_file.code.output_path memory_size = "128" runtime = "python3" handler = "index.handler" } 声明一个在demo_event_bus总线上的规则 resource "alicloud_event_bridge_rule" "demo_rule" { event_bus_name = alicloud_event_bridge_event_bus.demo_event_bus.event_bus_name rule_name = "demo_rule" description = "demo" 通过匹配source过滤来自于前面创建的自定义事件源的事件 filter_pattern = jsonencode( { "source" : ["{alicloud_event_bridge_event_source.demo_event_source.id}"] } ) targets { target_id = "demofctarget" type的取值可以查阅文档：https://registry.terraform.io/providers/aliyun/alicloud/latest/docs/resources/event_bridge_ruletype type = "acs.fc.function" endpoint = "acs:fc:::services/{alicloud_fc_service.fc_service.name}.LATEST/functions/{alicloud_fc_function.fc_function.name}" param_list { resource_key = "serviceName" form = "CONSTANT" value = alicloud_fc_service.fc_service.name } param_list { resource_key = "functionName" form = "CONSTANT" value = alicloud_fc_function.fc_function.name } param_list { resource_key = "Qualifier" form = "CONSTANT" value = "LATEST" } 注意form=ORIGINAL意味着每次投递事件都会将事件的原始内容作为这个参数的值 param_list { resource_key = "Body" form = "ORIGINAL" } } } 在命令行窗口依次执行命令 初始化 terraform init 预览变更 terraform plan 应用变更 terraform apply 在控制台模拟自定义事件源发布事件 在 FunctionCompute 的控制台页面查看函数调用日志 在 EventBridge 控制台查看事件轨迹 _总结_ EventBridge 作为构建 EDA 架构的基础设施，通过一些核心概念和特性提供了灵活丰富的事件收集、处理和路由的能力，并支持通过 OpenAPI、terraform 等方式将这些能力方便快捷的带给用户。本文介绍了 EventBridge 和 IaC 的重点概念和特性，然后演示了如何应用 IaC 理念自动化部署 EventBridge 来使用这些概念和特性。 期待大家可以发掘更多利用 EventBridge 快速搭建 EDA 架构的 idea，并使用 terraform 快捷的将这些 idea 变为现实。 相关链接 [1] 阿里云 terraform 文档 [2] terraform registry 文档 [3] 钉钉官方文档

阿里云消息队列 RocketMQ 5.0 实现了全新升级，实现了从“消息”到“消息、事件、流”的大融合，基于此，MessageDriven、EventDriven、Streaming 这三个词是近期消息领域高频词，但由于概念过于新，很多同学其实是不太理解这里的异同。本文把三个概念重新整理下，梳理出比较明确的概念讲给大家。 背景 首先这三个概念具体翻译如下： MessageDriven：消息驱动的通信； Event Driven：事件驱动的通信； Streaming：流模式。 这三个模式都是类似异步通信的模式，发送消息的服务不会等待消费消息服务响应任何数据，做服务解耦是三个模式共同的特性； 只要是在服务通讯领域内，在选型时还要考虑如下特性： 排序：是否可以保证特定的顺序交付； 事务：生产者或消费者是否可以参与分布式事务； 持久化：数据如何被持久化，以及是否可以重放数据； 订阅过滤：是否拥有根据Tag或其他字段做订阅过滤的能力； At – least once（最少交付一次），Atmostonce（最多交付一次），Exactlyonce （精确交付）。 通用背景介绍完，依次来看看各个模型代表的是什么意思。 消息驱动 MessageDriven 在消息驱动通信中，一般链路就是消息生产者（Producer）向消息消费者（Consumer）发送消息。模型如下： 消息驱动模式下通常会用到中间件，比较常见的中间组件有 RocketMQ，Kafka，RabbitMQ 等。这些中间件的目的是缓存生产者投递的消息直到消费者准备接收这些消息，以此将两端系统解耦。 在消息驱动架构中，消息的格式是基于消费者的需求制定的；消息传递可以是一对一，多对多，一对多或多对一。 消息驱动通讯比较常见的一个例子是商品订单推送，上游组件负责生成订单，下游组件负责接收订单并处理。通过这样的通讯方式上游生成组件其实无需关心整个订单的生命周期，更专注于如何快速生成订单，使单个组件的性能得以提升。 消息驱动模式在服务之间提供了轻的耦合（这部分耦合指代 Producer/Consumer SDK），并可以对生产和消费服务根据诉求进行扩展。 事件驱动 EventDriven 首先要申明一个观点：事件驱动其实是对消息驱动方法的改进，它对消息体大小，消息格式做了较为严格的限制，这层基于消息的限制封装其实就称为事件（Event）。 在事件驱动模式中，生产者发布事件来表示系统变更，任何感兴趣且有权限接入的服务都可以订阅这些事件，并将这些事件作为触发器来启动某些逻辑/存储/任务。 事件驱动的模式可以是一对一，多对一，一对多或多对多。通常情况下一般是多个目标根据过滤条件执行不同的事件。 在事件驱动架构中，事件的格式是由生产者根据事件标准协议制定的；由于更规范限制和封装，事件的生产者完全不需要关心有哪些系统正在消费它生成的事件。 事件不是命令，事件不会告诉消费者如何处理信息，他们的作用只是告诉消费者此时此刻有个事件发生了；事件是一份不可变的数据，重要的数据，它与消息的数据价值相同；通常情况下当某个事件发生并执行时，往往伴随着另一个事件的产生。 事件驱动提供了服务间的最小耦合，并允许生产服务和消费服务根据需求进行扩展；事件驱动可以在不影响现有服务的情况下添加各类新增组件。 事件驱动也可以举一个非常贴切的例子，我们以“客户购买完一款商品”为一个事件，举证在事件场景的应用： CRM（客户关系系统）系统接收到客户购买信息，可自行更新客户的购买记录； EMR（库存管理系统） 系统接收到客户购买信息，动态调整库存并及时补货； 快递服务接收到客户购买信息，自行打单并通知快递公司派送。 这么看，事件驱动模式是不是可以应用并出现在任何地方！ 在 EventBridge 产品化方向，也正是由于针对消息做了一些标准化封装，才有可能实现譬如针对事件本身的 filter（过滤） ，transform（转换），schema（事件结构），search（查询） 等能力。这些能力也拓展出更多针对事件驱动特有的场景功能及相关特性。 流 Streaming 流是一组有序的无界事件或数据，执行操作通常是固定的某个事件段（e.g. 00:00 – 12:00）或一个相对事件（E.g. 过去 12 小时）。 通常情况下单个事件往往就是使用事件本身，但是对于流可能的操作大概率是过滤，组合，拆分，映射等等。 流的操作可以是无状态也可以是有状态的： 对于单个事件操作是无状态的，包括过滤和映射； 依赖消息在流的时间或位置（e.g. offset，time）是有状态的。有状态操作中，流处理逻辑必须保留一些已被消费消息的内存。有状态包括对数据做 Batch Size，Batch Window 等。 流这里也可以举一个比较简单的例子，比如我们的物流系统在物品通过一个物流节点时会生成一个事件，但是要查到这个物品完整的流转状态事件，则必须是各个物流节点单个事件的聚合，那这个聚合事件就是流事件。 Kafka 是最典型的流式中间件，在流式场景中，事件的位置信息至关重要。通常情况下位置信息（E.g. offset）是由消费者托管的。 事件规范标准 聊完 Event 和 Streaming 是什么，再来补充一点有关于它们的规范。 事件规范存在的目的是为了清晰事件生产者和消费者的关系，目前主要有两部分：AsyncAPI 和 CloudEvents； AsyncAPI：基于事件 API 提供了与之对应的 Open API 和 Swagger 等；CloudEvents：侧重于处理事件的元数据。 下面也重点介绍一些关于 CloudEvents 的相关概念参考：CloudEvents 的核心其实是定义了一组关于不同组件间传输事件的元数据，以及这些元数据应该如何出现在消息体中。 其主旨大抵如下： 事件规范化； 降低平台集成难度； 提高 FaaS 的可移植性； 源事件可追踪； 提升事件关联性 准确的事件体，事件信息才可以做出更稳定的系统架构，永远保持对事件的敬畏。 附 一些术语及定义： Occurrence：发生，指事件逻辑上的发生，基于某种情况，事件出现了； Event：事件，表示事件以及上下文的数据记录。可以根据事件中的信息决定路由，但事件本身并不包含路由信息； Producer：生产者，真正创造事件的实例或组件； Source：源，事件发生的上下文，可以由多个 producer 组成； Consumer：消费者，接收事件并对事件进行消费； Intermediary：中介，接收包含事件的消息（message），并转发给下一个接收方，类似路由器； Context：上下文，上下文元数据被封装到 context attributes 中，用来判断事件与其它系统的关系； Data：数据，也可以叫做 payload； EventFormat：事件格式，例如 json； Message：消息，封装事件并将其从 source 传递到 destination； Protocol：协议，可以是行业标准如 http，开源协议如 Kafka 或者供应商协议如 AWS Kinesis； Protocol Binding：协议绑定，描述如何通过给定的协议收发事件，如何将事件放到消息里。

作为 Gartner 定义的 10 大战略技术趋势之一，事件驱动架构（EDA）逐渐成为主流技术架构。根据 Gartner 的预估，在新型数字化商业的解决方案中，将有 60%使用 EDA，在商业组织参与的技术栈中，EDA 有一半的占比。 当下比较成功的企业已然认识到，要想最大限度提升运营效率和客户体验，务必要将业务和技术两方面的举措紧密结合起来。运营事件或业务形势的变化是时下众多企业关注的焦点，这些变化能够为企业领导者带来切实有用的信息，而架构设计的主旨恰恰是从客户联系人、交易、运营等方面的信息中获取洞见，两者相辅相成。传统技术历来对企业从事件中获取洞见的速度有着诸多限制，比如用于记录、收集和处理此类事件的批处理 ETL（提取、转换、加载）等。基于以上背景，阿里云 EventBridge 应运而生。 EventBridge 是事件驱动的具体落地产品，也是 EDA 的最佳实践方式。 事件驱动（EDA）是什么 早在 2018 年，Gartner 评估报告将 EventDriven Model 列为 10 大战略技术趋势之一，事件驱动架构（EDA）将成为未来微服务的主流。该报告同时做出了以下断言： 到 2022 年，事件通知的软件模型将成为超过 60% 的新型数字化商业的解决方案； 到 2022 年，超过 50% 的商业组织将参与到事件驱动的数字化商业服务的生态系统当中。 很喜欢 George Santayana 在《 The Life of Reason》说的一句话 Those who fail to learn History are doomed to repeat it.（不懂历史的人注定会重蹈覆辙）。我们以史为鉴，来看看为什么会架构会演进到事件驱动。 上图是关于架构演进时间轴线。架构本身没有优劣之分，它本身就是一组技术决策，决定后续项目的所有功能开发（框架，编码规范，文档，流程….），所以这里不谈选型好坏，只谈为什么会引入某些框架，这个框架解决了软件开发中的什么问题。 单体架构：在单节点服务中，单体应用的所有模块都封装在单个进程运行，通信通过相同堆栈调用完成。这种模式下非常容易导致结构和关系不明确，难以对系统进行更改和重构。就像一个不透明的，粘稠的，脆弱的，僵硬的 Big Ball of Mud！ 分层架构：在经典的分层架构中，层以相当谨慎的方式使用。即一个层只能知道它下方层的数据。在随后的实际应用中，更多的方式是一个层可以访问它下面的任何层。分层架构解决了单体架构的的逻辑分离问题，每一层都可以被等效替换，是用层区分也更加标准化，同时一个层可以被几个不同/更高级别的层使用。当然，层也有比较明显的缺点，层不能封装掉一切，比如添加到 UI 的某个字段，可能也需要添加到 DB，而且额外多余的层会严重损害系统性能。 MVC 架构：MVC 架构产生的原因其实很简单，随着业务系统的复杂性增加，之前所谓“全栈工程师”已经不适用大部分场景。为了降低前端和后台的集成复杂性，故而开始推广 MVC 架构。其中，Model 代表业务逻辑；View 代表视图层，比如前端 UI 的某个小组件；Controller 提供 View 和 Model 的协调，比如将用户某项操作转为业务逻辑等。此外还有很多扩展架构，譬如 ModelViewPresenter，ModelViewPresenterViewModel，ResourceMethodRepresentation，ActionDomainResponder 就不在细说了，感兴趣的同学可以 wiki 搜索下。 EBI 架构：即 Entity，Boundary（接口），Interactor （控制）。EBI 架构将系统边界视为完整连接，而不仅仅是视图，控制器或接口。EBI 的实体代表持有数据并结束相关行为的实际实体，很类似阿里云的 POP API。EBI 主要还是后端概念，它是与 MVC 相辅相成的。 洋葱架构：洋葱架构是一种低耦合，高内聚的架构模型。所有的应用程序围绕独立的对象模型构建，内层定义接口，外层实现接口，耦合方向向中心内聚，所有代码都可以独立与基础设施进行编译和运行。 SOA 架构：SOA 是 Service Orientated Architure 的缩写，即面向服务架构。表示每一个功能都是通过一个独立的服务来提供，服务定义了明确的可调用接口，服务之间的编排调用可完成一个完整的业务。其实这个架构也是目前架构中最成熟的，日常使用最多的架构模式。 在介绍完之前全部的架构趋势后，在回过头看看什么是 EDA 架构。 EDA 事件驱动架构( EventDriven Architecture ) 是一种系统架构模型，它的核心能力在于能够发现系统“事件”或重要的业务时刻（例如交易节点、站点访问等）并实时或接近实时地对相应的事件采取必要行动。这种模式取代了传统的“ request/response ”模型，在这种传统架构中，服务必须等待回复才能进入下一个任务。事件驱动架构的流程是由事件提供运行的。 上图其实很好的解释了 EDA 架构的模型，但是其实还不够明确，所以这里我们和单体架构一起对比看看他们之间差异。 在如上对比图中，我们其实可以较为清楚看到它与传统架构的区别。在一般传统架构中，创建订单操作发生后，一系列的操作其实都是通过一个系统完成的。而事件驱动的概念则是将全部操作都转换为 “事件” 概念，下游通过捕获某个 “事件” 来决定调用什么系统完成什么样的操作。 我们回过头来看“事件”，刚刚介绍中比较的重要部分其实是将操作转换为某类事件进行分发。那这的事件我们怎么定义呢？ 简单来看，其实事件就是状态的显著变化，当用户采取特定行动时触发。以 4S 店售卖汽车为例： 当客户购买汽车并且其状态从 For Sale 变为 Sold 是一个事件； 成功交易后，从帐户中扣除金额是一个事件； 单击预订试驾后，从将预约信息添加到指定用户就是一个事件； 每个事件都可能触发一个或多个选项作为响应。 事件其实云原生 CNCF 基金会在 2018 年托管了开源 CloudEvents 项目，该项目旨在用统一和规范的格式来描述事件，来加强不同的服务、平台以及系统之间的互操作性。在该项目定义下，通用的事件规范是这样的： 事件主要由 Json 体构成，通过不同字段描述发生的事件。 总结来看，事件驱动其实是将比较重要的业务时刻封装成“事件”，并通过某个 EventBus 将事件路由给下游系统。 了解了 EDA 架构的整个处理过程，但是还没解决这个所谓的“EventBus”到底是什么？ 如上图就是 EventBus 的核心逻辑架构，它由 Event Producer 和 Event Consumer 两端组成，通过 Bus 解耦中间环节，是不是非常像某个传统的 MQ 架构？别着急，在接下来的落地实践部分会讲解这个架构的复杂部分。 EDA 架构的落地实践思考 在开始介绍落地实践时，我们先来看一个经典的 EDA 架构模型： 这是一个非常经典 EDA 订单架构，该架构主要使用了 EventBridge 和 FC 函数计算（如果不太熟悉 FaaS 的同学可以把 FC 节点当作 ECS 或 Kubernetes 的某个 POD 节点），通过事件驱动各个业务进行协作。 所以这块的中心节点（EventBridge）其实有三个比较重要的能力： 1. For Event Capturing（事件收集）：具备采集事件的能力； 2. For Routing（事件路由）：通过事件内容将事件路由分发至于下游的能力； 3. For Event Processing（事件过滤/替换）：对事件进行脱敏或初步过滤&筛选的能力。 通常情况下，要实现这三个能力是比较困难的，比如：Event Capturing 可能需要熟悉 Dell Boomi, Snaplogic, MuleSoft, Dataflow, Apache Apex 等，Routing 部分可能通过 RocketMQ、RabbitMQ、ActiveMQ、Apache Kafka，Event Processing 需要了解 Apache Storm, Apache Flink 。所以之前讲的逻辑架构其实非常理想，要想实现完成的 EDA 事件驱动还需要包括这些核心能力。 其实，从刚刚的架构中我们也能窥探到一些信息，EDA 架构其实看起来没有那么简单，那它有何优劣呢？ 下面简单罗列下 EDA 架构在实践中的优势： 松耦合：事件驱动架构是高度松耦合且高度分布式的架构模型，事件的创建者（来源）只知道发生的事件，并不知道事件的处理方式，也关心有多少相关方订阅该事件； 异步执行：EDA 架构是异步场景下最适合的执行工具，我们可以将需要事件保留在队列中，直到状态正常后执行； 可扩展性：事件驱动架构可以通过路由&过滤能力快速划分服务，提供更便捷的扩展与路由分发； 敏捷性：事件驱动架构可以通过将事件分发至任何地方，提供更敏捷高效的部署方案。 当然，劣势也很明显： 架构复杂：事件驱动架构复杂，路由节点多，系统结成复杂，功能要求多； 路由分发难：事件路由分发难，灵活的事件路由需要依赖强大的实时计算能力，对整体分发系统要求较高； 无法追踪：事件追踪是整个 EDA 架构的保证，EDA 架构中往往很难追踪到事件处理状态，需要大量的定制化开发； 可靠性差：事件驱动由于需要多系统集成，可靠性通常较差，且交付无法保障。 _ 针对 EDA 场景面临的这些问题，阿里云推出了 EventBridge，一款无服务器事件总线服务，其使命是作为云事件的枢纽，以标准化的 CloudEvents 1.0 协议连接云产品和应用、应用和应用，提供中心化的事件治理和驱动能力，帮助用户轻松构建松耦合、分布式的事件驱动架构；另外，在阿里云之外的云市场上有海量垂直领域的 SaaS 服务，EventBridge 将以出色的跨产品、跨组织以及跨云的集成与被集成能力，助力客户打造一个完整的、事件驱动的、高效可控的上云体验。 阿里云对 EventBridge 做了定义，核心价值包括： 统一事件枢纽：统一事件界面，定义事件标准，打破云产品事件孤岛； 事件驱动引擎：海量事件源，毫秒级触发能力，加速 EDA/Serverless 架构升级； 开放与集成：提供丰富的跨产品、跨平台连接能力，促进云产品、应用程序、SaaS 服务相互集成。 下面从架构层面和功能层面对 EventBridge 进行介绍： 架构层面 针对架构复杂问题，EventBridge 提供业内通用的 Source ，Buses，Rules，Targets 模块管理能力，同时支持 EventBus 和 EventStream 两种模式，大幅度降低事件驱动架构难度。 1）事件总线模型经典 EDA（ 事件驱动）场景的 N：N 模型，提供多事件路由，事件匹配，事件转换等核心能力，帮助开发者快速搭建事件驱动架构。 2）事件流模型标准 Streaming（1:1） 流式处理场景，无总线概念，用于端到端的数据转储，数据同步及数据处理等，帮助轻松构建云上端到端的数据管道服务。 功能层面 在功能层面，EventBridge 的核心亮点应用包括： 1）事件规则驱动 针对基于事件的路由分发，EventBridge 通过事件规则驱动，支持 8 大事件模式，4 重转换器，满足路由分发的全部诉求。 2）事件追踪 针对事件无法追踪，独家提供事件追踪能力，事件分析/查询能力。为用户完善的全链路事件查询分析能力。 3）DLQ/重试机制、事件全流程触发 针对可靠性差，支持 DLQ/重试机制，与事件全流程触发，大幅度保证由于用户下游系统导致的事件故障与延迟。 4）Schema 注册中心 针对事件管理复杂，支持 Schema 注册中心，支持事件信息的解释、预览和上下游代码生成能力，帮助用户低代码完成事件的收发处理。解决跨部门信息沟通困难，业务代码冗余等一系列事件管理问题。 5）同时，基于以上功能 EventBridge 支持对接 85 种以上的阿里云产品，847 种事件类型。 更多产品功能介绍，可访问 EventBridge 官网 阿里云 EventBridge 更多场景介绍 经典 EDA 事件驱动 事件总线（EventBridge）最重要的能力是通过连接应用程序、云服务和 Serverless 服务来构建 EDA（Eventdriven Architectures） 事件驱动架构，驱动应用与应用，应用与云的连接。 流式 ETL 场景 EventBridge 另一个核心能力是为流式的数据管道的责任，提供基础的过滤和转换的能力，在不同的数据仓库之间、数据处理程序之间、数据分析和处理系统之间进行数据同步/跨地域备份等场景，连接不同的系统与不同服务。 统一事件通知服务 EventBridge 提供丰富的云产品事件源与事件的全生命周期管理工具，您可以通过总线直接监听云产品产生的数据，并上报至监控，通知等下游服务。

企业数字化转型过程中，天然会遇到消息路由，异地多活，协议适配，消息备份等场景。本篇主要通过 EventBridge 消息路由的应用场景和应用实验介绍，帮助大家了解如何通过 EventBridge 的消息路由高效构建消息路由能力。 背景知识 EventBridge 消息路由主要涉及以下云产品和服务： 事件总线 EventBridge 事件总线 EventBridge 是阿里云提供的一款无服务器事件总线服务，支持阿里云服务、自定义应用、SaaS 应用以标准化、中心化的方式接入，并能够以标准化的 CloudEvents 1.0 协议在这些应用之间路由事件，帮助您轻松构建松耦合、分布式的事件驱动架构。 消息队列 RabbitMQ 版 阿里云消息队列 RabbitMQ 版支持 AMQP 协议，完全兼容 RabbitMQ 开源生态以及多语言客户端，打造分布式、高吞吐、低延迟、高可扩展的云消息服务。开箱即用，用户无需部署免运维，轻松实现快速上云，阿里云提供全托管服务，更专业、更可靠、更安全。 消息队列 MNS 版 阿里云消息服务 MNS 版是一款高效、可靠、安全、便捷、可弹性扩展的分布式消息通知服务。MNS 能够帮助应用开发者在他们应用的分布式组件上自由的传递数据、通知消息，构建松耦合系统。 场景应用 EventBridge 消息路由功能在构建在构建消息系统过程中主要应用于下面三个场景，一是消息路由场景，二是消息多活场景，三是多协议适配场景，下面对这三个场景进行简要介绍。 消息路由场景 该场景是指希望对消息进行二次分发，通过简单过滤或者筛选将消息分发到其他 Topic 或跨地域 Topic，实现消息共享 & 消息脱敏的场景。 通过一层转发将消息分发给不同的 Topic 消费，是消息路由的核心能力。随着企业转型遇到消息拆分且做业务脱敏的场景会越来越多。如下图是一个较为典型的路由分流场景。 消息多活场景 消息多活场景指每个数据中心均部署了完整、独立的 MQ 集群。数据中心内的应用服务只连接本地的 MQ 集群，不连接其他单元的 MQ 集群。MQ 集群中包含的消息路由模块，负责在不同单元 MQ 集群之间同步指定主题的消息。 根据应用服务是否具有单元化能力，可分为中心服务和单元服务两类。中心服务只在一个数据中心提供服务；单元服务在各个数据中心都提供服务，但只负责符合规则的部分用户，而非全量用户。 所有部署了单元服务的数据中心都是一个单元，所有单元的单元服务同时对外提供服务，从而形成一个异地多活架构或者叫单元化架构。通过多活管控平台可动态调整各个单元服务负责的流量。 多协议适配场景 随着业务团队的逐渐庞大，对消息的建设诉求与日俱增，由于部门技术栈的不同会导致部门间的消息协议也不尽相同。多协议适配是指用一种消息协议平滑迁移到多种消息协议的能力。 架构描述 使用 EventBridge 的事件流能力做消息路由，事件流模型是 EventBridge 在消息领域主打的处理模型，适用标准 Streaming（1:1）流式处理场景，无总线概念。用于端到端的消息路由，消息转储，消息同步及处理等，帮助开发者轻松构建云上数据管道服务。 下面的架构展示了如何通过桥接 EventBridge 实现 MNS 消息路由至 RabbitMQ Queues，MNS Queues。（A/B 链路任选其一进行试验） 应用实验 目标 通过本实验教程的操作，您可以通过阿里云控制台，在事件总线控制台中创建消息路由服务，在 EventBridge 控制台实现消息路由与简单的消息脱敏。 体验此实验后，可以掌握的知识有： 创建消息路由任务； 创建 RabbitMQ 实例、MNS 实例与简单的消息发送。 资源 使用到的资源如下：（本次实验资源遵循最小原则，使用满足场景需求的最小化资源） 资源一：EventBridge 事件总线 资源二：阿里云消息队列 RabbitMQ 版 资源三：阿里云消息队列 MNS 版 步骤 1）创建 MNS 资源 本实验分 A /B 两个可选场景： A 、场景通过 MNS Queues1 投递至 MNS Queues2 B 、场景通过 MNS Queues1 投递至 RabbitMQ Queues 可根据兴趣选择不同场景。 本步骤将指导您如何通过控制台创建消息队列 MNS 版。 使用您自己的阿里云账号登录阿里云控制台，然后访问消息队列MNS版控制台。[1] 在控制台左边导航栏中，单击队列列表。（资源地域为同地域即可，本次引导默认选杭州） 在列表页面，单击创建队列并填写名称信息“testmnsq” 创建完成后点击“详情” 找到 MNS 公网接入点信息，并记住该信息，后续实验会用到。 E.g. 注意：重复如上步骤即可创建 A 实验链路的 “testmnsq2” 2）创建 RabbitMQ 资源（B 实验可选） 本步骤将指导您如何通过控制台创建消息队列 RabbitMQ 版。 使用您自己的阿里云账号登录阿里云控制台，然后访问消息队列RabbitMQ版控制台。[2] 在控制台左边导航栏中，单击实例列表。（资源地域为同地域即可，本次引导默认选杭州） 在列表页面，单击创建实例，并完成创建。 创建完成后点击详情进入实例详情页； 在“Vhost 列表” 创建 “testamqpv”； 在“Queue 列表” ，选择 Vhost 为“testamqpv”，并创建 “testamqpq”； 3）创建 EventBridge 事件流任务   MNS TO MNS（A 实验可选） 本步骤将指导您如何通过控制台创建 EventBridge 事件流。 使用您自己的阿里云账号登录阿里云控制台，然后访问 EventBridge 控制台。[3] 注：第一次使用需开通。 单击“事件流”列表，并在列表创建任务 （资源地域为同地域即可，本次引导默认选杭州） 创建事件流名称为“testamqpmns2mns”，点击下一步； 指定事件源，事件提供方为“消息服务 MNS”，队列名称为“testmnsq”，点击下一步； 指定规则，规则部分可不做筛选，默认匹配全部，直接点击下一步； 注意：规则内容可根据需求自行指定，为降低难度本次实验默认投递全部，更多详情请查阅： 服务类型选择“消息服务 MNS”，队列名称选择“testmnsq2”，消息内容选择“部分事件”，点击创建 注意：消息内容可根据需求自行指定，本次实验默认投递 data 字段，更多详情请查阅： 创建完成后，可点击“启动”来启动事件流 4）创建 EventBridge 事件流任务 MNS TO RabbitMQ（B 实验可选） 本步骤将指导您如何通过控制台创建 EventBridge 事件流。 使用您自己的阿里云账号登录阿里云控制台，然后访问 EventBridge 控制台。[3]注：第一次使用需开通。 单击“事件流”列表，并在列表创建任务 （资源地域为同地域即可，本次引导默认选杭州） 创建事件流名称为“testamqpmns2rabbitmq”，点击下一步 指定事件源，事件提供方为“消息服务 MNS”，队列名称为“testmnsq”，点击下一步 指定规则，规则部分可不做筛选，默认匹配全部，直接点击下一步 注意：规则内容可根据需求自行指定，为降低难度本次实验默认投递全部，更多详情请查阅： 服务类型选择“消息队列 RabbitMQ 版本”，具体配置如下，点击创建 实例ID：选择创建好的RabbitMQ ID Vhost：选择“testamqpv” 目标类型：选择“Queue” Queue：选择“testamqpq” Body：选择“部分事件”，填写“$.data” MessageId：选择“常量”，填写“0” Properties：选择“部分事件”，填写“$.source” 注意：消息内容可根据需求自行指定，本次实验默认投递 data 字段，更多详情请查阅： 创建完成后，可点击“启动”来启动事件流 5）验证路由任务 向 MNS Source  “testmnsq ” 发送实验消息 点击下载 MNS SDK[4] 修改 sample.cfg 在 “sample.cfg ” 填写 AccessKeyId，AccessKeySecret，Endpoint 等信息 AccessKeyId，AccessKeySecret 可在阿里云 RAM 控制台[5]创建 Endpoint 即步骤 1 ， MNS 公网接入点地址 AccessKeyId = xxxxxx AccessKeySecret = xxxxxxx Endpoint = http://xxxx.mns.cnhangzhou.aliyuncs.com 填完效果如下，保存 找到 sample 目录的“sendmessage.py” 示例 将循环参数调整为 200，并保存 (可选) 保存并运行 “python sendmessage.py testmnsq” python sendmessage.py testmnsq 在事件流控制台[6]，分别点开 “testmnsq2”， “testamqpq” 查看详情转储详情。 注意：MNS Q 仅支持单订阅，不支持广播模式。故该测试需要将 MNS/RabbitMQ 两个实验，任选其一关停后进行实验。 如需广播模式，请创建 MNS Topic 资源。 A 链路实验结果： B 链路实验结果： 优势及总结 EventBridge 事件流提供端到端的消息路由能力，通过简单配置即可完成消息分发，消息同步，跨地域消息备份，跨产品消息同步等能力。具有运维简单，成本低，效率高，使用稳定等优势。同时使用 EventBridge 可以实现基础的数据过滤，数据脱敏等数据处理类能力。是消息路由场景下运维成本最低的解决方案。 相关链接 [1] 消息队列MNS版控制台 [2] 消息队列RabbitMQ版控制台 [3] EventBridge 控制台 [4] 点击下载 MNS SDK [5] 阿里云RAM 控制台 [6] 事件流控制台

操作系统、数据库、中间件是基础软件的三驾马车，而消息队列属于最经典的中间件之一，已经有30多年的历史。其发展主要经历了以下几个阶段： 第一个阶段，2000年之前。80年代诞生了第一款消息队列是 The Information Bus，第一次提出发布订阅模式来解决软件之间的通信问题；到了90年代，则是国际商业软件巨头的时代，IBM、Oracle、Microsoft纷纷推出了自己的 MQ，其中最具代表性的是IBM MQ，价格昂贵，面向高端企业，如大型金融、电信等企业；这类商业MQ一般采用高端硬件，软硬件一体机交付，MQ本身的架构是单机架构。 第二阶段，2000~2007年。进入00年代后，初代开源消息队列崛起，诞生了JMS、AMQP两大标准，与之对应的两个实现分别为 ActiveMQ、RabbitMQ，开源极大的促进了消息队列的流行度，降低了使用门槛，逐渐成为了企业级架构的标配。相比于今天而言，这类MQ主要还是面向传统企业级应用，面向小流量场景，横向扩展能力比较弱。 第三阶段，2007~2018年。PC互联网、移动互联网爆发式发展。由于传统的消息队列无法承受亿级用户的访问流量和海量数据传输，诞生了互联网消息中间件，核心能力是全面采用分布式架构、具备很强的横向扩展能力，开源典型代表有 Kafka、RocketMQ，还有淘宝的 Notify。Kafka 的诞生还将消息中间件从Messaging领域延伸到了 Streaming 领域，从分布式应用的异步解耦场景延伸到大数据领域的流存储和流计算场景。 第四阶段，2014~至今。IoT、云计算、云原生引领了新的技术趋势。面向IoT的场景，消息队列开始从云内服务端应用通信，延伸到边缘机房和物联网终端设备，支持MQTT等物联网标准协议也成了各大消息队列的标配。 随着云计算的普及，云原生的理念深入人心，各种云原生代表技术层出不穷，包括容器、微服务、Serverless、Service Mesh、事件驱动等。云原生的核心问题是如何重新设计应用，才能充分释放云计算的技术红利，实现业务成功最短路径。 消息队列本身作为云计算的PaaS服务之一，要进一步发挥“解耦”的能力，帮助业务构建现代化应用，这里最关键的一个能力演进是Eventing的演进。通过将消息升华为“事件”，提供面向标准 CloudEvent 的编排过滤、发布订阅等能力构建更大范围的解耦，包括云服务事件和业务应用的解耦、跨组织SaaS业务事件的解耦、遗留应用和现代化应用的解耦等，同时事件驱动也是天然符合云计算 Serverless 函数计算的范式，是应用 Serverless 化演进的催化剂。 云原生对于消息中间件而言，还有另一层含义就是消息队列自身架构的云原生化演进，如何充分发挥云的弹性计算、存储、网络，让自己获得更强的技术指标和 Serverless 弹性能力。 消息中间件在技术上有哪些进展与突破？ 阿里云 MQ 是基于 RocketMQ 打造的一站式消息服务，以 RocketMQ 作为统一内核，实现业界标准、主流的消息协议，包括MQTT、Kafka、RabbitMQ、AMQP、CloudEvent、HTTP等，满足客户多样化场景诉求。为了提高易用性，我们分别对不同的协议进行了产品化，以独立产品的模式提供消息服务（如阿里云RabbitMQ、阿里云Kafka），开箱即用、免运维、完备的可观测体系，帮助开源客户无缝迁云。 在经历数万企业客户多样化场景的持续打磨，数年的超大规模云计算的生产实践，我们的内核RocketMQ逐渐往一体化架构和云原生架构演进。 1. 一体化架构 微服务、大数据、实时计算、IoT、事件驱动等技术潮流，不断的扩展消息的业务边界，业界有不同的消息队列满足不同的业务场景，比如RabbitMQ侧重满足微服务场景，Kafka则是侧重于满足大数据、事件流场景，EMQ则是满足了IoT垂直领域场景。而随着数字化转型的深入，客户的业务往往同时涉及交叉场景，比如来自物联网设备的消息、或者微服务系统产生的业务消息要进行实时计算，如果是引入多套系统，会带来额外的机器、运维、学习等成本。 在过去“分”往往是技术实现的妥协，而现在“合”才是用户的真正需求。RocketMQ 5.0基于统一Commitlog扩展多元化索引，包括时间索引、百万队列索引、事务索引、KV索引、批量索引、逻辑队列等技术。在场景上同时支撑了RabbitMQ、Kafka、MQTT、边缘轻量计算等产品能力，真正实现了“消息、事件、流”，“云边端”一体化架构。 2. 云原生架构   云原生架构是指云上原生的架构，云计算是云原生的“源动力”，脱离了云计算谈云原生如同纸上谈兵。RocketMQ 过去几年正是立足于阿里云超大规模的云计算生产实践，帮助数万企业完成数字化转型的经验中吸取养分，从而完成互联网消息中间件到云原生消息中间件的进化。这也是 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化。在老架构里面，客户感知物理队列，物理队列绑定固定存储节点，强状态。Broker、客户端、物理队列的扩缩容互相耦合，负载均衡粒度是队列级，对Serverless的技术演进很不友好。为了实现极致弹性 Serverless，RocketMQ 5.0 对逻辑资源和物理资源做进一步的解耦。 在 Messaging/无序消息的场景，客户指定 Topic 进行消息无序收发，新架构对客户端屏蔽队列概念，只暴露逻辑资源 Topic。负载均衡粒度从队列级到消息级，实现了客户端的无状态化，客户端、服务端弹性伸缩解耦。 在 Streaming/顺序消息的场景，客户端需要指定 Topic 下的某个队列（也称分区）进行消息顺序收发。在新架构里，对客户端屏蔽物理队列，引入逻辑队列概念，一个逻辑队列通过横向分片和纵向分段，分散在不同的物理存储节点。横向分片解决了高可用问题，同一个逻辑队列的多个分片多点随机可写，基于 Happen before 的原理保序，秒级 Failover，无需主备切换；纵向分段，解决逻辑队列的扩容问题，通过多级队列映射，实现 0 数据迁移的秒级扩容，逻辑资源和物理资源的弹性伸缩解耦。   如何看待消息领域生态玩家? 在云原生、IoT、大数据的趋势引导下，消息成为现代化应用架构的刚需，使用场景更加广泛，可应用于微服务的异步解耦、事件驱动、物联网设备数据上下行、大数据流存储、轻量流计算等场景。客户需求旺盛、市场活跃，吸引了不少厂商加入角逐。 从好的角度来看，厂商的充分竞争，会进一步激活创新，培养更多用户，共同做大消息的市场，用户看起来也有更多的选择； 从坏的角度来看，未来部分竞争失利的消息队列会进入停滞期、下线期，用户的应用就会面临迁移大改造和稳定性风险，所以建议用户在满足自身业务需求的情况下，尽可能选择标准接口、协议的方式接入，或者直接使用业界事实标准的消息队列。 消息中间件未来的发展趋势是什么？   随着 IoT、5G 网络的持续发展，数据量增速28%,预计到2025年物联网设备将达到 400 亿台，进入万物互联的时代。物联网时代的消息存储量和计算量会爆发式增长，消息系统将面临巨大的成本压力。未来消息系统，需要深挖新硬件的红利，比如持久内存、DPU等技术，采用软硬结合的方式深度优化，将消息的存储计算成本进一步降低。 IoT时代还有另外一个很重要的趋势是边缘计算，Gartner 预计到 2025 年，75%的数据将在传统数据中心或云环境之外进行处理,消息系统需要进一步轻量化、降低资源消耗以适应边缘计算环境。这也意味着，消息中间件的一体化架构，要具备良好的插件化设计，能够根据场景的特点实现多形态输出。比如公共云的形态可以和公共云的基础设施深度集成，充分利用云盘、对象存储增强存储能力，集成日志服务、应用监控等服务提升可观测能力；而边缘计算的形态则是以最小的资源代价输出核心存储、轻量计算的能力，简单够用即可。 近几年云计算高速发展，得益于全球范围内大量企业在进行数字化转型，通过业务在线化、业务数据化、数据智能化来提升企业竞争力。数据化转型也伴随着商业思维的转型，越来越多的企业采用“事件驱动”的模式来构建商业逻辑和数字化系统。 Gartner预测，未来超过60%的新型数字化商业的解决方案会采用“事件驱动”模式，从业务角度看，“事件驱动”的模式能够帮助企业实时响应客户，抓住更多的商业机会，创造增量价值；从技术角度看，“事件驱动”的架构，能够以动态、灵活、解耦的方式来链接跨组织、跨环境的异构系统，天然适合用于构建大型的跨组织数字化商业生态。 为了应对这个趋势，Messaing 往 Eventing 演进，出现了 EventBridge （EventBroker）的产品形态。在 EventBridge 里，“事件”这个概念成为一等公民，事件的发布者和订阅者不耦合任何一种具体的消息队列SDK和实现。EventBroker 围绕标准的 CloudEvent 规范构建更加泛化的发布订阅模式，能够链接一切跨组织、跨环境的异构事件源和事件处理目标。 目前以“事件驱动”构建的数字化商业生态才刚起步，未来 EventBridge 将围绕事件这一抽象层次实现更强大的能力，比如事件的全链路可观测、事件分析计算、低代码开发等特性，帮助企业全面落地云时代的“事件驱动”架构。 作者介绍： 林清山（花名：隆基），阿里云资深技术专家，阿里云消息产品线负责人。国际消息领域专家，致力于消息、实时计算、事件驱动等方向的研究与探索，推进 RocketMQ 云原生架构、超融合架构的演进。