Node.js 是否应该用于密集处理？

Question

假设我正在构建一个 3 层网站，在后端使用 Mongo DB，在浏览器中使用一些非常轻量级的 javascript（假设只是对表单进行验证，也许是一些可以触发 AJAX 的精美控件请求）。

我需要为“中间”层选择一种技术（我们可以将其细分为子层，但这里的重点不是细节，只是整体技术选择），我想在其中处理一些原始数据从数据库中取出，并将其呈现为一些我推送到浏览器的 HTML。一个相当典型的瘦客户端 Web 架构。

我的安全选择是在 Java 中实现这个中间层，使用 Jongo 之类的库与 Mongo DB 对话，也许 Jackson 在他们发出 AJAX 请求时编组/解编 JSON 与我的花哨的控件对话。还有一些用于在服务器上呈现我的 HTML 的 Java 模板框架。

但是，我对将所有这些都抛在脑后并在这个中间层使用 Node.js 的想法很感兴趣，原因如下：

• 我喜欢 javascript（好的部分），假设这个应用程序的业务逻辑比 Java 更具表现力。

• 到处都是javascript。在堆栈上的任何位置工作时，无需在语言之间切换，实际上也无需在 OO 和功能范式之间切换。层之间没有翻译管道，JSON 在所有地方都得到原生支持。

• 我可以在客户端和服务器上重用验证逻辑。

1234563

如果您在这一点上并且喜欢 Node，那么以上所有内容都会显得很明显。那我应该选择Node吧？

但是...这就是我失败的地方：众所周知，Node 基于单线程异步 I/O Web 服务器模型。这对我在服务数据请求方面的可扩展性和性能非常有用，但是我的业务逻辑呢？我的模板渲染呢？这东西不会对单线程上的所有请求造成巨大的瓶颈吗？

想到了两个明显的解决方案，但都不是正确的：

1. 保留“阻塞”业务逻辑，只需使用 Node 实例集群和负载均衡器，即可真正并行地为请求提供服务。好的，那么为什么 Node 一开始就不是多线程的呢？或者这一直是这个想法，保持简单愚蠢并避免在基本情况下出现多线程复杂性的可能性，如果需要多核处理能力，让程序员在此基础上进行额外的设置工作？

2. 保持单个节点实例，并通过调用在其他多线程应用服务器上运行的我的业务逻辑的一些 java 实现来保持它的非阻塞。好的，这个选项完全抵消了我列出的所有使用 Node 的专业人士（实际上它比仅使用 Java 增加了复杂性），除了可能获得对数据库的 CRUD 请求的性能和可扩展性。

这最终让我想到了我的问题——我是否遗漏了 Node 难题的一些重要部分，我只是完全错误地理解了事实，还是 Node 不适合在服务器上处理业务逻辑？换句话说，与其他阻塞 I/O 的实现相比，Node 是否仅对坐在数据库上并以更高性能和可扩展性的方式为许多 CRUD 请求提供服务有用？而且您必须在下面的某个层甚至客户端执行所有业务逻辑，以保持任何合理水平的性能和可扩展性？

考虑到 Node 上的所有热议，我宁愿希望它带来比这更多的东西。我很乐意被说服！

Answer 1

在任何给定系统上，您都有 N 个可用的 cpu（1-64，或任何 N 恰好是）。在任何 CPU 密集型应用程序中，您都会遇到 N cpus 的吞吐量。没有神奇的方法可以通过添加超过 N 个线程/进程/任何东西来解决这个问题。要么你的代码必须更高效，要么你需要更多的 CPU。更多线程无济于事。

关于多 CPU 性能的一个鲜为人知的事实是，如果您需要同时运行 N+1 个 CPU 密集型操作，则每个 CPU 的吞吐量会下降很多. CPU 密集型进程在放弃它之前往往会在该 CPU 上挂起很长一段时间，从而使其他任务严重挨饿。在大多数情况下，阻塞 I/O 和伴随的任务切换使现代操作系统的多任务工作和它一样好。如果我们的日常常见任务中有更多受 CPU 限制，我们会发现我们的机器需要比目前更多的 CPU。

Node.js 在效率方面为服务器方带来的好处是对每个线程的彻底使用。理想情况下，您最终会减少任务切换。这不是一个巨大的胜利，但是让 N 个线程异步处理 N*C 个连接将比 具有性能优势N*C 阻塞线程在相同数量的 CPU 上运行。但是 CPU 的底线是一样的：如果你有超过 N 价值的实际 CPU 工作要做，你会感到有些痛苦。

我上次查看 Node.js API 时，有一种方法可以使用一个侦听器和每个 CPU 一个工作线程来启动服务器。如果你能做到这一点，我会倾向于使用 Node.js，前提是满足一些注意事项：

• Javascript 无处不在的方法为您带来了一些简单性。对于复杂的事情，我会担心异步编程风格会使事情变得更难而不是更容易。
• Node.js 中的模板处理和其他 CPU 密集型任务并不比您选择的其他语言/平台慢。
• 数据库驱动程序可靠。

我可以看到一个缺点：

• 如果某个线程崩溃，您将丢失该线程所服务的所有连接。

最后，请记住，程序员的时间通常比服务器或带宽更昂贵。