对于经验丰富的Node和后端人员来说，这可能是一个愚蠢的问题，让我希望这里没有长时间的辩论，但是......
为什么Heroku建议使用procfile并启动一个单独的Web和一个单独的工作进程与工头？
链接：https://devcenter.heroku.com/articles/node-best-practices
Procfile：
web: bin/web
worker: bin/worker
以下是我的想法以及他们推荐的3个理由，但我希望有人帮助我了解我是否走在正确的轨道上......
让我们想象一下这种情况：
1）A＆＃34; web＆＃34; app用于处理API 2）A＆＃34;工人＆＃34;应用程序用于需要时间或需要重试失败的东西。防爆。发送电子邮件。 API只是不想等待很长时间的HTTP响应，所以是的。 3）然后，有一个假设的网络+工作者＆＃34;这两个应用程序。
A）是否有一个单独的网络和工作者应用程序更好的性能？
我认为将应用分成单独的网络和工作人员应用会带来任何性能优势。在2 CPU机器中，如果我们有2个Web进程和2个工作进程，由于Node.js的单线程特性，它将与具有两个Web的组合应用程序的2个进程一样高效。 +工人工作＆＃34;。
B）为了代码的可读性而分离？
也许，我同意这个。
我们可以拥有类，函数等，只能在工作者中使用，有些只能在Web部件中使用。
C）是否具有稳健性？
理论上，是的......为了举例，我们说 1.如果我们有2台CPU机器， 2.我们不会分成网络和工作人员，应用程序的代码同时兼顾工作人员和网络工作人员。工作， 3.我们在群集的帮助下旋转该应用程序的2个进程， 4.我们安排了2个非常耗时且耗时的任务（CPU BOUND，没有任何I / O，只是为了示例，所以它实际上挂起了一个Node进程），整个应用程序只是挂起，因为两个进程忙于处理这两个任务。
但是，在这种情况下，我将创建2个Web进程和1个工作进程。这样，如果工作人员超级繁忙，剩余进程上的Web仍然可以获取API请求并响应客户端。我想是的......
我的想法是否正确？为什么Heroku建议将Node.js代码拆分为工作者和Web应用程序？
答案 0 :(得分：1)
Heroku的禅是The 12 Factor App。 Heroku鼓励为Web和worker提供单独的进程类型，这些进程类型将在可单独扩展的dynos上运行。 请参阅https://12factor.net/concurrency。
此外，对于node.js应用程序，Heroku使用optimizing application concurrency提出建议并为node.js clustering提供支持，以最大限度地提高在多核dynos上运行的node.js应用程序的性能。这使您可以在使用垂直缩放（即增加分配给dynos的计算资源）或水平缩放（即增加应用中每个进程类型的dyno实例数）之前，从每个dyno实例中挤出最大性能。
请注意，理论上您可以在一个dyno中同时运行Web和Worker进程，但不建议这样做。在proc文件中，您可以使用一些“主”进程类型，在运行时会生成其他进程。但是，您将遇到诸如如何监视进程是否正常运行以及其他问题等问题。如果你“遵守规则”（参见例如Dyno crash restart policy），所有这些都由Heroku自动照顾你。
这样做的底线是：你可以通过在一个dyno中运行Web和Worker进程来降低你的dyno成本，但这并不是Heroku打算让你做的事情，如果你这样做，您可能会遇到意外问题。