node.js - 每个网站都应该是自己的 `node.js`流程

Question

我们托管着大约150个正在考虑迁移到node.js的网站(可能会扩展到300多个)。大多数网站每月的访问量都非常低，<100万浏览量。

每个网站应该是它自己的node.js进程，还是我们应该使用相同的node.js进程(或一小组负载均衡的进程)为所有网站提供服务。每个服务器的 Node 进程数是否有技术上的限制或合理的限制？

每个站点的流程:感觉效率低下，但我不知道它是否实际上效率低下。可以确保一个 buggy 站点不会影响其他站点。

每个核心/少量进程集的进程:可能更高的性能，但是当我需要更新站点代码库时会发生什么，是否会导致其他站点瘫痪？同样，一个站点中的代码故障可能会影响其他站点。

理想情况下，我希望每个站点一个进程，以便我们可以从每个辅助服务器托管所有站点。这样，当负载增加时，我们可以启动另一个相同的工作服务器，并在两者之间实现负载平衡，而不必任意说SiteA转到ServerA，而SiteB转到ServerB。任何node.js专家都可以提供一些智慧吗？

所有静态文件请求都可能由Nginx或Varnish之类的东西处理。

Answer 1

这里有很多问题。概括的答案是，这取决于...正如您进行整个“性能”讨论时一样。话虽如此，建立可靠的Node的最简单方法是注意有关NodeJS的以下基本事实，并且我还将在它们与您的问题有关时对它们的含义进行评论。

在某些情况下，即IO繁重的操作，使用Node获得的并发性确实很好。我们在这里真正在谈论的是将等待下一个请求的停机时间减至最少。因此，Node在机器上每个内核只有一个进程的环境中确实能很好地工作。 Node确实在最大化可用于在高负载下为请求提供服务的CPU数量方面做得很好。这就是说，如果您在偶数循环中进行了几乎为零的其他工作，则可以看到每个内核具有多个 Node 进程，从而性能会有所提高(就最大请求数/秒/处理器内核而言)。但是，将这个数字增加到3以上，我从未见过任何好处。即使在整个事件循环实际上只是一个文件服务器的情况下，也是如此。

关于每个站点的评论过程。这是一个坏主意，原因有很多。首先，一个组装得很好的 Node 服务器每秒可以处理数千个请求。我们的(省略公司名称)服务器通过Amazon EC2托管在中型集群(大量ram，中型CPU时钟，4个内核)上，通常每个集群每秒约有3000个请求失败。我们的服务器执行大量CPU工作，对于简单的文件服务器，我相信您可以做得更好。严格来说，可以肯定的是，对于每个站点，通过在此处快速启动每个站点的进程/核心/升级，您将能够满足更多请求!但是从架构的角度来看，从成本和过于复杂的角度来看，这不是必需的。我将建议的是，投资具有大量RAM的安装程序。服务器缓存经常请求的文件的能力将对您的性能产​​生无限的影响，而不仅仅是为给定机器启动大量进程。

关于整个RAM的事情。您要为给定核心启动的进程数取决于两件事。一是事件循环中完成了多少同步工作。同步工作越多，给定请求进入与事件循环准备处理下一个请求之间的时间就越长。如果您有一个繁忙的事件循环，那么您将需要更多的进程/CPU内核。可以影响这一点的另一件事(尤其是与文件服务器相关的事情)是RAM的数量。 Node在高内存环境中运行得更好，但是您实际上可以对任何文件服务器这么说。这与 Activity 的异步操作数量有关。 Node 工作方式的一个弊端是负担很重，您可以一次激活大量事件处理程序。这对于并发性/简单性来说非常有用，但是，如果您的服务器正忙于等待大量异步磁盘/IO发生，它将比您拥有大量RAM的情况下变慢并崩溃得多。如果没有足够的RAM来处理所有这些事件处理程序，则将需要保持1个进程/核心安排。否则，Node同时启动多个事件处理程序会更容易，并且再次导致您比其他情况更快崩溃。

我确实没有足够的信息告诉您您应该做什么。这完全取决于特定服务器的体系结构，站点，站点大小，数据量等。但是，这三点知识是帮助您充分利用Node服务器的基本知识。老实说，将负载平衡的想法与上述注意事项结合在一起，对您来说应该做得很好。当然，可以进行微优化，但是如果您执行这些操作，则由于DDOS类型的条件，在开始崩溃之前，您应该很容易地看到每秒的请求数/千。