三代 AWS

关键摘记

• AWS 提供了 3 种基础设施原语：EC2 实例、ECS 任务和 Lambda 函数。
• Lambda 函数是最新的技术，费用支出上具有吸引力，只需低度运维管理，但现在并不适合所有类型的应用。
• EC2 实例支持任意工作负荷，但要很多能自己动手解决问题的专业人士来支持这些应用。
• ECS 任务同样支持任意工作负荷，并将实例安装和运维的大部分工作交由 AWS 完成。
• 主要聚焦于为各种应用构建 Docker 镜像。现在 ECS 可以很好地运行所有应用 Docker 镜像，而 ECS 和 Lambda 都具有的“无服务器”的特性是某种实现细节。

在 AWS 上构建一个新系统时，关于应用打包、运行时服务和负载平衡服务的架构方案，我们有三种选择。

我们可以构建一些 Amazon 机器镜像（AMIs），然后在 Elastic Compute Cloud（EC2） 上以虚拟机运行这些影像，用一个前端的 Elastic Load Balancer（ELB）实现负载均衡。

我们也可以构建一些 Docker 镜像，然后以容器的方式运行在 EC2 容器服务中（ECS），用一个前端的 Application Load Balancer（ALB）来实现负载均衡。

我们还可以构建一些 Node、Python 或 Java 项目的 zip 文件，然后作为 Lambda 函数运行，这些函数都位于一个 API 网关之后。

EC2、ECS 和 Lambda 函数代表了过去十年中 AWS 所提供的三代服务。实例、任务和函数各是每一代服务的主要构成要素。

尽管每一种架构都能导向成功，并且每种架构上都将会有一些实际系统在运行，但目前看来，ECS 任务是最好的架构选择。与手工配置的 EC2 实例比较，ECS 任务成本更低，更安全，速度也更快；而与 Lambda 函数比较，ECS 无需遵循 Lambda 函数的种种严格约束。

为什么选择 Lambda 函数？

Lambda 函数是最新的 AWS 技术，最近得到了很多的追捧，宣称是“云计算的未来”。实时函数调用、每请求计费和零服务器管理这些特性看来是不可战胜的。

围绕着 AWS 平台内部所生成的事件来添加自定义的逻辑，这是使用 Lambda 函数的最简单方法。经典的杀手级 Lambda“应用”是一个 JavaScript 函数，它被配置成每个新 S3 对象重新设置镜像大小时自动化调用该函数。

这种使用 Lambda 函数的事件驱动编程模式可以实现极端复杂的应用。如果结合使用 AWS 简单队列服务（SQS），再加上 DynamoDB，不需要任何服务器，你就能创建鲁棒的、动态的、成本经济的生产者和消费者系统。

在 2015 年，AWS 开始提供 API 网关服务，API 网关将访问者的 HTTPS 请求转换为事件，事件从而触发 Lambda 函数。Lambda 从而籍此拥有强大能力，支持无服务器的面向互联网的 API。

目前，用于构建基于 Lambda 函数的系统的工具都在爆炸式发展，相关的应用开发模式也正以同样的态势快速演化。

为什么不选择 Lambda 函数？

然而，以函数作为构建要素会有很多严格的约束，给系统构建带来严峻挑战。

目前，每个 Lambda 函数调用必须在 5 分钟之内完成，也不能使用多过 5G 的内存。如果函数调用违背了这些约束，则它会被简单地终止掉。

与此类似，API 网关服务仅支持 HTTPS 连接，既不支持 HTTP，也不支持 HTTP/2。

对于传统业务 Java、PHP 和 Rail 应用来说，这些约束决定了它们并不合适选择 Lambda 来起步。

Lambda 确实代表了云的未来。在接下来的十年中，AWS 将继续努力工作，以实现无服务器管理，并大幅降低用户的费用支出。

但是目前来说，由于这些约束的存在，Lambda 不能完全替代需要 EC2 实例的场合。而且 ECS 也能类似地简化服务器管理，减少用户支出，还不用做出种种艰难的折衷。

为什么不选择 EC2 实例？

EC2 实例是最古老的技术，离现在有 10 年了，被认为是云计算从实验探索变成现实存在的实现形式。基于供应和管理的 API 的特性和按小时计费一起替代了传统托管模式。

但是在 EC2 实例中管理应用还有很多不足之处。你需要选择操作系统，还要使用像 Chef 这样的配置管理工具来安装你的应用所需要的各种依赖部分，再使用类似 Packer 的镜像工具构建 AMI。

由于需要构建 AMIs，然后再启动 VMs，部署过程至少需要几分钟。在持续交付的今天，我们期望的是几秒之内就能完成部署。

为什么选择 EC2 实例？

刚提过，我们不能处处都使用 Lambda 函数，所以还是需要使用实例。

