Amazon ECS的核心是集群管理器，集群是一个供用户应用程序使用的计算资源池，而所谓的资源是指由容器划分的Amazon EC2实例的CPU、内存和网络资源。
Amazon EC2 Container Service (ECS) 是一个高度可扩展的高性能软件容器管理服务，它支持 Docker，使用户可以轻松地在 Amazon EC2 实例集群上运行应用程序。近日，Amazon首席技术官Werner Vogels撰文介绍了Amazon ECS的架构。下图是Amazon ECS包含的基本组件：
Amazon ECS的核心是集群管理器，这是一个处理集群协调和状态管理任务的后台服务，它的上面是不同的调度器。集群管理和容器调度相互分离，用户可以构建自己的调度器。集群是一个供用户应用程序使用的计算资源池，而所谓的资源是指由容器划分的Amazon EC2实例的CPU、内存和网络资源。Amazon ECS通过运行在每个实例上的Amazon ECS容器代理协调集群。该代理允许Amazon ECS与EC2实例通信，并在用户或调度器请求时启动、停止和监控容器。它是用Go编写的，在GitHub上遵循Apache许可协议开源。
为了协调集群，需要一个有关集群状态的唯一信息源，提供诸如集群包含的EC2实例、运行在实例上的任务、组成任务的容器以及可用资源或已占用的资源这样的信息。这样，才能成功地启停容器。为此，他们将状态存储在一个键/值存储中。在任何现代集群管理中，键/值存储都是一个核心。而且，为了实现持久性和高可用性，预防网络分区或硬件故障，该键/值存储需要采用分布式部署。但这又带来一个问题，就是数据一致性很难保证，并发修改也很难处理。这就需要有一种并发控制机制来确保多个状态修改不会冲突。
为了实现并发控制，他们在实现Amazon ECS时使用了Amazon的其中一个核心分布式系统组件：一个基于Paxos算法以事务日志为基础的数据存储。该组件记录了每个数据条目的每次修改。每次写入操作都会作为日志中的一个事务提交，并且有一个特定的有顺序的ID。数据存储中的当前值是根据日志记录所做的所有事务操作的总和。它允许Amazon ECS采用乐观并发的方式存储集群状态信息，在一个共享数据不断变化的环境中，这是非常合适的。
有了键/值存储，就可以协调集群了。而为了使用户能够利用Amazon ECS的状态管理功能，他们通过一组API开放了Amazon ECS集群管理器。用户可以通过它们以一种结构化的方式访问存储在键/值存储中的所有集群的状态信息。这组API成为用户在Amazon ECS上构建自己的解决方案的基础。Vogels举了两个例子。
一个是自创建第一天起就托管在AWS上的免费叫车应用Hailo。在过去的几年里，该应用从一个运行在单个AWS区域中的单体应用程序演化成为一个运行在多个区域中的基于微服务的架构。起初，每个微服务运行在一个实例集群上。但实例为静态分区，导致每个分区的资源利用率都不高。为此，他们决定基于服务优先级和其它指标在一个弹性资源池上调度容器。他们选择了Amazon ECS，因为后者通过API完全暴露了集群状态，使他们可以使用满足特定应用需求的逻辑构建一个自定义的调度器。
另一个是教育类通讯软件Remind。它起初是一个运行在Heroku上的大型单体应用。但随着用户数的增长，他们希望具备水平扩展的能力。因此，大约在2014年底，其工程团队开始探索使用容器迁移到微服务架构。他们希望在AWS上构建一个兼容Heroku API的PaaS（平台即服务）。为了管理集群和容器编排，他们首先考察了一些开源解决方案，如CoreOS和Kubernetes。但考虑到团队规模较小，他们没有时间管理集群基础设施及保持集群高可用。经过简单的评估之后，他们决定在Amazon ECS上构建他们的PaaS。这样，工程团队就可以专注于应用开发和部署。在6月份的时候，Remind开源了他们的PaaS解决方案“Empire”。在接下来的几个月中，他们将把核心基础设施的90%迁移到Empire上。
总之，Amazon ECS的架构提供了一种高可扩展、高可用、低延迟的容器管理服务。它允许以乐观并发的方式访问共享的集群状态信息，并通过API赋予用户创建自定义容器管理解决方案的能力。另外，Vogels还提到，集群中实例的数量并不会对Amazon ECS的延迟产生明显的影响。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
