SOA EDA 事件驱动架构 (Event-Driven Architecture，EDA) 简介

时间  2019-11-20
标签 soa eda 事件 驱动 架构 event driven architecture 简介 栏目 微服务 繁體版
原文   原文链接

 

事件驱动架构 (Event-Driven Architecture，EDA) 简介

能够从两个方面来理解 EDA：php

  1. EDA 是一种侧重于以生成/消费为基础的异步通讯的架构模式。这主要对照于传统的基于线程的同步系统。
  2. EDA 是一种以事件 (event)为核心，提供事件产生，路由，消费已经结果回调等机制的架构模式。

 

简单地说， 面向服务架构 (Service-Oriented Architecture, SOA) 是一种 IT 架构策略，其基于面向服务的概念之上。自从 2002 开始为你们熟知以来，SOA 已经逐渐地成为业界的标准，也获得了普遍的应用。html

SOA != Web Serviceweb

由于 SOA 常常和 Web Service 相提并论，因此致使你们一直有一个误区，认为这二者是等同的，其实否则。虽然二者有不少的关联，但它们是大相径庭的两个概念，或者说考虑问题的角度不一样。虽然 SOA 最初的流行离不开 Web Service 的贡献，但现在 SOA 早已超越了 Web Service 的范畴，变成一个独立的设计理念。安全

SOA 的局限性架构

SOA 主要从系统解构的角度入手，它侧重于将整个应用分解为一系列独立的服务，并指定各类标准和基础设施来使得这些服务易于重用，可以很容易地被各类平台上的应用来使用。可是在服务实际业务时出现了一些问题，由于 SOA 更多地是关注静态的信息，因此不能很好地与动态业务匹配。好比 SOA 不能很好地回答相似下面的一些问题：并发

好比在一个证券公司，有很完善的交易系统、后台系统、帐务系统和头寸管理系统等，当一个客户的下单在交易所执行后，全部的这些系统都应该获得通知，并作出相应的处理。这里面其实包含了几个问题：谁来负责触发这样一个事件，各个系统如何获得通知？如何保证各个系统行动的一致性？ SOA 架构因为其关注点的限制，并不能很好地解决上述问题，而这些问题每每又是实际系统很是须要的特性。所以，EDA 与 SOA 的集成引发了人们的注意。app

经过引入面向事件的机制，使得系统具有了感知和快速响应业务事件的能力。其实无论是 SOA 仍是 EDA 都不是什么新技术，无非是在一些旧的概念上添加了一些新元素。框架

什么是事件（Event）？

事件就是状态的显著变化，好比说前面提到的客户下单被执行。历来源来分，事件能够分为系统内部事件和外部事件。从类型来分，能够分为业务事件和系统事件。异步

其实你能够从 SOA 或 EDA 的身上很容易看到之前的技术 ( 好比 CORBA 或者 DCOM) 的影子。任何系统均可以简化为组件 / 服务加上通道 (channel，解决通信的问题 )，若是说 SOA 关注于组件和服务的话，那么 EDA 更多地关注通道。ide

 

回页首

Event-Driven SOA

咱们通常将 SOA 和 EDA 的集成体称之为事件驱动的面向服务架构 (Event-Driven SOA)，能够将其理解为 SOA 的一种衍生。SOA 和 EDA 的交互主要体如今如下几个方面：

将事件处理的能力引入到 SOA

一个事件的产生能够触发一个或多个服务被调用，这样就把这些静态的功能动态地串联起来。

服务自己也能够产生事件

服务除了完成特定的功能外，也能够根据自身须要产生某个事件。

有人将 EDA 和 SOA 的关系与人体作了一个形象的比喻，若是把 SOA 比做手和脚的话，那 EDA 就像人的眼睛和耳朵。当眼睛发现一只狮子正朝你奔来时，一个消息被发送到大脑，而后大脑向你的手脚发出指令：赶快跑。

 

回页首

Event-Driven SOA 架构的特色

固然，任何一种架构模式都有其适用的场景，Event-Driven SOA 天然也不例外。

首先，它适用于异步的环境。若是你的系统对实时性要求比较高，请不要使用该架构。

第二，若是你的系统须要面对复杂的异构环境——跨平台 / 跨语言，那么面向服务的架构可以很好地应对。

第三，将系统功能分解为适当粒度而且重用性高的一个个服务，能够显著地提升 IT 系统的适应性和效率，进而提升投资回报率 (ROI)。

第四，引入事件处理的能力之后，每一个服务都是由不一样的事件驱动，这样当某个事件发生后，系统的不一样服务就可以自动地进行触发。这对那些有更高自动化要求的系统来讲很是适合。

