EventBridge 与 FC 一站式深度集成解析

简介：本篇文章通过对 EventBridge 与 FC 一站式深度集成解析和集成场景的介绍，旨在帮助大家更好的了解面对丰富的事件时，如何使用 EventBridge 与 FC 的一站式集成方案，快速基于事件驱动（EDA）架构建云上业务系统。

作者：史明伟（世如）

前言：事件总线 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 触发器及异步集成

点击下方链接跳转查看：

《EventBridge 与 FC 一站式深度集成解析》EventBridge 触发器及异步集成第一步_哔哩哔哩_bilibili

函数计算异步链路支持将处理结果直接投递到 MQ 和 EventBridge，用户可以利用 EventBridge 将相关的结果投递到 SAAS 服务；

点击下方链接跳转查看：

《EventBridge 与 FC 一站式深度集成解析》EventBridge 触发器及异步集成2_哔哩哔哩_bilibili

双向集成的变化

1）用户更多的事件触发选择

函数计算支持 85+阿里云官方事件源；
函数计算支持整个阿里云消息队列的事件触发，包括 RocketMQ， RabbitMQ，MNS 等；

2）用户更便捷的事件触发体验

EventBridge 和函数计算控制台数据互通，用户无需在函数计算控制台和事件总线控制台来回跳转；
用户通过触发器详情，快速跳转，利用 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 目的。