开发者学堂课程【EventBridge 入门课程 ：EventBridge 与 FC 一站式深度集成解析（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1220/detail/18279
EventBridge 与 FC 一站式深度集成解析
三、 函数计算和 EventBridge 集成展示及案例分享
这个部分会给大家演示一下函数计算和 EventBridge 的产品能力。最后会跟大家分享集成过程中的一些案例场景。
首先，在进产品的演示之前，先来到整个 EventBridge 的阿里云官方主页。 大家一起浏览一下，目前整个 EventBridge 所支持的事件源的类型涵盖了阿里云新进产品。包括存储计算、网络、安全等相关的部分。看完了 EventBridge 整个事件源的分布情况，来到函数计算的控制台。
一起体验一下从函数计算的控制台的角度体验深度集成的情况。首先给大家提前创建了一个 service integration 服务。
先去创建一个函数。
为了演示随便创建一个最简单的事件函数。回到这个函数的整个情况，来到整个触发器的管理，这样的话希望能够创建一些触发器来触发这个函数的调用。首先在创建之前，我们先浏览目前的这个函数计算的触发器的现状。这边大概有一些分类，包括一些双向触发器、单向触发器。把 EventBridge 触发器做一下单列。原来的双向触发器是最早的时候支持业务的时候提供的一些触发器，大概有十几种吧。现在的 EventBridge 的触发器的集成，给函数计算带来了大概有90+的触发器的数量。同时，相关的 oss 的情况，看质量关于整个原来的双向触发器跟现在的差距化的能力。新的这边可以提供一些原来现在更高级的能力去定义。后面可能会加一些兼容的东西取代原来的方式，还有一些像 OPS 的一些表格存储。这样的触发器可以看到原来的触发器关于选择实例、表格等有一些创建性的角色的要求。需要在他的主页开通一些实例的 feature。在新的 OPS 表格存储当中，相对比较简单。这是整个触发器的对比。在 EventBridge 触发器这边刚才讲到 EventBridge 提供了两种类型的总线。一种是官方事件源总线，另外一个是。这样跟触发器的场景大概分为两类。一个是关于整个消息队列的，这边是自定义的事件源。阿里云官方事件源可以通过 FQ 去看，在这边一站式的触发器的创建会到这样的情况。如果是这样的话，可以去创建这样的触发器，包括 RockerMQ 里的消息。在自定义事件源增加针对卡夫卡的消息的支持，包括 RockerMQ、MS 以及卡夫卡。再看一下 ecs 的情况。关于最常见的 ecs 的场景 ，基本上支持了整个 ecs 里面实例的事件。可以创建这样的一个触发器帮助 ecs 的一些情况。现在分别创建了两个类型的触发器。一个是官方事件源的触发器，另一个是针对自定义事件源的 RockerMQ 的触发器。这样的触发器在整个创建过程中会看到并没有跳转到 EventBridge 的控制台上去创建相关的总线的事件规则以及事件目标。看到整个事件源的名称以及事件规则。因此可以完全在整个函数计算的控制台上完成整个 EDA 的包括事件的定域、整个事件处理的流程。以 ecs 为例，选择启用它。对它进行编辑。编辑会跟数据底层的一致性不会保持一致。如果用户在实际使用中有一些事件消费出现异常，则可以通过这样的方式直接跳转到 EventBridge 控制台进行相关的操作。从 Eventrule 的角度来看，其实可以被多个函数，多个服务的函数共享。所以当在某一个函数下建立一个相对通用的规则之后，这个规则也可以被其他的复用。再回到这个界面，如果可能需要它的事件的模式，跳转过来觉得需要一些操作或者编辑，可以删除一个东西，然后进行保存。相应的在函数计算册也会进行同步。同时，针对这些过程，也会提供一些实践追踪的能力。关于整个事件总线，针对事件的一些规则，可以进行一些相关事件的追踪。可以看一下目前的一些与 ecs 相关的事件是不是有相关的事件发生，可以在这里进行查阅。同时也可以确定当函数计算消费异常的时候，可以在这边查阅。同时，可以在函数计算的整个链路，有链路追踪能力，包括日志的一些情况，可以做相应的查询。这是整个函数计算的能力。刚才讲了在函数计算中在具体的函数上创建相关的 EventBridge 触发器，然后帮助函数实现整个事件驱动的能力，也看到整个这边的一些详情。通过这个详情可以快速地跳转到 EventBridge 控制台，然后帮助操作相关事件，包括编辑事件目标。可以实现在原来函数的基础上，创建的 Eventrule 的复用。这也是跟 EventBridge 的概念保持一致，同时我也可以编辑整个事件相关的能力，磁盘告警的情况，可以进行一些编辑，然后保存。也可以进行事件相关的一些追踪，查看最近的一些事件，包括在函数计算的一些事件。看到整个函数计算的情况下 EventBridge 的控制情况。后续会在整个执行，包括整个事件追踪，也能够在函数计算这边看到整个事件追踪。不仅能看到整个事件追踪，也能看到整个函数计算册函数执行的整个链路的追踪。本来在函数这边已经提供了一些链路追踪的能力。可以看到整个调用，包括能启动这样的一些能力。因此，跟事件的追踪、执行的追踪打通之后，就会有更进一步的体验。演示完了整个触发器的双向集成之后，再来看整个 EventBridge 情况调用方式。这边数据也做了一些同步，可以选择同步的调用方式，同样我们也可以选择异步调用方式触发函数。也可以跟 EventBridge 保持一致。再来看整个函数的异步配置上的一些情况。看到上面其实提供了一些从事的策略，交给函数计算去做一些可用性的能力，包括策略。可以将函数执行的成功的结果投递到这些消息册，包括rocketMQ 或者直接投递到事件总线，然后由事件总线把处理的结果投递给第三方应用，包括短信或者钉钉。这便形成了一个完整的闭环。另外，也可以将函数计算执行的一些失败结果投递到对应的一些消息对立或者 EventBridge 中。然后帮助用户更好地处理这些失败的情况。作为一个行队列的方式去使用，这也是整个在异步这块的一些能力跟 EventBridge 去结合。关于 EventBridge 跟函数计算的产品能力的集成演示到这里。接下来给大家分享一些在集成的过程中的一些案例。
1.EventBridge 触发器涵盖的事件源
由于在使用的官方事件源的场景，因为主要是由于一些厂商在使用某些方案或者是没法具体的区域提供给大家，但是在整个过程中，做了一下总结，大概是这四个场景。
首先第一个场景是一个单账号的云产品的运维的需求。通常客户希望基于这样的事件，包括像 ECS 或者镜像加速等可以做一些运维操作，或者自动化的诊断。也可以基于类似这样一些，尤其是有客户去进行一些镜像加速，比如阿里云的 acr 的容器镜像服务的东西做一些镜像加速相关的或者镜像实验监听去构建整个镜像预热相关的能力。这是场景一。场景二主要是一个单账号下使用了多个云产品的事件，希望能够进行聚合的分析或者是做一些故障处理，这样的产品。第三个场景主要是对一些大企业比如 IOT 领域的一家科技公司，他们在使用云产品的时候，实际上有多个账号使用了阿里云的产品。在多个账号多个产品的情况下，希望能够对一些账号中的云资源使用情况有全局统一的视角来进行实践分析，进行账号配额调整。因此，可以利用 EventBridge 的跨账号投递能力。同时利用函数计算的处理能力，能够快速地将事件进行聚合的消费，这也是一个典型的场景。场景四是账号之间的跨域的事件处理。现在 EventBridge 并没有提供跨域事件的能力。但是可以借助函数计算的跨域的能力，尤其函数计算的 HTB 的函数能力，帮助处理跨域的事件，可以满足用户的需求。在官方事件源的官方事件总线上的事件处理的一些场景总结。接下来会给大家分享一个自定义事件源关于 MS 的集成方案。
2.自定义事件源——MNS 集成方案
客户在 OSS 上传文件之后，根据文件上传的事件，对整个 ACK 进行扩容。目前是通过 OSS 事件发送到 MNS，然后用MSQ的消息通过 Eventbridge 除法函数计算。函数计算根据一定的逻辑，进行 ECI 资源的创建。在这个过程中，可能在没有 EventBridge 之前，实际上方案可能要更多地利用 MNS 的一些能力，而投递可能有一些限制。有了 EventBridge 之后可以大大地简化这个方案，利用 EventBridge 的多个投递的规则能力。当有用户去 OSS 的事件到 MNS 之后，可以通过在 EventBridge 上创建自定义的事件总线。然后通过一定的事件规则投递到整个消息通知，包括函数计算的服务上，能够简化整个方案的链路。这是 MNS 自定义事件源的方案。接下来的话会再为大家分享一个基于 RocketMQ 的自定义事件源的集成方案。因为客户的一个方案，征求客户的意见之后，因为没法把整个方案的完整呈现给大家，所以征求意能把一部分关于整个的 RocketMQ 利用 Eventbridge 的方式投递到函数计算，做整个 ETL 处理的场景。客户的痛点通常在整个 IOT 领域 RocketMQ 稳定性可靠性使用得比较多。IOT 场景数据的采集相对偏底层，更偏向裸数据。实际的业务层面客户需要找到一种快速高效的途径，比如 RocketMQ 中的数据进行加工。对它的特殊部分进行一些语义转换。客户利用 Eventbridge 跟函数计算进行快捷地打通。利用函数计算敏捷的手段帮助 RocketMQ 里的数据处理。针对这样的场景，客户针对 RocketMQ，包括 MNS 也有类似的场景做类似的方案进行数据处理和消息加工。关于整个第二部分，产品能力的分享以及案例分享到此结束。
3.函数计算和 Eventbridge 后续集成
后续集成计划主要是在整个架构中，围绕整个中间部分的数据的 ETL 的处理。整个事件的过滤和转换的这个阶段，希望能将函数计算和 Eventbridge 进行紧密地集成。由函数计算可以提供一些高级的 ETL。可以提升整个 Eventbridge 事件过滤转换的能力。
另外一部分是 Eventbridge 目前看，它的整个下游的事件目标相对来说还是比较少的。希望能够通过函数计算和 Eventbridge 的密切集成，利用函数计算的敏捷能力以及用户自持的能力，可以构建一些更丰富的 Eventbridge 事件目标，然后帮助丰富整个事件目标的生态。
同时也能够发挥整个函数计算的敏捷性的能力。这是整个函数计算跟 Eventbridge 在接下来的重点的建设方向。到这里关于今天的整个 Eventbridge 跟函数计算一站式集成的解析的内容就结束了。如果在实际的业务过程中或者是开发过程中有关于消息 Eventbridge 以及 Service 的一些需求可以随时联系阿里云 Eventbridge Service 团队或者可以加入到官方钉钉群做进一步的沟通，这里都将会提供一些指导和服务，帮助大家更快地使用产品能力，快速地构建自己的业务系统，取得业务成功。
