假设我正在构建一个 3 层网站，后端有 Mongo DB，浏览器中有一些非常轻量级的 javascript（假设只是对表单进行验证，也许是几个可以触发一些 AJAX 请求的花哨的控件）。
我需要为“中间”层选择一种技术（我们可以将其细分为子层，但该细节不是这里的重点，只是整体技术选择），我想在其中处理一些来自DB，并将其呈现为我推送到浏览器的一些 HTML。一个相当典型的瘦客户端 Web 架构。
我的安全选择是在 Java 中实现这个中间层，使用 Jongo 之类的库与 Mongo DB 对话，也许 Jackson 在他们发出 AJAX 请求时编组/解编 JSON 与我的花哨的控件对话。还有一些用于在服务器上呈现我的 HTML 的 Java 模板框架。
但是，我对将所有这些都扔到窗外并在这个中间层使用 Node.js 的想法很感兴趣，原因如下：
我喜欢 javascript（好的部分），假设这个应用程序的业务逻辑比 Java 更具表现力。
到处都是javascript。在堆栈上的任何位置工作时，无需在语言之间切换，实际上也无需在 OO 和功能范式之间切换。层之间没有翻译管道，JSON 在任何地方都受到原生支持。
我可以在客户端和服务器上重用验证逻辑。
如果将来我决定在浏览器中进行 HTML 渲染客户端，我可以用 Backbone 之类的东西重用现有模板，只需极少的重构/重新测试工作。
如果您在这一点上并且喜欢 Node，那么以上所有内容似乎都是显而易见的。所以我应该选择Node对吗？
但是……这就是我失败的地方：众所周知，Node 基于单线程异步 I/O Web 服务器模型。这对我在服务数据请求方面的可扩展性和性能非常有用，但是我的业务逻辑呢？我的模板渲染呢？这些东西不会对单线程上的所有请求造成巨大的瓶颈吗？
我想到了两个明显的解决方案，但它们都不是正确的：
保留“阻塞”业务逻辑，只需使用节点实例集群和负载均衡器，即可真正并行地为请求提供服务。好的，那么为什么 Node 一开始就不是多线程的呢？或者这始终是一个想法，保持简单愚蠢并避免在基本情况下多线程复杂性的可能性，如果需要多核处理能力，让程序员在此之上进行额外的设置工作？
保持单个节点实例，并通过调用在其他一些多线程应用服务器上运行的我的业务逻辑的一些 java 实现来保持它的非阻塞。好的，这个选项完全抵消了我列出的使用 Node 的每个专业人士（实际上它比仅使用 Java 增加了复杂性），除了可能获得对数据库的 CRUD 请求的性能和可伸缩性。
这最终让我想到了我的问题——我是否遗漏了 Node 难题的一些重要部分，我是否完全错误地理解了事实，或者 Node 只是不适合在服务器上处理业务逻辑？换句话说，与其他阻塞 I/O 的实现相比，Node 是否仅对坐在数据库上并以更高效和可扩展的方式服务许多 CRUD 请求有用？而且您必须在下面的某个层甚至客户端执行所有业务逻辑，以保持任何合理水平的性能和可扩展性？
考虑到关于 Node 的所有讨论，我宁愿希望它带来的不仅仅是这个。否则我很想被说服！