第五，与面向过程的系统中客户端必须轮询更改请求 ( 经过 API 调用 ) 不一样，事件驱动架构容许系统和组件在事件发生时实时动态地作出响应。事件驱动架构经过引入长时间运行的处理功能来弥补 SOA 的不足。这一点对于金融系统来讲尤为重要，好比说一次股票买卖从客户下单到最终交割会经历几天的生命周期。

最后，Event-Driven SOA 使得增长事件的 consumer 和 producer 很是容易，这样就使得增长系统吞吐量也变得很简单，系统的弹性很是好，很是适合那些业务量持续增长的系统。在这方面，有一个 EDA 的变体 SEDA（Staged Event-Driven Architecture）将这方面的设计发挥到了极致，详细的介绍请参考正文后的参考资料。

 

回页首

Event-Driven SOA 在金融系统的应用

金融系统的实际需求

在当今社会，市场变化莫测，商机稍纵即逝，企业须要有极强的灵活性和应变能力，金融行业尤为如此，特别是在中国这样一个金融行业处于快速发展的市场里。企业要求 IT 系统可以快速地对业务需求作出应对，不然就会丧失先发优点。这有点相似于现代战争条件下，各国都要求部队具有快速反应能力，这种能力主要体如今 IT 部门可以经过快速开发或者重用 / 整合现有资源来达到快速响应业务需求。还有，金融行业业务愈来愈庞大复杂，所涉及的第三方系统或者遗留系统很是多，这就要求 IT 系统有很强的整合能力及对异构环境的适应能力。最后，因为金融行业的发展突飞猛进，特定金融业务都会在其初期发展后迎来一个快速膨胀期，业务量和业务类型会急剧增长，这也要求 IT 系统有很好的可扩展性。

对照前面提到的 Event-Driven SOA 的特色，咱们能够很直观地发现该架构能够很好地知足金融系统的实际需求。固然，金融系统也是一应俱全，特色各不同，这里可能更偏重于金融行业的交易系统。

为何选择 Event-Driven SOA ——适用性讨论

除了上面提到的这些大的因素以外，咱们还能够深刻到具体系统的内部，从一些微观层面来考虑 Event-Driven SOA 是否仍然可以符合咱们的要求。下图是一个证券公司股票交易系统的简图：


图 1. 证券公司股票交易系统概略图
图 1. 证券公司股票交易系统概略图 

从上图咱们能够看出，整个应用被分为不少子系统，各个子系统之间存在着大量的信息交互。并且大部分应用输入都须要经历一个比较长的生命周期，好比说一个客户订单输入到系统后，会前后经历前台系统 (Front Office)，中台系统 (Middle Office) 以及后台系统 (Back Office)，并且每一个系统内部又包括不少服务组件。除了系统层面的跨度外， 这个生命周期也体如今时间长度上。并且，现在全部的金融系统都追求 STP (Straight Through Processing) 的能力，主张尽量少的人工干预，这样全部的服务组件都须要具有自触发的能力。

 

回页首

Event-Driven SOA 架构设计

架构师在着手每次的架构设计时，其实都是在提出并回答一系列的问题，把这些问题都回答了，架构设计也就出来了。好比咱们每次确定都会问：系统的最终用户是谁，他们会如何来使用该系统，他们的核心诉求是什么。固然，不是全部的问题都能有一个圆满的答案，更多的时候实际上是一个取舍的过程。好比说系统的关键指标咱们很难一会儿所有知足，就须要结合具体的业务需求和人力物力以及时间的具体状况来作取舍。下表就列出了一些我在作 Event-Driven SOA 架构设计时认为比较关键的问题（在遵循通常架构设计的原则的基础之上），看看你是否也有同感。


表一：Event-Driven SOA 架构设计时的几个关键考虑

领域 关键考虑
设计原则 业务为先
坚持简单适用的原则
系统的关键指标有哪些？互联互通最重要
设计演变 功能分解，服务定义，事件的定义及分类
基础架构的选择
EDA 的实现途径
最佳实践 如何重用已有的基础组件

 

下面我就其中的几点具体展开讨论一下：

业务为先

任何的技术或者架构思想都是由具体的业务需求驱动的，好比 SOA 的出现是因为人们打破竖井应用 (application silos) 并追求功能重用的强烈需求，而 EDA 的出现也迎合了业务流程化、自动化的趋势。因此，任何的架构设计都要服从于自身业务的具体需求，没有最好的架构设计，只有最合适的。

在 SOA 实践中，尤为强调业务为先的原则，由于咱们必须先进行业务流程的整合重组，而后才是 IT 系统的服务化。业务流程自己的问题仍是须要从业务自己去解决，再好的技术也解决不了业务的问题。试想一下，若是一个企业各个部门之间各自为战，缺少协做和沟通，那么可能开发出一个好的面向服务的 IT 系统吗？

