前言：事件总线 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 下游事件目标，帮助丰富整个事件目标的生态。 活动推荐 阿里云基于 Apache RocketMQ 构建的企业级产品消息队列RocketMQ 5.0版现开启活动： 1、新用户首次购买包年包月，即可享受全系列 85折优惠！ 了解活动详情：

引言 事件驱动架构（EDA）是一种以事件为纽带，将不同系统进行解耦的异步架构设计模型。在 EDA 中，事件驱动的运行流程天然地划分了各个系统的业务语义，用户可以根据需求对事件与针对此事件做出的响应灵活定制，这使得基于 EDA 架构可以方便地构建出高伸缩性的应用。据 Daitan Group 的调研报告，早在 2017 年，例如 UBER、Deliveroo、Monzo 等公司就已经采用了 EDA 去设计他们的系统。 为了便于用户更加轻松地开发以 EDA 为架构的应用，在 2020 年云栖大会上，阿里云正式推出了 EventBridge。EventBridge 是一款无服务器事件总线服务，能够以标准化的 CloudEvents 1.0 协议在应用之间路由事件。目前，EventBridge 已经集成了众多成熟的阿里云产品，用户可以低代码甚至零代码完成各个阿里云产品和应用之间的打通，轻松高效地构建分布式事件驱动架构。 事件源是事件驱动的基石，如何获取更多事件源也是 EventBridge 一直在探索和尝试的方向。针对市场上其他云厂商和垂直领域的 Saas 服务，EventBridge 发布了 HTTP Source 能力，提供简单且易于集成的三方事件推送 ，帮助客户更加高效、便捷地实现业务上云。 HTTP Source 概述 接入 EventBridge 应用有多种情况：用户自定义应用、阿里云服务、其他云厂商服务或者其他 SaaS 产品。 对于用户自定义应用，用户可以使用 EventBridge 官方的 API 接口、多语言客户端以及 CloudEvents 社区的开源客户端来完成接入。 对于阿里云的云产品，EventBridge 原生支持，用户可以在默认事件总线中选择对应的云产品与其相关的触发事件。 而对于其他云厂商、SaaS 产品，EventBridge 同样也提供便捷的接入方式便于用户进行集成，HTTP Source 事件源便是一种典型的接入方式。 具体而言，HTTP Source 事件源是 EventBridge 支持的事件源的一种，它以 Webhook 形式暴露了发布事件的 HTTP 请求地址，用户可以在有 URL 回调的场景配置 HTTP Source 事件源，或者直接使用最简单的 HTTP 客户端来完成事件的发布。HTTP Source 事件源提供了支持 HTTP 与 HTTPS，公网与阿里云 VPC 等不同请求方式、不同网络环境的 Webhook URL，便于用户将其集成到各类应用中。接入时无需使用客户端，仅需保证应用可以访问到对应 Webhook URL 即可，这使得接入过程变得简单而高效。 在将 HTTP 请求转换为 CloudEvent 的时候，EventBridge 会将请求的头部和消息体部分置于 CloudEvent 字段中，其余字段会依据用户 EventBridge 资源属性以及系统默认规则进行填充。用户可以在事件规则中，对所需的内容进行过滤、提取，最终按照模板拼装成所需的消息内容投递给事件目标。 HTTP Source 事件源目前支持 3 种类型的安全设置，分别是请求方法、源 IP 以及请求来源域名。 请求方法：用户可以配置当前请求此事件源时合法的 HTTP 请求方法，如果方法类型不满足配置规则，请求将被过滤，不会投递到事件总线。 源 IP：用户可以设置允许访问此事件源时合法的源 IP（支持 IP 段和 IP），当请求源 IP 不在设置的范围内时，请求将被过滤，不会投递到事件总线。 请求来源域名：即 HTTP 请求的 referer 字段，当请求的 referer 与用户配置不相符时，请求被过滤，不会投递到事件总线。 抛砖引玉，下面就介绍如何使用 HTTP Source 来构建 SaaS 应用集成的最佳实践，帮助大家快速上手 SaaS 集成方案。 SaaS 集成最佳实践 钉钉监控 GitHub 代码推送事件 GitHub 提供了 Webhook 功能，代码仓库在发生某些特定操作（push、fork等）时，可以通过回调来帮助用户完成特定功能。针对多人开发的项目，将 GitHub 事件推送到特定钉钉群可以帮助成员有效关注代码变更，提高协同效率。 本节我们展示如何通过钉钉监控 GitHub 代码推送事件的最佳实践，主要包含以下几个步骤： 创建一个钉钉机器人； 创建 EventBridge 相关资源：事件总线、事件源（HTTP Source 类型）、事件规则、事件目标（钉钉）； 创建自定义事件总线； 选择 GitHub 代码仓库创建 Webhook； 向 GitHub 代码仓库推送代码变更； 钉钉群接收此次代码推送相关信息。 1）创建钉钉机器人 参考钉钉官方文档[1]，创建一个群机器人。创建群机器人时，安全设置请勾选“加签”并妥善保管密钥和稍后生成的机器人 Webhook 地址。 2）创建 EventBridge 相关资源 创建 EventBus 事件总线 创建事件源。事件源配置完成之后，点击跳过，我们接下来会专门配置事件规则与目标。 创建完成后，进入事件源详情页，保存刚刚生成的 Webhook URL。 在 EventBridge 控制台页面点击进入刚刚创建的 EventBus 详情页，在左侧一栏中“事件规则”选择“创建规则”。 创建时间目标。选择钉钉，并将钉钉机器人的 Webhook 地址和密钥填入，推送内容侧可以按照需求设计。 我们填写模板变量为： {"repo":"$.data.body.repository.full_name","branch":"$.data.body.ref","pusher":"$.data.body.pusher.name"} 模板为： {"msgtype": "text","text": {"content": "Github push event is triggered. repository: {repo}, git reference: {branch}, pusher: {pusher}." } } 3）在 GitHub 代码仓库创建 Webhook 登陆 GitHub，在 GitHub 代码仓库“setting”中选择左侧“Webhooks”，选择新建 Webhook。 在创建 Webhook 的配置项中填入 HTTP Source 事件源的 Webhook 地址，Content type 部分选择“application/json”，下方触发事件类型选择“Just the push event.”，随后点击“Add Webhook”，创建完成。 4）向 GitHub 代码仓库推送代码变更 本地仓库做一定变更，commit 后推送 GitHub。 5）钉钉群接收此次代码推送相关信息 _异步消费监控报警信息_ 业务上存在异步消费报警信息的场景，例如报警内容备份，根据报警频率自适应调整报警阈值等。而且对于多云业务的用户，如何将跨云服务的报警信息整合起来也是一个麻烦的问题。依托 HTTP Source，用户可以将不同云厂商（腾讯云、华为云等）、不同监控产品（Grafana、Zabbix、Nagios等）统一集成到 EventBridge 平台，以便于实现对报警信息的异步消费。 本节我们介绍如何使用 EventBridge 集成 Grafana，实现异步消费监控报警信息。Grafana 是一款开源数据可视化工具，也同时具有监控报警功能，具体使用可以参阅Grafana 官方文档[2]。本节主要包含以下步骤： 创建 MNS 队列； 创建 EventBridge 相关资源； Grafana 上配置 Webhook； 测试接收结果。 创建 MNS 队列 在 MNS 控制台，选择“队列列表创建队列”。 创建 EventBridge 相关资源 同上文所述，这里仅示例创建事件目标时相关配置。 Grafana 上配置 Webhook 点击 Grafana 控制台左侧“AlertingNotification channels”，选择“Add channel”。 在“type”一栏中选择“Webhook”，url 填写 HTTP Source 事件源的 Webhook 地址，点击下方“Test”。 测试接收结果 登陆 MNS 控制台，进入队列详情页，点击页面右上角“收发消息”，可以看到 MNS 已经接收到刚刚 Grafana 发送的消息。 点击对应消息详情可以看到消息内容，说明消息已经被成功消费。 _更多集成_ HTTP Source 支持的三方集成包括 Prometheus，Zabbix，Skywalking，Grafana，OpenFalcon，Cacti，Nagios，Dynatrace，Salesforce，Shopify，Gitee 等 SaaS 应用。通过简单配置 Webhook 无需开发既可实现事件接收能力。 _总结_ 本文重点介绍 EventBridge 的新特性：HTTP Source 事件源。作为一款无服务器事件总线服务，EventBridge 已经将阿里云云产品管控链路数据、消息产品业务数据整和到事件源生态中，提高了上云用户业务集成的便捷性，Open API 与多语言 sdk 的支持，为客户自身业务接入 EventBridge 提供了便利。 在此基础之上，HTTP Source 事件源更进一步，以 Webhook 形式开放了针对了其他云厂商、SaaS 应用的集成能力，无需代码改动，仅需要简单配置即可完成 EventBridge 集成操作。 _相关链接_ 活动推荐 阿里云基于 Apache RocketMQ 构建的企业级产品消息队列RocketMQ 5.0版现开启活动： 1、新用户首次购买包年包月，即可享受全系列 85折优惠！ 了解活动详情：

