Express / Socket.io / Node 一个进程内的多个应用程序

Question

更多的是“最佳实践”问题，而不是技术问题，但是我正在尝试找出组织节点/快速应用程序的最佳方式，以实现对扩展的最优化。目前我们有一个单一的 express js 应用程序，它包含一个站点的多个“部分”。这包括聊天、我们的 BoxNet api 等领域。

将这些区域分成各自的快速应用程序以单独扩展每个区域会更好，还是将它们全部保存在一个快速应用程序中会更好？在应用程序的不同部分之间进行交谈是不存在的，因为它并不是真正必要的。对我来说，分离这些应用程序的最佳理由是轻松扩展不同区域之一，而不必扩展未受到太多影响的部分。我看到的负面影响将是潜在的管理噩梦或每个应用程序*规模的多个数据库连接。想法？

谢谢，

阿里克

Answer 1

将它们分开可以有两个原因：

1. 如果您的服务器上有多个处理器，则每个 Node.js 应用程序都可以在单独的核心上运行其事件循环，并且实际上并行运行，而不是看起来如此，从而让您立即加倍/服务器性能提高三倍（假设不受 I/O 限制）。
2. 因为所有逻辑服务都在一个事件循环中，所以您正在增加系统的脆弱性。如果一个服务锁定了事件循环，所有服务都被锁定。即使您的各种服务从未出现错误，您仍然会遇到“高性能”服务因被置于同一事件循环中而受到惩罚的问题。

例如，假设您有三个服务：一个是简单的服务，它在 Node.js 事件循环中花费约 50 毫秒，并且不访问数据库、文件等；这一切都在记忆中。第二个服务在 Node.js 事件循环中花费约 100 毫秒，并在 DB/文件 I/O 上花费约 400 毫秒。第三个服务在 Node.js 事件循环中花费约 400 毫秒，在数据库中花费约 100 毫秒。因为事件循环本质上是一个队列，每次等待非阻塞 I/O 时，逻辑请求都会被扔回堆栈的末尾，因此您的第三个服务可能会因第二个服务而额外减慢约 300 毫秒它和队列前面之间的队列，每个第一个服务大约 50 毫秒（在摊销这些第一个服务中的 2 个之后）。

当对 Node.js 服务器的所有请求都具有相似的处理和 I/O 延迟时，您将获得对用户的一致响应时间，这比 随机 响应时间，因为前者意味着自适应流式音频/视频将以更高的比特率播放（例如），并且以一致的“节奏”浏览网页的用户将很快自己进入节奏并停止感知延迟（当然，除非太重要）。

您的数据库至少应该能够同时处理数十个连接，所以这应该不是问题；但如果服务之间真的不怎么交流，您可能还希望将数据库拆分为单独的进程。