开发者学堂课程【事件总线 EventBridge 生态集成课程：事件总线+函数计算构建云上最好的事件驱动架构应用】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1235/detail/18406
事件总线+函数计算构建云上最好的事件驱动架构应用
（4）为什么需要事件总线服务
第三个问题，为什么如此需要实践总线服务，前面说过，已经通过函数计算和云上的众多的云产品进行了集成深度集成，提供了一些开箱即用的能力，同时也提供了一些触发通道。那么为什么还需要实践总线服务来去构建实践驱动这样一个应用架构，在整个去构建基于函数计算构建事件驱动的这样一个服务的过程中，面临了主要来自三个方面的挑战。
首先是需要去跟众多的这个事件员多样性所导致的这样一个接入困难，去将实践驱动的这样一个生态去更大化的去扩展到包括语音产品客户的客户自己的应用以及云上的一些SARS系统的时候，就会面临这样的一个众多的困难，同时面对不同的这样一个事件源的这个集成诉求，产品之间的授权复杂，非授权复杂度越来越高，针对不同的产品需要提供不同的这样一个授权策略，变得异常困难。最后基于这样一个事件集成的过程中，发现需要去沉淀一些更通用的，在实践通道上能够提供一些更通用的能力的时候，发现随着这样一个实践员，不同实践员接入方式不同，这些能力的沉淀变得异常困难。那面对这样的挑战的情况下，急需一款服务或者是这样的一个产品接入的这样一个角色，能够统一的去提供一个事件驱动的这样一个因为它channel的这样一个接入面，帮助去更好的去解决来自这三个层面的挑战。那在这样的背景下，事件区事件总线作为承担这样一个角色的一个云上服务，事件总线跟函数计算的这样一个结合，可以去解决在事件驱动的这样一个生态构建的过程中所面临的这些问题。
下面是事件总线的一个基本架构模型，会看到事件总线的话，也是按照之前的这样一个事件驱动的架构去构建的这样一个通用的框架，包括整个事件源的接入，事件总线以及最终的这样一个下游事件处理引擎，以及它的事件目标。在这样一个架构下，事件总线服务能够更好的去对接不同的实践员，包括阿里云产品用户业务，业务服务以及相关的这样一个SARS事件。客户再去开通了这样一个事件总线服务的时候，那他会接收到整个来自阿里云200多款产品的这样一个云产品事件，来帮助去构建这样一个云产品事件驱动架构的这样一个能力。
那同时除了这个云产品的架构以及下游的这样一个接入的能力之后，那面对一些更复杂的一些事件类型，包括事件流，去提供了这样一个英文的bridge，提供了一个事件流的架构模型，那通过这样一个事件流的架构模型，能够将上游的一些数据面的一些或者业务层面的一些消息，包括下列这些服务中间的数据，能够通过统一的这样一个事件流的这样一个通道，去到下游的这样一个函数计算，去统一去构建一个事件驱动型的这样一个架构服务，提供高性能的事件通道能力，最终再结合函数计算提供的这样一个数据处理引擎的这样一个弹性能力构建，帮助客户去构建更好的这样一个事件驱动型架构。
在这样的一个事件驱动型事件总线服务的引入，帮助去实现了这样的一个目的，首先去简化统一了事件源的接入，采用事件总线跟相关的实践员，采用开源的实践标准，去对接不同的云产品，解决了产品接入多样性带来的这样一个复杂度，以及面对不同的这个授权的这样一个复杂度，帮助去可以构建更加丰富的事件驱动生态。
第二个部分的话就是事件总线服务的引入，可以帮助去沉淀更通用的事件通道能力，包括在事件通道上去提供这样一个过滤转换的能力，可以提供事件通道的自定义能力，满足下游函数计算以及不同的这样一个事件目标，对事件处理的这样一个需求可以做一些前置的过滤，剔除掉一些不必要的事件，触发相关的这样一个无效的调用对下游的这样一个就是无效的这样一个资源的浪费。包括针对事件流的这样一个场景，去提供了一些通用的这样一个数据转换，以及基于函数计算的这样一个 remote transform的这样一个能力，同时针对事件流场景下，客户对于成本以及对于处理数据处理的一些聚合的需求，去提供了这样一个简单的一些窗口能力，包括Bachmann，他们这些能力可以更好的去帮助去处理客户的数据沉淀作为这个事件通道的一个通用能力，去服务众多的下游事件事件目标。
最后事件总线服务的引入，可以帮助去提供更利于产品集成的通用能力的这样一个提供，可以基于函数的这样一个URL，提供API端点端点能力，帮助更好的去以多种这样的一个形态去订阅消费上游的不同的类型的这个事件源的事件，最终构建出一个多态的这样一个事件驱动型架构模型。那在聊完了事件总线的一些引入，能够给事件驱动架构带来的一些基本好处之后，那接下来会去分享一些客户场景案例，去看看的客户是如何去利用事件总线和函数计算，构建自己的这样一个满足客户的这样一个业务诉求。
四、相关案例分享
首先第一个需求是在一些大的企业客户，通过事件总线以及通过这样一个 action trial的这样一个审计事件的这样一个订阅，通过函数计算去处理这些多个账号的这样一个action trial的这个事件，然后去做一些后续的这样一个审计，相关的一些报警，还有一些通知相关的操作，然后去管理不同的账号，对于资源的这样一个使用和操作的一些相关相关的后续的就是流程性工作，这是的第一个案例。
那第二个案例是的客户通过事件总线和函数计算，然后利用 oss类型的事件，通过去在oss上上传文件，然后根据上传文件的这样一个事件，以及去实现，去通过函数计算订阅相关的oss事件，去做操纵相关的云上资源，做一个资源扩容，这是看到的第二个客户用例。然后将客户操作的一些结果，再通过实践总线提供的下游upstream的通用能力，再去通知到相关的业务方进行一个事件的通知。
第三个部分的话，也是看到一个比较常见的一个云上的操作，包括云上的一些资源的自动化申请，那看到的客户通过将自己这个描述的一些资源申请的这样一个 get UPS的一些描述，telephone的文件通过上传到oss然后通过oss触发投事件投递到因为它不认证，然后再通过函数计算去订阅这样的一些相关事件，触发去执行telephone的相关的这样一个资源申请。
同时在这个执行过程中，用户可能在函数计算里面需要去访问自己的这样一个外部的一些API，然后去帮助自己更好的去打通云上资源跟客户这样一个多架构的多云架构的这样一个架构下的一个资源的协同能力，最后通过这样一个操作，然后也可以通过interpret提供的这些upstream的能力，将这样的一个操作去通知到相关方，这是看到的另外一个场景。那基于上面的话主要是客户基于因为它range和函数计算针对语音产品的事件做的一些云产品运维以及审计相关的工作。
另外一个部分的话也是基于客户基于视线流做业务消息的处理，会看到这样一个基本的架构，客户的话会将 produce作为一个微服务去去生产相关的这样一个数据，最终通过interpret的事件流能力去订阅这些消息，利用函数计算这样一个细离度的资源能力以及消息的这样一个波峰波谷，这样一个对后端资源的这个弹性的需求模型的这样一个要求，可以结合函数计算去实现消息的一个更好的更快的消费，实现满足他的业务诉求。
那下面是针对在事件流这个场景下看到的几个具体的案例。那首先客户将应用性能数据写入通过先写入卡夫卡这样的一个语音产品，再通过因为它bring事件流的这样一个能力，将相关的这个数据清洗之后写入到oss为客户进一步做大数据处理，去做相关的这样一个前置数据数据清洗。
同时也可以在相关的一个数据清洗之后，它导入到clickhouse的这样一个服务，进行一个在线的数据分析，这是看到的。另一个客户的话是关于这个事件驱动，场景的这个数据一定要处理。那首先客户将自己的这样一个业务系统生产的这样一个数据书到了这个 APM 里面，再通过因为它range的这样一个时间流的能力去订阅的消息，通过在函数计算中对这些数据进行 et要处理，然后做后续的这样一个相关的操作。
最后一个场景的话是看到的客户利用事件总线以及函数计算构建的这样一个购物车运营通知的这个事件驱动架构。首先客户在客户会在购物车的这样一个架构架构的行为，以及商品的这样一个价格变动，以及它的一个过期的相关的一个通知的情况下，会去通知它的整个业务服务业务服务，再通过函数计算的这样一个相关的能力去通知他的客户方现在购物车相关的产品的一些变动做一些运营操作，那最后将这样的一个运营操作的结果在进行到输入，后续通过interpret的这样一个通路再去订阅绕开明做后续的这样一个数据的清洗以及入库操作，实现自己的整个购物车的这样一个运营的流程。
