我应该使用 AWS Elastic Beanstalk 还是 Amazon EC2 Container Service (ECS) 来扩展 Docker 容器？

Question

我开发了一个由多个微服务组成的基于 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 中的自动缩放组进行配置。现在第二个实例启动了，但是除了第 5 个容器之外的每个容器几乎都处于空闲状态，当然我不希望它们在第二个实例中也产生 4 个不必要的容器，这会浪费资源。只有第 5 个应该产生，其他的应该根据可配置的参数像第 5 个比例缩放，例如：CPU/内存/SQS。

我不完全知道 Amazon ECS 是否正在这样做，或者是否有可能，但我真的在互联网上找不到任何关于这个主题的资料，一般来说，基于实例进行扩展/容器。

Answer 1

EB 与 ECS 真正归结为控制。你想控制你的扩展和容量，还是你想要更抽象，而是主要关注你的应用程序。 ECS 将为您提供控制，因为您必须指定集群中节点的大小和数量以及是否应使用自动扩展。使用 EB，您只需提供一个 Dockerfile，而 EB 负责扩展您的节点数量和大小的配置，您基本上可以忘记使用 EB 路由的基础设施。

这是 Docker 上的 EB 文档：http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker.html

使用 ECS，您必须先构建基础架构，然后才能开始部署 Dockerfile，因此这实际上归结为 1）您对基础架构的熟悉程度和 2）您希望在基础架构上花费的工作量与应用程序。

Answer 2

不要复活一个死问题，但希望这对某人有所帮助。

接受的答案不够明确：根据 OP 的描述，OP 想要 ECS，而不是 Multi-Container Elastic Beanstalk (MCEB)。据我所知，MCEB 从未尝试有效地将容器打包到实例中。 OP 在评论中问道，“如果只有一个负载，它只扩展这个，还是总是扩展实例并启动所有容器，无论它们处于什么负载下？”答案是“后者”； MCEB 扩展实例并启动所有容器，无论它们处于何种负载下。

编辑

不要使用你想象中的架构。

您的微服务有多微型？给他们每个人一个 t2.nano 会很荒谬吗？然后让它们每个都成为单容器 Docker EB 应用程序 - EB 工作程序应用程序可以由 SQS 消息驱动。或使用apex.run。

编辑 1/31/18：

AWS Fargate 看起来很酷。

2019 年 6 月 5 日编辑：

如果您需要编排容器来满足需求，请使用 EKS。但实际上，尽量避免这种情况。分布式系统很难。