我应该使用AWS Elastic Beanstalk还是Amazon EC2 Container Service（ECS）来扩展Docker容器？
我开发了一个由多个微服务组成的基于Docker的应用程序。 它必须使用Amazon SQS消息并对其进行处理。 起初我想使用AWS Elastic Beanstalk，但后来我倒了EC2容器服务。 现在我不知道选哪一个。
到目前为止，Elastic Beanstalk支持多容器环境。 这很好，因为每个微服务都有一个Docker容器内的自己的应用服务器。 下一个问题是缩放：
我不知道缩放机制是如何工作的。 例如：我在Elastic Beanstalk环境中有5个docker容器。 现在只有第五个docker集装箱承受着沉重的负担，因为它有大量的SQS信息要处理，另外四个几乎空闲，因为它们不需要太多的CPU或者可能没有太多的SQS信息。 我们假设第5个容器运行一个JBoss应用程序服务器。 据我所知，即使有足够的CPU /内存，服务器也只能消耗有限的并行请求。
如果JBoss Docker容器不能处理大量的请求，但有足够的CPU /内存可用，当然我想在同一个实例上自动启动第二个Docker / JBoss容器。 但是如果我没有足够的CPU /内存会发生什么呢？ 当然，我想旋转第二个实例，可以通过EB中的自动缩放组进行configuration。 现在是二审，但五号以外的每一个集装箱都快空闲了，当然我也不希望它们在二次产生不必要的东西，这样会浪费资源。 只有第五个应该产卵，其他的应该像第五个规模那样根据可configuration参数如CPU /内存/ SQS进行缩放。
我不完全知道Amazon ECS是否正在这样做，或者如果可能的话，但是我真的无法在互联网上find关于这个主题的任何来源，这通常是基于实例/容器的扩展。
EB和ECS真的可以控制。 你想控制你的扩展和容量，或者你想要更抽象的，而主要集中在你的应用程序。 由于您必须指定群集中的节点的大小和数量以及是否应使用自动缩放，ECS将为您提供控制。 通过EB，您只需提供一个Dockerfile，然后EB负责扩展节点的数量和大小的configuration，您基本上可以忘记EB路由的基础架构。
以下是Docker上的EB文档： http : //docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker.html
使用ECS，在开始部署Dockerfile之前，您必须首先构build基础架构，这样才能真正降低到1）您对基础架构的熟悉程度以及2）希望在基础架构和应用程序上花费的工作量。
不要复活一个死的问题，但希望这可以帮助一个人。
接受的答案还不够清楚：根据OP描述的内容，OP需要ECS，而不是Multi-Container Elastic Beanstalk（MCEB）。 据我所知，MCEB从来没有试图有效地将容器打包成实例。 OP在评论中提出：“如果只有一个负载不足，只能扩展这个负载，或者总是扩大实例并启动所有容器，不pipe负载是多less？” 答案是“后者”; MCEB扩大实例并启动所有的容器，不pipe它们在什么样的负载下。
编辑
不要使用你想象的架构。
你的微服务有多微？ 给他们每个人一个t2.nano会是荒谬的吗？ 然后使它们成为单个容器的Docker EB应用程序 – EB工作应用程序可以由SQS消息驱动。 或者使用apex.run 。
