引言 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 消费模式：_

当下降本增效是各行各业的主题，而 SaaS 应用作为更快触达和服务业务场景的方式则被更多企业熟知和采用。随着国内 SaaS 商业环境的逐渐成熟，传统企业中各个部门的工程师和管理者，能迅速决定采购提升效率的 SaaS 产品，然后快速投入生产和使用。但是随着行业 SaaS 越来越多，如何解决各个 SaaS 系统的数据孤岛，如何将SaaS 应用数据与现有系统数据进行打通，已然变成了企业使用 SaaS 的瓶颈。因此，业内也广泛提出 B2B integration 企业集成的概念。 本文将结合实际业务场景讲述在 SaaS 行业的洞察与 SaaS 集成的探索实践。 什么是 SaaS SaaS 概述 SaaS（SoftwareasaService，软件即服务）源自于美国 Salesforce 公司（1999 年创立）创造的新软件服务模式。相比于传统软件，用户使用的 SaaS 软件，其数据保存在云端（国内有很多行业 SaaS 由于其数据敏感会单独部署在客户 IDC）。而且，SaaS 公司提供给客户的服务通常是按需租用的，比如按年缴纳使用费5年，第二年再续费，如果不满意也可以不续费，这会大大激发 SaaS 创业公司持续的打磨产品、持续的为客户提供更大价值的动力。 SaaS 典型分类 SaaS 分类比较繁琐，一般有两个分类维度。一个维度按照使用场景，另一个维度按照商业价值。 SaaS 一般分类为 通用 SaaS 和 行业 SaaS 两个基础类。 通用 SaaS 顾名思义是通用的，跨行业的，比如钉钉即时通讯或者某司的 HR 产品，由于使用场景更广，因而客群也会更多。 行业 SaaS 是在某个行业内使用的产品，比如餐饮企业 SaaS、电商 SaaS 等。 当然，还有第二个维度是工具 SaaS 和 商业 SaaS。 工具 SaaS，为客户企业提供一个提高管理效率的工具；商业 SaaS，除了提供一部分“工具”价值外，还能为客户企业提供增值价值，比如增加营收、获得资金等。 商业 SaaS 产品虽然风险更大，但在国内特色的商业环境、管理水平及人才结构下，更容易快速实现客户价值和自我价值。 SaaS 在中国的发展历程 对于 SaaS 领域来讲，云服务的普及提振了大家对 SaaS 服务稳定性和数据安全性的信心。同时，人口红利消退使得 SaaS 成本优势凸显。当下疫情环境也加快了市场教育，企业主转变思路，降本增效的需求显著上升。随着整个行业的渗透率加快，SaaS 场景和行业越做越深，SaaS 市场可以遇见在未来会有高速的增长。很多企业会在新业务场景使用 SaaS 服务，小步快跑试错，解决活下来的问题，而不是重复造轮子。 什么是 B2B ？ B2B 即 BusinesstoBusiness (B2B) integration 是指将两个或者多个组织之间的业务流程和通讯自动化，通过自动化关键业务流程，实现不用应用和组织关系的打通，有效促进应用提供方和客户之间的数据打通与合作。 可以断言，随着 SaaS 行业逐渐渗透，企业集成的诉求会逐渐增多。数据同步、用户同步、接口同步的诉求会逐步增多，包括自建服务与 SaaS 服务的打通，SaaS 服务与 SaaS 服务的打通等。 SaaS 集成领域场景分析 随着行业类 SaaS 的逐渐丰富，在企业生产实践中，应用和应用的数据集成和互通变得至关重要。包括 API 集成，数据集成，流程集成等场景。 API 集成 通过 API 将 SaaS 应用的业务流程串联，现阶段大部分 SaaS 集成对接都是通过标准 API 协议实现的。源端采用 WebHook 机制推送到指定 HTTP 端点，目标端则采用类似 API 接口调用的方式，主动调取执行动作。 实现结构如下： 业内通用方案通几乎均为同步方案，通过 API + 中间网关对调用做解耦和映射。该方案的主要问题是调用追溯难；其次如出现上下游接口限制不一致问题，会导致下游调用大量失败。 数据集成 数据集成场景主要是企业自建系统和 SaaS 系统的打通。当企业使用的行业 SaaS 逐渐增多，数据一致性问题就会变的迫在眉睫。 大部分企业通常会面临云上数据导入/同步到 SaaS 应用的场景，而业内对 SaaS 应用的数据集成方案并没有类似 CDC 场景下的 Debezium 那么标准和通用。 企业在 SaaS 集成领域的痛点 接入成本高 对大量使用 SaaS 应用的企业来讲， SaaS 集成是必须做的基础建设。但是该部分基础建设通常会消耗大量人力，由于各个行业的 SaaS 百花齐放，通常很难使用一套架构满足全部集成场景。意味着通常情况下，企业使用每一款 SaaS 都会面临 SaaS 系统与自身系统集成的困难。 异构数据多 异构数据多是集成领域又一个比较典型的特点，异构数据通常有结构化数据，非机构化数据，半结构化数据。比如企业自建关系型数据库就是典型的结构化数据，但是要被其他 SaaS 系统集成通常是 Json 这种半结构数据入参。当然这部分内容可以通过定制代码搞定，但这个思路一定不是做消息枢纽的思路； 异构数据如何高效的统一处理其实是当前 SaaS 集成亟待解决的问题，也是最大的冲突点。 分发/路由困难 当很多集成需求同时涌现时，如何对已集成数据进行合理分发，会变成集成领域又一个难以解决的问题。每个细分场景甚至每个集成链路所需要的数据内容甚至数据类型都不一样。如果路由/分发无法完成，那么企业统一集成将无法实现。 集成追踪困难 当全部采用同步链路时，这里的集成状态追踪就会变成玄学，除非将链路接入 Tracing ，但是这部分又回产生高额的改造成本，同时多源 Tracing 的复杂相对于单链路会呈几何倍数的增加。 老系统迁移困难 老系统迁移主要是数据集成部分，如果将新老系统对接，并构建统一的应用网是当下企业构建 SaaS 建设的难点。企业迫切的需要一种能将"新"“老”应用联接起来的方式，打破企业应用发展的时间与空间界限，协同企业原有核心数据资产及创新应用，构建可平滑演进的企业IT架构。 EventBridge 一站式企业 SaaS 集成方案 针对业内 SaaS 系统集成的种种痛点，EventBridge 推出一站式企业 SaaS 集成方案。通过收敛 SaaS 集成痛点诉求，EventBridge 推出 API 集成方案和数据集成方案，打通应用与应用，云与应用的连接。 低代码集成平台 提供完全托管的集成平台服务，仅需在控制台进行简单配置即可在几分钟内完成应用集成。客户无需关心底层资源及实现细节即可打通云下到云上，SaaS 到 SaaS 的集成与连接，轻松完成异构数据接入。 金融级稳定性 满足不同客户企业级集成项目的要求，提供高可用性、灾难恢复、安全性、服务等级协议（SLA）和全方面的技术支持。 全方位的集成能力 支持各种集成场景，打通云上云下企业应用、物联网、设备及合作伙伴之间的信息孤岛。支持事件规则，事件路由等多种路由方式，实现跨云跨地域互通和信息共享。同时强大的链路追踪能力可以帮助企业快速排障。 开放的平台 拥抱 CloudEvents 社区，提供标准化的事件集成方案。提供丰富的开发者工具，拥有海量的生态伙伴及开发者，丰富开箱即用的连接器和应用组件可以帮助加速企业业务创新。 EventBridge 在 SaaS 领域的典型应用场景 SaaS 应用同步 应用同步是指在特定时间点将一组特定的事件从一个系统迁移到另一个系统的行为。事件同步模式允许开发人员创建数据自动迁移集成服务；业务人员和开发人员可以通过配置集成应用，自动化的将特定范围内的数据传递到下游应用；创建可重用的服务可以为开发和运营团队节省大量时间。 例如： 把销售机会数据从一个旧式 CRM (客户关系管理) 系统迁移到新的 CRM 实例； 把销售订单数据从一个 CRM 组织迁移到另一个组织； 从 ERP (企业资源计划) 同步产品主数据到 CRM 系统中。 事件广播 事件广播是在连续的、近实时或实时的基础上将事件从单个源系统移动到多个目标系统的行为。本质上，它是一对多的单向同步。通常，“单向同步”表示 1:1 关系。但是，广播模式也可以是 1:n（n 大于 1）的关系。 例如： 当一个销售机会在 CRM 中被标记为成功关单的时候，应在 ERP 中创建销售订单。 SaaS 应用通知 事件通知是指当 SaaS 应用发生某个类型的事件，可以通过钉钉，短信等通知方式告知用户。用户可及时获取到关键事件信息。 例如： 当一个销售机会在 CRM 中被标记为重要商机的时候，会及时通知给其他同事进行跟进并关注。 自建系统到云上迁移 EventBridge 支持云上数据库、云上消息队列、云产品事件对接 SaaS 系统，完善企业用户建设应用一张网的诉求，打破企业应用发展的时间和空间界限，协同企业原有核心资产与 SaaS 系统，构建可演进的企业 IT 架构。 例如： 当引入一个新的 SaaS 应用时，可通过 EventBridge 将数据库/大数据平台的核心资产（如人员信息等）同步至 SaaS 应用。

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