除了业务部门的努力外，IT 部门在作任何架构设计的决定前，必须确保理解清楚了业务部门的具体需求。因此说，项目前期 IT 部门和业务部门之间的协做和交流很是重要。

这里很容易有一个误区，尤为是对那些经验丰富的架构师。他们每每拥有丰富的 IT 经验和业务知识，自认为已经很是了解业务部门的需求，甚至有些时候都可以指导业务部门如何去改进。在这种自负的情绪中，他们以为能够先把所谓先进的 IT 系统开发出来，而后再去推广，他们认为用户确定会欣然接受这些系统，由于他们表明着先进的理念，但每每事与愿违。姑且不去深究究竟孰对孰错，退一万步讲，一个没有充分听取用户意见，没有用户参与的系统可以那么容易获得用户的承认吗？即使你是对的。

互联互通

在 Event-Driven SOA 的实施过程当中，有几个关键指标：服务的分类和建立，事件的定义和管理，服务的互联互通，业务流程的理解和 IT 实现等。那咱们应该更加关注哪一个指标呢？由于咱们每每很难一会儿兼顾全部的指标。我的认为这其中最重要的就是服务的互通互联。固然这里所讲的互通互联并无那么简单，并非仅仅创建起通信的通道就能够，它包括如下几个方面的内容：

  • 不管通信的方式如何，最好作到自动化

实现通信的方式有不少种：同步调用，异步消息，Socket 甚至是文件，不管采用哪一种，最好作到自动化的实现。任何人工的干预都容易引发错误和延迟。

  • 通信的双方之间须要定义清晰的接口，有共同的异常应对机制

特别是当通信的双方是由不一样的开发团队来完成，必定要在开始阶段就定义清楚接口，并在随后的开发过程当中严格遵照，同时保持实时的沟通。这里面须要强调的一点就是异常的应对机制，要让双方都充分理解可能面对的异常状况及应对措施。

  • 基础数据的共享

在金融系统中，会用到大量的基础数据（通常称之为 Reference Data），这些数据在各个系统都会用到。但事实上状况每每并不如此，常常是各个系统各自为战，不用或者是使用不一样的数据源，致使在通信过程当中的识别歧义。

作到以上这些，技术上并不困难，更重要的是项目之间的协做和执行力强的领导团队。

结合到实际的例子，好比美国三军联合做战系统，其核心就是其“数据链”系统，它使得战场上的指挥中心、做战部队和武器平台可以实时交换数据，达到精确协做的目的。从下面这段描述咱们就能感觉到这种高效无缝协做的威力：

“在 7 年以后的海湾战争中，初级的“数据链”就已显威战场。以美军拦截导弹做战为例，就能够看到“数据链”的做用。伊军的“飞毛腿”导弹一发射，12 秒钟以后，位于太平洋上空的美国防支援计划（DSP）的导弹预警卫星就发现了“飞毛腿”，并迅速测出它的航行轨道及预约着陆地区，报警信息及有关数据迅速传递到位于澳大利亚的美国航天司令部的一个数据处理中心，数据中心的巨型计算机紧急处理这些数据以后，获得对“飞毛腿”导弹进行有效拦截的参数，而后航天司令部将这些参数经过卫星传给位于沙特阿拉伯的“爱国者”防空导弹指挥中心。防空导弹指挥中心马上将数据装填到“爱国者”导弹上并发射，整个过程只须要 3 分钟左右的时间，而“飞毛腿”至少要飞行 4 ～ 5 分钟才能到达预约目标的上空，这就为拦截导弹创造了条件。…”

设计考虑

在明确了以上这些设计原则外， 咱们须要一步步考虑整个架构的实现途径。首先面临的就是一些基础架构的选择。

  • 基础架构的选择

在这里咱们须要回答一系列的问题：本身开发仍是购买？开源的仍是商业的？选择什么 Web Service 的基础平台？选择什么样的消息中间件（Message Oriented Middleware, MOM）？是否采用企业服务总线（Enterprise Service Bus, ESB）？

这其中讨论的最多的就是是否以及如何使用 ESB。我的观点，ESB 是有价值的，仅当系统确实须要 ESB 的功能时。Accenture 首席技术官 Don Rippert 在他的一次早期访谈中提到发挥 SOA 的所有潜力大体须要如下 4 个步骤：

  • 开始采用 SOA 架构，使用 XML 等标准的方式来使用应用程序接口
  • 捕获一些业务过程，并将它们转化为 Web 服务
  • 引入并全面使用企业服务总线
  • 将业务过程执行语言（Business Process Execution Language, BPEL）集成进来，利用业务过程建模工具和 BPEL 能够建立不一样的应用行为，而无需修改软件

