这篇文章很早之前就想写出来了，迫于对时间管理不到位一直被滞后。等真正要上前给人讲东西的时候才开始准备。这里就先当作一个记录吧。其实大部分人对去架构趋势，架构理解都是比较多的。这里也只是以EDA架构为引子，引出一些关于产品和技术趋势的思考。我们开始吧！
当下比较成功的企业已然认识到，要想最大限度提升运营效率和客户体验，务必将业务和技术两方面的举措紧密结合起来。运营事件或业务形势的变化是时下众多企业关注的焦点，这些变化能够为企业领导者带来切实有用的信息，而架构设计的主旨恰恰是从客户联系人、交易、运营等方面的信息中获取洞见，两者相辅相成。传统技术历来对企业从事件中获取洞见的速度有着诸多限制，比如用于记录、收集和处理此类事件的批处理 ETL（提取、转换、加载）。
事件驱动型架构 (EDA) 方兴未艾，作为一种 Serverless 化的应用概念对整个云原生架构具有着深远影响。当我们讨论到一个具体的架构时，首当其冲的是它的发展如何，是否具有技术先进性。为了保证文章更有带入感，我会先从我们熟悉的MVC架构，SOA架构谈起。所以这里我们先聊一聊关于消息事件领域的历史与发展趋势。
消息事件领域的发展趋势
上面这张图其实是去年云栖大会 EventBridge 产品发布时的一张宣讲图。早在 2018 年，Gartner 评估报告将 Event-Driven Model 列为10大战略技术趋势之一，事件驱动架构（EDA）将成为未来微服务的主流。该报告同时做出了以下断言：
- 到 2022 年，事件通知的软件模型将成为超过 60% 的新型数字化商业的解决方案；
- 到 2022 年，超过 50% 的商业组织将参与到事件驱动的数字化商业服务的生态系统当中；
很喜欢 George Santayana 在《 The Life of Reason》说的一句话 Those who fail to learn History are doomed to repeat it.（不懂历史的人注定会重蹈覆辙）。我们以史为鉴，来看看为什么会架构会演进到事件驱动。
上图，是我总结的关于架构演进时间轴线。架构本身没有优劣之分，它本身就是一组技术决策，决定后续项目的所有功能开发（框架，编码规范，文档，流程….），所以这里我们不谈选型好坏，只谈为什么会引入某些框架，这个框架解决了软件开发中的什么问题。
- 单体架构：在单节点服务中，单体应用的所有模块都封装在单个进程运行，通信通过相同堆栈调用完成。这种模式下非常容易导致结构和关系不明确，难以对系统进行更改和重构。就像一个不透明的，粘稠的，脆弱的，僵硬的 Big Ball of Mud！
- 分层架构：在经典的分层架构中，层以相当谨慎的方式使用。即一个层只能知道它下方层的数据。在随后的实际应用中，更多的方式是一个层可以访问它下面的任何层。分层架构解决了单体架构的的逻辑分离问题，每一层都可以被等效替换，是用层区分也更加标准化，同时一个层可以被几个不同/更高级别的层是用。当然，层也有比较明显的缺点，层不能封装掉一切，比如添加到UI的某个字段，可能也需要添加到DB，而且额外多余的层会严重损害系统性能。
- MVC 架构：MVC 架构产生的原因其实很简单，随着业务系统的复杂性增加，之前所谓“全栈工程师”已经不适用大部分场景。为了降低前端和后台的集成复杂性，故而开始推广MVC架构。其中，Model 代表业务逻辑，View 代表视图层比如前端UI的某个小组件，Controller 提供View和Model 的协调比如将用户某项操作转为业务逻辑等。这里还有很多扩展架构，譬如 Model-View-Presenter ，Model-View-Presenter-ViewModel，Resource-Method-Representation，Action-Domain-Responder 就不在细说了，感兴趣的同学可以wiki搜索下。
- EBI 架构：即Entity，Boundary（接口），Interactor （控制）。EBI架构将系统边界视为完整连接，而不仅仅是视图，控制器或接口。EBI的实体代表持有数据并结束相关行为的实际实体，很类似阿里云的 POP API。EBI 主要还是后端概念，他是与MVC相辅相成的。
- 洋葱架构：洋葱架构是一种低耦合，高内聚的架构模型。所有的应用程序围绕独立的对象模型构建，内层定义接口外层实现接口，耦合方向向中心内聚，所有代码都可以独立与基础设施进行编译和运行。
- SOA 架构：SOA 是Service Orientated Architure的缩写，即面向服务架构。表示每一个功能都是通过一个独立的服务来提供，服务定义了明确的可调用接口，服务之间的编排调用完成一个完整的业务。其实这个架构也是目前架构中最成熟的，日常使用最多的架构模式。
什么是 EDA 架构？
我们聊完之前全部的架构趋势后，在回过头看看什么是 EDA 架构。
EDA 事件驱动架构( Event-Driven Architecture ) 是一种系统架构模型，它的核心能力在于能够发现系统“事件”或重要的业务时刻（例如交易节点、站点访问等）并实时或接近实时地对相应的事件采取必要行动。这种模式取代了传统的“ request/response ”模型，在这种传统架构中，服务必须等待回复才能进入下一个任务。事件驱动架构的流程是由事件提供运行的。
上图其实很好的解释了EDA架构的模型，但是其实还不够明确，所以这里我们和单体架构一起对比看看他们之间差异。
在如上对比图中，我们其实可以较为清楚看到它与传统架构的区别。在一般传统架构中，创建订单操作发生后，一系列的操作其实都是通过一个系统完成的。而事件驱动的概念则是将全部操作都转换为 “事件” 概念，下游通过捕获某个 “事件” 来决定调用什么系统完成什么样的操作。
总结来看，事件驱动其实是将比较重要的业务时刻封装成“事件”，并通过某个EventBus将事件路由给下游系统。
那这样我们了解EDA架构的整个处理过程，但是还没解决这个所谓的“EventBUS”到底是啥样。
上图就是事件驱动的核心逻辑架构。是不是非常像某个传统 MQ？别着急，下面我会讲到这个架构的复杂部分。
讲完 EventBus，我们回过头来看“事件”，刚刚介绍中比较重要部分其实是将操作转换为某类事件进行分发。那这的事件我们怎么定义呢？
简单来看，其实事件就是状态的显著变化，当用户采取特定行动时触发。以4S店售卖汽车为例：
- 当客户购买汽车并且其状态从 For Sale 变为 Sold 是一个事件。
- 成功交易后，从帐户中扣除金额是一个事件。
- 单击预订试驾后，从将预约信息添加到指定用户就是一个事件。
每个事件都可能触发一个或多个选项作为响应。
关于事件其实云原生 CNCF 基金会在2018年托管了开源 CloudEvents 项目，该项目旨在用统一和规范的格式来描述事件，来加强不同的服务、平台以及系统之间的互操作性。在该项目定义下，通用的事件规范是这样的：
事件主要由 Json 体构成，通过不同字段描述发生的事件。
EDA 架构的落地实践思考
在开始介绍落地实践时，我们先来看一个经典的 EDA 架构模型：
这是一个非常经典 EDA 订单架构，该架构主要使用了 EventBridge 和 FC 函数计算（如果不太熟悉 FaaS 的同学可以把FC节点当作 ECS 或 K8s 的某个POD节点），通过事件驱动各个业务进行协作。
所以这块的中心节点（EventBridge）其实有三个比较重要的能力：
- For Event Capturing（事件收集）：具备采集事件的能力
- For Routing（事件路由）：通过事件内容将事件路由分发至于下游的能力的
- For Event Processing（事件过滤/替换）：对事件进行脱敏或初步过滤&筛选的能力
通常情况下，要实现这三个能力是比较困难的，比如： Event Capturing 可能需要熟悉 Dell Boomi, Snaplogic, MuleSoft, Dataflow, Apache Apex 等，Routing 部分可能通过 RocketMQ，RabbitMQ, ActiveMQ, Apache Kafka ，Event Processing 需要了解 Apache Storm, Apache Flink 。所以之前讲的逻辑架构其实非常理想，要想实现完成的 EDA 事件驱动还需要包括这些核心能力。
其实，从刚刚的架构中我们也能窥探到一些信息，EDA 架构其实看起来没有那么简单，那它有何优劣呢？下面我就简单罗列下EDA 架构在实践中的优势：
松耦合：事件驱动架构是高度松耦合且高度分布式的架构模型，事件的创建者（来源）只知道发生的事件，并不知道事件的处理方式，也关心有多少相关方订阅该事件。
异步执行：EDA 架构是异步场景下最适合的执行工具，我们可以将需要事件保留在队列中，直到状态正常后执行。
可扩展性：事件驱动架构可以通过路由&过滤能力快速划分服务，提供更便捷的扩展与路由分发。
敏捷性：事件驱动架构可以通过将事件分发至任何地方，提供更敏捷高效的部署方案。
当然，劣势也很明显：
架构复杂 事件驱动架构复杂，路由节点多，系统结成复杂，功能要求多。
路由分发难 事件路由及分发难，灵活的事件路由需要依赖强大的实时计算能力，对整体分发系统要求较高。
无法追踪 事件追踪是整个EDA架构保证，EDA 架构中往往很难追踪到事件处理状态，需要大量的定制化开发。
可靠性差 事件驱动由于需要多系统集成，可靠性通常较差，且交付无法保障。
阿里云 EventBridge 如何解决 EDA 场景下的困境
针对 EDA 场景下面临的这些问题，阿里云推出了 EventBridge，一款无服务器事件总线服务，其使命是作为云事件的枢纽，以标准化的 CloudEvents 1.0 协议连接云产品和应用，应用和应用，提供中心化的事件治理和驱动能力，帮助用户轻松构建松耦合、分布式的事件驱动架构；另外，在阿里云之外的云市场上有海量垂直领域的 SaaS 服务，EventBridge 将以出色的跨产品、跨组织以及跨云的集成与被集成能力，助力客户打造一个完整的、事件驱动的、高效可控的上云体验。
架构复杂：提供业内通用的 Source ，Buses，Rules，Targets 模块管理能力，同时支持 EventBus 和 EventStream 两种模式。大幅度降低事件驱动架构难度。
路由分发：EventBridge 通过事件规则驱动，支持8大事件模式，4重转换器，满足路由分发的全部诉求。
无法追踪：独家提供事件追踪能力，事件分析/查询能力。为用户完善整体事件链路。
可靠性差：支持DLQ/重试机制，大幅度保证由于用户下游系统导致的事件故障与延迟。
同时，在此基础上 EventBridge 支持82种阿里云产品，847 种事件类型。
更多产品功能介绍，可访问 EventBridge官网
阿里云 EventBridge 更多场景介绍
1. 经典EDA事件驱动：事件总线（EventBridge）最重要的能力是通过连接应用程序，云服务和 Serverless 服务构建 EDA（Event-driven Architectures） 事件驱动架构，驱动应用与应用，应用与云的连接。
2. 流式 ETL 场景：EventBridge 另一个核心能力是为流式的数据管道的责任，提供基础的过滤和转换的能力，在不同的数据仓库之间、数据处理程序之间、数据分析和处理系统之间进行数据同步/跨地域备份等场景，连接不同的系统与不同服务。
3. 统一事件通知服务：EventBridge 提供丰富的云产品事件源与事件的全生命周期管理工具，您可以通过总线直接监听云产品产生的数据，并上报至监控，通知等下游服务。
更多 EDA 场景欢迎各位探索。
预告：10月16日，本人将在北京为大家分享 EventBridge 的相关落地与EDA场景的介绍，欢迎大家前来观看。。
