0

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

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

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

  3. 我读到了事件驱动系统如何像 nodejs 和 ngnix 一样更快，所以我想使用 disuptor 框架将所有传入的请求推送到 ringbuffer，然后编写一个处理程序，将事件发送到将开始处理请求的协调器和还与请求一起发送回调，以便当协调器完成时，它将使用回调将响应发回给调用者。但是由于请求的类型不同，所以我将无法利用中断对象分配。

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

4

1 回答 1

1

答案＃1是一个糟糕的主意。您将有效地为每个服务绑定一个线程。如果服务的数量超过了支持执行器服务的线程数量，那么你就有了一个即时的、自动的 DOS。另外，如果服务相互依赖......所有你可以死锁的方式。另外，如果实际上只需要 M (< N)，则使用 N 个线程的效率低下。

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

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

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

于 2015-10-18T07:20:54.510 回答