作者 | 史明伟（世如）
间隔阿里云事件总线（EventBridge）和 Serverless 函数计算（Function Compute，FC）发表全面深度集成曾经过来一年。站在零碎元数据互通，产品深度集成的肩膀上，这一年咱们又走过了哪些历程？
从事件总线到事件流，从基于 CloudEvents 的事件总线触发到更具个性化的事件流触发，函数计算已成为事件总线生态不可或缺的重要组成部分，承载了 EventBridge 零碎架构中越来越多的角色，事件流基础架构的函数 Transform，基于函数计算的多种上游 Sink Connector 投递指标反对，函数作为 EventBridge 端点 API Destination；基于事件总线对立，规范的事件通道能力，和基于函数计算麻利、轻量、弹性的计算能力，咱们将又一次起航摸索云上事件驱动架构的最佳实际。
本文主题围绕事件总线 + 函数计算，构建云上最佳事件驱动架构利用。心愿通过上面的分享，帮忙大家深刻了解 Serverless 函数计算、EventBridge 事件总线对于构建云上事件驱动架构利用的价值和背地的逻辑、为什么函数计算是云上事件驱动服务最佳实际？为什么咱们如此须要事件总线服务？随同着这些谜题的解开，最初，让咱们一起理解利用于理论生产的一些 Serverless 事件驱动客户案例。
事件驱动架构的实质
Back to the Nature of Event-Driven
大家可能会纳闷，事件驱动 妇孺皆知，为什么咱们又要从新探讨事件驱动呢？我想这也正是咱们须要探讨它的起因，回归实质，从新起航。
事件驱动可能是一个比拟宽泛的概念，而本文聚焦事件驱动架构的探讨，事件驱动架构作为一种软件设计模式，确实不是一个新的概念，随同着计算机软件架构的演进，它曾经存在了一段很久的工夫，大家对它的探讨也从未进行过，当咱们须要从新探讨一个曾经存在的概念的时候，我想咱们有必要从新回到它最开始的定义，一起摸索那些实质的货色，重新认识它。
下面的这些内容是我从相干的一些材料上摘录的对于事件驱动架构的一些形容，“abstract”，“simple”，“asynchronous”，“message-driven”这些具备代表性的词汇很好的给予事件驱动架构一个宏观的形容；从事件驱动架构的抽象概念，到它简洁的架构，以及事件驱动架构要达成的目标，和它在理论的零碎架构中所展示的状态。
事件驱动架构基本概念及状态
在理解了对于事件驱动架构的一些根本形容之后，咱们须要进一步明确事件驱动架构所波及的一些基本概念和架构状态。依据维基百科形容，事件驱动架构波及的外围概念如下所示：
事件驱动架构根本状态
围绕事件的流转，依据事件驱动架构的概念和根本状态，次要波及以下四个外围局部：
- Event Producer：负责产生事件，并将产生的事件投递到事件通道；
- Event Channel：负责接管事件，并将接管的事件长久化存储，投递给订阅该事件的后端解决引擎；
- Event Processing Engine：负责对于订阅的事件做出响应和解决，依据事件更新零碎状态；
- Downstream event-driven activity：事件处理实现之后，对于事件处理响应的一种展现；
事件驱动架构要达成的目标
理解了事件驱动架构的根本状态，架构中事件通道的引入，解耦了事件生产和事件处理这两个最根本的零碎角色，那么这样的架构模型所要达成的最终目标到底是什么？
零碎架构松耦合
事件生产者与事件订阅者在逻辑上是离开的。事件的生成与应用的拆散意味着服务具备互操作性，但能够独立扩缩、更新和部署。
只面向事件的涣散耦合能够缩小零碎依赖项，并容许您以不同的语言和框架实现服务。您无需更改任何一个服务的逻辑，即可增加或移除事件生成方和接管方。您无需编写自定义代码来轮询、过滤和路由事件。
零碎的可伸缩性
基于事件驱动架构的松耦合个性，意味着能够独立对事件生产者，事件通道服务，以及事件处理引擎进行独立的扩缩容；尤其对于后端事件处理引擎，能够依据音讯解决响应 SLA 和后端资源供应进行弹性扩缩容；同时能够基于事件粒度构建不同规格的后端解决服务，实现更细粒度的零碎弹性伸缩。
零碎的可扩展性
零碎的可扩展性，次要体现在当零碎须要减少新的性能，如何疾速的基于现有零碎架构疾速构建反对新的业务逻辑，在事件驱动架构利用中，围绕事件粒度的解决模式，可能人造疾速反对减少新的基于事件的数据流形象。
当零碎中减少新的事件类型的时候，无需调整变更公布整个零碎，只须要关注须要订阅的事件进行事件处理逻辑的开发和部署即可，也能够基于原来的零碎做很少的代码变更即可实现，也能够在业务初期通过独立的服务订阅指定的事件实现特定的业务逻辑反对。
** 为什么函数计算是云上事件驱动服务最佳实际？
**
在探讨完 事件驱动架构根本模型 之后，我想对于事件驱动的概念，状态咱们有了对立的意识和了解，接下来咱们进入议题的第二个局部，为什么函数计算是云上事件驱动服务最佳实际？
函数计算简介
函数计算 FC 是一款基于事件驱动的全托管计算服务，相干的产品细节能够见官网介绍。作为一款通用的事件驱动型计算服务，接下来我会从三个方面进行具体的介绍。
编程范式
应用函数计算，用户无需洽购与治理服务器等基础设施，只需编写并上传代码。函数计算为你筹备好计算资源，弹性地、牢靠地运行工作，并提供日志查问、性能监控和报警等 开箱即用性能，编程范式带来开发的“简略，快捷”。
依照函数粒度进行独立的性能单元开发，疾速调试，疾速的部署上线，省去了大量资源购买，环境搭建的运维工作；同时函数计算是一个事件驱动的模型，事件驱动，意味着用户不须要关注服务产品数据传递的问题，省去了在编写代码中波及的大量服务拜访连贯的逻辑；“事件驱动”+“函数粒度开发”+“免服务器运维”等几个维度特色帮忙函数计算撑持“聚焦业务逻辑麻利开发”的底层逻辑。
计算模型
除了开发模式带来的研发效力晋升之外，函数计算提供十分细粒度的计算资源和毫秒级计费模型，撑持 按需计算，按量免费；可能反对按用户的申请，依据用户流量的模型为计算付费；当然按用户申请付费存在技术上微小的挑战，要求函数计算实例的启动小于用户的 RT 要求，冷启动性能尤为重要，这时候极致弹性成为了 Serverless 按需付费，业务降本的底层技术撑持。函数计算通过“极致弹性”+“按需付费”的模型帮忙 Serverless 函数计算实现真正的按需计算逻辑。
事件驱动
在基于云的开发环境，云产品承载的服务绝对内聚，各自扮演着分布式系统架构中的各个重要角色，云产品之间的事件触发机制可能帮忙客户更好的基于多个云产品构建本人的业务零碎；否则须要用户本人负责云产品事件的监听，串联云服务，进行简单的错误处理，这是非常复杂，开发代价极其低廉的一件事；
除了产品连贯带来的开发效率之外，当用户订阅某个事件，并提供解决逻辑的时候，客户曾经潜在的过滤掉了不须要解决的事件申请，事件驱动意味着每一次的事件触发申请都是一次齐全无效的计算。
函数计算对于事件驱动架构的价值
为什么函数计算是云上最佳的事件驱动架构服务？函数计算对于事件驱动架构的外围价值到底是什么？
事件驱动架构始终存在，在没有函数计算的时候，同样也有事件驱动架构，在微服务的时候也同样有事件驱动架构。现在，当咱们从新再来探讨事件驱动架构的时候，到底是什么产生了变动，有哪些实质的区别？在整个事件驱动架构中，函数计算最大的价值在于帮忙构建“Event Processing Engine”这个角色，我想次要是以下两个方面产生了实质的变动：
零碎可扩展性价值
开发模式产生了实质的变动：函数计算提供的框架能力及编程模型，最大化的打消了客户业务逻辑之外的解决内容，极大的减速了客户业务开发，同时基于这样这样的开发模式，用户对于新增事件处理逻辑可能在最短的工夫实现解决并上线，细粒度，专一业务的麻利开发模式可能减速业务疾速上线。
零碎可伸缩性价值
计算模式产生了实质的变动：基于事件驱动架构事件粒度的解决逻辑和函数计算更细粒度力度计算弹性能力，可能从多个维度实现“Event Processing Engine”组件的弹性能力，这我想这也是函数计算对于事件驱动架构的一个最外围价值。
为什么咱们如此须要事件总线服务？
构建云上事件驱动架构挑战
函数计算以其轻量，快捷，可能利用事件驱动的形式与其余云产品进行联动的特点，成为很多客户利用事件驱动架构构建业务零碎的首选，随着业务及客户需要的一直减少，客户对于函数计算和更多云产品及服务的连贯需要变得越来越多，同时对于其余云产品的客户而言，也心愿可能利用 Serverless 函数计算的特点帮忙解决一些零碎工作和事件。
只管函数计算和云上的泛滥云产品进行了集成，提供了一些开箱即用的事件触发能力，那么咱们为什么还须要事件总线服务来构建事件驱动利用架构呢？
围绕函数计算构建事件驱动架构生态的过程中，咱们面临次要来自三个方面的挑战。面对这些挑战，基于函数计算和事件总线帮忙云上客户构建齐备的事件驱动架构生态火烧眉毛。
事件源多样性挑战
事件驱动作为函数计算产品外围竞争力，买通函数计算和其它云产品，以及用户自定义利用，SaaS 服务的连通成为函数计算生态集成的迫切需要，但系统集成，生态建设素来都不是一件容易的事件。
函数计算零碎在和 EventBridge 集成之前，曾经和 OSS，SLS 等用户典型场景的云产品进行了集成，也和阿里云的其它大略十多款产品进行了集成，不同零碎具备不同的事件格局，不同零碎的注册告诉机制也各不相同，以及上游不同零碎的失败解决机制也各不相同。
局部零碎反对同步的调用形式，局部零碎反对异步的调用形式，调用形式的差别次要取决于上游零碎在接入函数计算的时候过后面临的产品业务场景，对于新的产品能力和业务场景的扩大反对，在过后并未有太多的思考。随着和更多云产品的集成，集成的投入，集成的艰难度和底层数据管理难度越来越大。面对多种事件源集成的主观艰难，函数计算急需进步和其余云产品的集成效率。
受权简单及安全隐患
除此之外，函数计算心愿晋升用户体验，保障用户只关怀事件的解决；同时心愿可能在面对大量的云产品时保证系统受权层面的复杂度。用户在应用事件触发的时候，须要理解不同产品接入函数计算的权限要求，针对不同的产品须要提供不同的受权策略，对于客户应用函数计算带来了十分大的艰难，为了减速产品接入，大量用户常常应用 FullAcees 权限，造成较大产品安全隐患，和其它云产品的集成急需对立的受权界面，对立用户体验。
通用能力难以积淀
面对上游不同的事件源，如何更好的投递事件、更好的生产事件？如何进行事件的错误处理？函数计算调用形式如何抉择？以及函数计算后端谬误 Backpressure 能力的反馈、重试策略和上游零碎参数设置、触发器数量的限度等问题获成为函数计算事件触发不得不面对的问题。
为了更好的服务客户，提供牢靠的生产解决能力，函数计算心愿可能有一个对立的接入层，基于对立的接入层进行生产能力和流控能力的建设。通过积淀在这样一个规范的层面，在保障调用灵活性的同时，提供牢靠的服务质量。
事件总线简介
阿里云事件总线（EventBridge）是一种无服务器事件总线，反对将用户的应用程序、第三方软件即服务 (SaaS)数据和阿里云服务的数据通过事件的形式轻松的连贯到一起，这里汇聚了来自云产品及 SaaS 服务的丰盛事件；
总线模式（EventBus）
从整个架构来看，EventBridge 通过事件总线，事件规定将事件源和事件指标进行连贯。首先，让咱们疾速遍及下 EventBridge 架构中波及的几个外围概念：
- 事件：状态变动的记录；
- 事件源：事件的起源，事件的产生者，产生事件的零碎和服务，事件源生产事件并将其公布到事件总线；
-
事件总线：负责接管来自事件源的事件；EventBridge 反对两种类型的事件总线：
- 云服务专用事件总线：无需创立且不可批改的内置事件总线，用于接管您的阿里云官网事件源的事件。
- 自定义事件总线：规范存储态总线，用于接管自定义利用或存量音讯数据的事件，个别事件驱动可选该总线。
- 事件规定：用于过滤，转化事件，帮忙更好的投递事件；
- 事件指标：事件的消费者，负责具体事件的解决。
通过下面的流程，实现了事件的产生，事件的投递，事件的解决整个过程。当然事件并不是一个新的概念，事件驱动架构也不是一个新的概念，事件在咱们的零碎中无处不在，事件驱动架构同样随同着整个计算机的架构演进，一直地被探讨。
对于 EventBridge，采纳云原生事件规范 CloudEvents 来形容事件；带来事件的标准化，这样的标准化和事件规范的开放性带来一个最显著的劣势：接入的标准化，无论是对于事件源还是事件指标。
事件流模式（EventStreaming）
音讯产品凭借其异步解耦、削峰填谷的特点，成为了互联网分布式架构的必要组成部分，Serverless 函数计算有着与其齐全吻合的利用场景，针对音讯产品生态集成，函数计算在架构层面做了专门的建设，基于 EventBridge 产品提供的 EventStreaming 通道能力建设了通用的音讯生产服务 Poller Service，基于该架构对用户提供了 RocketMQ，Kafka，RabbitMQ，MNS 等多个音讯类型触发能力。
将生产的逻辑服务化，从业务逻辑中剥离由平台提供，生产逻辑和解决逻辑的拆散，将传统架构的音讯拉模型转化成 Serverless 化的事件驱动推模型，可能撑持由函数计算承载音讯解决的计算逻辑，实现音讯解决的 Serverless 化。
基于这样的架构，可能帮忙客户解决音讯客户端的集成连贯问题，简化音讯解决逻辑的实现，同时对于波峰波谷的业务模型，联合函数计算提供细粒度的计算弹性能力，可能实现资源的动静扩容，升高用户老本。
事件总线对于事件驱动架构的价值
简化对立事件源接入
积淀通用事件通道能力
晋升优化用户集成体验
利用函数计算提供的 HTTP 函数 URL 能力，联合事件总线端点 API 能力，可能疾速的帮忙客户进行零碎扩大和集成。
客户场景案例分享
总线模式 + 函数计算用户案例
利用 ActionTrail 事件触发函数进行多账号审计治理
利用 OSS 文件上传事件触发函数扩容 ACK 集群资源
利用 OSS 文件上传执行 Terraform 文件并拜访内部 API 做后果告诉
事件流模式 + 函数计算用户案例
利用函数计算细粒度资源弹性特色，联合业务波峰波谷的特点，实现疾速的音讯荡涤和解决。
事件流触发函数计算解决业务音讯
事件流触发函数计算进行简略 ETL 数据同步
事件流触发函数进行简略 ETL 数据荡涤入库
函数异步 + 事件流触发函数构建电商经营告诉零碎
在购物车加购，商品变更告诉场景，利用函数计算异步零碎（外部自带 Queue 能力），触发大量经营告诉，利用函数异步的 Destination 能力将经营告诉后果写入 MQ，而后利用事件流能力对 MQ 数据进行再次解决，写入 HBase 数据库中。