开发者学堂课程【事件总线 EventBridge 生态集成课程： EventBridge EDA (事件驱动):架构场景实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1235/detail/18407
EventBridge EDA (事件驱动)：架构场景实践
内容介绍
一、概括
二、事件及事件驱动介绍
三、事件驱动架构设计
四、事件驱动架构实施
一、概括
本次视频课程将围绕 EDA 架构在 EventBridge 的场景实践来为大家完全展示 EDA 架构是什么以及在 EventBridge 这款云产品中如何去正确落地 EDA 架构本次课程时长在一个小时左右，请大家预约好时间。
二、事件及事件驱动介绍
1.趋势演进
第一章节将重点介绍事件及事件驱动，来看一下第一篇的讲解。
（1）在最早的时候，架构叫单体架构。单体架构的意思是它的所有服务都是在单节点服务中,单体应用所有的模块都是分装在单个的进程中进行的,通讯主要还是通过相同的 BGM 的一些调用来完成。这种模式非常容易导致结构关系不明确，难以对系统进行更改和重构。这其实是单体架构的内容，即 PPT 最上面的一部分。
（2）然后会演进出另一个架构体系叫分层架构。比较经典的分层架构和其他层的调用是非常谨慎的,即在最早的分子架构中，记一个层，其实只知道在下层的一些数据结构,在随后的实际应用中会发现更多的使用方式，一个层可以访问下面的任何层,这是最早对分层架构的理解。其实它是类似于堆栈的结果，它是一层一层往下分来的。第一层可以调用下层的任何层，但是下层任何层没有办法往上调用,这就是分层架构,分层架构解决了单体架构的逻辑分离问题,其实每一层都可以被等效替换，也使现有的层级区分，更加各种化。同时一个层可以被几个不同的更高层做复用。这也是在最早架构模型设计中推崇的做法，也是方案,但是层也有一些比较明显的缺点,比如层不能封装掉一切,比如添加一个字段到 UI，同时可能也需要把这个字段添加到 DB。然后额外的层会严重损害现有的系统性能,这是最早的分层架构，分层架构大家有兴趣可以直接在 VK 或搜索引擎上检索一下相关信息,当然现在很少有架构会用到现有的这套分层架构。
（3）下面 PED 迭代发现，进入了 MVC 架构体系,MVC 架构产生的原因非常简单,它会随着现有的业务系统的复杂性增加,之前所谓的全传工程师，已经不太适合大部分的场景，更多是希望去做一些职能划分。比如后端只负责提供进口调用，前端负责 UI，还包括 web 页面的开发,这是分架构的底层逻辑。所以它的出现目的主要是降低前端后端集成的复杂性。这套架构不管在哪个业务面都会遇到,所以画这张图不是说哪个架构谁优谁劣，只是把它铺开来看，可能会挑选几个架构选型,所以 MVC 架构，现在很多企业还有前端后端型的方式都依赖于 MVC 架构的推广,当然典型的 MVC 架构里面其实会有 controller, will, model 这种逻辑分层，但现有的前端和后端账户会把 controller 完全通过 API 调用来完成，或者完成线上的发布或逻辑处理,所以这其实是 MVC 架构在信用体系下影响甚广的一个架构。
（4）下面讲了 EBI架构,EBI 架构不仅仅是在 MVC 架构提到 shift 服务器或者接口，EBI的实体其实是代表持有数据并结束相关行为的实体。给大家举一个非常简单的例子，就像阿里云的泡沫 API。EBI 架构主要还是后端的概念，它其实和 MVC 的关系是相辅相成的，它其实也并不是完全替代前者的 MVC,这是 EBI 架构。
（5）演进到此，有个术语叫洋葱架构。洋葱架构是一个低耦合高内聚的价架构模型，所有的应用程序都围绕独立的对象模型做构建，然后内存定义，接外层的事件接口，然后耦合方向向中心内聚。所以所有的代码，都可以做独立运行。然后和基础设施是完全隔离的，这是洋葱架构。现在有很多架构设计都会用到这种低耦合高内聚的架构模型。这是洋葱架构。
（6）下面架构模式叫 SOA 架构。这是大家用的最普遍架构。现在很多大型企业中小型企业都会用到 SOA 架构,SOA 架构学名叫面向服务架构,它表示每个功能都可以通过一个独立的服务来提供。服务定义了可调用的接口,它类似于服务之间的编排，来完成整体的完整业务。
目前来讲，很多架构模型都是 SOA 架构，也是现在架构模型中最成熟的用的最多的架构款式,包括后面提到的 EDA 架构也是辅助完成面向服务架构的一个模型和工具，或者是一个新的架构方式,所以刚刚之前一直强调的，现在所推崇的 EDA 架构并不是和其他架构完全仅有的关系,架构和架构之间一定是相辅相成的，类似于之前讲的MVC和 EBI架构，它们两个之间是相辅相成的,这是 SOA 架构。
（7）这一讲的重点内容是 EDA 架构, Event-Driven，即通过事件去交付，然后去和下游通信的架构范式,聊完了整体的趋势演进，相信大家对架构范式还有比较典型或者比较常用的一些架构都有非常详细的了解。
2.EDA 架构概述
然后再去看今天主讲的内容，EDA 架构范式，就是事件驱动架构。事件驱动架构其实在 PPT 里面写的比较明确，它是系统架构的模型，它比较核心的能力在于能够发现事件或业务中的重要时刻。比如交易节点还有站点访问等一系列可能会对系统造成变更的时间节点，然后把这些时间节点转换成一个事件，实时地做处理。这就是现在 EDA 架构的模型。这个图里面发现 EDA 架构逻辑其实非常简单，它其实取代了传统的 request/response 模型,它不需要实时地等待下游端接收到消息，再 response 事件，再做业务串联，而是通过 EVENT BROKER 中间模式把上游和下游事件做分割,EDA 架构的三要素给大家说一下，这一块讲的也比较明确。第一块是生产者，即现有的应用系统的触发,比如上游系统是一个订单系统，那么生产者是订单系统的业务或者服务测,第二块是 broker,它由很多东西构成，这里叫做 topic, 比如 topic 01、02、03，把 event 发到 broker 上，通过 broker 发送到下游端去消费。Broker 是中心环节，也是比较核心的承接方案,第三块是消费者。消费者即消费事件的主体,以刚刚的订单为例，比如现在产生了一个订单事件，然后由订单系统把事件发出,那这个订单消费到哪边呢？这个订单系统需要通知到用户,那么 consumer 就是一个 communication 通知的模块,这是现在 EDA 架构的简单的概述。大家比较好理解,可以简单看一下，最关键的是这个模型取代了传统的 request/response 模型。它的主要能力是 consumer 端完全不用关心上游,然后上游也完全不用关心下游，它完全是通过 event broker 做中间结构,EDA 架构和之前做的消息 message 一样，但其实它有本质区别，后面会给大家讲事件和消息的一些区别,这是 EDA 架构的一个概述。
3.EDA 架构 VS 传统架构
（1）EDA 架构和传统模型的一些对比。这里画了一个简单的图，传统架构里面创建一个订单是怎么做呢？传统架构里面可能是它的订单服务，即使它用 SOA，订单服务也是一个服务。所以它一般创建订单，是在一个服务下面完成的。或者是叫 SOA 的单个节点完成这样的订单服务。这个订单服务其实有几块，第一是新的订单，第二操作数据库，第三可能要把这个订单发出去，然后做一些短信通知。这是现在传统架构的做法，它都是在一个服务里面完成的,因为它都要订单服务,当然可以拆，但是拆其实感觉没有什么必要,在传统架构里包括通信都会成为阻塞点。这是传统架构创建订单的做法。
（2）然后 EDA 架构做起来非常简单。用户要操作一个创建订单。创建订单会完成一个订单新建服务，新建一个事件，这个事件把现在的订单情况，比如有多少销售额，订单的地址是什么，联系人是什么等用户下单的一些信息，通过事件把它分装，然后给下游。下游叫 event bus，如果大家对 eventbus 不太了解，后面会详细介绍。eventbus 可以对标一下现有的 event broker 这一块。event bus 相当于上图讲的 event broker，然后发送到下游的中继点，做删出。就比如有一端，要做操作写库，那这一端的事件监听，接收者写数据库，第二端做短信通知，那这一端就做短信通知的能力,再其次还可以接很多东西，比如可以直接把大数据的一些东西塞到里面。然后还可以去接一些其他系统，比如要去监控。可以把事件分装成普罗米修斯的指标，然后直接放大出来,所以这是 EDA 架构。
（3）发现一个问题，在 EDA 架构里面，事件是可以被无限放大，可以投递到任何端。比如即使再去新建一个类似于事件接收方，也是可以的，比如这个业务满足不了诉求，短信满足不到诉求，需要建一个钉钉,那这块就只需要配置一个定业的规则。然后就有一个新的接收方叫钉钉,但是在传统架构里面，就要把这个业务给重写,这套电路是完全不负用的，可能要重新写一些东西或自己去管理 controller 控制器，然后把它分发。这个基础逻辑是非常复杂的，所以这是 EDA 架构和传统架构区别,EDA 架构可以完全横向扩展。假如完成了事件接收方接入，下游端应该是任何的应用，下游的一些系统。这是 EDA 架构和传统架构的区别。
