每个网站都应该是自己的`node.js`进程吗？

Question

每个网站都应该是自己的`node.js`进程吗？

node.jsload-balancing

4

我们托管大约150个网站（可能会扩展到300个以上），我们正在考虑将它们迁移到node.js。大部分网站的流量都较低，每月<100万页面浏览量。

每个网站是否应该有自己的node.js进程，还是使用同一个node.js进程（或小型负载均衡进程集合）来为所有网站提供服务？服务器上每个node.js进程的数量是否存在技术限制或合理限制？

每个网站一个进程：感觉效率不高，但我不知道它是否真的效率低下。可以确保一个有问题的网站不会影响其他网站。

每个核心/小型进程集合一个进程：可能性能更高，但当我需要更新某个网站的代码库时，不会使其他网站崩溃吗？此外，一个网站的代码错误会对其他网站产生影响。

理想情况下，我希望每个网站有一个进程，这样我们就可以从每个工作服务器上托管所有网站。这样，当负载增加时，我们可以启动另一个相同的工作服务器并在两者之间进行负载平衡，而不必随意地说SiteA去ServerA，SiteB去ServerB。有任何node.js专家能提供一些建议吗？

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

- Owen Allen

2个回答

1

不，不要这样做。保持简单！并查看http://12factor.net/。

与你失去的简单性相比，几百个进程微不足道。在一个Node进程中服务多个站点（或“逻辑应用单元”）将是一个可怕的决定，从许多方面来看都是如此。

如果您正在问这个问题，在“迁移到”Node之前，您可能需要更多地了解Node。错误处理和关注点分离在Node中比其他情况更加复杂。具体来说，无论是domain还是cluster API都不够成熟。但实际上，你会违反简洁和简单的应用部署理念。我可以继续说下去。

- Dmitry Minkovsky

我的理想情况是每个站点有一个进程。我的问题是这样做会不会出现问题。在单个框上拥有200多个进程会引入巨大的膨胀开销吗？例如，在我们当前的JVM环境中，200多个JVM实例的想法是可笑的。在超过20之前，该框将死亡。我需要知道的是，这种限制是否存在于node中。 - Owen Allen

我并不是在回避你的问题，而是在说你别无选择。这是 /唯一/ 的方法，不是因为我对想出更节约资源的解决方案心态封闭，而是因为如果你不按照这种方式做，你会给自己制造一个复杂的混乱。有时候你不能只在一个盒子上运行所有东西。Node 进程可以达到 10-30MB。 - Dmitry Minkovsky

当然，这绝对取决于您的硬件。一个盒子可以有500MB的RAM或5000MB的RAM。我认为一个大盒子可以处理200个节点。但是，嘿，为什么不选择4个中等大小的盒子呢？ - Dmitry Minkovsky

看起来在Node中最轻量级的轻量级HTTP服务器（就像您在HTTP服务器示例中看到的那样）根据架构在RAM中为4-8 MB。 - Dmitry Minkovsky

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- MobA11y · Accepted Answer

这里涉及到很多问题。总体而言，答案是视情况而定...当你谈到整个“性能”讨论时，总是如此。话虽如此，建立一个稳定的Node设置的最简单方法是注意以下有关NodeJS的基本事实，并且我也将评论它们与你的问题相关的含义。

使用Node可以在某些情况下获得很好的并发性能，特别是在IO密集型操作中。我们真正要讨论的是最小化等待下一个请求的停机时间。因此，Node非常适合在每个机器核心上有一个进程的环境中工作。在重载情况下，Node非常擅长最大化可用CPU以服务请求。话虽如此，如果你的事件循环中没有任何其他工作，你可以通过每个核心拥有多个Node进程来看到轻微的性能提升（以每个处理器核心的最大请求数为单位）。但是，我从未见过将此数字增加到3以上的任何好处。即使在整个事件循环实际上只是一个文件服务器的情况下也是如此。

关于每个站点的进程评论。这是一个不好的想法，原因有很多。首先，一个精心设计的Node服务器可以每秒处理数千个请求。我们（公司名称省略）的服务器，通过Amazon EC2在中型集群上托管（大量内存，中等CPU时钟，4个核心），通常在每个集群每秒3000个请求左右失败。我们的服务器做了相当多的CPU工作，对于简单的文件服务器，我相信你可以做得更好。严格来说，确实，每个站点，通过在其自己的进程/核心中启动每个站点，你将能够通过快速升级来服务更多的请求！但从成本和架构过于复杂的角度来看，这是不必要的。我会建议你投资一个有很多RAM的设置。你的服务器缓存常请求的文件的能力将无限地影响你的性能，而不是为给定的机器启动大量进程。

关于整个RAM的问题。你想为给定的核心启动的进程数量取决于两件事。一件是在你的事件循环中完成了多少同步工作。同步工作越多，一个给定请求到达和事件循环准备好处理下一个请求之间的时间就越长。如果你的事件循环很繁忙，你将处于需要更多进程/CPU内核的情况。另一件事情，特别是对于文件服务器来说，可能会影响这一点的是RAM的数量。Node在高RAM环境中运行得更好，但实际上你可以对任何文件服务器都这样说......这与活动异步操作的数量有关。Node的一种缺点是，在重载情况下，你可能会同时有大量的事件处理程序处于活动状态。这对并发性/简单性非常有利，但是，如果你的服务器忙于等待许多异步磁盘/IO发生，它会比如果你有足够的RAM要慢得多并且更容易崩溃。如果你没有足够的RAM来处理所有这些事件处理程序，你将想保持每个核心1个进程的安排。否则，Node更容易同时启动许多事件处理程序，并再次导致你比其他情况下更快地崩溃。

我没有足够的信息告诉您应该做什么。这完全取决于您特定服务器的架构、站点、站点大小、数据量等等。但是，以下三个知识点是帮助您充分利用Node服务器的基本要素。老实说，结合上述考虑因素，您对负载平衡的想法应该很好。当然，微小的优化是可能的，但如果您执行这些操作，您应该可以轻松看到每秒请求数在数千个之前，在遇到DDOS类型的情况导致崩溃之前。