为何将 ESB 的使用放在第三个步骤呢，那咱们须要从 ESB 的定义入手，来了解 ESB 究竟带给咱们些什么。ESB 应该被理解为模式而不是产品，它应该至少具有如下这些功能：

  • 服务的虚拟化，支持虚拟化通信参与方之间的服务交互并对其进行管理。意思就是服务只须要关注完成本身的功能，不须要关心哪一个服务调用它以及它须要调用哪一个服务。
  • 服务的转化、包装以及桥接
  • 消息的传递、过滤以及路由
  • 服务编制（Orchestration）

还记得前面将 EDA/SOA 和人体进行类比的例子吗？若是按照该思路，ESB 就能够看做是人体的中枢神经系统。其接受眼睛传入的“狮子来了”的信息，总体加工后成为协调的运动性传出，手脚也就开始动做了。

从上面的定义能够看出，ESB 更多地关注应用流程方面的信息，将业务流程剥离出来并将其交由 ESB 来统一管理。所以，有一个很是简单的标准来判断是否须要采用企业服务总线：就是看你的应用自己是否有很复杂的业务流程，并且可能这些流程会常常发生变化。依据这条标准，我以为不少应用一开始都没有复杂到须要当即采用企业服务总线，好比说一个股票的后台管理系统，其业务流程相对来讲比较简单固定，就没有必要引入企业服务总线这样重量级的解决方案。

固然，ESB 中分解流程信息的思想咱们仍是能够借鉴的，只不过咱们能够用更简单的方法来实现。

  • EDA 的实现途径

在 EDA 中，按照事件简易程度的不一样，事件处理模型能够分为如下三种：

    • 简单事件处理 (Simple Event Processing)
    • 流事件处理 (Stream Event Processing)
    • 复琐事件处理 (Complex Event Processing, CEP)

在一个成熟的事件驱动架构中，这三种每每会混合在一块儿使用。目前，不少公司都推出了支持 CEP 功能的产品。可是在实际应用过程当中，咱们仍是须要秉承由简入繁的原则。能用简单的事件处理解决问题，就不必使用复杂的。

实现事件驱动架构最简单、直观的方式就是使用消息。在 JMS 的体系架构里，咱们很容易来实现事件驱动的一些基础元素：事件的生产者、消费者和通道。下图为在发布 / 订阅模式下，消息发布者、订阅者以及消息通道和主题之间的交互。


图 2. 一个发布者、多个订阅者、事件通道和主题之间的交互
图 2. 一个发布者、多个订阅者、事件通道和主题之间的交互 

（图片来自 http://www.ibm.com/developerworks/cn/opensource/os-ag-eventdriven/index.html）

严格意义上来讲，事件和消息是不一样的概念。消息表明非直接交互时简短的信息，而事件每每表明状态的显著变化。能够把事件看做消息的子类，由于后者还包括包含数据的消息等。并且，在实际应用中，一个消息中每每同时包含事件和数据的内容。好比系统接收客户的订单后，它会发布一条消息：其中既包括事件（新增客户订单），又包括新订单的具体数据。

基础组件

在肯定了系统的架构后，咱们须要着手来实现它。通过这么多年的实践，人们也总结出一些基础的组件，这些组件对于事件驱动的面向服务架构来讲是必不可少的，或者说常常被使用到的。

  • Web 服务基础架构 （XML，SOAP，WSDL，UDDI 和 Quality of services）
  • 企业服务总线（针对复杂应用）
  • 消息中间件
  • 监控体系
  • 异常处理的讨论
  • 配置和规则引擎

其中第1、二项你们讨论得最多，第三项也常常被说起。做为消息运转的基础，消息中间件（Message-Oriented Middleware，MOM）必须作到安全、可靠和快捷。市面上有不少很成熟的产品，好比 WebSphere MQ，Apache ActiveMQ 等。并且还有些针对特定行业的特点化产品，好比 WebSphere MQ Low Latency Messaging 是一款专门针对金融行业的中间件，用来知足高吞吐量、低延迟的业务需求。

然后三项讨论的并很少，但这些对于咱们的应用来讲又都是很是关键的。我会在后续的文章中逐一进行介绍。

图 3. 各个子系统和基础组件之间的协做
图 3. 各个子系统和基础组件之间的协做 

 

回页首

结束语

采用某个概念很是简单，咱们实际须要的是如何结合自身项目的实际需求，真正地利用这些概念背后那些好的思想。利用这些智慧结晶来解决面临的问题，这就须要你们多从实际出发来思考问题。不少时候，过多的概念只会让你更加混淆，咱们真正须要记住的不是这些名词，而是这些名词背后的思想——这些在软件架构中一直被传承的东西。

 

参考资料

学习

得到产品和技术

讨论

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程