Java 同步servlet处理对于分布式服务器端应用程序有意义吗

这一问题的范围/背景： 我将开发一个基于Java/JavaEE的分布式服务器端应用程序，它是可伸缩的（而不是向外扩展的）

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

为了实现这一点，我考虑了一个松散耦合的异步系统。 我想我会使用异步servlet（Servlet3.0）和一个应用程序管理的线程池，将客户机请求放在JMS队列上，由一个分布式服务实例选择并处理。可以使用JMS将响应从服务实例中继回客户机，并将其转发到servlet容器中的响应线程

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

因此，出现了一个问题，在保持分布式、可伸缩性和松散耦合的同时，同步这样做有意义吗？ 如果答案是肯定的，那么请分享实现这一目标的可能方法（同时保持“建设性”）

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

（假设有意义）我可以想到的一个可能的实现是使用RMI。 例如：一个服务注册中心，用于注册分布式服务实例，并让负载平衡器跨所有可用实例分发RMI调用。但这感觉像是老一代的解决方案。还有更好的选择吗

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

• 客户端是基于浏览器的，不需要异步 服务器端
• 我不需要服务器推送
• 在任何时候，我都不会有比流行web服务器（甚至Apache）的最大工作线程更多的未完成请求
• 出于上述原因，a中提到的用例似乎不适用于我的场景

---

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

---

在可伸缩性方面，问题更加复杂。在同步模型中，每个挂起的请求需要一个线程。如果您需要扩展到真正的高负载（例如，每台服务器上有数千个并发请求），异步模型可以更好地扩展。然而，为了从中获益，从处理传入连接开始的整个处理需要以异步方式完成。让同步请求处理线程委托给异步线程池，并在线程池计算出结果之前阻塞，没有什么意义——毕竟，请求线程也可以自己完成这项工作

如果您需要返回响应，我会在可伸缩性允许的情况下（通常是这样）进行同步请求处理

编辑：

---

与分布式后端服务器对话的方式有很多种。您可以简单地使用EJB（如果我没记错的话，它在幕后使用RMI）。或者，您可以在负载平衡器后面使用Web服务。

除了在问题中包含各种流行语之外，应用程序的实际功能是什么？我们每秒讨论多少查询？后端服务是否已经存在？如果是的话，他们在说什么协议？我不想用应用程序/域来玷污这个问题。因此，我把它漏掉了。正如我在qn中提到的，在任何时候，我都不会有比流行web服务器（甚至Apache）的最大工作线程更多的未完成请求。后端服务是基于Java的，尚待开发。所以，我可以自由选择他们说什么。谢谢对我同意如果我采用异步方式，它应该从servlet处理开始。这就是我在标题中明确提到servlet处理的原因。我的问题是如何同步实现这一点，同时保持其他好处。也许你忽略了怎么做，因为有很多方法可以实现它。即使如此，请陈述几个选项来指导我。谢谢谢谢我在想，现在可能有更好的方法来实现这一点。我仍然觉得这方面可能有一些新的发展。“让一个同步请求处理线程委托给一个异步线程池，并在线程池计算出结果之前进行阻塞是没有意义的——毕竟，请求线程也可以自己完成这项工作。”：在请求线程中执行所有处理将导致单片设计。不是吗？我不知道你如何定义“整体设计”，我既不能回答这个问题，也不能评估“整体设计”在这种情况下是否是不好的。是的。我意识到这是一件主观的事情，需要长时间的讨论才能理解双方。别担心！不管怎样，你确实回答了我的主要问题。所以，接受它。