Java 设计web应用程序：业务逻辑应该驻留在哪里？

有一个web应用程序的设计，我不知道如何评价它的好坏。
想法如下：
您在Tomcat中部署了一个web应用程序（非常重要），它接受客户端请求。我想Tomcat可以处理的负载可能是最大的。
现在，实际的处理不是在容器内完成的，而是委托给另一个进程，该进程通过一个

TCP

连接进行连接。因此，这里基本上发生的是多路复用。
也就是说，客户端请求由客户端并发发送，这些请求作为消息发送到另一个要处理的进程（我想该进程本身是多线程的），但通过一个连接。
我从一个同事那里听到过类似的设计（在另一个平台上），它的性能非常好，但在我看来，这在使用单一TCP连接方面存在瓶颈。
虽然我在多线程方面很有经验，但我并不知道或使用过异步方法（nio等），我想知道这是否属于这一类。

---

有没有人把多路复用作为一个大项目的一部分（至少是这样）？这是一个好的选择吗

我同意你的看法。这是一个瓶颈，也是一个糟糕的设计。如果第二个TCP服务器可以是多线程的，并且一次可以处理多个客户机，那么您肯定应该以这种方式实现它，与另一个TCP服务器（例如Tomcat本身）完全相同，并使用多个连接到它。

我不认为在两台机器之间打开更多TCP连接会增加吞吐量；这可能会影响吞吐量。所以一个连接更好。当然，这需要一些仔细的设计。@unreputable:你说得有道理。但是如果你的客户端负载很大，那么在同一个连接上进行多路复用可以节省资源，但是响应速度是否足够快？@unreputable:当然可以，不是1，而是3呢？或者正好是4？如何在设计时确定这样一个数字？显然，在实现完成后，您不能进行性能测试和重构，在这种情况下，如果它是连接到数据库的一个好选择-当精确调整时-我不明白为什么连接池在您的体系结构中不是一个好主意…如果我说tcp连接是一种消息总线是正确的，那么它的实现实际上应该隐藏在api后面的库中，并且可能与其他库互换1）如果第二台服务器接受多个连接，而不是像您所指出的那样只有一个连接，那么后端处理首先直接从tomcat中的web应用程序完成，而不是作为代理向其他进程发送请求，可能会更好吗？2） @Unreputable的评论在某种意义上似乎是合理的，认为在物理层，消息无论如何都会按顺序发送，但你认为这样的理由可以证明这样的设计选项吗？：我误解了你的答案吗？你说的是在Tomcat中处理一切？不确定你所说的

第二个TCP服务器