背景 以事件集成阿里云，从 EventBridge 开始”是 EventBridge 这款云产品的愿景和使命。作为一款无服务器事件总线服务，EventBridge 从发布以来，以标准化的 CloudEvents 1.0 协议连接了大量云产品和云事件，用户可以通过 EventBridge 轻松访问云上事件，驱动云上生态。 截止目前为止，EventBridge 已集成 85+ 阿里云产品，提供了 941+ 事件类型，集成 50+ SaaS产品，通过事件规则可轻松驱动 10+ 阿里系一方云产品的计算力。 另一方面，钉钉生态空前繁荣，拥有 4000+ 家的生态伙伴，包括 ISV 生态伙伴、硬件生态伙伴、服务商、咨询生态和交付生态伙伴等。通过事件将钉钉生态与阿里云生态联通，是践行「云钉一体」战略的重要途径，EventBridge 作为阿里云标准化的事件枢纽，其重要性不言而喻。 今天，EventBridge 联合钉钉连接器，打通了钉钉生态和阿里云生态，钉钉的生态伙伴可以通过通道的能力驱动阿里云上海量的计算力。 关键技术 EventBridge 集成阿里云和钉钉生态的方案，核心能力由钉钉连接器和 EventBridge 的 HTTP 事件源能力提供。 钉钉连接器 钉钉连接平台通过可视化拖拽配置、一键订阅等零代码方式，简单高效的实现钉钉、企业内部系统、知名厂商系统（金蝶、用友、SAP 等）、钉钉第三方企业应用之间数据互通和集成。 近期，钉钉连接器在「连接流」中发布了「HTTP Webhook」的执行动作能力，支持将钉钉生态开放给外部生态，EventBridge 正是通过该能力将钉钉生态接入到阿里云生态。 EventBridge HTTP 事件源 事件源是事件驱动的基石，如何获取更多事件源也是 EventBridge 一直在探索和尝试的方向。针对市场上其他云厂商和垂直领域的 Saas 服务，EventBridge 发布了 HTTP 事件源能力，提供简单且易于集成的三方事件推送 ，帮助客户更加高效、便捷地实现业务上云。 具体而言，HTTP 事件源是 EventBridge 支持的事件源的一种，它以 Webhook 形式暴露了发布事件的 HTTP 请求地址，用户可以在有 URL 回调的场景配置 HTTP  事件源，或者直接使用最简单的 HTTP 客户端来完成事件的发布。HTTP  事件源提供了支持 HTTP 与 HTTPS，公网与阿里云 VPC 等不同请求方式、不同网络环境的 Webhook URL，便于用户将其集成到各类应用中。接入时无需使用客户端，仅需保证应用可以访问到对应 Webhook URL 即可，这使得接入过程变得简单而高效。 在将 HTTP 请求转换为 CloudEvent 的时候，EventBridge 会将请求的头部和消息体部分置于 CloudEvent 字段中，其余字段会依据用户 EventBridge 资源属性以及系统默认规则进行填充。用户可以在事件规则中，对所需的内容进行过滤、提取，最终按照模板拼装成所需的消息内容投递给事件目标。 在安全方面，HTTP 事件源不需要用户进行复杂的签名鉴权，支持 3 种类型开箱即用的安全设置，分别是请求方法、源 IP 以及请求来源域名。 请求方法：用户可以配置当前请求此事件源时合法的 HTTP 请求方法，如果方法类型不满足配置规则，请求将被过滤，不会投递到事件总线。 源 IP：用户可以设置允许访问此事件源时合法的源 IP（支持 IP 段和 IP），当请求源 IP 不在设置的范围内时，请求将被过滤，不会投递到事件总线。 请求来源域名：即 HTTP 请求的 referer 字段，当请求的 referer 与用户配置不相符时，请求被过滤，不会投递到事件总线。 应用场景 钉钉连接器市场有数百款连接器，包含官方连接器和第三方生态连接器。 官方连接器，来源主要是钉钉官方的应用，比如视频会议、日程、通讯录、审批流、钉盘、宜搭等，企业和 SaaS 厂商可以充分利用这些官方应用的事件构建企业级的应用系统，也可以将钉钉的官方数据流与其他系统做深度集成。 第三方连接器，来源主要是钉钉的生态合作伙伴，比如金蝶、行翼云、集简云、用友、易快报、销帮帮等。SaaS 厂商可以通过开放连接器来开放数据，与其它应用互联互通。 如上图所示，借助钉钉连接器，可以将钉钉官方事件源和钉钉 SaaS 事件源连接到阿里云 EventBridge，从而能驱动云上的弹性资源。SaaS 厂商能够借助 EventBridge 连接的能力快速构建云原生的 SaaS 应用，借助云的弹性能力，采用云原生最新的技术栈，快速高效地开发 SaaS 应用，同时利用 EventBridge 获取钉钉和其它 SaaS 应用的数据源，轻松进行业务创新。 当钉钉生态和 EventBridge 联通后，能产生哪些应用场景呢？ 分析场景：企业借助 EventBridge 事件分析能力，对钉钉官方事件进行分析，快速洞察企业运转数据。比如审批效率，员工变更趋势、会议效率等。 通知场景：钉钉连接器 + EventBridge  可覆盖绝大多数消息通知场景，帮助企业用户快速感知 审批，员工变动，会议室信息等一些列企业基础支持系统。 集成场景：基于阿里云基础建设，可快速提升钉钉生态和企业内部数据的互通。例如当公司需要对钉钉和企业内部 IT 系统进行数据打通时，EventBridge 解决方案可以毫不费力地将建立在阿里云体系的 IT 系统连通起来，比如函数计算，云数据库，消息队列等连接扩展阿里云生态。 EDA 场景：使用 EventBridge 快速构建 EDA 驱动的自动化业务流程。例如在新员工入职时，获取员工变动信息。并集中推送到邮箱系统，业务支持系统（DB），CRM 系统等。对企业新员工权限账户进行一站式授权，较少重复机械的业务审批流程。 最佳实践：新增员工 0 代码入库 本章节介绍使用钉钉连接器和 EventBridge 的最佳实践，通过一个例子展示如何 0 代码将钉钉的一个新员工入职记录录入到自定义的数据库当中，企业可以根据该数据库搭建各类员工管理系统。 方案简介 整个方案涉及到钉钉、钉钉连接器、EventBridge、阿里云数据库等产品，整个链路如下图所示： 前置条件： 拥有一个钉钉账号，并创建一个团队成为管理员，并能登陆钉钉开放平台。 拥有一个阿里云账号，并开通 EventBridge 和阿里云数据库。 实践步骤 整个实践过程分为以下几个步骤。 1）创建事件总线和 HTTP 事件源 首先登陆 EventBridge 控制台，创建一个事件总线和 HTTP 事件源，如下图所示，可以先跳过规则和目标的创建。 创建完成后，进入事件总线的详情列表，获取 HTTP 事件源的公网「Webhook 地址」，如下图所示： 2）创建钉钉连接流 登陆钉钉开放平台，进入连接平台，在「我的连接」下创建连接流，在创建界面，选择触发器为「官方通讯录通讯录用户增加」。 连接流创建完成后，进入编辑页面，添加一个「HTTP Webhook」的节点，在「请求地址」一栏填入上个步骤获取到的「HTTP 事件源」地址。 3）钉钉触发新增员工事件 打开钉钉，进入团队，邀请另一个账号加入团队，然后进入事件总线的「事件追踪」页面，可以发现该员工新增事件已经投递到了事件总线之上。 该事件被转换成了一个「CloudEvents」格式，其「$.data.body」为事件的详情，包含 dingId, userId, department 等字段。 { "datacontenttype": "application/json", "aliyunaccountid": "1148", "data": { "headers": { }, "path": "/webhook/putEvents", "body": { "syncAction": "user_add_org", "orderInDepts": "{1:1762632512}", "dingId": "$::$5RUQhP/pK+4A==", "active": true, "avatar": "", "isAdmin": false, "userId": "141146379", "isHide": false, "isLeaderInDepts": "{1:false}", "isBoss": false, "isSenior": false, "name": "小明", "department": [ 1 ] }, "httpMethod": "POST", "queryString": {} }, "subject": "acs:eventbridge:cnhangzhou::eventbus//eventsource/my.dingtalk", "aliyunoriginalaccountid": "11848", "source": "my.dingtalk", "type": "eventbridge:Events:HTTPEvent", "aliyunpublishtime": "20220513T07:28:29.505Z", "specversion": "1.0", "aliyuneventbusname": "chenyangbus", "id": "7059131cb232c4c3592120ae", "time": "20220513T15:28:29.504+08:00", "aliyunregionid": "cnhangzhou", "aliyunpublishaddr": "..61.88" } 4）数据库创建员工表 通过 RDS 控制台购买一个实例，并创建好数据库，然后根据上述新增员工事件的格式，提取部分字段对数据库进行建表。 CREATE TABLE 'user_info' ( 'dingId' varchar(256) NULL, 'active' varchar(256) NULL, 'isAdmin' varchar(256) NULL, 'userId' varchar(256) NULL, 'name' varchar(256) NULL ) ENGINE=InnoDB DEFAULT CHARACTER SET=utf8; 5）创建事件规则 数据库准备好后，返回 EventBridge 控制台，为第一步创建的事件总线创建事件规则，对「新增员工事件」进行转换并投递至数据库当中。 首先创建规则，过滤第一步创建的 HTTP 事件源。 然后选择 RDS 目标，做好参数映射。 6）触发事件入库 第三步触发事件时，因未配置规则和目标，事件没有被消费，故需要通过钉钉重新触发一次事件，然后从 EventBridge 控制台观察推送轨迹。 从轨迹中可以看出推送成功，然后通过 RDS 控制台可以查询到该条记录。 至此，一个钉钉团队新员工入职的记录通过 0 代码的方式入库到企业数据库当中，可以非常低的成本开发企业级管理应用。 _参考链接：_

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

