EDA 事件驱动架构与 EventBridge 二三事

这篇文章很早之前就想写出来了,迫于对时间管理不到位一直被滞后。等真正要上前给人讲东西的时候才开始准备。这里就先当作一个记录吧。其实大部分人对去架构趋势,架构理解都是比较多的。这里也只是以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)其实有三个比较重要的能力:

  1. For Event Capturing(事件收集):具备采集事件的能力
  2. For Routing(事件路由):通过事件内容将事件路由分发至于下游的能力的
  3. 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场景的介绍,欢迎大家前来观看。。