剑客
关注科技互联网

三代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 )关注我们。

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址