EvenBridge 集成概述 EventBridge 是阿里云所推出了一款无服务器事件总线，其目标是拓展事件生态，打破系统间的数据孤岛，建立事件集成生态。提供统一的事件标准化接入及管理能力，完善集成与被集成通路，帮助客户快速实现事件驱动的核心原子功能，可将 EventBridge 快速集成至 BPM、RPA、CRM 等系统。 EventBridge 通过事件标准化，接入标准化，组件标准化三个方向作为支点拓展 EventBridge 事件生态： 事件标准化：拥抱 CloudEvents 1.0 开源社区标准协议，原生支持 CloudEvents 社区 SDK 和 API，全面拥抱开源社区事件标准生态； 接入标准化：提供标准事件推送协议 PutEvent，并支持 Pull 和 Push 两种事件接入模型，可有效降低事件接入难度，提供云上完善的事件接入标准化流程； 组件标准化：封装标准的事件下游组件工具链体系，包括 Schema 注册、事件分析、事件检索、事件仪表盘等。提供完善的事件工具链生态。 在集成领域 EventBridge 重点打造事件集成和数据集成两类核心场景，下面将围绕这两类场景具体展开描述。 事件集成 目前 EventBridge 已经拥有 80+ 云产品的事件源，800+ 种事件类型。整个事件生态还正在逐步丰富中。 那么，EventBridge 如何实现云产品的事件集成呢？ 首先在 EventBridge 控制台可以看见一个名为 default 的事件总线，云产品的事件都会投递到这个总线； 然后点击创建规则，就可以选择所关心的云产品以及它的相关事件进行事件的监听和投递。 下面以两个例子为例，来看下 EventBridge 事件集成的方式。 OSS 事件集成 以 OSS 事件源为例，来讲解一下如何集成 OSS 事件。 OSS 事件现在主要分为 4 类，操作审计相关、云监控相关、配置审计相关、以及云产品相关的事件例如 PutObject 上传文件等等。其他的云产品的事件源也类似，基本都可以分为这几个类型的事件。 下面演示一下事件驱动的在线文件解压服务： 在 OSS Bucket 下面会有一个  zip 文件夹存放需要解压的文件，一个 unzip 文件夹存放解压后的文件； 当上传文件到 OSS Bucket 之后，会触发文件上传的事件并投递到 EventBridge 的云服务专用总线； 然后会使用一个事件规则过滤 zip 这个 bucket 的事件并投递到解压服务的 HTTP Endpoint； 解压服务会在收到事件之后，根据事件里面的文件路径从 OSS 下载文件解压，并在解压之后将文件传到 unzip 目录下； 同时，还会有一个事件规则，监听 unzip 目录的文件上传事件，并将事件转换后推送到钉钉群。 一起来看下是如何实现的： 前往下方链接查看视频： 1）首先创建一个 bucket，下面有一个 zip 目录用于存放上传的压缩文件，一个 unzip 目录用于存放解压后的文件。 2) 部署解压服务，并且暴露公网访问的地址。 解压服务的源码地址为： 也可以使用 ASK 直接部署，yaml 文件地址为： 3）创建一个事件规则监听 zip 目录下的上传文件的事件，并投递到解压服务的 HTTP  Endpoint。 这里使用 subject，匹配 zip 目录。 4）再创建一个事件规则监听 unzip 目录的事件，投递解压事件到钉钉群。 这里同样使用 subject，匹配 unzip 目录。 对于变量和模板的配置可以参考官方文档 ： 。 EventBridge 会通过 JSONPath 的方式从事件中提取参数，然后把这些值放到变量中，最后通过模板的定义渲染出最终的输出投递到事件目标。OSS 事件源的事件格式也可以参考官方文档 ： _ _，并根据实际的业务需要使用 JSONPath 定义变量。5）最后，通过 oss 控制台上传一个文件进行验证。 可以看到刚刚上传的 eventbridge.zip 已经解压到并上传上来了，也可以在钉钉群里面，收到解压完成的通知。此外，还可以在事件追踪这边查看事件的内容已经投递的轨迹。 可以看到有两个上传事件：一个是通过控制台上传的事件，一个是解压文件后上传的事件。 可以查看轨迹，都成功投递到了解压服务的 HTTP Endpoint 以及钉钉机器人。 以自定义事件源以及云产品事件目标的方式集成云产品 刚才演示的 demo 是集成云服务的事件源，下面再通过一个 demo 看一下如何通过以自定义事件源以及云产品事件目标的方式集成云产品。 前往下方链接查看视频： 这个 demo 的最终效果是通过 EventBridge 自动进行数据的清洗，并投递到 RDS 中去。事件内容是一个 JSON，拥有两个字段一个名字一个年龄，现在希望将把大于 10 岁的用户过滤出来并存储到 RDS 中。 整体的架构如图所示，使用一个 MNS Queue 作为自定义事件源，并通过 EventBridge 过滤并转换事件最终直接输出到 RDS 中去。 1）首先已经创建好了一个 MNS Queue，创建好一个 RDS 实例以及数据库表，表结构如下所示： 2）创建一个自定事件总线，选择事件提供方为 MNS，队列为提前创建好的队列； 创建好了之后，我们就可以在事件源这里看见一个已经正在运行中的事件源； 3）接下来创建规则投递到 RDS 配置的事件模式内容如下： { "source": [ "my.user" ], "data": { "messageBody": { "age": [ { "numeric": [ "", 10 ] } ] } } } 数值匹配可以参考官方文档：   4) 点击下一步，选择事件目标为数据库，填写数据库信息，配置转化规则，完成创建。 5）最后，先用 MNS Queue 发送一个消息，这个的 age 是大于 10 的。 可以看见这条事件就输出到了 RDS 里面了。 下面再发一个小于 10 的消息到 MNS Queue。 这条事件就被过滤掉了，没有输出到 RDS。 也可通过事件追踪查看事件： 可以看到一条事件成功投递到了 RDS，一条事件被过滤掉了，没有进行投递。 数据集成 事件流是 EventBridge 为数据集成提供的一个更为轻量化、实时的端到端的事件流试的通道，主要目标是将事件在两个端点之间进行数据同步，同时提供过滤和转换的功能。目前已经支持阿里云各消息产品之间的事件流转。 不同于事件总线模型，在事件流中，并不需要事件总线，其 1：1 的模型更加的轻量，直接到目标的方式也让事件更加的实时；通过事件流，我们可以实现不同系统之间的协议转换，数据同步，跨地域备份的能力。 下面将通过一个例子讲解如何使用事件流，将 RocketMQ 的消息路由到 MNS Queue，将两个产品集成起来。 整体的结构如图所示，通过EventBridge 将 RocketMQ 中 TAG 为 MNS 的消息路由到 MNQ Queue。 一起看下怎么实现： 前往下方链接查看视频： 首先创建一个事件流，选择源 RocketMQ 实例，填写 Tag 为 mns。 事件模式内容留空表示匹配所有。 目标选择 MNS，选择目标队列完成创建。 完成创建之后，点击启动，启动事件流任务。 事件流启动完成之后，我们就可以通过控制台或者 SDK 发送消息到源 RocketMQ Topic 里面。当有 Tag 为 mns 的时候，我们可以看见消息路由到了 mns；当有 Tag 不为 mns 的时候，消息就不会路由到 mns。 总结 本篇文章主要向大家分享了通过 EventBridge 如何集成云产品事件源，如何集成云产品事件目标以及通过事件流如何集成消息产品.

