我们正在考虑迁移到node.js的大约150个网站(可能扩展到300个).大多数网站的流量相当低,每月的网页浏览量低于1万.

每个网站应该是它自己的node.js流程,还是我们应该使用相同的node.js流程(或一小组负载平衡流程)为所有网站提供服务.每台服务器的节点进程数量是否存在技术限制或合理限制？

每个站点的进程：感觉效率低下,但我不知道它实际上是否效率低下.确保一个越野车站点不会影响其他站点.

每个核心/一小组流程的处理：可能性能更高,但是当我需要更新站点代码库时会发生什么,它不会取消其他站点吗？此外,一个站点中的代码失败会影响其他站点.

理想情况下,我更喜欢每个站点一个进程,以便我们可以托管每个工作服务器的所有站点.这样,当负载增加时,我们可以启动另一个相同的工作服务器并在两者之间进行负载平衡,而不必随意说SiteA转到ServerA而SiteB转到ServerB.任何node.js大师都可以提供一些智慧吗？

所有静态文件请求都可能由Nginx或类似Varnish处理.

最佳答案 这里有很多问题在起作用.大局回答是,这取决于……当你引入整个“绩效”讨论时它总是如此.话虽如此,设置实体节点的最简单方法是注意以下关于NodeJS的基本事实,并且我还将评论它们与您的问题相关的含义.

>使用Node获得的并发性在某些情况下非常好,即IO繁重的操作.我们在这里真正谈论的是最小化等待下一个请求的停机时间.因此,Node在一台机器上每个核心有一个进程的环境中运行良好. Node确实能够最大限度地提高在高负载下提供请求的CPU数量.这就是说,如果您在偶数循环中进行了其他工作,那么通过在每个核心上拥有多个节点进程,您可以看到性能上升(在最大请求/秒/处理器核心方面).但是,我从未见过将此数字增加到3以上的任何好处.即使在整个事件循环实际上只是文件服务器的情况下也是如此.
>关于每个网站的流程评论.出于多种原因,这是个坏主意.例如,一个整合好的节点服务器可以每秒处理数千个请求.我们(公司名称省略)服务器通过Amazon EC2在中型集群(大量内存,中间CPU时钟,4个内核)上托管,通常每个集群每秒失败约3000个请求.我们的服务器做了相当多的CPU工作,对于简单的文件服务器,我相信你可以做得更好.严格地说,当然,每个站点,您将能够通过在其自己的进程/核心中快速启动每个站点/升级来提供更多请求！但是,从架构的角度来看,从成本和复杂性来看并不是必需的.我将推荐的是投资于具有大量RAM的设置.服务器缓存经常请求的文件的能力将比为特定计算机启动丰富的进程无限地影响您的性能.
>关于整个RAM的事情.要为给定核心启动的进程数取决于两件事.一个是在事件循环中完成了多少同步工作.同步工作越多,给定请求进入和事件循环准备好下一个请求之间的时间就越长.如果您有一个繁忙的事件循环,您将处于需要更多进程/ CPU核心的情况.影响这一点的另一件事,特别是与文件服务器相关的是RAM的数量. Node在高ram环境中运行得更好,但你可以说任何关于任何文件服务器的真正……这与活动异步操作的数量有关.节点工作方式的一个缺点是,在负载很重的情况下,您可以立即激活大量事件处理程序.这对于并发性/简单性非常有用,但是,如果您的服务器忙于等待大量异步磁盘/ IO发生,那么它将比您有足够的RAM更快地减速和崩溃.如果没有足够的RAM来处理所有这些事件处理程序,则需要保留1个进程/核心安排.否则,Node会更容易同时启动许多事件处理程序,并再次导致您比其他情况更快崩溃.

我真的没有足够的信息告诉你你应该做什么.这完全取决于您的特定服务器的体系结构,站点,站点大小,数据量等等.但这三个知识是帮助您充分利用节点服务器的基本知识.说实话,您对负载平衡的想法与上述考虑因素混合在一起,应该很适合您.当然,微观优化是可能的,但如果你做这些事情,你应该很容易看到成千上万的请求/秒,因为DDOS类型的条件,你开始遇到崩溃.