使用Disruptor和Executor在Java中设计Orchestrator

Question

我们正在用Java设计一个Orchestrator系统，它将托管一个Web服务，并在请求时将调用以XML编写的流，该流只是一个接一个地执行的步骤，但是XML告诉用户该流是什么，他也可以通过更改XML来更改流程。 他可以添加新服务并将其添加到XML。 但是在设计时，我现在对类似的东西感到困惑。

1. 我是否应该使服务成为具有阻塞队列的可运行服务，并通过将其调度到执行程序来使其始终处于活动状态，所以当新请求到达时，我会将请求推送到阻塞队列中，然后服务将对其进行处理。 并创建一个邮箱，它将承载不同服务之间的消息传递任务。

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

3. 我了解了像nodejs和ngnix这样的事件驱动系统如何更快，因此我在考虑使用Disuptor框架将所有传入请求推送到环形缓冲区，然后编写一个将事件发送给协调器的处理程序，该处理程序将开始处理请求并还发送带有请求的回调，以便协调器完成后，它将使用回调将响应发送回调用方。 但是由于请求的类型不同，所以我将无法利用中断对象分配。

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

Answer 1

答案1是一个可怕的想法。 您将有效地为每个服务占用一个线程。 如果服务数量超过支持执行程序服务的线程数量，您将拥有一个即时的自动DOS。 另外，如果服务之间是相互依赖的...您可以采用所有方式进行死锁。 另外，如果仅需要M（<N），则使用N个线程的效率低下。

答案2：如果建议的流程是“请求解析->调度->服务处理->回调”，则您依赖于实际的“服务”不会阻塞，因为这将阻止调用回调和/或使应用程序DOS。 本质上：如果服务中发生异常会怎样？ 这还会影响将来对同一服务和/或其他服务的请求吗？

同样，并行的机会仅限于框架处理传入请求的方式。 这意味着，如果您有X个请求，并且框架固有地按顺序处理它们，则会积压X个请求。 在这种情况下，您的延迟要求可能很难满足。

答案3：事件驱动的系统确实是更好的方法：让调度程序将作业分配给执行服务，以使系统动态分配所有服务的总负载，并具有对事件进行生成和响应的机制以处理事件。控制流。 如果服务数量变得非常大且每个“工作”相当合理（这样，与实际执行的工作相比，调度/调度的开销就很低），则这种方法的扩展性更好。