企业数字化转型过程中，天然会遇到消息路由，异地多活，协议适配，消息备份等场景。本篇主要通过 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] 事件流控制台 活动推荐 阿里云基于 Apache RocketMQ 构建的企业级产品消息队列RocketMQ 5.0版现开启活动： 1、新用户首次购买包年包月，即可享受全系列 85折优惠！ 了解活动详情：

本文目录 背景知识 大数据时代的构架演进 RocketMQ Connector&Stream Apache Hudi 构建Lakehouse实操 本文标题包含三个关键词：Lakehouse、RocketMQ、Hudi。我们先从整体Lakehouse架构入手，随后逐步分析架构产生的原因、架构组件特点以及构建Lakehouse架构的实操部分。 背景知识 1、Lakehouse架构 Lakehouse最初由Databrick提出，并对Lakehouse架构特征有如下要求： （1）事务支持 企业内部许多数据管道通常会并发读写数据。对ACID事务的支持确保了多方并发读写数据时的一致性问题； （2）Schema enforcement and governance Lakehouse应该有一种方式可以支持模式执行和演进、支持DW schema的范式（如星星或雪花模型），能够对数据完整性进行推理，并且具有健壮的治理和审计机制； （3）开放性 使用的存储格式是开放式和标准化的（如parquet），并且为各类工具和引擎，包括机器学习和Python/R库，提供API，以便它们可以直接有效地访问数据； （4）BI支持 Lakehouse可以直接在源数据上使用BI工具。这样可以提高数据新鲜度、减少延迟，并且降低了在数据池和数据仓库中操作两个数据副本的成本； （5）存储与计算分离 在实践中，这意味着存储和计算使用单独的集群，因此这些系统能够扩展到支持更大的用户并发和数据量。一些现代数仓也具有此属性； （6）支持从非结构化数据到结构化数据的多种数据类型 Lakehouse可用于存储、优化、分析和访问许多数据应用所需的包括image、video、audio、text以及半结构化数据； （7）支持各种工作负载 包括数据科学、机器学习以及SQL和分析。可能需要多种工具来支持这些工作负载，但它们底层都依赖同一数据存储库； （8）端到端流 实时报表是许多企业中的标准应用。对流的支持消除了需要构建单独系统来专门用于服务实时数据应用的需求。 从上述对Lakehouse架构的特点描述我们可以看出，针对单一功能，我们可以利用某些开源产品组合构建出一套解决方案。但对于全部功能的支持，目前好像没有一个通用的解决方案。接下来，我们先了解大数据时代主流的数据处理架构是怎样的。 大数据时代的架构演进 1、大数据时代的开源产品 大数据时代的开源产品种类繁多，消息领域的RocketMQ、Kafka；计算领域的flink、spark、storm；存储领域的HDFS、Hbase、Redis、ElasticSearch、Hudi、DeltaLake等等。 为什么会产生这么多开源产品呢？首先在大数据时代数据量越来越大，而且每个业务的需求也各不相同，因此就产生出各种类型的产品供架构师选择，用于支持各类场景。然而众多的品类产品也给架构师们带来一些困扰，比如选型困难、试错成本高、学习成本高、架构复杂等等。 2、当前主流的多层架构 大数据领域的处理处理场景包含数据分析、BI、科学计算、机器学习、指标监控等场景，针对不同场景，业务方会根据业务特点选择不同的计算引擎和存储引擎；例如交易指标可以采用binlog + CDC+ RocketMQ + Flink + Hbase + ELK组合，用于BI和Metric可视化。 （1）多层架构的优点：支持广泛的业务场景； （2）多层架构的缺点： 处理链路长，延迟高； 数据副本多，成本翻倍； 学习成本高； 造成多层架构缺点主要原因是存储链路和计算链路太长。 我们真的需要如此多的解决方案来支持广泛的业务场景吗？Lakehouse架构是否可以统一解决方案？ 多层架构的存储层是否可以合并？Hudi产品是否能够支持多种存储需求？ 多层架构的计算层是否可以合并？RocketMQ stream是否能够融合消息层和计算层？ 当前主流的多层架构 3、Lakehouse架构产生 Lakehouse架构是多层架构的升级版本，将存储层复杂度继续降低到一层。再进一步压缩计算层，将消息层和计算层融合，RocketMQ stream充当计算的角色。我们得到如下图所示的新架构。新架构中，消息出入口通过RocketMQ connector实现，消息计算层由RocketMQ stream实现，在RocketMQ内部完成消息计算中间态的流转；计算结果通过RocketMQHudiconnector收口落库Hudi，Hudi支持多种索引，并提供统一的API输出给不同产品。 Lakehouse架构 下面我们分析下该架构的特点。 （1）Lakehouse架构的优点： 链路更短，更适合实时场景，数据新鲜感高； 成本可控，降低了存储成本； 学习成本低，对程序员友好； 运维复杂度大幅降低； （2）Lakehouse架构的缺点 对消息产品和数据湖产品的稳定性、易用性等要求高，同时消息产品需要支持计算场景，数据湖产品需要提供强大的索引功能。 （3）选择 在Lakehouse架构中我们选择消息产品RocketMQ和数据湖产品Hudi。 同时，可以利用RocketMQ stream在RocketMQ集群上将计算层放在其中集成，这样就将计算层降低到一层，能够满足绝大部分中小型大数据处理场景。 接下来我们逐步分析RocketMQ和Hudi两款产品的特点。 RocketMQ Connector & Stream RocketMQ 发展历程图 RocketMQ从2017年开始进入Apache孵化，2018年RocketMQ 4.0发布完成云原生化，2021年RocketMQ 5.0发布全面融合消息、事件、流。 1、业务消息领域首选 RocketMQ作为一款“让人睡得着觉的消息产品”成为业务消息领域的首选，这主要源于产品的以下特点： （1）金融级高可靠 经历了阿里巴巴双十一的洪峰检验； （2）极简架构 如下图所示， RocketMQ的架构主要包含两部分包括：源数据集群NameServer Cluster和计算存储集群Broker Cluster。 RocketMQ 构架图 NameServer节点无状态，可以非常简单的进行横向扩容。Broker节点采用主备方式保证数据高可靠性，支持一主多备的场景，配置灵活。 搭建方式：只需要简单的代码就可以搭建RocketMQ集群： Jar： nohup sh bin/mqnamesrv & nohup sh bin/mqbroker n localhost:9876 & On K8S： kubectl apply f example/rocketmq_cluster.yaml （3）极低运维成本 RocketMQ的运维成本很低，提供了很好的CLI工具MQAdmin，MQAdmin提供了丰富的命令支持，覆盖集群健康状态检查、集群进出流量管控等多个方面。例如，mqadmin clusterList一条命令可以获取到当前集群全部节点状态（生产消费流量、延迟、排队长度、磁盘水位等）；mqadmin updateBrokerConfig命令可以实时设置broker节点或topic的可读可写状态，从而可以动态摘除临时不可用节点，达到生产消费的流量迁移效果。 （4）丰富的消息类型 RocketMQ支持的消息类型包括：普通消息、事务消息、延迟消息、定时消息、顺序消息等。能够轻松支持大数据场景和业务场景。 （5）高吞吐、低延迟 压测场景主备同步复制模式，每台Broker节点都可以将磁盘利用率打满，同时可以将p99延迟控制在毫秒级别。 2、RocketMQ 5.0概况 RocketMQ 5.0是生于云、长于云的云原生消息、事件、流超融合平台，它具有以下特点： （1）轻量级SDK 全面支持云原生通信标准 gRPC 协议； 无状态 Pop 消费模式，多语言友好，易集成； （2）极简架构 无外部依赖，降低运维负担； 节点间松散耦合，任意服务节点可随时迁移； （3）可分可合的存储计算分离 Broker 升级为真正的无状态服务节点，无 binding； Broker 和 Store节点分离部署、独立扩缩； 多协议标准支持，无厂商锁定； 可分可合，适应多种业务场景，降低运维负担； 如下图所示，计算集群（Broker）主要包括抽象模型和相对应的协议适配，以及消费能力和治理能力。存储集群（Store）主要分为消息存储CommitLog（多类型消息存储、多模态存储）和索引存储Index（多元索引）两部分，如果可以充分发挥云上存储的能力，将CommitLog和Index配置在云端的文件系统就可以天然的实现存储和计算分离。 （4）多模存储支持 满足不同基础场景下的高可用诉求； 充分利用云上基础设施，降低成本； （5）云原生基础设施： 可观测性能力云原生化，OpenTelemetry 标准化； Kubernetes 一键式部署扩容交付。 RocketMQ 5.02021年度大事件及未来规划 3、RocketMQConnector a、传统数据流 （1）传统数据流的弊端 生产者消费者代码需要自己实现，成本高； 数据同步的任务没有统一管理； 重复开发，代码质量参差不齐； （2）解决方案：RocketMQ Connector 合作共建，复用数据同步任务代码； 统一的管理调度，提高资源利用率； b、RocketMQ Connector数据同步流程 相比传统数据流，RocketMQ connector数据流的不同在于将 source 和 sink 进行统一管理，同时它开放源码，社区也很活跃。 4、RocketMQ Connector架构 如上图所示，RocketMQ Connector架构主要包含Runtime和Worker两部分，另外还有生态Source&Sink。 （1）标准：OpenMessaging （2）生态：支持ActiveMQ、Cassandra、ES、JDBC、JMS、MongoDB、Kafka、RabbitMQ、Mysql、Flume、Hbase、Redis等大数据领域的大部分产品； （3）组件：Manager统一管理调度，如果有多个任务可以将所有任务统一进行负载均衡，均匀的分配到不同Worker上，同时Worker可以进行横向扩容。 5、RocketMQ Stream RocketMQ Stream是一款将计算层压缩到一层的产品。它支持一些常见的算子如window、join、维表，兼容Flink SQL、UDF/UDAF/UDTF。 Apache Hudi Hudi 是一个流式数据湖平台，支持对海量数据快速更新。内置表格式，支持事务的存储层、一系列表服务、数据服务（开箱即用的摄取工具）以及完善的运维监控工具。Hudi 可以将存储卸载到阿里云上的 OSS、AWS 的S3这些存储上。 Hudi的特性包括： 事务性写入，MVCC/OCC并发控制； 对记录级别的更新、删除的原生支持； 面向查询优化：小文件自动管理，针对增量拉取优化的设计，自动压缩、聚类以优化文件布局； Apache Hudi是一套完整的数据湖平台。它的特点有： 各模块紧密集成，自我管理； 使用 Spark、Flink、Java 写入； 使用 Spark、Flink、Hive、Presto、Trino、Impala、 AWS Athena/Redshift等进行查询； 进行数据操作的开箱即用工具/服务。 Apache Hudi主要针对以下三类场景进行优化： 1、流式处理栈 (1) 增量处理； (2) 快速、高效； (3) 面向行； (4) 未优化扫描； 2、批处理栈 (1) 批量处理； (2) 低效； (3) 扫描、列存格式； 3、增量处理栈 (1) 增量处理； (2) 快速、高效； (3) 扫描、列存格式。 构建 Lakehouse 实操 该部分只介绍主流程和实操配置项，本机搭建的实操细节可以参考附录部分。 1、准备工作 RocketMQ version：4.9.0 rocketmqconnecthudi version：0.0.1SNAPSHOT Hudi version：0.8.0 2、构建RocketMQHudiconnector (1) 下载： _  git clone _ (2) 配置： /data/lakehouse/rocketmqexternals/rocketmqconnect/rocketmqconnectruntime/target/distribution/conf/connect.conf 中connectorplugin 路径 (3) 编译： cd rocketmqexternals/rocketmqconnecthudi mvn clean install DskipTest U rocketmqconnecthudi0.0.1SNAPSHOTjarwithdependencies.jar就是我们需要使用的rocketmqhudiconnector 3、运行 (1) 启动或使用现有的RocketMQ集群，并初始化元数据Topic： connectorclustertopic （集群信息） connectorconfigtopic （配置信息） connectoroffsettopic （sink消费进度） connectorpositiontopic （source数据处理进度 并且为了保证消息有序，每个topic可以只建一个queue） (2) 启动RocketMQ connector运行时 cd /data/lakehouse/rocketmqexternals/rocketmqconnect/rocketmqconnectruntime sh ./run_worker.sh Worker可以启动多个 (3) 配置并启动RocketMQhudiconnector任务 请求RocketMQ connector runtime创建任务 curl http://{runtimeip}:{runtimeport}/connectors/{rocketmqhudisinkconnectorname} ?config='{"connectorclass":"org.apache.rocketmq.connect.hudi.connector.HudiSinkConnector","topicNames":"topicc","tablePath":"file:///tmp/hudi_connector_test","tableName":"hudi_connector_test_table","insertShuffleParallelism":"2","upsertShuffleParallelism":"2","deleteParallelism":"2","sourcerecordconverter":"org.apache.rocketmq.connect.runtime.converter.RocketMQConverter","sourcerocketmq":"127.0.0.1:9876","srccluster":"DefaultCluster","refreshinterval":"10000","schemaPath":"/data/lakehouse/config/user.avsc"\}’ 启动成功会打印如下日志： 20210906 16:23:14 INFO pool2thread1 Open HoodieJavaWriteClient successfully (4) 此时向source topic生产的数据会自动写入到1Hudi对应的table中，可以通过Hudi的api进行查询。 4、配置解析 (1) RocketMQ connector需要配置RocketMQ集群信息和connector插件位置，包含：connect工作节点id标识workerid、connect服务命令接收端口httpPort、rocketmq集群namesrvAddr、connect本地配置储存目录storePathRootDir、connector插件目录pluginPaths 。 RocketMQ connector配置表 (2) Hudi任务需要配置Hudi表路径tablePath和表名称tableName，以及Hudi使用的Schema文件。 Hudi任务配置表 _点击__即可查看Lakehouse构建实操视频_ 附录：在本地Mac系统构建Lakehouse demo 涉及到的组件：rocketmq、rocketmqconnectorruntime、rocketmqconnecthudi、hudi、hdfs、avro、sparkshell0、启动hdfs 下载hadoop包 cd /Users/osgoo/Documents/hadoop2.10.1 vi coresite.xml fs.defaultFS hdfs://localhost:9000 vi hdfssite.xml dfs.replication 1 ./bin/hdfs namenode format ./sbin/startdfs.sh jps 看下namenode,datanode lsof i:9000 ./bin/hdfs dfs mkdir p /Users/osgoo/Downloads 1、启动rocketmq集群，创建rocketmqconnector内置topic QickStart：https://rocketmq.apache.org/docs/quickstart/ sh mqadmin updatetopic t connectorclustertopic n localhost:9876 c DefaultCluster sh mqadmin updatetopic t connectorconfigtopic n localhost:9876 c DefaultCluster sh mqadmin updatetopic t connectoroffsettopic n localhost:9876 c DefaultCluster sh mqadmin updatetopic t connectorpositiontopic n localhost:9876 c DefaultCluster 2、创建数据入湖的源端topic，testhudi1 sh mqadmin updatetopic t testhudi1 n localhost:9876 c DefaultCluster 3、编译rocketmqconnecthudi0.0.1SNAPSHOTjarwithdependencies.jar cd rocketmqconnecthudi mvn clean install DskipTest U 4、启动rocketmqconnector runtime 配置connect.conf workerId=DEFAULT_WORKER_1 storePathRootDir=/Users/osgoo/Downloads/storeRoot Http port for user to access REST API httpPort=8082 Rocketmq namesrvAddr namesrvAddr=localhost:9876 Source or sink connector jar file dir,The default value is rocketmqconnectsample pluginPaths=/Users/osgoo/Downloads/connectorplugins 拷贝 rocketmqhudiconnector.jar 到 pluginPaths=/Users/osgoo/Downloads/connectorplugins sh run_worker.sh 5、配置入湖config curl http://localhost:8082/connectors/rocketmqconnecthudi?config='\{"connectorclass":"org.apache.rocketmq.connect.hudi.connector.HudiSinkConnector","topicNames":"testhudi1","tablePath":"hdfs://localhost:9000/Users/osgoo/Documents/basepath7","tableName":"t7","insertShuffleParallelism":"2","upsertShuffleParallelism":"2","deleteParallelism":"2","sourcerecordconverter":"org.apache.rocketmq.connect.runtime.converter.RocketMQConverter","sourcerocketmq":"127.0.0.1:9876","sourcecluster":"DefaultCluster","refreshinterval":"10000","schemaPath":"/Users/osgoo/Downloads/user.avsc"\}' 6、发送消息到testhudi1 7、 利用spark读取 cd /Users/osgoo/Downloads/spark3.1.2binhadoop3.2/bin ./sparkshell \ packages org.apache.hudi:hudispark3bundle_2.12:0.9.0,org.apache.spark:sparkavro_2.12:3.0.1 \ conf 'spark.serializer=org.apache.spark.serializer.KryoSerializer' import org.apache.hudi.QuickstartUtils._ import scala.collection.JavaConversions._ import org.apache.spark.sql.SaveMode._ import org.apache.hudi.DataSourceReadOptions._ import org.apache.hudi.DataSourceWriteOptions._ import org.apache.hudi.config.HoodieWriteConfig._ val tableName = "t7" val basePath = "hdfs://localhost:9000/Users/osgoo/Documents/basepath7" val tripsSnapshotDF = spark. read. format("hudi"). load(basePath + "/") tripsSnapshotDF.createOrReplaceTempView("hudi_trips_snapshot") spark.sql("select from hudi_trips_snapshot").show() 活动推荐 阿里云基于 Apache RocketMQ 构建的企业级产品消息队列RocketMQ 5.0版现开启活动： 1、新用户首次购买包年包月，即可享受全系列 85折优惠！ 了解活动详情：

