为什么Heroku在Node.js中推荐Foreman？

Question

对于经验丰富的Node和后端人员来说，这可能是一个愚蠢的问题，让我希望这里不再有争论，但是...

为什么Heroku建议使用procfile并与工头一起启动单独的Web和单独的工作进程？

链接： https ： //devcenter.heroku.com/articles/node-best-practices

Procfile：

web: bin/web
worker: bin/worker

这是我的想法以及他们会推荐它的3个原因，但是我希望有人能帮助我了解我是否处在正确的轨道上...

让我们想象一下这种情况：

1）“ Web”应用程序用于处理API 2）“ worker”应用程序用于处理需要时间或需要重试失败的内容。 防爆。 发送电子邮件。 API只是不想长时间等待HTTP响应，所以是的。 3）然后，有一个假想的“网络+工作者”应用程序可以同时执行这两种操作。

A）是否有单独的Web应用程序和辅助应用程序更好地提高了性能？

将应用程序分离为单独的Web应用程序和辅助应用程序，看不到任何性能上的好处。 在2个CPU的计算机中，如果我们有2个Web进程和2个工作进程，由于Node.js的单线程性质，它的性能与具有2个同时执行Web +工作任务的组合应用程序的进程一样”。

B）是否为了代码的可读性而分开？

也许我可以同意这一点。

我们可以有只能在worker中使用的类，函数等，而有些只能在web部件中使用。

C）是否出于鲁棒性？

从理论上讲，是的...让我们举个例子：1.如果我们有2个CPU的计算机，2.我们不分离为web和worker，并且应用程序的代码同时执行“ worker和web”工作， 3.我们在群集的帮助下旋转了该应用程序的2个进程，4.我们安排了2个非常耗时的任务（CPU BOUND，没有任何I / O，仅出于示例目的，因此它实际上挂起了Node进程） ），整个应用只是挂起，因为两个进程正在忙于处理这两个任务。

但是，在这种情况下，我将创建2个Web进程和1个工作进程。 这样，如果工作人员非常忙，则其余进程上的Web仍可以接收API请求并响应客户端。 我认同...

我的想法正确吗？ 为什么Heroku建议将Node.js代码拆分为工作程序和Web应用程序？

Answer 1

Heroku的禅宗是12要素应用程序 。 Heroku鼓励为Web和工作人员使用单独的进程类型，这些进程类型将在单独的可伸缩dynos上运行。 请参阅https://12factor.net/concurrency 。

此外，对于node.js应用程序，Heroku提出了建议，并提供了使用node.js集群 优化应用程序并发性的支持，以最大化在多核dyno上运行的node.js应用程序的性能。 这使您能够在诉诸垂直缩放（即增加分配给dyno的计算资源）或水平缩放（即增加应用程序中每个进程类型的dyno实例的数量）之前，从每个dyno实例中挤出最大性能。

请注意，从理论上讲，您可以在单个dyno中同时运行Web和Worker进程，但是完全不建议这样做。 在procfile中，您可能有一些“主要”进程类型，运行时会产生其他进程。 但是，您将遇到一些问题，例如如何监视流程是否正常运行以及其他问题。 如果您“遵守规则”（请参阅​​例如Dyno崩溃重新启动策略 ），那么Heroku会自动照顾好所有这些。

这样做的底线是：您可以通过在单个dyno中运行Web和Worker进程来减少dyno成本，但这实际上不是Heroku想要的，如果这样做，您可能会遇到意外的问题。