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