精华内容
下载资源
问答
  • 事件驱动架构
    千次阅读
    2021-02-01 12:40:00

      

    事件驱动架构

    事件驱动架构(Event Driven Architecture)是一个流行的分布式异步架构模式,可以用来设计规模很大的应用程序。基于这种架构模式应用可大可小。它由高度解耦的,单一目的的事件处理组件组成,可以异步地接收和处理事件。

    一个事件驱动系统典型地由事件消费者和事件产生者组成,事件消费者向事件管理器订阅事件,事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时,事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的,事件管理者将保留这个事件,一段间隔之后再次转送该事件消费者。

    关键概念解释

    事件:系统或组件的状态发生变化时,系统层发出的通知。

    解耦方式:每个对象都通过与中间件(Mediator or Broker)实现与外界的沟通,而不是相互依赖(迪米特法则)。

    通讯方式:以消息为载体、通过中间件传递通讯。

    拓扑结构分类

    它包括两个主要的拓扑结构:mediator 和 broker。

    • mediator拓扑结构

      需要你在一个事件通过mediator时精心安排好几个步骤;

    • broker拓扑结构

      无需mediator,而是由你串联起几个事件。

    这两种拓扑架构的特征和实现有很大的不同,所以你需要知道哪一个适合你。

    Mediator拓扑结构

    Mediator拓扑结构适合有多个步骤的事件,需要安排处理层次。

    采用Mediator模式的架构中,事件一般是复杂的(包含多个执行单元的合集),而Mediator的责任就是将该复合事件拆解为独立的子事件,然后发送到不同类型的子事件处理系统中,由子系统完成独立子事件的分发和处理。

    在结构上,Mediator的EDA架构包括4个组件:

    • event queues

    用于原始事件(分类)存储,并转发给Event Mediator,一般是以MQ的形式存在。

    • event mediator

    用于原始事件的拆解(成为多个独立子事件),并转发给相关的Channel;

    • event channels

    通道(可以理解为细分的Event Queue),按照事件的类型不同作以划分。它可以是一个消息队列,提供给特定的Processor查询,或是消息Topic,发送特定的广播。

    • event processors

    事件处理器,监听特定的Channel,并在捕获事件后进行处理

    Mediator的处理过程如下图所示:

    • 客户端发送一个事件到事件队列(event queues)中,它用来将事件传送给event mediator;

    • Event mediator收到初始的事件后,会发送额外的一些异步事件给event channels来执行处理的每个步骤;

    • Event channels 既可以是消息队列,也可以是消息topic,大部分是消息topic,这样可以由多个消息处理器(event processor)处理同一个消息。

    • Event processors监听event channels,接收事件并处理一些业务逻辑。

    值得注意的是:

    1、在事件驱动架构中有十几个甚至几百个事件队列都很正常。

    2、模式本身没有限定事件队列的实现方式,它可能是一个消息队列,一个web service或者其它;

    3、消息处理器包含实际的业务逻辑。每个消息处理器都是自包含的,独立的,高度解耦的,执行单一的任务。

    Broker拓扑架构

    Broker是一种更简洁的事件驱动架构,不同于上面的结构,它没有中心的Mediator。

    在结构上,Broker的EDA架构包括3个组件:

    • Event

      事件消息;

    • Event Channel

      消息队列或者是Topic,根据订阅推送(或是转发)消息;消息可能被转发到Event Processor,或是其他的Event Channel中。

    • Event Processor

      获得消息后执行处理。它可能是一个消息的处理终结点,也可能在处理过程中继续下发消息,或生成新的事件,并被再次提交到Event Channel中,继续下一轮的转发和处理。

    如图所示,它包含两个组件broker和 event processor。

    • broker中的event channel可以是消息队列,消息topic或者它们的复合形式。

    • 每个event processor负责处理事件,发布新的事件。

    架构考量

    事件驱动架构模式实现起来相对复杂,主要是由于它的异步和分布式特性。这可能会带来一些分布式的问题,比如远程处理的可用性,缺乏响应,broker重连等问题。

    1、分布式的异步架构

    事件处理器之间高度解耦,软件的扩展性好,事件处理器可以独立地加载和卸载,容易部署,同时性能较好,因为事件的异步本质,软件不易产生堵塞。

    2、对于单一的逻辑缺乏原子事务

    此模式需要将原子事务交给一个事件处理器执行,跨事件处理器的原子事务是很困难的,很难进行回滚操作。同时对于事件处理器的创建,维护和管理比较困难,事件通常有特殊的约定(数据值和格式)。

    模式分析

    结合上文分析,事件驱动架构设计模式整体分析如下:

    • 总体灵活性: 高

    • 发布易用性: 高

    • 可测试性: 低

    • 性能: 高

    • 规模扩展性: 高

    • 开发容易度: 低

    - END -


    「技术架构精进」专注架构研究,技术分享

    Thanks for reading!

    更多相关内容
  • 事件驱动架构及应用

    2021-02-27 06:17:50
    Gartner在2003年引入了一个新术语事件驱动架构(EventDrivenArchitecture,EDA),主要用于描述一种基于事件的范例。EDA是一种用于进行设计和实现应用和系统的方法—在这些应用和系统里,事件所触发的消息可以在独立的...
  • 为了解决传统的单体应用(MonolithicApplication)在可扩展性、可靠性、适应性、高部署成本等方面的问题,许多公司(比如Amazon、eBay和NetFlix等)开始使用微服务架构(MicroserviceArchitecture)构建自己的应用。...
  • 软件架构-事件驱动架构

    千次阅读 2021-02-21 21:02:31
    事件驱动架构是一种系统或组件之间通过发送事件和响应事件彼此交互的架构风格。当某个事件发生时,组件A不直接调用组件B,而只是发出一个事件。组件A不知道哪些组件监听并处理这些事件事件驱动架构可以在进程内和...

    软件架构-事件驱动架构

    你好,我是看山。

    本文源自并发编程网的翻译邀请,翻译的是 Jakob Jenkov 的 《软件架构》 中关于事件驱动的内容,虽然是 2014 年的文章,但是从软件架构层面上,并不过时。

    以下是正文。

    事件驱动架构是一种系统或组件之间通过发送事件和响应事件彼此交互的架构风格。当某个事件发生时,组件A不直接调用组件B,而只是发出一个事件。组件A不知道哪些组件监听并处理这些事件。事件驱动架构可以在进程内和进程间使用。比如,GUI框架中会大量使用事件驱动。【译者注:目前很多系统采用微服务架构,事件驱动使用的更加广泛了。】此外,正如我在并发模型教程 中所提到的,装配线并发模型(AKA reactive,非阻塞并发模型)也使用了事件驱动架构。

    本文主要介绍进程之间的事件驱动架构,后文提到这个词的时候也是指进程交互方式。

    进程间的事件驱动架构

    事件驱动架构是一种架构风格,先将请求事件集中存放在一个或多个事件队列中,然后事件从这些事件队列转发到后端服务,处理这些事件。

    因为事件可以被看做是消息流,所以事件驱动架构也被称为消息驱动架构或者流处理架构。流处理架构又可以被称为lambda架构。为了保证统一,后文会继续使用事件驱动这个名词。

    事件队列

    在事件驱动架构中,你会有一个或多个集中的事件队列,所有的事件被处理前,会先保存在集中的事件队列中。下面给出一个简单示例:

    event-driven-architecture

    事件插入队列时是有序的,这样就可以顺序处理这些事件。

    事件日志

    写入事件队列时,消息可能写入到事件日志(通常是磁盘存储)中。如果发生系统崩溃,系统只需要重放事件日志即可恢复到崩溃前的状态。下面是一个事件驱动架构的示例,其中包括一个用于持久化事件的事件日志:

    event-driven-architecture

    我们还可以通过备份事件日志,来备份系统状态。在将新版本的系统部署在生产环境之前,可以使用这个备份数据对其性能进行测试。或者,通过重放事件日志的备份,来重现某些错误。

    事件收集器

    请求都是通过网络传输,比如HTTP或者其他协议。为了保持一致,可以通过事件采集器接收来自不同来源的事件。下面是一个添加了事件收集器的事件驱动架构示例:

    event-driven-architecture

    响应队列

    有时,我们还需要向请求(即事件)返回响应,所以,很多事件驱动架构除了包含事件队列,还会有一个响应队列。下面是包含事件队列(入队队列)和响应队列(出队队列)的事件驱动架构示例:

    event-driven-architecture

    如你所见,响应队列必须路由到正确的事件收集器。比如,如果HTTP收集器(本质上是web服务器)通过HTTP接收的请求发送到事件队列中,则该事件生成的响应可能也需要通过HTTP收集器发回客户端。

    通常,响应队列不会持久化,也就意味着它不会写入事件日志,只有输入的事件才会持久化到事件日志中。

    读事件 vs. 写事件

    如果将所有传入的请求都认为是事件,就需要将这些事件都推送到事件队列中。如果事件队列是实现了持久化(持久化到事件日志中),就意味着所有事件都需要持久化。通常持久化都比较慢,如果我们能够过滤掉一些不需要持久化的事件,我们就能够提升队列的性能。

    我们将事件持久化到事件日志的原因是,我们可以重放事件日志,并重建因为事件引起的系统状态变化。为了支持这个特性,实际上只需要持久化更改系统状态的事件。换句话说,我们只需要将事件分为读事件和写事件。读事件只读取系统数据,不会更改,写事件会更改系统数据。

    通过根据读和写划分事件,我们只需要持久化写事件的消息即可。这将提升事件队列的性能,提升比例大小,取决于读写事件之间的比例。

    为了将事件划分为读写事件,需要在事件到达事件队列之前,也就是事件收集器中进行区分。否则,事件队列无法知道到达的事件是否需要持久化。

    还可以将事件队列拆分为两个,一个用于存储读事件的事件队列,一个用于存储写事件的事件队列。这样读事件就不会慢于写事件,事件队列也不需要检查每条事件是否需要持久化。读事件队列不需要进行持久化,写事件队列始终持久化事件。

    下面是一个事件驱动架构的示例,其中事件队列分为读和写事件队列:

    event-driven-architecture

    上图示例中箭头比较乱,但实际上创建3个丢列并在它们之间分发消息简单很多。

    事件日志重放的挑战

    事件驱动架构的一大优点是,在系统崩溃或系统重启情况下,只需要重放事件日志,就能够重建系统状态。在日志可以独立于时间和周边系统的情况下重放日志,这是一个很大的优势。

    但是,完全独立于时间重放事件日志有时候很难实现。接下来介绍下事件日志重放的一些挑战。

    处理动态数据

    如前所述,写事件处理时可能会修改系统数据。有些情况,这种数据的修改受事件处理时动态数据的影响。比如,处理事件的日期和时间或者特定日期和时间的货币汇率。

    这些动态数据会对事件重放造成困难。如果在不同的时间重放事件日志,处理该事件的服务可能会解析不同的动态值,比如其他的日期和时间或其他汇率。因此,在不同的日期重放事件日志,可能会出现重建系统数据与最初处理事件产生的数据不一致。

    要解决动态数据的问题,可以让写事件队列将所需的动态数据标记在事件中。但是,要实现这种方案,需要事件队列知道每条事件消息需要哪些动态数据。这样会使事件队列的设计复杂化,每次需要新的动态数据时,事件队列都需要知道如何查找这些动态数据。

    另外一种解决方案是,写事件队列只在写事件上标记事件的日期和时间。使用事件的原始日期和时间,处理事件的服务可以查找给定日期和时间对应的动态数据。比如,可以通过原始的日期和时间,查询当时有效的汇率。这就要求处理事件的服务需要基于日期和时间查询动态数据,但是这只是理想状态。

    与外部系统的交互

    事件日志重放的另一个挑战是与外部系统的协调。比如,事件日志中包含电商平台的订单,在第一次处理这个事件时,需要将订单发送到外部支付网关,以从客户信用卡中收费。

    如果重放事件日志,就不希望再次为同一个订单向客户收费。因此,就不希望在事件重放时,将订单发送到外部支付网关。

    事件日志重放解决方案

    解决重放事件日志问题挺不容易的。有些系统没有问题,可以直接重放事件日志;有些系统可能需要知道原始事件的日期和时间;有些系统可能需要知道更多类似于事件原始处理过程中从外部系统获取的原始数据。

    重放模式

    在任何情况下,倾听写事件队列中事件的任何服务都必须知道传入事件是原始事件还是重放事件。这样,处理服务就能够确定如何处理动态数据或者如何与外部系统交互了。

    多步骤事件队列

    另外一个解决方案是采用多步骤事件队列。第一步,收集所有写事件;第二步,解析动态数据;第三步,与外部系统交互。如果需要重放事件日志,只需要跳过第一步和第二步,重放第三步即可。具体如何实现,需要取决于具体的系统设计。


    你好,我是看山,公众号:看山的小屋,10 年老后端,Apache Storm、WxJava、Cynomys 开源贡献者。主业:程序猿,兼职:架构师。游于码界,戏享人生。

    原文链接:Event-driven Architecture
    翻译: https://www.howardliu.cn
    译文链接: 软件架构-事件驱动架构
    CSDN主页: http://blog.csdn.net/liuxinghao
    CSDN博文: 软件架构-事件驱动架构

    公众号:看山的小屋

    展开全文
  • 事件驱动架构模式是⼀一种主流的异步分发事件架构模式,常⽤用于设计⾼高度可拓展的应⽤用。当然了,它有很⾼高 的适应性,使得它在⼩小型应⽤用、⼤大型应⽤用、复杂应⽤用中都能表现得很好。事件驱动架构模式由⾼...

    事件驱动架构模式是一种主流的异步分发事件架构模式,常用于设计高度可拓展的应⽤用。当然了,它有很高的适应性,使得它在小型应用、大型应用、复杂应用中都能表现得很好。事件驱动架构模式由高度解耦、

    单一目的的事件处理组件构成,这些组件负责异步接收和处理事件。 
    事件驱动架构模式包含了两种主要的拓扑结构:中介(mediator)拓扑结构和代理(broker)拓扑结构。 
    mediator 拓扑结构通常在你需要在事件内使用一个核心中介分配、协调多个步骤间的关系、执行顺序时使用;而代理拓扑结构则在你想要不通过一个核心中介将多个事件串联在一起时使用。
    由于这两种结构在结构 特征和实现策略上有很大的差别,所以如果你想要在你的应用中使用它们的话,一定要深入理解两者的技术 实现细节,从而为你的实际使⽤用场景选择最合理的结构。

    目录

    中介 ( Mediator )拓扑结构

    代理 (Broker) 拓扑结构


    中介 ( Mediator )拓扑结构

    中介拓扑结构适合用于拥有多个步骤,并需要在处理事件时能通过某种程度的协调将事件分层的场景,

    举例(股票交易) :

    1.首先需要证券所批准交易,检查这次交易是否违反了股票交易的某种规定,
    2.检查完成后将它交给一个经纪人,计算佣金,最后与经纪人确认交易。

    以上所 有步骤都需要通过中介进⾏行某种程度的分配和协调,以决定各个步骤的执行顺序,判断哪些步骤可以并行, 哪些步骤可以串行。 
    在中介拓扑结构中主要有四种组件:
    事件队列(event queue), 事件中介, 事件通道(event channel), 和 事件处理器(event processor)。
    当事件流需要被处理,客户端将一个事件发送到某个事件队列中,由消息 队列将其运输给事件中介进⾏行处理和分发。事件中介接收到该消息后,并通过将额外的异步事件发送给事件通道,
    让事件通道执行该异步事件中的每一个步骤,使得事件中介能够对事件进行分配、协调。同时,⼜又因 为事件处理器是事件通道的监听器,
    所以事件通道对异步事件的处理会触发事件处理器的监听事件,使事件 处理器能够接收来⾃自事件中介的事件,执⾏行事件中具体的业务逻辑,从而完成对传入事件的处理。事件驱动 

    中介拓扑模式结构大体如下图:

    在事件驱动架构中拥有十几个,甚至几百个事件队列是很常见的情况,该模式并没有对事件队列的实现有明确的要求
    这就意味着事件队列可以是消息队列,Web 服务端,或者其它类似的东西。
    在事件驱动架构模式中主要有两种事件:初始事件和待处理事件。

    初始事件:     是中介所接收到的最原始的事件,没有经过其他组件的处理;

    待处理事件:  是由事件中介生成,由事件处理器接收的组件,不能把待处理 事件看作初始事件经过处理后得到的事件;

    事件中介负责分配、协调初始事件中的各个待执行步骤,事件中介需要为每一个初始事件中的步骤发送一个特定的待处理事件到事件通道中,触发事件处理器接收和处理该待处理事件。
    这里需要注意的是:事件中介没有真正参与到对初始事件必须处理的业务逻辑的实现之中;相反,事件中介只是知道初始事件中有哪些步 骤需要被处理。
    事件中介通过事件通道将与初始事件每一个执行步骤相关联的特定待处理事件传递给事件处理器。尽管我们通常在待处理事件能被多个事件处理器处理时才会在中介拓扑结构中使用消息主题,
    但事件通道仍可以是消息队列或消息主题。(但需要注意的是,尽管在使用 消息主题时待处理事件能被多个事件处理器处理,由于接收到的待处理事件各异,所以对其处理的操作也各不相同)

    代理 (Broker) 拓扑结构


    代理拓扑结构与中介拓扑结构不同之处在于:

    代理拓扑结构中没有核心的事件中介;相反,事件流在代理拓 扑结构中通过一个轻量的消息代理(例如:ActiveMQ, HornetQ,等等……)将消息串联成链状,

    分发至事 件处理器组件中进行处理。代理扑结构适用的使用场景大致上具有以下特征:你的事件处理流相对来说⽐比较 简单,而且你不想(不需要)使用核心的事件分配、调节机制以提高你处理事件的效率。

    在代理拓扑结构中主要包括两种组件:

    代理和事件处理器。代理可被集中或相互关联在一起使用,

    此外,代理中还可以包含所有事件流中使⽤用的事件通道。 存在于代理组件中的事件通道可以是消息队列,消息主题,或者是两者的组合。 代理拓扑结构大致如下图,如你所见,

    在这其中没有一个核心的事件中介组件控制和分发初始事件;相反, 每一个事件处理器只负责处理一个事件,并向外发送一个事件,以标明其刚刚执行的动作。

    例如,

       假如一个事件处理器用于平衡证券交易,那么事件处理器可能会接受一个拆分股票的初始事件,为了处理这项初 始事件,事件处理器则需要重新平衡股票的投资金额,而这个重新平衡的事件将由另一个事件处理器接收、 
       
       处理。在这其中一个细节需要注意:处理初始事件后,由事件处理器发出的事件不被其他事件处理器接 收、处理的情况时常会发生,尤其是你在为应用添加功能和进行功能拓展时,这种情况更为常见。

    整理灵活性:高
    分析:整体灵活性用于评价架构能否在不断改变的使用场景下快速响应,因为事件处理器组件使用目的单一、高度解耦、与其他事件处理器组件相互独立,
    不相关联,那么发生的改变对一个或多个事件处理器来说 普遍都是独立的,使得对改变的反馈非常迅速,不需要依赖其他事件处理器的响应作出处理。


    可测试性:低
    分析:虽然在事件驱动架构模式中进行单元测试并不困难,但如果我们要进行单元测试,我们就需要某种特 定的测试客户端或者是测试工具产生事件,为单元测试提供初始值。此外,
    由于事件驱动架构模式是异步进 行事件分发的,其异步处理的特性也为单元测试带来了一定的困难。

    Performance 性能:高
    分析:对消息传递的架构可能会让设计出来的事件驱动架构的表现不如我们的期望,但通常来说,该模式都 能通过其异步处理的特性展示优秀的性能表现;换句话来说,高度解耦,
    异步并行操作大大减少了传递消息 过程中带来的时间开销。

    伸缩性:高
    分析:事件驱动架构中的⾼高度解耦、相互独立的事件处理器组件的存在,使得可拓展性成为该架构与生俱来 的优点。架构的这些特定使得事件处理器能够进行细粒度的拓展,使得每一个事件处理器都能单独被拓展而不影响其他事件处理器

    易于开发:低

    分析:由于使用事件驱动架构进行开发需要考虑其异步处理机制、协议创建流程,并且开发者需要用代码为 事件处理器和操作失败的代理提供优秀的错误控制环境,无疑使得用事件驱动架构进行开发会比使用其他架 构进行开发要困难一些。


    中介和代理似乎没什么区别,尤其是了解 proxy 的读者会更加困惑,这三者之间到底是什么关系?它们的概念 是互通的吗?为了解决这种混淆,译者将在此阐述三者间的区别:


    mediator: 将把事件流交给 mediator,会把事件分解为多个步骤,并分析其中的执行逻辑,调整和分发事件(例如判断哪些事件可以并行,哪些事件可以串行),
    然后根据 mediator 分解、调节的结果去执行事件中的每一个步骤,把所有步骤完成后,就能把需要处理 的事件处理好。

    broker: 把事件交给 broker,broker 获得事件后会把事件发出去(在本文 中为:通知架构中所有可用的事件处理器),
    事件处理器们接收到事件以后,判断处理这个事件是否为自己的职责之一,如果不是则无视,与自己有关则把需要完成的工作完成,完成后如果事件还有后续需 要处理的事件,
    则通过 broker 再次发布,再由相关的事件处理器接收、处理。以这样的方式将事件不断 分解,沿着事件链一级一级地向下处理子事件,直到事件链中的所有事件被完成,我的事件也就处理好了。

    proxy: 自己对需要处理的事件进行了分解,然后把不同的子事件委托给不同的proxy,由被委托的proxy 帮我完成子事件,从而完成我要做的事件

    展开全文
  • EDA 事件驱动架构

    2017-04-10 16:50:32
    EDA 是事件驱动架构,在面向服务架构(SOA)领域,一个比较重要的概念就是事件驱动 的体系结构 (EDA),英文全称为 Event-driven Architecture
  • 事件驱动架构(翻译)

    千次阅读 2019-04-09 10:53:31
    事件驱动的架构模式时一个...时间驱动架构模式主要由两种拓扑结构组成,中继器与代理。如果你需要把一个事件中各个步骤通过中央中继器组合起来,那么就使用中继器拓扑结构。当你不想有中央中继器,而是将各个步骤...

    事件驱动的架构模式时一个非常流行的分布式异步架构模式,通常用来生成高扩展性的应用。它的适应性非常强,可以用在小应用也可以用在大的复杂的应用上。事件驱动的架构是由高度解耦、单目的的事件处理单元组成,这些单元异步地接受和处理事件。

    时间驱动架构模式主要由两种拓扑结构组成,中继器与代理。如果你需要把一个事件中各个步骤通过中央中继器组合起来,那么就使用中继器拓扑结构。当你不想有中央中继器,而是将各个步骤串起来,就使用代理拓扑结构。因为不同拓扑结构的特性和实现区别挺大,所以有必要搞清楚这两者来选择最适合应用的结构。

    中继器拓扑

    如果事件有许多步骤而且需要有效的组合在一起来处理事件,中继器拓扑会很实用。举例来说,一个单一的事件,完成证券交易,这个事件需要你首先验证这个交易,然后检查交易的合规性,再讲交易委托给代理,计算佣金,最终通过代理完成交易。所以这些步骤都需要有效的组合,来决定步骤的顺序,以及哪些步骤应该串行,哪些该并行。

    中继器拓扑主要有四种不同的架构组成部分:事件队列,事件中继器,事件通道,事件处理器。事件流从一个客户端发送事件到事件队列开始,事件队列将事件传给中继器。中继器接受最初事件然后将事件分解成各个步骤,发送到不痛的事件通道来执行每一步。事件处理器,会监听事件通道,从事件中继器接受事件并执行具体的业务逻辑。图2-1说明了事件驱动的中继器拓扑结构。

    在事件驱动架构中,通常有十几到几百个事件队列。事件队列的实现并没有限制,可以是一个消息队列,一个wed服务端点,或者是他们的组合。

    在这种模式下,有两类事件:初始事件和待处理事件。初始事件是中继器接受的原始事件,而待处理事件是由中继器生成并由事件处理单元接收。

    事件中继器负责组织初始事件包含的步骤。对每一个步骤,中继器会发送一个特定的待处理事件到事件通道,然后待处理事件会被事件处理器接收并处理。需要重点关注的是,中继器并不直接执行处理初始事件的业务逻辑,而是将初始事件分为几个步骤。

    事件通道是中继器用来给事件处理器异步发送待处理事件的,这些待处理事件是初始事件经过中继器生成的。事件通道可以是消息队列或者消息主题,待处理事件被多个事件处理器处理(每个处理器根据接收的事件处理不同的任务)。

    事件处理器包含对事件处理的业务逻辑。事件处理器是独立的、互不依赖的、高度解耦的结构,处理应用中某个具体的任务。尽管时间处理器的粒度可能从很精细(根据书序计算商业税)到很粗糙(处理一项保险申购),还是要注意大体上,每个事件处理器都应该执行不同的任务而且不应该依赖其他的处理器来完成它自身的任务。

    事件中继器可以通过各种各样的方法来实现。作为一个架构师,我们应该理解每一种实现来确保我们选择的方案是最适应应用场景的。

    最简单常见的事件中继器实现方案是开元的集成蜀绣,比如Spring Integration, Apache Camel, 或Mule ESB。这些开元集成枢纽的事件流通常是用Java或DSL实现的。对于更复杂的中继器和组合方法,可以用BPEL(business process execution language)耦合一个BPEL引擎比如开元的Apache ODE。BPES是一个像XML一样的标准语言,它描述可以描述处理初始事件的数据和步骤。对非常大型的应用来说,如果包含非常复杂的组合(保罗需要人为干预的步骤),可以用一个BPM比如jBPM来实现。

    理解需求毕竟找到最适合场景的中继器实现,是中继器拓扑结构最重要的事情。使用一个开源的基础枢纽来进行非常复杂的业务处理管理是失败的,就想使用BPM来处理非常简单的逻辑,一样也是失败的。

    为了说明中继器逻辑是如何工作的,假设你已经被保险公司确认投保,然后你决定执行。在这个例子中,初始事件可以称作“重定位事件”。图2-2表明了中继器怎么处理一个重定位事件。对每个初始事件步骤,事件中继器会创建一个待处理事件(比如修改地址,重新计算报价等),将待处理事件发送给事件通道并等待事件通道被相应的事件处理器处理。这个处理会一直持续知道所有的初始事件被处理完毕。重新计算报价和更新理赔的步骤,是可以同时异步执行的。

    代理人拓扑

    代理人拓扑和中继器拓扑最大的区别是代理人没有中央事件中继器;小溪流像链条一样分布到事件处理器中,这过程由一个轻量级的消息代理(如ActiveMQ,HornetQ等)完成。当你需要一个相对简单的事件处理过程而且你不需要中央组成器的时候,这种拓扑结构就会非常有用。

    代理人拓扑也有两类主要的成分:代理人和事件处理器。代理人组件可以是集中式或联邦式的,而且包含所有事件流中用到的的事件通道。这些事件通道可以是消息队列,消息主体或者两者结合。

    图2-3就是代理人拓扑结构。可以从图表中看出,没有中央事件中继器组件控制和组合初始事件;二是每个事件处理器组件负责处理一个事件并且发布一个新的事件来说明它刚才执行的动作。举例来说,一个事件处理器比如平衡一个证券投资组合,可能会接受一个叫做股票拆分的初始事件。基于这个初始事件,事件处理器会做一些投资组合调整,然后发布一个新的事件“调整投资组合”给代理人,这个事件会被另外一个不同的事件处理器接收。注意到会有一个事件被发出来后没有被另一个事件处理器接收的情况发生。这通常发生在你给应用升级或者提供一些未来的功能和拓展的时候。

     

    为了说明代理人拓扑的工作方式,我们使用和中继器拓扑一样的例子(一个确认投保的人搬家)来说。因为代理人拓扑没有一个中央事件中继器来接收初始事件,消费者处理组件直接接收这个事件,改变消费者的地址(如 地址变更事件)。在这个例子中,有两个事件处理器对地址变更事件感兴趣:报价处理和理赔处理。报价处理器根据地址变更重新计算新的汽车保险赔率,并发布一个事件告诉其他处理器它所做的事情。理赔处理组件,另一方面,接收同样的地址变更事件,但是它会更新一个没有理赔的保险并发布一个新的事件“更新理赔”到系统中去。这些新的事件会被其他事件处理组件接收,而且这个链式的系统会一直进行直到没有和初始事件有关的事件产生。

    从图2-4中可以看到,代理人拓扑所有都是有关业务逻辑处理的整个过程。最好的理解方式就是把它想象成一个接力赛。在接力赛中,运动员拿着一个接力棒然后跑一段固定的距离,然后将接力棒交给下一个运动员,依次进行知道最后一个运动员冲过终点。在接力赛中,一旦运动员交接完接力棒,他就和接力赛无关了。这对代理人拓扑也是适用的:一旦一个事件处理器交接了事件,它就不会再参与到这个事件的处理过程中。

    思考

    事件驱动架构模式实现起来相对来说比较复杂,根本上是因为它的异步分布式本质。当我们实现这个模式时,一定要处理各种各样的分布式架构的问题,比如远程处理能力,相应的缺乏,以及代理或中继器失败后的重连逻辑。

    一个需要考虑的点是当选择这种模式时,需要考虑单个业务处理之间的原子性。因为事件处理器是高度解耦和分布的所以很难维持一个工作的食物单元。出于这个原因,在使用这种模式设计应用时,一定要持续思考哪些事件可以或不可以独立执行,以及根据事件来设置事件处理器的粒度。如果需要将单一工作拆分到多个事件处理器中,即需要强行把一个能单独处理的事物拆分到多个事件处理器,那么可能不太适合这种模式。

    也许事件驱动最难的部分是事件处理器组件数据结构的创造、维护和管理。每个事件通常都有一个特定的结构(如 传给处理器的数据值和数据格式)。当使用这种模式时,选定一个标准的数据格式非常重要,然后从一开始就建立数据结构的控制。

    模式分析

    全局灵活性

    评分:高

    分析:全局灵活性是对持续变化的环境做出快速响应的能力。由于事件驱动组件都是单一目的而且和其他处理器是完全解耦的,所以改变也会隔离在一个或少数处理器中因此使得它能够快速的对改变做出应对且不影响其他组件。

    部署容易程度

    评分:高

    分析:总体来说这种模式相对来说是比较容易部署的,因为各个事件处理器天然是解耦的。代理人拓扑比中继器拓扑更容易部署,主要是因为中继器拓扑有中央中继器,中继器和事件处理器都和中央中继器耦合,所以事件处理器的改变可能也会引起事件中继器的改变,两者都需要重新部署。

    可测试性

    评分:低

    分析:尽管独立单元测试总体来说并不难,也不需要一些特定的客户端或工具来获得测试结果。但是由于这种模式的异步天性,测试还是一件复杂的事情。

    性能

    评分:高

    分析:尽管由于事件驱动架构包含一个消息队列结构,会造成这种架构性能的下降,但是通常,由于异步特性,这种模式还是具有非常高的性能。换句话说异步和解耦分布式带来的好处比消息队列带来的坏处要大。

    可扩展性

    评分:高

    分析:扩展性是这种架构模式的天性,因为整个架构都是解耦的,分布式的。每个事件处理器都可以独立的扩展。

    开发容易程度

    评分:低

    分析:由于异步特性,这种模式开发起来可能不那么容易。

     

    展开全文
  • 事件驱动架构

    2012-12-10 12:02:32
    事件驱动架构Esper文档,Esper是一个开源的事件驱动框架,对于处理CEP,ESP的架构不错,比如事件监控、网络监控等等基于事件的模型。
  • EDA - 是一个用于实现事件驱动架构的库
  • Esper事件驱动架构

    2017-08-21 17:38:17
    事件驱动架构(Event Driven Architecture,EDA)一个事件驱动框架(EDA)定义了一个设计和实现一个应用系统的方法学,在这个系统里事件可传输于松散耦合的组件和服务之间。一个事件驱动系统典型地由事件消费者和...
  • 什么是事件驱动架构(EDA)?

    千次阅读 2020-05-21 01:03:56
    事件驱动架构 事件驱动架构模式是一种非常流行的分布式异步架构模式,经常被用与构建高可伸缩性的应用程序。当然它也适合小型应用,复杂应用和规模比较大的应用。这种架构模式由一系列高度解耦的、异步接收和处理...
  • 架构范式一 - 事件驱动架构(EDA)

    千次阅读 2022-07-02 19:00:02
    EDA 是一种基于发布/订阅模式的消息异步通信的架构,你可以把它理解为架构层面的观察者模式,它主要分为以下7个核心对象。 大致流程为:第一,因为它是异步的,因此特别适合以下:第二,如果业务模式的整个主流程不...
  • 事件驱动架构的电网实时自然灾害监测预警平台.ppt事件驱动架构的电网实时自然灾害监测预警平台.ppt事件驱动架构的电网实时自然灾害监测预警平台.ppt事件驱动架构的电网实时自然灾害监测预警平台.ppt事件驱动架构的...
  • 计算机-后端-事件驱动架构在金融交易清算系统中的应用.pdf
  • DDD的一大好处便是它不需要使用特定的结构,由于核心域在限界上下文中,所以我们可以在整个系统中使用多种风格的结构。...质量驱动架构选择是种风险驱动方式(我们采用的架构是用来减少失败风险的,而不是增加风险)
  • 针对Web服务集成过程中分阶段事件驱动架构(SEDA)仅考虑服务集成架构的资源消耗,而对被集成的服务及由其构成的任务资源耗费考虑不足的问题,提出了分阶段优先级事件驱动架构(SPEDA).选取评价指标,通过熵权法对事件...
  • 文章目录一、事件驱动二、事件驱动编程事件驱动和异步IO看图说话讲事件驱动模型三、C/C++实现事件驱动四、常用的C/C++事件驱动库 一、事件驱动 首先我们来看看百度百科的介绍。 所谓事件驱动,简单地说就是你点什么...
  • 事件驱动 事件驱动架构会议 演示文稿链接: :
  • 聊架构(三):事件驱动架构

    千次阅读 2018-11-27 14:38:35
    接上篇,我们采用了领域驱动的开发方式,使用了充血模型,享受了他的好处,但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。 事务一致性 事务一致性的问题在Monolithic下面不是大问题,...
  • 基于事件驱动架构的 敏捷企业中台; 一企业IT架构的演变;业务中台;大数据平台; 一企业IT架构的演变; 一企业IT架构的演变;云平台;VANTIQ;Vantiq平台;Vantiq平台;Vantiq平台;热力系统整体架构敏捷演进的中台;热力系统...
  • 1eer-to-Peer架构和事件驱动架构-课程内容.rar
  • 202x年事件驱动架构的电网实时自然灾害监测预警平台(专业完整版).pdf
  • 基于事件驱动架构的实时企业(Richard).pdf
  • 软件体系结构 Zhenyan Ji Beijing Jiaotong University Peer-to-Peer架构 架构风格 点对点架构 节点...连接器网络协议通常是自定义的 点对点架构 Event-Driven架构 架构风格 事件驱动风格 设计方案基于事件调度程序(an
  • 1eer-to-Peer架构和事件驱动架构-MOOC课程内容.pdf
  • p u o 事件驱动架构 r G 实现企业的数据实时处理能力 n e p O 赵信荣 e 2020年4月26 日 h T 数据的处理方式 p 批处理方式 u o r 时间分配方式 分时处理方式 G 实时处理方式 n 单道处理方式
  • Sample-EDA:使用大众运输的事件驱动架构的完整示例
  • 事件驱动架构模式是一个非常流行的异步分布模式,可生成高可扩展性应用。而且它也具有强适应能力,可被用于小程序或者大型复杂程序。事件驱动架构是由高耦合度、单一目的的事件处理模块构成,这些模块异步接收、处理...
  • 6 种事件驱动架构模式

    千次阅读 2022-04-27 14:11:14
    通过消费来自 Kafka 的数据,并为特定的上下文创建一个“物化视图”,反向查找写入器服务能够创建一个最终一致...借助 Kafka 和[WebSocket]((),我们就有了一个完整的事件驱动,包括浏览器-服务器交互。 这使得交互..

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 404,946
精华内容 161,978
关键字:

事件驱动架构

友情链接: 全屏FLASH广告代码.rar