引言 事件总线 EventBridge 是阿里云提供的一款无服务器事件总线服务，支持将阿里云服务、自定义应用、SaaS 应用以标准化、中心化的方式接入，并能够以标准化的 CloudEvents 1.0 协议在这些应用之间路由事件，帮助您轻松构建松耦合、分布式的事件驱动架构。事件驱动架构是一种松耦合、分布式的驱动架构，收集到某应用产生的事件后实时对事件采取必要的处理，然后路由至下游系统，无需等待系统响应。使用事件总线 EventBridge 可以构建各种简单或复杂的事件驱动架构，以标准化的 CloudEvents 1.0 协议连接云产品和应用、应用和应用等。 事件目标（Target）负责事件的处理终端与消费事件，是 EventBridge 的核心模块。针对市场上其他云厂商和垂直领域的 DB 服务，EventBridge 发布基于事件目标模块的数据库 Sink，提供简单且易于集成的 DB 落库能力，帮助开发者更加高效、便捷地实现业务上云。 数据库 Sink 概述 数据库 Sink 事件目标是 EventBridge 支持的事件目标的一种，主要能力是通过 EventBridge 将数据投递至指定数据库表中。 得益于 EventBridge 生态体系，数据库 Sink 支持众多接入方式： 阿里云云产品事件，EventBridge 支持云服务总线，通过简单配置即可直接对云服务相关事件进行入库操作； SaaS 应用事件，EventBridge 支持三方 SaaS 事件接入，支持对 SaaS 触发事件落库、查询； 用户自定义应用，用户可以使用 EventBridge 官方的 API 接口、多语言客户端、HTTP Source 以及 CloudEvents 社区的开源客户端来完成接入。 数据库 Sink 能力重点聚焦在如何将 EventBridge 业务的半结构化 Json 数据转为结构化 SQL 语句，提供 LowCode 交互接入，帮助开发者一站式完成数据入库。 数据库 Sink 最佳实践 典型案例： 希望把一些 MNS 的消费消息或者 RocketMQ 的消费消息存储到指定的数据库表中，方便后面的数据分析和消息排查，也可以通过这种方式把数据新增到数据库表中； 通过 HTTP 的事件源把一些重要的日志或者是埋点数据直接存储到 DB 中，不需要经过用户业务系统，可以方便后续的客户场景分析。 使用介绍： 首先现阶段数据库 Sink For MySQL 支持两种方式：一种是基于阿里云的 RDS MySQL（VPC），另一种是用户自建的 MySQL（公网），可根据业务场景选择的不同方式接入。 步骤一 ：点击事件规则并创建事件规则 步骤二 ：选择事件源 可以选择阿里云官方或者自定义事件源 步骤三 ：选择事件目标 1）在事件目标下面的服务类型选择数据库，这时会有两个选项就是一个是阿里云的 RDS MySQL，一个是自建 MySQL； 2）如果是阿里云 RDS MySQL，需要创建服务的关联角色。 3）授权以后就可以选择用户自己创建的 RDS MySQL 数据库的实例 ID 和数据库名称。 数据库账号和密码需手动填写，并发配置可以根据实际业务需要进行填写。因为 RDS MySQL 涉及到了跨地域访问，所以需要专有网络 VPC 的支持。 步骤四 ：入库配置 入库配置支持快速配置与自定义 SQL 两种方式： 1）快速配置，支持 LowCode 方式快速选择入库内容。 2）自定义 SQL，支持自定义高级 SQL 语法。 步骤五：事件发布 当创建成功以后可以通过控制台进行事件发布： 步骤六 ：事件状态追踪和查询 可以通过上个步骤中的事件 ID 可看到轨迹的详细信息，包括事件执行成功与否等信息。如果事件执行失败，会在页面展示异常信息。 通过事件追踪也可以看到详细的事件轨迹 ： 总结 本文重点介绍 EventBridge 的新特性：数据库 Sink 事件目标。 作为一款无服务器事件总线服务，EventBridge 已经将阿里云云产品管控链路数据和消息产品业务数据整合到事件源生态中，提高了上云用户业务集成的便捷性，满足 Open API 与多语言 sdk 的支持，在此基础之上，通过 EventBridge 将数据投递至指定的数据库表中，为客户自身业务接入 EventBridge 提供了便利。 相关链接 [2] RDS 官方文档 [3] 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] 钉钉官方文档

