SEDA: An Architecture for Well-Conditioned, Scalable Internet Services
“SEDA是staged event-driven architecture的首字母缩写，将一个复杂的、事件驱动的应用程序分解成一组stages，通过queues。”
我了解它是一种架构，并且有许多 SEDA 实现（请参阅Wikipedia article）。什么是“舞台”？有人可以对分阶段事件驱动架构进行全面的高级总结，以及它与传统（非分阶段？）事件驱动架构有何不同？
【问题讨论】：
标签： architecture stage event-driven eda
现实生活中的线程架构与分阶段事件驱动架构：
假设你有一家餐馆。现在，它将如何工作？
使用“线程架构”：
在这种情况下，服务员在整个过程中都与客户在一起。如果服务器有 10 个线程，可以同时处理 10 个连接。
使用 SEDA：
在这种情况下，有不同类型的演员在做这些活动。这有助于在花费更少时间的活动中重用参与者，并且结果更有效。确实，这就是餐厅的运作方式（可能更多的 Waiter 实例是同一个人，但厨师绝对不是）。
这是一个极端的例子，当然使用线程服务器可以完成一些异步任务。这只是一个理论上的例子。
【讨论】：
舞台类似于“事件”。为了简化这个想法，将 SEDA 视为在它们之间发送消息的一系列事件。
我认为使用这种架构的一个原因是，你可以将逻辑碎片化并可以将其连接并解耦每个事件，主要适用于低延迟要求的高性能服务。
如果您使用 Java TPE，您可以监控每个阶段的运行状况、吞吐量、错误、延迟，并快速找到性能瓶颈所在。作为一个很好的副作用，使用更小的代码，您可以轻松地测试它们并增加您的代码覆盖率（这就是我的情况）。
为了记录，这是 Cassandra (NoSQL) 和 Mule ESB (AFAIK) 的内部架构。
我建议阅读原论文（对不起，重复链接）：
这是我为 Java EE 的 SEDA 建模创建的框架：http://code.google.com/p/seide/
【讨论】：
文档可在github获取
文档中提到的 SEDA： “SEDA 中处理的基本单元是阶段。一个阶段 是一个独立的应用程序组件，由一个事件处理程序组成， 传入事件队列和线程池... 每个阶段都由影响调度的控制器管理 和线程分配。阶段线程通过从传入事件队列中拉出一批事件并调用应用程序提供的事件处理程序来进行操作。事件处理程序处理每批事件，并通过将它们排入其他阶段的事件队列来调度零个或多个事件。”
对我来说，您可以将舞台设计为应用程序流程的逻辑模块化。它可以基于功能、基于关注点分离、基于性能、基于操作和维护。
我想请你阅读附件的 PDF，因为它提到需要一个事件队列来解耦东西，逻辑能力以实现组件的最大效率，如何有效地重用应用程序运行的现有资源，如网络、存储、CPU 周期等，
为了打个比方，有研究表明，流水线工人从头到尾串联组装，生产率较低，但当他们被隔离并被要求做单一工作并将部分组装的单元传递给下一组，他们每个人都变得高效地管理他/她的工作。基本上，您的组装流程分为多个阶段，每个阶段或一组负责在一个阶段工作。
这里所做的只是围绕每个人或小组启用和建立一个框架，以及从一个人/小组到另一个人/小组的沟通模式。现在我们可以将每个人/组以及围绕他设置的框架与一个舞台进行比较。
要在 SEDA 中添加事件维度，请考虑人员组如何相互通信以及涉及的事件数量。举例来说，阶段 1 的人已经用完了完成阶段的螺母和螺栓，他们立即通知订单部门经理有关螺母和螺栓的信息。订单部门经理可能从另一个第 6 阶段的人那里收到了类似的要求，即螺母和螺栓已经用完。现在，他在一个中心点看到请求（他就像 SEDA 中的控制器）和他拥有的 Excel 表，其中所有条目都保存了要放置的订单请求（就像 SEDA 中的队列），他将它们组合在一起并一次性订购它们，而不是发送两个订单请求（SEDA 中的线程和调度管理）。
现在，如果您的软件架构中有类似的机制，它有多个组件，相互发送各种事件，并让控制器使用它们并相应地采取行动，那么您可能已经有了一个非常好的分阶段事件驱动设置.
【讨论】：