开发者学堂课程【EventBridge 入门课程 ：EventBridge 与 FC 一站式深度集成解析（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1220/detail/18279
EventBridge 与 FC 一站式深度集成解析
内容介绍
一、回顾
二、为什么要进行 EventBridge 和函数计算的深度集成
三、函数计算和 EventBridge 集成展示及案例分享
一、 回顾
在前两节课中，分别介绍了 EventBridge 是什么以及 EventBridge 架构的整个演进。在第二节课中，我们的同学给大家分享了应用的 player 如何帮助企业客户集成 SaaS 应用。今天的课程作为整个系列课程的第三讲，将跟大家分享 EventBridge 与函数计算。
二、 为什么要进行 EventBridge 和函数计算的深度集成
1.什么是 EventBridge？
在前面两节课中已经反复讲过 EventBridge 的架构，今天继续再跟大家讲一遍。一是对前面内容做一个回顾，另外可能也会帮助新上线的同学们——如果他们没有了解过 EventBridge，则可以帮助他们了解过程中的一些概念，从而方便同学们在后续的内容中理解这些概念带来的一些产品上的能力。首先，从这张架构图上来看，
EventBridge 整体架构实际上是一个链购事件源跟事件目标的一个架构，是一个 connection 的架构。在这个架构中，有四个非常关键的概念：事件源、事件目标、事件总线和事件规则。围绕这四个概念最核心的词是事件。事件这个概念想必线上的同学们都不陌生，或多或少在整个架构中和一些相关的文献中都了解过事件。事件即状态变化的一种记录。围绕事件的应用架构的演进不是一个新的事物，它在整个计算机的架构演进中一直伴随着整个事件驱动的架构的讨论。今天 EventBridge为什么要重新事件驱动的架构呢?首先，是在目前的云计算以及云原生的背景下，EventBridge 对事件遵循了整个云原生领域的 cut event 的事件标准，这个事件标准所带来的整个应用架构的演进的意义是非常重要的特征。之前事件驱动，因为各自的系统定义了自己的事件格式，因此形成了一个客观的因素，即就是说事件的格式成为了系统互通的障碍，阻碍了事件驱动架构在更广的范围中的应用。
在这张图中，左边是事件源。事件源是产生事件的服务或产品，包括云服务、客户的 SaaS 应用、自定义的应用、其他的云厂商的和支持 events 沟通的产生事件的系统等。关于目标事件，在这些事件产生之后，需要有人去消费它。那就是两端的实现目标。在它们两个之间得有一个桥梁去衔接，即图中的事件总线。它作为整个事件的载体。在这个架构中有两类事件总线，一是默认事件总线，二是自定义事件总线。但从目前整个阿里云的 EventBridge 来看，默认事件总线主要是去存放官方的云产品产生的事件。基于这个事件总线，怎样把事件投递到下游的事件目标或者事件目标如何决定自己去消费什么样的事件是由事件规则来决定的。事件规则包括事件过滤、事件转换以及事件投递方式。这是整个 EventBridge 架构的基本的概览。关于其他更 detail 的问题，前面的章节已经讲过了，这里不会再细聊。从这个架构来看，再回到整个 EventBridge 跟函数计算的集成的背景下，它的最大的特点是什么？
2.EventBridge 最显著的特点
首先 EventBridge 最显著的特点是它通过标准化的事件以及标准化的接入方式来更快、更一致地跟上游系统的或者事件源的系统进行集成。然后将事件进行统一的管理投递来供下游消费。所以从这个角度来看，它提供了标准化的接入和消费模式的定义。那这是整个 EventBridge 跟函数计算集成的最大的特点，也是函数计算为什么要做一站式集成的最主要的原因。
3.什么是函数计算？
关于函数计算，在现在的背景下，同学们可能或多或少都有所了解。Service 这个概念作为目前比较热门的概念，可能大家从不同的方面都听说过。整个架构总结起来主要有两点。第一，用户面向代码开发只需要上传代码，然后剩下的整个执行无需去 survey 或 sublist 一个概念，只需按需付费然后获得执行结果来提供计算服务。从实际操作来看，上传代码在实际的操作过程中可能比想象的更加起来。因为为了帮助开发者更快地使用函数计算，也帮助实际的开发者能够快速地构建自己的业务系统，在整个过程中沉淀了一些函数模板，也应用了一些 subotion。因此，用户在函数计算控制台或者从 giharb 仓库上获得一些最新的比较普遍使用的应用模板或者函数模板，可以快速地进行函数的能力。另外，用户不需要关心这些资源，按需付费。这样的情况依赖函数计算提供的完备的观测性能力，它可以帮助客户去观测自己的资源弹性、任务执行以及整个任务执行的中间状态，包括整个资源的准备情况，都能够通过观测性能力去打消对 no servey 或者 sublist 的担忧。这是整个函数的一些特点。关于函数计算，既然有这么好的、快捷的、敏捷的手段可以帮助我们去处理计算逻辑，当然，它也是处理事件的最佳手段和最敏捷的最高效的手段。
4.为什么函数计算需要 EventBridge？
刚才提到，有了高效的处理能力和计算服务，但如果没有相关的数据或没有相关的事件来驱动，那这样的计算能力的使用就会大打折扣。在这样的背景下，它就是面向事件驱动的模型去设计的，包括整个触发器，整个调用的方式都是基于整个 EDA 的架构。在这样的背景下，函数计算会面临最大的一个问题，就是它需要跟其他的系统或云服务进行集成，因此，才能帮助把整个计算服务的能力最大化发挥出来。在跟 EventBridge 集成之前，尝试过跟阿里云的十多款产品进行联动的集成。这些集成的过程中非常艰辛，充满了挑战。随着整个函数计算和阿里整个云产品的范围的扩大，以及对集成需求的不断需要的话，我们面临的集成的投入和集成的困难度会越来越大。在这这样的背景下，我们需要去跟 EventBridge 进行集成。那首先说一下最大的挑战，即事件源的多样性，基本上原来的时候在产品初期会投入的能力，会去集中做一个几个产品的集成。随着产品越来越多，这些产品实际上都有对函数计算系统之间的打通的需求，包括一些数据库、一些其他的系统、这些系统可能有类似 UDF 场景的情况。它们都有对计算或者对函数的计算模式的需求。这样的方式给整个集成的时间的多样性带来了巨大的挑战。基本上集成的投入会越来越大。整个集成的质量因为差异化，包括事件的一些差异化，给集成造成了很大的困难。另一个问题是面对这么多的云产品体系的授权。当然，授权本身不能马虎，安全无小事。这对帮助用户使用产品带来了很大的体验上的阻碍。这也是整个授权体系，因为要面对多的系统去做构建这样的一个授权体系。最后一个问题是函数计算在面对这些上游的事件源之后，这些事件源如何把事件投递到函数计算。关于整个投递过程的失败的处理，从事的策略以及函数计算对失败的处理或对上游的要求，都是会存在一定的差异。那导致对一些通用能力的沉淀带来了很大的困难。
基于这样的问题，公司层面或者说 BU 层面的战略级的要求，函数计算跟 EventBridge 进行了深度的集成，从架构层面进行了设计来解决利用 EventBridge 的标准化的介入以及统一的对接层减少整个授权的复杂度。最后可以把整个关于事件的投递、事件消费的能力，通过沉淀在标准的层面，这样的话，就能够帮助用户最大地减少整个链路中的数据的一致性以及数据的消费存在的众多风险。这也是为什么函数计算需要 EventBridge 的最大的一个问题。在这样的背景下，EventBridge 跟函数这样集成。
5.为什么 EventBridge 需要函数计算？
看这张图，
其实同样 EventBridge 也需要函数计算。EventBridge 作为一个事件中心或者标准的事件中心，最终的目的是希望能够利用这些事件把产品的能力进行联动，同时能更好地消费这些事件。或者是用最敏捷、最快捷的方式去消费这些事件，帮助业务获得成功。所以 EventBridge 跟函数计算实际上为了形成一个共同的目标——帮助客户快速地基于 EDA 架构的业务系统作为实验处理，形成很好的能力的互补。这就是关于第一部分为什么要 EventBridge 和函数计算进行这样的一站式的深度集成。