对于日志分析大家可能并不陌生，在分布式计算、大数据处理和 Spark 等开源分析框架的支持下，每天可以对潜在的数百万日志进行分析。 事件分析则和日志分析是两个完全不同的领域，事件分析对实时性的要求更高，需要磨平事件领域中从半结构化到结构化的消息转换管道，实现查询检索，可视化等功能。但是目前针对流式的事件做分析的可用工具非常少，这对于期望使用Serverless架构或 EDA（事件驱动）架构的开发者会非常不便。（更多 EDA 架构介绍参考 ：） 基于事件的特征，无法追溯事件内容，无法跟踪事件流转，无法对事件做可视化分析成为了事件驱动架构演进的绊脚石。为了解决事件领域中针对流式事件做分析的难题，EventBridge 近日发布了针对事件/消息领域的全新分析工具EventBridge 实时事件分析平台。下面简要对 EventBridge 实时事件分析平台的内容进行介绍。 EventBridge 实时事件分析平台简介_ EventBridge 实时事件分析平台依托基于事件的实时处理引擎，提供数值检索、可视化分析、多组态分析、事件轨迹、事件溯源和 Schema 管理等能力。EventBridge 实时事件分析平台具有无入侵、无需数据上报，低成本，操作快捷等特点，通过简单的引导式交互，即可快速实现基于事件的流式查询与分析。 EventBridge 实时事件分析平台依托基于事件的实时处理引擎，提供数值检索，可视化分析，多组态分析，事件轨迹，事件溯源，Schema 管理等能力。EventBridge 实时事件具有无入侵，无需数据上报，低成本，操作快捷等特点，通过简单的引导式交互，即可快速实现基于事件的流式查询与分析。 核心功能 多场景支持 目前市面上比较流行的是事件查询平台，但是分析和查询还是有些本质区别，分析基于查询，但是查询并不是分析的全部。 EventBridge 构建了一套完整的事件工具链，帮助开发，运维，甚至运营团队更高效的使用分析工具，统一在一个分析平台上无缝整合全部事件，提供高效、可靠、通用的事件分析能力。 Serverless 领域：得益于 Serverless 架构的推广，事件驱动被更多用在企业核心链路。无服务器的定义是不必管理任何基础设施，但是无服务器的不透明且难以调试却是整个架构必需解决的痛点，当我们配置完触发器后不会知道什么数据在什么时刻触发了函数，触发链路是否异常。EventBridge 事件分析能力将彻底解决 Serverless触发数据黑箱的问题，让所有事件触发都清晰可见。 微服务领域：微服务在现代开发架构中比较常见，该架构由小型、松耦合、可独立部署的服务集合而成，这导致微服务架构很难调试，系统中某一部分的小故障可能会导致大规模服务崩溃。很多时候不得不跳过某些正常服务来调试单个请求。EventBridge 事件分析可将全部链路微服务消息通过事件 ID 染色做有效追踪与排障，帮助微服务做可视化排障。 消息领域：在传统消息领域，消息 Schema 管理、消息内容检索一直是无法解决的难题，大部分情况下需要增加订阅者来对消息做离线分析。EventBridge 事件分析平台提供消息 Schema 管理与消息内容查询能力，为消息可视化提供更完全的解决方案。 云产品领域：云产品在极大程度降低了企业对基础设施建设的复杂性，但同样带来了诸多问题，以 ECS 为例，很多情况会因系统错误或云盘性能受损而触发故障类事件，这类事件通常会涉及到周边产品（比如 ACK 等），捕获全部云上事件做基础排障的挑战性比较大。EventBridge 支持全部云服务事件无缝接入，更大程度降低由云产品变更导致的运维故障。 EventBridge 提供更高效、通用的事件分析平台，基于该平台可以解决大部分场景对事件分析、事件查询、事件轨迹的诉求。 开箱即用 支持提供 Schema 管理，数值检索，可视化分析，多组态分析，事件轨迹，事件溯源等核心能力，无需额外部署，即开即用。 数值检索：提供基础数值检索能力，支持键入 key，value ，= ，!= , exists ，AND，OR 等参数，满足事件检索场景的基本诉求。 可视化分析：提供 GROUP BY，ORDER BY 等可视化分析能力，支持多组态，多图表，多维度分析能力。 链路追踪：提供事件轨迹能力，还原事件整体链路状态。帮助开发者快速排障，快速定位链路问题。 低成本接入 EventBridge 支持以事件总线（EventBus）形式接入，分为云服务事件总线和自定义事件总线。云服务总线支持几乎全部阿里云产品事件，无缝支持云服务事件接入事件分析平台；自定义事件总线支持 RocketMQ、Kafka 或其他自定义事件接入（当前版本仅支持少量云服务事件）。 整体接入流程较为简单，对原有业务入侵小，可随时关闭或开启事件分析，同时实现在线配置，且具备实时生效功能。 总结_ EventBridge 提供更便捷高效的事件分析工具，可以帮助开发人员简单定义查询条件，及时进行可视化的事件内容分析。 活动推荐 阿里云基于 Apache RocketMQ 构建的企业级产品消息队列RocketMQ 5.0版现开启活动： 1、新用户首次购买包年包月，即可享受全系列 85折优惠！ 了解活动详情：

