每个网站应该是自己的`node.js`进程
我们主持约150个网站（可能缩放到300+），我们正在考虑迁移到node.js 大多数网站stream量相当低，每月浏览量不足1百万次。
每个网站应该是自己的node.js进程，还是应该使用相同的node.js进程（或一组小负载平衡进程）来为所有网站提供服务。 每台服务器的节点进程数是否有技术限制或合理的限制？
每个站点的进程：感觉效率低下，但我不知道它是否实际上效率低下。 将确保一个越野车网站不会影响其他网站。
每核心进程/一小组进程：可能更高的性能，但是当我需要更新站点代码库时会发生什么情况，是不是会占用其他站点？ 另外，一个站点中的代码失败会影响其他站点。
理想情况下，我希望每个站点都有一个进程，以便我们可以托pipe每个工作服务器上的所有站点。 这样，当负载增加时，我们可以旋转另一个相同的工作服务器，并在两者之间进行负载平衡，而无需任意说SiteA去ServerA和SiteB去ServerB。 任何node.js大师可以提供一些智慧？
所有的静态文件请求将被Nginx或类似Varnish的东西处理。
在这里玩很多问题。 总的来说，答案是，这取决于…当你进行整个“表演”讨论时，它总是这样。 也就是说，build立一个坚实的节点的最简单的方法是注意以下关于NodeJS的基本事实，我也将评论它们与你的问题有关的含义。
-
在某些情况下，使用Node获得的并发性非常好，即IO操作。 我们在这里真正讨论的是最大限度地减less等待下一个请求的停机时间。 正因为如此，Node在一台机器上每个内核有一个进程的环境中工作得非常好。 节点确实能够最大限度地提高在高负载下可用于处理请求的CPU数量。 这就是说，如果你真的在零循环中执行其他的工作，你可以看到每个核心有多个节点进程，性能提高了（以最大请求/秒/处理器核心为单位）。 但是，我从来没有看到任何增加这个数字3的好处。即使在整个事件循环实际上只是一个文件服务器的情况下。
-
在每个网站评论的过程。 这是一个坏主意，原因很多。 首先，一个放在一起的节点服务器可以每秒处理数千个请求。 我们的（公司名称省略）服务器通过Amazon EC2在中等群集（大量ram，中央CPU时钟，4个内核）上托pipe，通常每个集群每秒钟发出约3000个请求。 我们的服务器做了一些CPU的工作，对于简单的文件服务器，我相信你可以做得更好。 严格地说，每个站点都可以通过自己的进程/核心/快速升级每个站点来提供更多的请求！ 但是从体系结构的angular度来看，这并不是必须的，也不是必须的。 我会推荐的是投资于一个有很多内存的设置。 您的服务器caching经常请求的文件的能力将比为特定机器启动大量进程更多地影响您的性能。
-
整个RAM的东西。 您要为特定核心启动的进程数量取决于两件事情。 一个是你的事件循环做了多less同步工作。 同步工作越多，进入的请求和事件循环之间的时间就越多，以准备好迎接下一个请求。 如果您有一个繁忙的事件循环，则会出现需要更多进程/ CPU核心的情况。 另一件可以影响这个function的东西，特别是与文件服务器相关的是RAM的数量。 节点在ram高的环境下运行得更好，但是你可以对任何一个文件服务器这么说…这与活动asynchronous操作的数量有关。 节点工作方式的一个缺点是负载很重，你可以同时获得大量的事件处理程序。 这对于并发性/简单性来说非常好，但是，如果你的服务器正在忙着等待大量asynchronous磁盘/ IO的发生，它会比如果你有足够的RAM更快地崩溃和崩溃。 如果你没有足够的内存来处理所有这些事件处理程序，那么你将需要遵循1进程/内核安排。 否则，Node更容易同时启动许多事件处理程序，并再次导致您比其他情况更快崩溃。
我没有足够的信息来告诉你你应该做什么。 这完全依赖于特定服务器的体系结构，站点，站点大小，数据量等等。但是这三个知识点是帮助您充分利用Node服务器的基本知识。 说实话，你有关负载平衡的想法混在上面的考虑，应该很好地为你做。 当然，微观优化是可能的，但是如果你做了这些事情，你应该很容易看到数千个请求/秒，然后由于DDOStypes的条件而开始遇到崩溃。
不，不要这样做。 把事情简单化！ 并检查出http://12factor.net/ 。
几百个进程相比，你失去的简单。 在这么多的层面上，这将是一个可怕的决定，要有一个以上的站点（或称“逻辑应用程序单元”）由单个节点进程提供服务。
如果您提出这个问题，您可能需要在“迁移”到Node之前更多地探究Node。 error handling和问题分离在Node中比在其他情况下更复杂。 具体而言， domain和cluster API都不成熟。 但是真的，这是干净和简单的应用程序部署的哲学，你会违反。 我可以继续下去。