java - 使用 Disruptor 和 Executors 在 Java 中设计 Orchestrator

Question

我们正在用 java 设计一个 Orchestrator 系统，它将托管一个 Web 服务，并根据对其的请求将调用一个用 XML 编写的流程，该流程只不过是一个接一个执行的步骤，但 XML 告诉用户该流程是什么是的，他还可以通过更改 XML 来更改流程。他可以添加新服务并将其添加到 XML 中。但在设计时，我现在对诸如此类的事情感到困惑。

1. 我应该让一个服务成为一个带有阻塞队列的可运行服务，并通过将其调度到执行器来使其始终保持 Activity 状态，以便当新请求到达时，我会将请求推送到阻塞队列中，并且服务将处理它。并创建一个Mailbox，用于承载不同服务之间的消息传递任务。

2. 我应该使用 spring IOC，而不是使服务可运行，它将使类成为单例，因此只有一个实例，我将直接向服务方法发送请求，这样我就不必麻烦了因为没有线程，也不需要实现任何邮箱。

3. 我读到了事件驱动系统如何像nodejs和ngnix一样更快，所以我想使用disuptor框架将所有传入请求推送到环形缓冲区，然后编写一个处理程序，将事件发送到协调器将开始处理请求，并随请求发送回调，以便协调器完成后，它将使用回调将响应发送回调用者。但由于请求的类型不同，因此我无法利用干扰器对象分配。

系统需要以低延迟提供最大吞吐量，系统将来会向 XML 添加新的服务/流，因此它应该在不影响性能的情况下采用新的流。我只能使用 java 7，不能使用 Scala，所以我受到限制。

Answer 1

答案#1是一个糟糕的主意。您将有效地为每个服务绑定(bind)一个线程。如果服务数量超过支持执行程序服务的线程数量，您将获得即时、自动的 DOS。另外，如果服务相互依赖……所有的方式都可能导致死锁。另外，如果实际只需要 M (< N) 个线程，则使用 N 个线程的效率很低。

答案#2:如果建议的流程是请求解析 -> 分派(dispatch) -> 服务处理 -> 回调，那么你依赖于实际的“服务”不会搞砸，因为这将阻止回调被调用和/或 DOS 应用程序。本质上:如果服务中发生异常会发生什么？这是否也会影响 future 对同一服务和/或其他服务的请求？

此外，并行性的机会仅限于框架处理传入请求的方式。这意味着如果您有 X 请求并且框架本质上连续处理它们，那么您会积压 X 请求。在这种情况下，您的延迟要求可能很难满足。

答案＃3:事件驱动的系统确实是更好的方法:让调度程序将作业分配给执行程序服务，以允许系统动态分配所有服务的总负载，并具有生成事件和对事件使用react的机制来处理控制流。如果服务数量变得非常大并且每个“作业”都相当大(因此与正在执行的实际工作相比，调度/分派(dispatch)的开销较低)，那么这种扩展性会更好。