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

Question

对于更有经验的 Node 和后端人员来说，这可能是一个愚蠢的问题，我希望这里没有长时间的争论，但是......

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

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

过程文件：

web: bin/web
worker: bin/worker

这是我的想法和他们推荐它的 3 个理由，但我希望有人能帮助我了解我是否走在正确的轨道上......

让我们想象一下这个场景：

1) “网络”应用用于处理 API 2）“工人”应用程序适用于需要时间或需要重试失败的东西。前任。发送电子邮件。 API 只是不想等待 HTTP 响应太久，所以是的。 3) 然后，有一个假设的“web + worker”应用程序可以两者兼得。

A) 使用单独的 Web 和工作应用程序会更好地提高性能吗？

我没有看到将应用分离为单独的 Web 和工作应用程序的任何性能优势。在 2 个 CPU 的机器中，如果我们有 2 个 Web 进程和 2 个工作进程，由于 Node.js 的单线程特性，它的性能将与“同时执行 Web + 工作工作的组合应用程序”的 2 个进程一样高效”。

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

也许，我可以同意这个。

我们可以有只能在worker中使用的类、函数等，还有一些只能在web part中使用。

C) 是为了健壮性吗？

理论上，是的……我们举例来说， 1.如果我们有一台2 CPU的机器， 2.我们不分web和worker，app的代码同时做“worker和web”的工作， 3. 我们在集群的帮助下旋转该应用程序的 2 个进程， 4.我们安排了2个非常长且耗时的任务（CPU BOUND，没有任何I/O，只是为了举例，所以它实际上挂了一个Node进程），整个应用程序只是挂起，因为两个进程正忙于处理这2个任务。

但是，在这种情况下，我将创建 2 个 Web 进程和仅 1 个工作进程。这样，如果 worker 非常忙，剩余进程上的 web 仍然可以接受 API 请求并响应客户端。我想是的……

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

Answer 1

Heroku 的禅宗是The 12 Factor App。 Heroku 鼓励 web 和 worker 使用不同的进程类型，它们将在单独可扩展的 dyno 上运行。 见https://12factor.net/concurrency。

此外，对于 node.js 应用程序，Heroku 提出建议并使用 node.js clustering 提供对 optimizing application concurrency 的支持，以最大限度地提高在多核 dynos 上运行的 node.js 应用程序的性能。这使您能够在采用垂直扩展（即增加分配给您的 dyno 的计算资源）或水平扩展（即增加应用程序中每个进程类型的 dyno 实例的数量）之前，从每个 dyno 实例中获得最大性能。

请注意，理论上您可以在单个 dyno 中同时运行 Web 和 Worker 进程，但根本不建议这样做。在您的 procfile 中，您可以有一些“主要”进程类型，当运行时会产生额外的进程。但是，您将遇到诸如如何监控您的进程是否正常运行等问题以及其他问题。如果您“按规则行事”（例如，请参阅 Dyno crash restart policy），Heroku 会自动处理所有这些。

这样做的底线是：您可以通过在单个测功机中同时运行 Web 和 Worker 进程来降低测功机成本，但这确实不是 Heroku 打算让您做的事情，如果您这样做，您可能会遇到意想不到的问题。