0

这个问题的范围/上下文：我要开发一个基于 Java/Java EE 的分布式服务器端应用程序，它是可扩展的（向上扩展，而不是向外扩展）。

我的应用程序由使用分布式后端服务的多个实例来处理客户端请求的 servlet 组成。如果我需要实现更高的吞吐量，我希望能够添加更多这些分布式服务的实例（同一台或另一台机器上的 JVM）并（期望）看到吞吐量的增加。

为了实现这一点，我正在考虑一个松散耦合的异步系统。我想我会使用 Async Servlets (servlet 3.0) 和一个应用程序管理的线程池，它将客户端请求放在 JMS 队列上，由分布式服务实例之一选择并处理。可以使用 JMS 将响应从服务实例转发回 servlet 容器中的响应线程。

然而，异步系统似乎（显然）比同步系统更复杂（例如：错误处理和错误中继到客户端、请求跟踪等）。我也担心设计/代码的未来可维护性。

因此，出现了一个问题， 同步执行此操作是否有意义，同时仍保持分布式、可扩展和松散耦合？如果答案是肯定的，那么请分享实现这一目标的可能方法（同时保持“建设性”）。

如果我能以同步的方式很好地做到这一点，那么它将简化整个系统。我不想不必要地增加系统的复杂性。

（假设它是有道理的）我能想到的一种可能的实现是使用 RMI。例如：分布式服务实例的服务注册表，用于注册并让负载均衡器在所有可用实例之间分配 RMI 调用。但感觉是老一代的解决方案。有没有更好的选择？

编辑：有关此问题范围的其他详细信息：

  • 客户端是基于浏览器的，不需要异步服务器端。
  • 我不需要服务器推送。
  • 在任何时候，我都不会比流行的 Web 服务器（甚至 Apache）的 max-worker-threads 有更多的未完成请求。
  • 由于上述原因，相关问题中提到的用例似乎不适用于我的场景。
4

1 回答 1

1

松散耦合和分布与处理是同步的还是异步的无关。

有了可扩展性，事情就变得更加复杂了。在同步模型中，每个待处理的请求都需要一个线程。如果您需要扩展到非常高的负载（例如，每台服务器有数千个并发请求），异步模型可能会更好地扩展。然而，为了从中受益，从处理传入连接开始的整个处理都需要以异步方式完成。将同步请求处理线程委托给异步线程池并阻塞直到该线程池计算出结果是没有意义的——毕竟，请求线程也可以自己完成工作。

如果您需要返回响应，那么只要可扩展性允许（通常会这样做），我就会进行同步请求处理。

编辑：有很多方法可以与分布式后端服务器通信。您可以简单地使用 EJB（如果我没记错的话，它在后台使用 RMI）。或者，您可以在负载均衡器后面使用 Web 服务。

于 2013-04-17T20:01:55.077 回答