前言：事件总线 EventBridge 产品和 FC (Serverless 函数计算) 产品全面深度集成，意味着函数计算和阿里云生态各产品及业务 SaaS 系统有了统一标准的接入方式；依托 EventBridge 统一标准的事件源接入能力，结合 Serverless 函数计算高效敏捷的开发特点，能够帮助客户基于丰富的事件，结合 EDA 架构快速构建云上业务系统。为了帮助大家更好的理解，今天的介绍主要分为三部分：为什么需要一站式深度集成、FC 和 EventBridge 产品集成功能演示及场景介绍、EventBridge 和函数计算深度集成下一阶段规划。 为什么需要一站式深度集成？ 首先让我们一起来看看什么是 EventBridge，什么是函数计算？ 什么是 EventBridge? 阿里云事件总线（EventBridge）是一种无服务器事件总线，支持将用户的应用程序、第三方软件即服务 (SaaS)数据和阿里云服务的数据通过事件的方式轻松的连接到一起，这里汇聚了来自云产品及 SaaS 服务的丰富事件； 从整个架构来看，EventBridge 通过事件总线，事件规则将事件源和事件目标进行连接。首先，让我们快速普及下 EventBridge 架构中涉及的几个核心概念： 事件：状态变化的记录； 事件源：事件的来源，事件的产生者，产生事件的系统和服务， 事件源生产事件并将其发布到事件总线； 事件总线：负责接收来自事件源的事件；EventBridge支持两种类型的事件总线： 云服务专用事件总线：无需创建且不可修改的内置事件总线，用于接收您的阿里云官方事件源的事件。 自定义事件总线：标准存储态总线，用于接收自定义应用或存量消息数据的事件，一般事件驱动可选该总线。 事件规则：用于过滤，转化事件，帮助更好的投递事件； 事件目标：事件的消费者，负责具体事件的处理。 通过上面的流程，完成了事件的产生，事件的投递，事件的处理整个过程。当然事件并不是一个新的概念，事件驱动架构也不是一个新的概念，事件在我们的系统中无处不在，事件驱动架构同样伴随着整个计算机的架构演进，不断地被讨论。对于 EventBridge，采用云原生事件标准 CloudEvents 来描述事件；带来事件的标准化，这样的标准化和事件标准的开放性带来一个最显著的优势：接入的标准化，无论是对于事件源还是事件目标。 什么是函数计算（FC）？ 函数计算是事件驱动的全托管计算服务。使用函数计算，您无需采购与管理服务器等基础设施，只需编写并上传代码。函数计算为您准备好计算资源，弹性地、可靠地运行任务，并提供日志查询、性能监控和报警等功能。 通过上面的描述，总结起来大家只需要记住几点： 简单易用：快速上线，极大提升业务研发效率； 无服务器运维：节省运维投入； 按需付费：沉稳应对突发流量场景； 事件驱动：云产品互通，快速联动。 为什么函数计算需要 EventBridge? 函数计算以其轻量，快捷，能够利用事件驱动的方式与其他云产品进行联动的特点， 成为很多客户利用事件驱动架构构建业务系统的首选，随着业务及客户需求的不断增加，客户对于函数计算和更多云产品及服务的连接需求变得越来越多，同时对于其他云产品的客户而言， 也希望能够利用Serverless函数计算的特点帮助处理一些系统任务和事件。 1）事件源多样性挑战 事件驱动作为函数计算产品核心竞争力，打通函数计算和其它云产品，以及用户自定义应用，SaaS 服务的连通成为函数计算生态集成的迫切需求，但系统集成，生态建设从来都不是一件容易的事情。函数计算系统在和 EventBridge 集成之前，已经和 OSS，SLS 等用户典型场景的云产品进行了集成，也和阿里云的其它大概十多款产品进行了集成，不同系统具有不同的事件格式，不同系统的注册通知机制也各不相同，以及上游不同系统的失败处理机制也各不相同；部分系统支持同步的调用方式，部分系统支持异步的调用方式，调用方式的差异主要取决于上游系统在接入函数计算的时候当时面临的产品业务场景，对于新的产品能力和业务场景的扩展支持，在当时并未有太多的考虑。随着和更多云产品的集成，集成的投入，集成的困难度和底层数据管理难度越来越大。面对多种事件源集成的客观困难，函数计算希望提高和其他云产品的集成效率。 2）授权复杂及安全隐患 除此之外， 函数计算希望提升用户体验，保证用户关心事件的处理；同时希望能够在面对大量的云产品时保证系统授权层面的复杂度。用户在使用事件触发的时候， 需要了解不同产品接入函数计算的权限要求， 对于客户使用函数计算带来了非常大的困难，为了加速产品接入，大量用户经常使用 FullAcees 权限，造成较大产品安全隐患。 3）通用能力难以沉淀 面对上游不同的事件源， 如何更好的投递事件、更好的消费事件？如何进行事件的错误处理？函数计算调用方式如何选择？以及函数计算后端错误 Backpressure 能力的反馈、重试策略和上游系统参数设置、触发器数量的限制等问题成为函数计算事件触发不得不面对的问题。为了更好的服务客户，提供可靠的消费处理能力，函数计算希望能够有一个统一的接入层，基于统一的接入层进行消费能力和流控能力的建设。通过沉淀在这样一个标准的层面，在保证调用灵活性的同时，提供可靠的服务质量。 为什么 EventBridge 同样需要函数计算？ EventBridge 作为标准的事件中心，目的是希望能够帮助客户把这些事件利用起来，能够通过事件将产品的能力进行联动，为了达成这样的目的，势必需要帮助客户通过更便捷的路径来快速消费处理这些事件。EventBridge 和函数计算的深度集成正是为了这样的共同目标 —— 帮助客户快速的构建基于 EDA 架构的业务系统，促进业务获得成功。 FC 和 EventBridge 产品集成功能演示及场景介绍 EventBridge 具体支持的事件类型， 基本上包括了阿里云所有的官方产品。可以通过 EventBridge 官方主页查看目前支持的阿里云官方产品事件源类型 。 EventBridge 触发器及异步集成 点击下方链接跳转查看： 函数计算异步链路支持将处理结果直接投递到 MQ 和 EventBridge，用户可以利用 EventBridge 将相关的结果投递到 SAAS 服务； 点击下方链接跳转查看： 双向集成的变化 1. 函数计算支持 85+阿里云官方事件源； 2. 函数计算支持整个阿里云消息队列的事件触发，包括 RocketMQ， RabbitMQ，MNS 等； 1. EventBridge 和函数计算控制台数据互通，用户无需在函数计算控制台和事件总线控制台来回跳转； 2. 用户通过触发器详情，快速跳转，利用 EventBridge 事件追踪能力帮助用户快速排查问题； 官方事件源运维场景总结 基于官方事件源的事件驱动场景，大概可以总结抽象成四个场景。 场景一：单账号下某个云产品的运维需求。通常客户希望基于这样的一个事件，包括类似像云服务器事件 ECS，或者容器服务镜像事件，通过这样的事件监听做一些自动化诊断和运维操作。 场景二：实际是在场景一的基础上的一个扩展，针对多个云产品的事件，希望能够进一步分析，做一些故障处理。 场景三：我们观察到，大的一些企业，在使用云产品的时候，实际上是由多个账号去使用阿里云的产品。在多个账号，多个产品的情况下，希望能够对多个账号中的云资源使用情况有一个全局统一的视角进行实践分析，同时进行账号配额的一些调整。那这样的话就是可以利用到 EventBridge 跨账号事件投递的能力，然后再利用函数计算做一个统一处理。 场景四：这个场景实际上是一个账号跨域事件处理场景，EventBridge 目前并没有去提供这样一个跨域的能力，这种情况下，可以借助函数计算提供的 HTTP 函数能力，自动生成 HTTP Endpoint，通过 EventBridge 的 HTTP 事件源，完成事件的跨域消费。 自定义事件源场景总结 1）MNS 队列自定义事件源触发场景：客户在 OSS 中上传文件之后，根据文件上传事件对 ACK 进行扩容，目前通过 OSS 事件发送到 MNS 中，然后由 MNSQueue 消息通过 EventBridge 触发函数计算， 在函数计算中根据一定的逻辑进行 ECI 资源的创建；同时客户希望通过 MNS 进行通知服务；利用 EventBridge 订阅模式，通过事件规则的定义，让通知服务和函数计算共享同一个事件订阅规则，可以大大的简化用户的方案。 2）RabbitMQ 队列自定义事件源触发场景：鉴于 RabbitMQ 在稳定性和可靠性方面的表现，在 IOT 场景具有非常普遍的使用，客户通常会选择使用 RabbitMQ 来进行端设备数据采集和存储， 考虑到 IOT 相关的嵌入式设备性能使用环境，通常端设备采集的数据比较偏向底层裸数据，在实际业务层面，客户需要找到一种快速高效的途径对 RabbitMQ 中的数据进行加工，通过 EventBridge 提供的自定义事件总线，利用函数计算对 RabbitMQ 中的数据快速处理， 实现 ETL 目的。 EventBridge 和函数计算深度集成下一阶段规划 事件过滤高级 ETL 处理 将函数计算和 EventBridge 进行更紧密的集成，由函数计算提供一些高级的 ETL 能力，提升整个事件过滤转换的能力。 提供更丰富的事件目标 目前 EventBridge 整个下游的事件目标相对来说较少，我们希望能够通过函数计算和 EventBridge 的一个密切集成，利用函数计算敏捷的开发能力，分别通过大账号模式和用户自持的这样一个能力，构建一些更丰富的 EventBridge 下游事件目标，帮助丰富整个事件目标的生态。

阿里云消息队列 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：协议绑定，描述如何通过给定的协议收发事件，如何将事件放到消息里。