随着云原生技术的普及和落地，企业在构建业务系统时，往往需要依赖多个云产品和服务，产品互联、系统协同的需求越来越强。事件驱动架构将事件应用于解耦服务之间的触发和交互， 能够帮助用户很好实现产品、系统之间的互联互动。函数计算作为事件驱动架构的最佳选择，需要为用户提供丰富的事件源触发能力。 对于函数计算而言，事件源接入需要清晰地了解上游每一个事件源的诸多细节和鉴权要求，同时事件处理和系统错误追踪变得越加困难，集成效率成为阻碍产品能力的最大障碍。为了加速事件源集成的效率，函数计算需要找到一种统一标准的事件源接入方式，基于通用的接入层进行基础能力和可观测性的建设，为客户提供丰富的事件源触发选择。 在这样的背景和需求下，阿里云函数计算（Function Compute）和阿里云事件总线（EventBridge）产品完成全面深度集成。这意味着函数计算和阿里云生态各产品及业务 SaaS 系统有了统一标准的接入方式，意味着函数计算将具备接入 EventBridge 所有事件源的触发能力，Serverless 函数计算将实现触达阿里云全系产品服务的“最后一公里”，为基于阿里云生态产品提供重要的架构扩展能力。 为什么是 EventBridge？ 阿里云事件总线（EventBridge）是一种无服务器事件总线，支持将用户的应用程序、第三方软件即服务（SaaS）数据和阿里云服务的数据通过事件的方式轻松的连接到一起，这里汇聚了来自云产品及 SaaS 服务的丰富事件，EventBridge 具备事件标准化和接入标准化的能力： 事件标准化：EventBridge 遵循业界标准的 CloudEvent 事件规范，汇聚了来自阿里云生态和 EventBridge 合作伙伴丰富事件源的各种事件，同时提供了完善的事件投递机制和消费策略，整个系统事件流转遵循统一的事件格式； 接入标准化：函数计算选择和 EventBridge 集成，无论是产品服务类型众多的阿里云官方事件源，还是第三方 SaaS 系统，EventBridge 都能够为函数计算和其它系统集成提供统一的集成界面，函数计算无需关注上游事件源的具体实现细节，只需要专注于事件处理，将事件的集成和投递全部交给 EventBridge 来处理； EventBridge  + Function Compute 的结合让事件驱动型应用程序的构建变得简单，因为它可以为您完成事件摄取和交付、安全保障、授权以及错误处理工作。允许您构建松散耦合和分布的事件驱动型架构，帮助提高开发人员敏捷性和应用程序弹性。函数计算系统提供了完善的函数创建， 发布和运行体系，灵活的构建能力结合极致的运行时弹性能力将帮助业务构建云原生时代最富显著特征的事件驱动型架构。 同时，EventBridge 能够提供来自事件源（例如 MQ、OSS、RDB等）的实时数据流，并将该数据路由到阿里云函数计算作为目标。您可以设置路由规则来确定发送数据的目的地，以便构建能够实时响应所有数据源的应用程序架构。 函数计算 + EventBridge 带来的变化？ 提供 90+ 事件源接入 在和 EventBridge 集成之前， 函数计算已经实现了和阿里云部分核心系统的集成，随着函数计算 EventBridge 的深度集成，阿里云生态大量服务实现了和函数计算集成， 这些服务或产品的事件将作为事件源触发函数；目前函数计算触发器类型已经从原来的 15+ 增加到 90+，并随着 EventBridge 上游接入系统的增加而不断丰富； 控制台享受一站式服务 EventBridge 和函数计算控制台数据互通，用户在 EventBridge 控制台能够以事件为主体选择函数计算作为事件处理目标，在 EventBridge 控制台享受一站式服务；同样在函数计算控制台，用户能够根据不同触发器类型根据对应的事件类型编写函数；用户无需在函数计算控制台和事件总线控制台来回跳转； 保证数据一致性和稳定性 用户无论是在函数计算控制台上通过创建触发器的方式处理指定事件源的事件；还是在 EventBridge 控制台使用函数计算作为事件处理目标，提供统一的资源视图；同时在底层系统实现上，由于后端系统 API 的深度集成，能够保证上层业务逻辑采用统一的 API 及处理逻辑，从技术层面确保了多个入口功能实现的一致性，为客户系统稳定运行奠定坚实的基础； 简化数据消费投递的复杂度 对于数据消费场景，EventBridge 负责了上游系统的对接和数据消费，用户无需关心事件源系统数据具体消费方式，这部分工作统一由 EventBridge 完成；对于函数计算用户，只需要考虑数据投递的逻辑；用户可以直接选择 EventBridge 提供的下游 Target 实现数据投递，也可以在代码层面仅使用 EventBridge 提供的 SDK 实现数据的投递，大大简化了数据投递的复杂度。 触发器业务应用场景 下面就让我们一起探索， 实际的业务生产环境，我们如何利用这两把利器让这一切简单的发生： 自动化运营分析和展示 业务系统会产生大量动态指标数据，需要提取指标数据做运营分析和展示，通过 EventBridge 和 FC 异步化串联实现自动化运营分析和展示。传统方案需要基于实时计算或者离线计算产品做数据提取和分析，整个方案较重，配置复杂。数据分析结果需要做预定义的展示渲染和推送，需要手工对接业务系统，步骤繁琐。 采用新的 EDA 架构，采用 EventBridge 对接业务自定义事件数据，规则驱动过滤逻辑简单。采用 FC 可以轻量化实现常见的数据分析操作，代码编写调试更简单；同时利用EventBridge 丰富的推送能力，可以实现分析结果快速触达受众。 异步解耦 以交易引擎为例，交易系统引擎作为最核心的系统，每笔交易订单数据需要被几十几个下游业务系统关注，包括物品批价、发货、积分、流计算分析等等，多个系统对消息的处理逻辑不一致，单个系统不可能去适配每一个关联业务。结合 EventBridge 事件中心和函数计算灵活的逻辑扩展能力构建业务逻辑。 新零售大促场景 Serverless + EDA 整合 大型新零售场景会伴随不定期大促，平时流量不大的业务在大促场景也会产生系统流量突增，极致弹性和稳定解耦的架构至关重要。基于传统模式开发稳定可靠、高弹性的后台服务人力不足、工期紧张；大促场景保障峰值流量需要预留大量资源，平时低峰期资源闲置浪费。新零售大促场景利用函数计算 + EventBridge + API 网关搭建 Serverless 模式服务中台，支撑海量请求访问， 系统具备极致弹性，无需预留管理 IaaS 资源，极大程度降低闲置成本；同时函数计算提供敏捷开发结合 EventBridge 低代码异步驱动，业务迭代效率大幅提升。 总结 如果说事件背后的服务是阿里云生态服务的积木， 那么 Serverless 函数计算将是能够将这些积木通过轻巧的方式组合起来艺术化的最佳手段；你可以利用函数计算为这些积木涂上更绚丽的色彩，同时能够将他们串联起来，搭建一个具有无比想象空间的 SaaS/PaaS 服务艺术品。 EventBridge 触发器现已在阿里云函数计算控制台所有地域（Region）开放，欢迎大家点击进行使用体验！ 关于触发器具体创建，配置，参考阿里云函数计算官方帮助文档： 活动推荐 阿里云基于 Apache RocketMQ 构建的企业级产品消息队列RocketMQ 5.0版现开启活动： 1、新用户首次购买包年包月，即可享受全系列 85折优惠！ 了解活动详情：