EC2 实例非常灵活，所以有很多策略来成倍地加速部署过程。一种常见的技巧就是使用像 Ansible 这样的工具，用 SSH 方式登录至每个实例，拉取代码的一个新版本，然后重启应用服务器。但现在我们是使用 bespoke 脚本来改变添加到失败场景中的实例。

另外一个策略是“蓝绿部署”。我们能启动一整个部署着新版本软件的 EC2 实例集（蓝），并将流量迁移至该实例集，然后停掉老的实例集（绿）。这种方式可以减少故障场景，但并不一定会增加部署速度。这种方式还存在需要双倍容量的窗口，这会增加费用支出，在服务停用中很可能无法满足这种需求。

一种尖端技术是在每个实例中安装一个代理，代理协同启动和停止过程，以实现滚动部署。像 Google 和 Twitter 这些大公司已经实际成功运用了这种跨通用实例集群的调度模型。现在很多开源的项目像 Docker Swarm 和 Apache Mesos 都采用这种技术，编排跨集群的快速部署操作。

因为速度，固定的容量需求，Google 的成功实践，而成熟的开源解决方案又使得各种各样的数据中心（本地或云）都可以采用它，容器编排是一种现代的最佳实践。

所以带有容器编排的 EC2 实例是 AWS 现代最好的实践。

这也说明了为什么在容器编排软件中竞争激烈，这也是 AWS 推出自己的全管理的 EC2 容器服务（ECS）的原因。

如果我们安装了 Swarm 或 Mesos，那我们就得负责这些软件的运维。我们必须确保编排服务 100% 可用，这样实例才一直能检入，才知道它们是否需要启动或是停止。而如果我们使用了 ECS，Amzon 就代为承担了这些职责，我们完全不用再操心了。

为什么选择 ECS 任务？

ECS 任务是一种年轻的技术，不过容器编排是现在云计算的最佳实践。把我们的应用打包成一种标准镜像格式，内含操作系统，然后跨“哑”实例集群的调度容器，这种方式所具有的种种特性相对于较陈旧的 EC2 实例策略来说，极大地提升了效率。

与 EC2 实例相比，更容易构建容器，也能更快地启动容器。一个实例可以运行多个容器负载，这样带来的效果是减少了操作系统承担的额外开销，而且减少了需要维护和付费的实例数量。编排同样地协同了快速部署和故障恢复。

ECS 最重要的区别是它受管理的服务。

Amazon 提供一个“已 ECS 优化的 AMI”，它有着正确的服务器操作系统。Docker 服务器已事先配置过。AWS 负责保持 ECS APIs 一直在线，所以实例能总是连接上，并请求做更多的事情。AWS 负责编写运行在每个实例上开源 ecs 代理。

因为 AWS 建设了整个栈，我们能信任其质量，如果有地方运行异常，我们也相信 AWS 将会有计划来保证它能正常运作。

AWS 将任务视为整个 AWS 平台的第一等原语，明白这一点也是非常重要的。

每个任务—我们每一个在集群中运行的命令—都拥有下面的配置选项：

• CPU 和内存限制。
• 基于 IAM 角色的安全策略。
• 使用外部 syslog、fluentd 系统或 CoudWatch Logs 组记录日志。
• 注册至某个负载均衡器。

今年新推出了两个服务。Elastic File System（EFS）和 Application Load Balancer（ALB） 显然都是围绕着容器化的工作负载进行设计，并消除了 Elastic Block Store（EBS）和 Elastic Load Balancer（ELB）所具有的主要约束，EBS 和 ELB 都是源自 EC2。

综上所述，与 EC2 相比，任务具有更多立即可用的特性。

我期望 AWS 会不断地围绕着任务进行着平台改进，比如在接下来的几年中，改进了审计和收费。我还期望减少集群管理所需的工作开销。

所以选择 ECS 任务的话，我们只负责提供任意一个 Docker 镜像，Amazon 则负责其它事务以保证应用一直运行下去。

总结

EC2 实例太原始，为了支持一个应用，需要大量的定制工作。Lambda 函数又有太多约束，不太合适传统的应用。ECS 任务则刚好，为打包和运行任何应用提供了一种简单方式，同时还能让 AWS 为我们操心一切。

如果你正在 AWS 中构建一个现代的实际系统，最好选择基于 ECS 任务的架构。

作者简介

Noah Zoschke是 Convox 的 CTO，Convox 是一个开源的基础设施框架。Convox 采用了关于 Docker 和 AWS 最佳实践，还提供了用于构建、开发和管理应用的简单命令，带来了真正的开发和生产效率的平衡。他曾担任过 Heroku 的平台架构师。在 Heroku 任职期间，他设计、构建并管理过面向消费者的的云容器服务，这是最早和最大的云容器服务之一。点击 @nzoschke 和 @goconvox 在 Twitter 跟随他，请查看 The Convox Blog 以保持联系。

查看原文连接： The Three Generations of AWS

感谢冬雨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。