开发者学堂课程【EventBridge 入门课程 ：EventBridge 事件总线及 EDA 架构解析（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1220/detail/18276
EventBridge 事件总线及 EDA 架构解析
内容介绍：
一、事件及事件驱动介绍
二、概述
三、核心能力
四、产品特性
五、事件分析平台
六、应用场景
七、使用案例
一、事件及事件驱动介绍
1. 趋势演进
本次直播将会大家将使用实践总线的概念以及 eda 架构的一个详解，直播课程是我们系列课程的第一部分，后续我们还会有更多内容为大家来做一些详细的介绍，第一个方面叫做 event bridge 事件总线，就是我们阿里云推出的的实验总线的一个产品，第二部分就是 EDA 单点架构运营追问的一个架构详解，为大家去介绍事件驱动架构到底是什么，他在生产环境中到底是这样使用的。
第一部分的内容，就是事件及事件驱动的具体的介绍，首先可以看到我们 PPT 上其实有一个叫做驱动演进的一个架构图，
这部分图其实是详细阐述了软件发展历史，还有包括在发展过程中可能经历的一些阶段，第一个阶段我们找本体架构，整体架构其实是最简单的加1/5，因为他是现有的一些类似于加固方式，其实都是从一个单体架构来的，比方说我把所有的服务，然后全都一股脑的找一个当地机里面。单体架构其实有一个名词叫锯齿架，单体架构其实是非常原始的一个架构。第二部分叫做分层架构，分层架构其实也是基于单体架构的一个演进，在分层架构中，其实一个层其实只知道正下方的一些信息，然后分子塔架构解释，或者是说他的优势，就是比如说将我们的一些类似系统，然后做了一些成绩的一个服装，然后让他更轻便，更好用。
那么最后还有一部分就是我们的 mvc 的架构，mvc 架构它解决的问题其实是前后端关注点的分离，因为之前其实在架构或者是叫分寸架构，他其实是没有做胶杆分离的，会导致前端和后端的充电线不太明确，导致我们类似于封沟，还有包括我们类似于的一些架构的一些组织方面会有问题。那么 mvc 他是解决了前后端架构分明的一个东西。那后面叫做一般架构，相对于 mvc 来讲，它其实是将边界视为外部世界的一个完整链接，他不仅仅是试图控制器或者是一个接口，所以他这个架构，在我们的整体的生产使用中可能很少听到，那一般架构他最早也是出现在一个论文里。后面是洋葱架构，洋葱架构其实是进步做类似于分离职责的一个演变，然后提供那种高内聚，还有包括高配区的一个类似于架构的一个模型，提供更多，比方说我们的可观测性，还有包括我们的可扩展性洋葱架构，在我们确切实的一个类似于我们的生产环境，还有包括我们做一些架构设计的时候也是比较长常容易用到的一个类似于加工模型，后面的话就是我们比较熟悉的 oa，就是面向用户，还包括应用程序，然后他是很适用的，可组合的，技术占独立的一个加工模型。
2.eda 架构的概述
后面是 eda 架构的一个概述，那个 eda 架构它其实是一个类似于系统加工模型，然后他主要的核心能力在于发现系统事件，或者是业务这个关键时刻，这个关键时刻其实有几点，
比方说我们的景点，比方说我们的站点访问或者是说我们可能去触发到的某一个类似系统操作，都是比较关键的时刻，这些时刻需要去实施或者进食时的对相应的事件采取内容，我们可能会关注到，比如说用s的东西应该清楚，可能会关注到某一个 qs 的节点要去除，这个驱逐的话可能会对加油产生一些问题，所以我们可能会捕获到类似于建区组织事件，所以说这些业务可能是我们业务时刻，在业务架构的时候，也有可能是系统架构的一个市场。它其实是有两个部分构成的，其实这部分事件是取代了我们原有的请求响应的一个模型，因为在我们传统的架构中，服务必须得等待返回，我们才能进行下一个任务，那一点它其实是不需要返回的，他其实通过一个生产者，比方说这个生产者可能就是某一种系统，然后我去产生了一个实践，在某时某刻，然后我的客户购买了一部手机。
我把这个事件然后发送到一个叫做不可被揭露或者是教育的一个地方，然后他可能会有很多的考虑，其实只要做的就是被动去接受这个原子，然后去做一些类似于消费的一些操作，所以说其实我们会发现eda架构，他的模型其实是增加了一层缓存节点，然后去取代我们类似于我们传统的请求和响应。那这样做的一个优势就是说我们其实是可以把我们的统做更高维度的一个结构，就比方说可能订单系统之前申请有响应的模式，那可能必须得等到后端服务返回的一个正确结果，然后才能去执行下面的这些东西。
那通过一列下去指令之后，其实可以把这个事件或者是找消息记录下来，然后再通过类似于的一些时间规则，还有包括世界的一些方法，然后做更多后续的一个处理，那这个其实是eda架构的一个比较核心的一个优势。
3.Eda 架构与传统架构的区别
再去看一下 eda 架构和我们的传统架构的一个具体区别，eda架构其实我们以一个类似于主单提交的 case 的一个主力，eda 架构其实可以看到这个点，第一个点其实是用户，然后在传统情况下，用户创建订单会操作了一个新订单，后面可能会有一个单体或者叫做 sv 的 oa。一个类似于这个模型，帮助他去把一些类似于什么订单服务从0~1创建，比方第一步去新建一个订单，第二步去操作记录，去写一个数据库，然后第三步给用户去发送一个短信，告诉他这个订单已被支退提交了。
传统模型是完全有合的，就是说其实我先建了新建订单，然后才能去超出库，然后我才能去发短信会，或者是说假如如果有一段挂掉了，就比方说这块儿可能写的不太全，我们可能还有两个通知模型，我有短信通知和邮箱通知，那我可能先去操作短信通知，发现等短信通知完成之后呢，那就是他没办法去进行到类似我们下一步的一个项目，所以说这个其实是传统架构的一个弊端。
我们这边的订单服务基本上是不可被揭露的，就是说不可被我们复用的，假如我要去灵活的去添加一些其他音乐或者是添加一些其他操作，那其实我需要把整个论坛服务，然后完全打碎，然后重新去做，然后在eda架构里面，这件事情就会非常简单，因为用户他只要去操作创建一个订单，我们可能也会有一个订单服务，但是这个订单服务可能创建完了之后它会发送一个原子，这个事件也叫做静态创建，然后他发送给后端的一个服务商，比方说这个服务可能就要通过油画，把这个事件就是我们订单创建完成的这个事件，分发给类似于下游的一些系统，可能要去记录一下一些创建订单的一些信息，然后把订单信息记录完之后，我可能要对用户这一些短信通知或者是最新通知。做一些类似于邮箱通知等一系列的一些东西，所以说这边的话其实就是一点架构和传统架构的这种区别，我们其实清楚的看到，其实通过 eda 架构的结构，这部分的内容其实是完全可以无缝去拓展的，比方说去加个钉钉很简单，加个邮箱也很简单，甚至是可以把这条事件存到于我们的上面的，这些都是可以的，这就是 eda 架构和传统架构的一个主要的一个区别。
4.什么是事件
什么是事件，用户或者是我们的应用系统有某时某刻的一些类似于显著变化或者叫状态变更，把它叫做事件，可以举一个例子，以4s 店售卖汽车为例，当我们的一个购买汽车的一个售卖状态发生变更的时候，他其实就是一个事件，当我们成功交易之后，然后从账户里面去扣除部分的金额，其实也是一个事件。然后当我们去提交某一个预定试驾的一个信息之后，然后将预定剩下的一些信息，然后指定到某个用户，他这个也是一个事件，然后保存用户，我们其实是可以跟对用户做一些类似短信，都是可以通过类似于分装一个完整的一个事件体制作。扩展一下，就是说在我们的右图里面看到我们这边的一个事件的一个详细的一个情况，其实事件其实在原生领域它其实是有一个标准，也是比较规范的一个协议叫做问题，其实这个的协议它其实就是规定了事件所涵盖的一些内容，比方说我们的第一部分，这部分内容其实就是事件的一个版本号，type 可能就是我们的一个中距离的类型，我们硕士就是我们的上游端，解决的是我们上端的是谁的一个问题，我们在 jack 其实是对有他的一个细讲述，我们的一个 ID 可能就是他这个东西的唯一标识，包括我们的时间，还有其他比如说 data 或者是类似于描述详细的一点描述，那这个部分其实是构成 eda 事件架构的一个完整形态，但通过去把这些字段给声明完成，然后其实下游系统，其实是完全不用关心上游系统发生了什么事，下游系统只要去接收去处理，然后其实就可以完成对一个事件的具体的操作，所以其实也是事件驱动架构的一个比较核心的一个能力，其实消费者他不用关心生产者到底是谁，甚至不用关心有多少个消费者和他并存，他只要关心我接触到这个试验之后，我应该怎么去处理这个事件，这个其实就是我们整体式驱动架构的一个详细情况。
f
"specversion":“1.0",
"type"："com.github.pull_request.opened",
" source"："https://github.com/cloudevents/spec/pull",
"subject":"123" ,
"id”：“A234-1234-1234",
"time"：“2018-04-05T17:31:00Z",
"comexampleextension1":"value",
"comexampleothervalue":5,
"datacontenttype":"text/xml",
"data":"”
