Architecture 什么是SEDA(阶段性事件驱动架构)?

Architecture 什么是SEDA(阶段性事件驱动架构)?,architecture,stage,event-driven,eda,Architecture,Stage,Event Driven,Eda,SEDA是阶段性事件驱动体系结构的缩写,它将复杂的事件驱动应用程序分解为一组由队列连接的阶段 我知道这是一种体系结构,并且有许多SEDA的实现(请参阅)。什么是“舞台”?是否有人能对分阶段事件驱动的体系结构进行全面的高层总结,以及它与传统(未分阶段的?)事件驱动体系结构的区别?一个阶段类似于一个“事件”。为了简化这个想法,可以将SEDA看作是在它们之间发送消息的一系列事件 我认为,使用这种体系结构的一个原因是,您可以将逻辑分割开来,将其连接起来,并将每个事件解耦,主要用于具有低延迟需求的高性能服

SEDA是阶段性事件驱动体系结构的缩写,它将复杂的事件驱动应用程序分解为一组由队列连接的阶段


我知道这是一种体系结构,并且有许多SEDA的实现(请参阅)。什么是“舞台”?是否有人能对分阶段事件驱动的体系结构进行全面的高层总结,以及它与传统(未分阶段的?)事件驱动体系结构的区别?

一个阶段类似于一个“事件”。为了简化这个想法,可以将SEDA看作是在它们之间发送消息的一系列事件

我认为,使用这种体系结构的一个原因是,您可以将逻辑分割开来,将其连接起来,并将每个事件解耦,主要用于具有低延迟需求的高性能服务

如果使用JavaTPE,您可以监视每个阶段的运行状况、吞吐量、错误、延迟,并快速找到性能瓶颈所在。作为一个很好的副作用,使用较小的代码片段,您可以轻松地测试它们并增加代码覆盖率(这就是我的情况)

作为记录,这是Cassandra(NoSQL)和Mule ESB(AFAIK)的内部架构

我建议阅读原稿(对不起,重复链接):


下面是我为JavaEE建模SEDA而创建的一个框架:

文档可在

文件中提到的SEDA: “SEDA的基本处理单元是阶段。阶段 是由事件处理程序组成的自包含应用程序组件, 传入事件队列和线程池。。。 每个阶段都由影响调度的控制器管理 和线程分配。后台线程通过将一批事件从传入事件队列中拉出并调用应用程序提供的事件处理程序来运行。事件处理程序处理每批事件,并通过将它们排队到其他后台的事件队列中来调度零个或多个事件。“

对我来说,您可以将stage设计为应用程序流的逻辑模块化。它可以基于功能、基于关注点分离、基于性能、基于操作和维护

我想请您阅读随附的PDF,因为它提到需要一个事件队列来解耦内容,逻辑补偿以实现组件的最大效率,如何有效地重用应用程序运行时所使用的现有资源,如网络、存储、CPU周期等

与此相似的是,有研究表明,流水线工人从头到尾进行串联组装时,生产率较低,但当他们被隔离,被迫做一项工作,并将部分组装好的部件传递给下一组时,他们中的每一个人都能有效地管理自己的工作。基本上,你组装东西的流程分为多个阶段,每个阶段或一组阶段负责一个阶段的工作

这里所做的一切就是围绕每个人或群体建立一个框架,以及一个人/群体与另一个人/群体之间的沟通模式。现在,我们可以将每个人/组和他周围的框架设置作为一个阶段进行比较

要在SEDA中添加事件维度,请考虑人员组如何相互沟通以及涉及的事件数量。比如说,第1阶段的人员已经用完了完成该阶段所需的螺母和螺栓,他们立即将螺母和螺栓的情况通知订单部门经理。订单部门经理可能收到另一个第6阶段人员的类似请求,即螺母和螺栓已用完。现在,他在一个中心点(他就像SEDA中的控制器)和excel表上看到了这些请求,他保存了所有订单请求的条目(就像SEDA中的队列),他将它们组合在一起,一次完成订单,而不是发送两个订单请求(SEDA中的线程和日程管理)


现在,如果您的软件体系结构中有这样一种机制,它有多个组件,相互发送各种事件,并让控制器使用它们并相应地执行操作,那么您可能有一个非常好的阶段性事件驱动设置。

线程体系结构与现实生活中的阶段性事件驱动体系结构:

假设你有一家餐馆。现在,它将如何工作

使用“线程架构”:

  • 顾客来了
  • 服务员(a)走向他/她
  • 服务员(a)带他/她到一张空桌旁
  • 服务员(a)点菜
  • 服务员(a)点菜
  • 服务员(a)把点菜带到桌上
  • 服务员(a)等到客户吃完饭才付款
  • 服务员(a)带客户出去
  • 在这种情况下,服务员在整个过程中都与客户在一起。如果服务器有10个线程,则可以同时处理10个连接

    对于SEDA:

  • 顾客来了
  • 服务员(a)走向他/她
  • 服务员(a)将他/她带到一张可用的桌子旁(然后回来让另一位客户过来)
  • 服务员(b)点菜(大量I/O,需要时间)
  • 厨师点菜
  • 服务员(c)把点菜带到桌上
  • 服务员(d)等到客户吃完饭才付款
  • 侍者(e)带客户出去
  • 在这种情况下,有不同类型的演员在做这些活动。这有助于在活动中重用参与者,这些活动花费的时间更少,结果更有效。事实上,这就是餐厅的运作方式(可能更多的服务员是同一个人,但厨师绝对不是)


    这是一个极端的例子,当然,使用线程服务器可以完成一些异步任务。这只是一个理论上的例子。

    哈佛论文的链接现在断了。有人有副本吗?@德语你有副本吗