什么是SEDA（分阶段事件驱动架构）？
“SEDA 是分阶段事件驱动架构的缩写，它将复杂的事件驱动应用程序分解为一组由连接的阶段队列。”
我知道它是一种架构，并且 SEDA 有许多实现（请参阅维基百科文章 ）。什么是“舞台”？有人可以对分阶段事件驱动架构进行全面的高级总结，以及它与传统（非分阶段？）事件驱动架构有何不同？
SEDA: An Architecture for Well-Conditioned, Scalable Internet Services
"SEDA is an acronym for staged event-driven architecture, and decomposes a complex, event-driven application into a set of stages connected by queues."
I understand that it's an architecture and that there are many implementations of SEDA (see the Wikipedia article). What is a "stage"? Can someone give a thorough high-level summary of a staged event-driven architecture, and how it differs from traditional (unstaged?) event driven architectures?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
现实生活中的线程架构与分阶段事件驱动架构：
假设您有一家餐厅。现在，它将如何运作？
使用“线程架构”：
在这种情况下，服务员在整个过程中都在顾客身边。如果服务器有10个线程，可以同时处理10个连接。
使用 SEDA：
在这种情况下，有不同类型的演员进行活动。这有助于在花费更少时间且结果更有效的活动中重用参与者。事实上，这就是餐厅的运作方式（可能更多的服务员是同一个人，但厨师绝对不是）。
这是一个极端的例子，当然使用线程服务器可以完成一些异步任务。这只是一个理论上的例子。
Thread Architecture vs Staged Event-Drive Architecture in real life:
Imagine you have a restaurant. Now, how it will work?
with "Thread Architecture":
In this case, the waiter is with the client during the whole process. If the server has 10 threads, can handle 10 connections concurrently.
with SEDA:
In this case, there are different kind of actors doing the activities. This helps to reuse actors in the activities that take less time and the outcome is more effective. Indeed, this is how a restaurant works (probably more instances of Waiter are the same person, but the cook definitely not).
This is an extreme example, and of course with threaded servers some async tasks can be done. This is only a theoretical example.
阶段类似于“事件”。为了简化这个想法，可以将 SEDA 视为在它们之间发送消息的一系列事件。
我认为使用这种架构的一个原因是，你可以将逻辑碎片化，并且可以将其连接起来并解耦每个事件，主要对于低延迟要求的高性能服务非常适合。
如果使用Java TPE，您可以监控每个阶段的运行状况、吞吐量、错误、延迟，并快速找到性能瓶颈所在。作为一个很好的副作用，使用较小的代码片段，您可以轻松地测试它们并增加代码覆盖率（这就是我的情况）。
根据记录，这是 Cassandra (NoSQL) 和 Mule ESB (AFAIK) 的内部架构。
我建议阅读原始论文（抱歉，重复的链接）：
这是我创建的一个框架，用于为 Java EE 建模 SEDA：http://code.google.com/p/seide/
A Stage is analogous to an "Event". To simplify the idea, think of SEDA as a series of events sending messages between them.
One reason to use this kind of architecture, I think, is that you fragment the logic and can connect it and decouple each event, mainly for high performance services with low latency requirements fits well.
If you use Java TPE, you could monitor the health, throughput, errors, latency of each stage, and quickly find where the performance bottleneck is. And as a nice side effect, with smaller pieces of code, you can easily test them and increment your code coverage (that was my case).
For the record, this is the internal architecture of Cassandra (NoSQL), and Mule ESB (AFAIK).
I recommend reading the original paper (sorry, duplicate link):
Here is a framework I've created to model SEDA for Java EE: http://code.google.com/p/seide/
这些文档位于 github
SEDA，如文档中提到的：
“SEDA 中处理的基本单位是阶段。阶段
是一个独立的应用程序组件，由事件处理程序组成，
传入事件队列和线程池...
每个阶段都由影响调度的控制器管理
和线程分配。阶段线程通过从传入事件队列中拉出一批事件并调用应用程序提供的事件处理程序来进行操作。事件处理程序处理每批事件，并通过将事件排入其他阶段的事件队列来调度零个或多个事件。”
对我来说，您可以将阶段设计为应用程序的逻辑模块化它可以基于功能、基于关注点分离、基于性能、基于操作和维护，
我会要求您阅读随附的 PDF，因为它提到需要一个事件队列来解耦事物、逻辑补充。实现组件的最大效率，如何有效地重用应用程序运行时的现有资源，如网络、存储、CPU 周期等。
为了进行类比，有一项针对装配线工人的研究，这些工人串联起来组装一些东西从头到尾的生产力较低，但当他们被孤立并被迫完成一项工作并将部分组装的单元传递给下一组时，他们每个人都可以高效地管理他/她的工作基本上，您的组装流程得到了提高。分为多个阶段，每个阶段或一组阶段负责在一个阶段上工作。
这里所做的只是围绕每个人或团体启用并建立一个框架以及一个人/团体与另一个人/团体之间的沟通模式。现在我们可以将每个人/团体以及他周围的框架设置与一个阶段进行比较。
要在 SEDA 中添加事件维度，请考虑人员组如何相互通信以及涉及的事件数量。举例来说，第一阶段的人员已经用完了完成阶段所需的具体细节，他们立即将具体细节通知订单部门经理。订单部门经理可能收到了另一个 6 阶段人员的类似请求，但具体细节已经用完。现在，他在中心点看到请求（他就像 SEDA 中的控制器）和他拥有的 Excel 工作表，其中保存了要下订单的请求的所有条目（就像 SEDA 中的队列），他将它们组合起来并一次性将它们订购在一起，而不是发送两个订购请求（SEDA 中的线程和调度管理）。
现在，如果您的软件架构中有一个类似的机制，该机制具有多个组件，相互发送各种事件，并让控制器使用它们并相应地采取行动，那么您可能已经有了一个非常好的分阶段事件驱动设置。
The docs are available at github
SEDA as mentioned in the document:
"The fundamental unit of processing within SEDA is the stage. A stage
is a self-contained application component consisting of an event handler,
an incoming event queue, and a thread pool...
Each stage is managed by a controller that affects scheduling
and thread allocation. Stage threads operate by pulling a batch of events off of the incoming event queue and invoking the application-supplied event handler. The event handler processes each batch of events, and dispatches zero or more events by enqueuing them on the event queues of other stages."
To me, you could design your stage as a logical modularization of your application flow. It could be based on functionality, based on separation of concerns, based on performance, based on operations and maintenance.
I would ask you to read the attached PDF as it mentions the need for a event queue to decouple stuff, logical compenentization to achieve maximum efficiency of the component, how to efficiently reuse the existing resources above which the application is running like network, storage, CPU cycles etc.,
To draw a parallel, there are studies made on assembly line workers who worked in series assembling something from start to end achieved less productivity, but when they were isolated and made to do a single job and pass the partly assembled unit to the next group, each one of them became efficient in managing his/her work. Basically your flow of assembling something got split into multiple stages and each one of them or a group of them were responsible to work on a stage.
All that was done here was to enable and set-up a framework around each person or group and a mode of communication from one person/group to another. Now we can compare each person/group and the framework set-up around him to a stage.
To add the event dimension in SEDA, think about how the person group communicate with each other and the number of events which are involved. Say for example, the stage 1 guys have ran out of nuts and bolts to complete their stage and they immediately inform the Order Section manager about the nuts and bolts. It is possible that the order section manager has got a similar request from another stage 6 guys that nuts and bolts have run out. Now, he sees the requests at a central point (he is like the controller in SEDA) and the excel sheet which he has where all the entries he has kept the requests of orders to be placed (is like the queue in SEDA), he combines them and orders them together at one go instead of sending two order requests (thread and schedule management in SEDA).
Now if you have a mechanism like that in your software architecture which has multiple components, sending various events to each other and have controllers consuming them and acting accordingly, then you probably have a very good staged event driven set-up in place.