node.js - 在Amazon ECS上的Docker中运行Node API的最佳方法是什么？

随着docker的出现以及诸如Amazon ECS之类的调度与编排服务的出现，我试图确定部署Node API的最佳方法。除了Docker和ECS，我想利用node集群库通过创建一个主进程和多个工作处理器，以解决documentation中建议的异步错误，从而使Node app崩溃。

集群方法的好处之一是，除了优雅地处理错误外，还为每个可用的CPU创建一个工作处理器。但这在docker世界中有意义吗？在单个Docker容器中运行多个要被缩放到ECS上的EC2实例集群的节点进程是否有意义？

如果没有Node集群方法，我将失去正常处理错误的能力，因此我认为至少应该为每个Docker容器运行一个master进程和一个worker进程。对于在ECS的“任务定义”中定义多少个CPU，我仍然感到困惑。 ECS documentation讲述每个CPU实例具有1024个单元的每个容器实例；但这与EC2计算单元不同，是吗？话虽如此，我需要选择带有适当数量的vCPU的EC2实例类型才能实现这一目标？

我了解实现最佳配置可能需要对我的特定Node API应用程序进行一定程度的基准测试，但是对从何处开始有一个更好的了解将是很棒的。也许我需要做一些研究/研究？任何指导我前进的道路或建议的指针，将不胜感激!

编辑:回顾我的具体问题:

是否有必要在docker容器中运行here所述的master/worker集群以实现正常崩溃？

使用与Cluster文档中描述的几乎相同的代码来通过require('os').cpus().length“扩展”到可用的CPU是否有意义？

Amazon在ECS任务定义的文档中是什么意思，在cpus设置中表示container instance has 1024 units per CPU是什么？而此设置的一个很好的起点是什么？

将实例类型用于基于以上所述的旨在为Node API提供服务的ECS集群的最佳起点是什么？可用的vCPU如何影响先前的问题？

最佳答案

所有这些技术都是新技术，并且仍在建立最佳实践，因此仅根据我的经验将其视为技巧。

每个容器一个进程更多的是建议，而不是一成不变的规则。使用完容器后，最好在容器中运行多个进程，尤其是在主进程派生 worker 的情况下。正如您在问题中所建议的，仅使用一个容器并允许它为每个内核派生一个进程。

在EC2上，实例类型具有多个vCPU，这些vCPU将作为OS的核心。对于ECS群集，请使用EC2实例类型，例如带有四个vCPU的c3.xlarge。在ECS中，这转换为4096个CPU单位。如果要让该应用程序使用所有4个vCPU，请创建一个需要4096 cpu单位的任务定义。

但是，如果您这样做只是为了阻止应用崩溃，您也可以使用重启策略来在崩溃时重启容器。看来ECS尚不支持重启策略。