我们托管了大约 150 个网站（可能扩展到 300+），我们正在考虑迁移到node.js. 大多数网站的流量都相当低，每月不到 100 万次浏览量。
每个网站应该是它自己的 node.js 进程，还是我们应该使用相同的 node.js 进程（或一小组负载平衡进程）为所有网站提供服务。每台服务器的节点进程数是否存在技术限制或合理限制？
每个站点的流程：感觉效率低下，但我不知道它是否真的效率低下。将确保一个有缺陷的站点不会影响其他站点。
每个核心/小组进程的进程：可能性能更高，但是当我需要更新站点代码库时会发生什么，它不会关闭其他站点吗？此外，一个站点中的代码故障会影响其他站点。
理想情况下，我希望每个站点一个进程，以便我们可以托管来自每个工作服务器的所有站点。这样，当负载增加时，我们可以启动另一个相同的工作服务器并在两者之间进行负载平衡，而不必随意说 SiteA 到 ServerA，SiteB 到 ServerB。有没有大师node.js可以提供一些智慧？
所有静态文件请求都可能由 Nginx 或 Varnish 之类的东西处理。
不，不要这样做。把事情简单化！并查看http://12factor.net/。
与您否则会失去的简单性相比，几百个过程算不了什么。在很多层面上，让一个 Node 进程为多个站点（或“逻辑应用程序单元”）提供服务将是一个糟糕的决定。
如果你问这个问题，你可能想在“迁移”到 Node 之前更多地探索 Node。Node 中的错误处理和关注点分离比其他情况更复杂。具体来说，无论是APIdomain还是clusterAPI 都不成熟。但实际上，您将违反干净和简单的应用程序部署理念。我可以继续下去。
这里有很多问题在起作用。大局的答案是，这取决于……当您引入整个“性能”讨论时，它总是如此。话虽这么说，设置可靠 Node 的最简单方法是注意以下有关 NodeJS 的基本事实，我还将评论它们与您的问题相关的含义。
使用 Node 获得的并发性在某些情况下非常有效，即 IO 繁重的操作。我们在这里真正谈论的是最大程度地减少等待下一个请求的停机时间。正因为如此，Node 在机器上每个核心有一个进程的环境中工作得非常好。Node 在最大化可用于在重负载下处理请求的 CPU 量方面做得非常好。话虽如此，如果您在偶数循环中进行了零其他工作，您可以通过每个核心拥有多个节点进程来看到较小的性能提升（就最大请求数/秒/处理器核心而言）。但是，我从未见过将这个数字增加到超过 3 的任何好处。即使在整个事件循环实际上只是一个文件服务器的情况下。
关于每个站点评论的过程。由于许多原因，这是一个坏主意。一方面，一个组合良好的节点服务器每秒可以处理数千个请求。我们的（公司名称省略）服务器通过 Amazon EC2 托管在中等集群（大量内存、中等 CPU 时钟、4 核）上，通常每个集群每秒约 3000 个请求失败。我们的服务器做了相当多的 CPU 工作，对于简单的文件服务器，我相信你可以做得更好。严格来说，当然，每个站点，您将能够通过在其自己的进程/核心/快速升级中启动每个站点来满足更多请求！但从架构的成本和过于复杂的角度来看，这不是必需的。我会推荐的是投资具有大量 RAM 的设置。
在整个 RAM 方面。您要为给定核心启动的进程数量取决于两件事。一是在您的事件循环中完成了多少同步工作。同步工作越多，给定请求进入和事件循环准备处理下一个请求之间的时间就越长。如果您有一个繁忙的事件循环，您将处于需要更多进程/CPU 核心的情况。另一个可能影响这一点的因素，尤其是与文件服务器相关的因素，是 RAM 的数量。Node 在高 ram 环境中运行得更好，但你可以说任何文件服务器真的......这与活动异步操作的数量有关。节点工作方式的一个缺点是在重负载下，您可以一次激活大量事件处理程序。这对于并发/简单性非常有用，但是，如果您的服务器正忙于等待大量异步磁盘/ IO 的发生，它会比您拥有大量 RAM 时速度变慢并更快崩溃。如果您没有足够的 RAM 来处理所有这些事件处理程序，您将希望保持 1 进程/核心安排。否则，Node 会更容易同时启动许多事件处理程序，并再次导致您比其他情况更快地崩溃。
我真的没有足够的信息来告诉你应该做什么。这完全取决于您的特定服务器的体系结构、站点、站点的大小、数据量……等等。但这三项知识是帮助您充分利用 Node 服务器的基本知识。老实说，您关于负载平衡的想法与上述考虑因素相结合，应该对您有好处。当然，微优化是可能的，但如果你做这些事情，你应该很容易看到每秒请求数以千计，然后因为 DDOS 类型的条件而开始遇到崩溃。