问什么是SEDA (阶段性事件驱动体系结构)？

EN

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

想象一下你有家餐厅。现在，它将如何工作？

使用“线程架构”：

1. 顾客来了
2. 侍者(A)去找他/她
3. 侍者(A)带他(她)到一张可用的桌子上
4. 侍者(A)接受点菜
5. 侍者(A)煮饭
6. 侍者(A)端到餐桌上点菜
7. 侍者(A)等到顾客吃完饭才付款
8. 侍者(A)送客人出去

在这种情况下，服务生在整个过程中与客户在一起。如果服务器有10个线程，则可以并发处理10个连接。

与SEDA：

1. 顾客来了
2. 侍者(A)去找他/她
3. 侍者(A)带他(她)到一张可用的桌子(然后回来找另一位客人)
4. 服务员(B)点菜(大量的I/O，需要时间)
5. 厨师下厨
6. 侍者(C)端到餐桌上点菜
7. 侍者(D)等到顾客吃完饭才付款
8. 侍者(E)送客人出去

在这种情况下，有不同类型的行动者在做这些活动。这有助于在花费较少时间和结果更有效的活动中重用参与者。事实上，这就是餐厅的运作方式(可能会有更多的服务生是同一个人，但厨师肯定不是这样)。

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

舞台类似于“事件”。为了简化这个想法，请将SEDA看作是一系列在它们之间发送消息的事件。

我认为，使用这种体系结构的原因之一是，您可以对逻辑进行分解，并将其连接起来并将每个事件解耦，这主要是为了满足高性能、低延迟需求的服务。

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

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

我建议阅读原文(抱歉，重复链接)：

• https://github.com/mdwelsh/mdwelsh.github.io/blob/master/papers/seda-sosp01.pdf

下面是我为Java建模SEDA而创建的一个框架：http://code.google.com/p/seide/

这些文档可在github上使用。

正如文档中所提到的：“SEDA中的基本处理单元是阶段。阶段是一个独立的应用程序组件，由一个事件处理程序、一个传入事件队列和一个线程池组成……每个阶段由一个影响调度和线程分配的控制器管理。stage线程通过从传入事件队列中提取一批事件并调用应用程序提供的事件处理程序来操作。事件处理程序处理每一批事件，并通过在其他阶段的事件队列上排队来调度零或多个事件。”。

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

我想请您阅读附加的PDF，因为它提到需要事件队列来解耦组件、逻辑精简以实现组件的最大效率、如何有效地重用应用程序正在运行的现有资源，如网络、存储、CPU周期等。

与之相提并论的是，有人对装配线工人进行了研究，他们从头到尾都在组装一些东西，但当他们被孤立起来，被迫做一项单一的工作，并将部分组装的单元交给下一组时，他们中的每一人都变得高效地管理他/她的工作。基本上，你组装东西的流程被分成多个阶段，每个阶段或其中一组负责在一个舞台上工作。

这里所做的就是启用并建立一个围绕每个人或组的框架，以及一个人/组之间的交流模式。现在，我们可以比较每个人/组和框架设置围绕他到一个阶段。

要在SEDA中添加事件维度，请考虑人员组如何相互通信以及所涉及的事件数量。例如，第一阶段的人已经没有螺母和螺栓来完成他们的阶段，他们立即通知订单部门经理关于螺母和螺栓。订单部门经理有可能从另一个6级人员那里得到了类似的请求，螺母和螺栓都用完了。现在，他在一个中心点看到请求(他就像SEDA中的控制器)和excel表，他在其中保存了所有要发出订单请求的条目(就像SEDA中的队列)，他将它们组合在一起，并将它们一次性订购，而不是发送两个订单请求(SEDA中的线程和调度管理)。

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