AWS上的计算抽象：一个视觉故事-优快云博客

本文通过可视化方式，概述了AWS提供的从物理服务器到函数计算的多种计算抽象层级，包括实例、容器、函数和裸机抽象，展示了AWS如何帮助用户摆脱非核心任务，专注于业务创新。

去年我加入AWS的时候，我想找到一个方法，以尽可能简单的方式从计算角度解释AWS为用户提供所有的产品。有很多方法来细细讲解，但是，我想跟大家分享一下我创造的“可视化”的方法。

我把计算域定义为“拥有CPU和内存容量，允许运行特定语言编写的任意一段代码的所有一切”。你的定义范围也许因定义的方式而异，但是，这个定义的范围足够宽泛，应该能涵盖很多不同的解释。

我的故事中一个关键部分是介绍业界在过去的20年间所见证的不同级别的计算抽象。

职责分离

我的方法始于一条线。在云环境中，这条线定义了使用者和供应商这两个角色之间的边界。在云中，有些事由AWS做，还有些事由使用者做。这些职责范围的不同取决于您选择使用的服务。如果您想更多地了解这个概念，请参阅AWS共享安全责任模型文档（the AWS Shared Responsibility Model documentation）。

不同的抽象级别

上面这条线是倾斜的原因是，它需要和不同的计算抽象级别相切。如果想一下在过去20年间IT行业所发生的事，我们已经看到了大量不同的计算抽象，这些计算抽象改变了人们消耗CPU和内存资源的方式。这一切都始于1980年代的物理（X86）服务器，然后，我们看到了业界在逐年添加抽象级别（比如，虚拟机管理程序、容器、函数）。

抽象的级别越高，云供应商就越能增加价值，并且可以让消费者脱离非战略活动。很多这样的活动往往是“无关紧要的重活”。我们把这个定义为AWS使用者必须做的事，但是不一定能将其与他们的竞争者区分开来（因为这些活动是特定行业的筹码）。

我们发现，为了支持AWS上数百万的使用者，我们所提供的服务需要具有一定程度的灵活性，因为要满足很多不同的模式、用例和要求。

在我们深入探讨之前，还有一些最后的说明。这个故事通过博文建立的方式与各种服务发布日期的进展保持一致，但有一些例外。另外，所提及的服务都是普遍可用的和生产级的。为了完全透明，它们之间的一些整合可能还在进行的过程中，我将在其明确的时候明明白白地告诉大家。

实例（或虚拟机）抽象

这是我们早在2006年就引入AWS的第一个抽象。亚马逊弹性云计算（Amazon Elastic Compute Cloud，简称Amazon EC2）是允许AWS客户在云中启动实例的服务。当客户使用这个级别的抽象时，他们对客户操作系统及以上应用（中间件、应用程序等）和它们的生命周期负责。AWS负责管理硬件和虚拟机监控程序，包括它们的生命周期。

同一级别的还有Amazon Lightsail，它是“开发人员、小企业、学生以及其他需要简单虚拟专有服务（virtual private server，简称VPS）解决方案的用户开始使用AWS最简单的方法。Lightsail为开发人员提供计算、存储、网络容量和功能以在云中部署、管理网站和网络应用程序”。

下图显示了这两个服务在我们可视化中呈现出来的样子：

容器抽象

随着微服务的兴起，在过去的几年里，一种新的抽象方式席卷了整个行业，那就是容器。容器不是新技术，几年前Docker兴起的让更多的人开始使用容器。你可以把容器看作是具有软边界的独立环境，其中包含你自己的应用程序以及运行它的软件依赖项。而实例（或VM）虚拟化硬件，以便运行专门的操作系统，容器技术又可以虚拟化操作系统，这样你可以运行具有不同（通常是不兼容）软件依赖性的独立应用程序。

现在是棘手的部分了。基于容器的现代解决方案通常用两个主要的逻辑部分实现：

容器控制平面负责暴露API和接口，以定义、部署容器并对容器进行生命周期管理，有时也被称为容器编排层。\\t
容器数据平面负责提供容量（如CPU/内存/网络/存储），以便这些容器可以实际运行和连接到网络。从实际的角度来看，它通常是Linux主机或Windows主机，容器可以在其中启动并连接到网络。\

可以说，在特定的计算抽象中，数据平面是关键，但是了解控制平面部件也一样重要。

亚马逊于2014年发布了产品级的容器控制平面，该容器控制平面被称为AWS ECS，它“是一个具有高扩展性、高性能的容器管理服务，支持Docker……使用亚马逊ECS，你将无需安装、操作和扩展集群管理基础架构。”

在2017年，亚马逊还宣布有意发布基于Kubernetes的新服务，也就是EKS （Amazon Elastic Container Service for Kubernetes）。Kubernetes是开源容器控制平面技术。亚马逊EKS于2018年6月初上市。

与ECS一样，EKS旨在把AWS的客户从不得不管理容器控制平面的重任中解放出来。过去，AWS的客户在EC2抽象之上启动EC2实例以及部署和管理自己的Kubernetes masters（masters是Kubernetes运行控制平面主机的名字）。但是，我们认为，很多AWS客户将把管理这一层的重任交给AWS，这是通过ECS或EKS来实现的，具体情况取决于他们的用例。

到目前为止，我们已经讨论了容器控制平面。那么容器数据平面呢？它通常是客户管理的一组EC2实例。容器控制平面由AWS管理，而容器数据平面由客户管理。有人可能会对此产生争议，通过ECS和EKS，我们已经提高了控制平面的抽象级别，但是，我们还没有真正提高数据平面的抽象级别，因为数据平面仍然由常规的EC2实例构成，这些实例是由客户负责的。

以下是容器控制平面和容器数据平面服务呈现出来的样子：

函数抽象

在2014的re:Invent大会上，AWS引入了另一个抽象层：AWS Lambda。Lambda是一个执行环境，允许AWS客户运行单个函数。因此，无需管理和运行整个OS实例来运行代码，也无需在用户构建的容器中跟踪所有的软件依赖项来运行代码，Lambda允许上传代码，大规模的运行则交给AWS。

Lambda的特别之处在于事件驱动模型：不仅可以直接调用Lambda（比如，通过亚马逊API网关），而且可以根据在另一个AWS服务中的事件触发一个Lambda函数（比如，一个到亚马逊S3的上传或在亚马逊DynamoDB表中的更改）。

使用Lambda，你将无需管理运行函数之下的基础架构，无需跟踪物理主机状态和机群容量，无需修补运行该函数的操作系统。简而言之，无需在无关紧要的重活上耗费时间和金钱。

这就是Lambda服务呈现出来的样子：

裸机抽象

也称为“无抽象”。

在最近的2017年的re:Invent大会上，我们发布了亚马逊EC2裸机抽象实例（预览版）。该服务于2018年5月向公众开放。

\
“……（AWS客户）希望访问物理资源，因为这样应用程序可以利用底层硬件功能，比如performance counters和Intel® VT，这些功能在虚拟环境中不总是受到全面的支持。另外，客户也是希望访问在硬件上直接运行或在非虚拟环境中获得授权和支持的应用程序。”
\

这就是裸机亚马逊EC2 i3.metal实例呈现出来的样子：

i3.metal是基础EC2实例类型，处于VMware的VMware Cloud on AWS服务之上。现在，我们给所有AWS用户提供裸机实例的能力。但这并不意味着你可以开箱即用加载自己选择的虚拟机管理程序，但是，你可以处理一些用传统EC2实例无法做到的事。

更严重的是，我经常被问到的一个问题是，用户是否可以自己在i3.metal上安装ESXi。这个如今还做不到，但是，我有兴趣听听你的相关用例。

完整的容器抽象（缺少一个更好的术语）

现在我们已经介绍了所有的抽象，是时候回头看看我们是否可以给AWS的客户提供其他的优化。当我们在讨论容器抽象时，我们说到尽管有两个不同的全托管容器控制平面（ECS和EKS），但是没有数据平面的托管选项。

有些客户曾经（并且仍然）对能完全控制所述实例感到高兴。也有一些客户一直想要摆脱管理基础设施生命周期的业务（无关紧要的重活）。

AWS Fargate是一个生产级的服务，给AWS容器控制平面提供计算容量。实际上，Fargate正在让容器数据平面落入“供应商空间”职责范围。这意味着公开给用户的计算单位是容器抽象，而AWS将透明地管理下面的数据平面抽象。

这是Fargate服务呈现出来的样子：

现在，ECS有两种“启动类型”：一种称之为“EC2”（您的任务被部署在用户管理的EC2实例群上），另一个被称为“Fargate”（您的任务被部署在AWS管理的EC2实例群上）。

总结

文中介绍了AWS上可用的抽象级别，AWS客户如何根据其用例以及他们的云成熟度来使用这些抽象。想提升和转型的客户可能更倾向于使用处于图片左侧的服务，而采用更成熟的云原生方法的客户可能对使用处于图片右侧的服务更感兴趣。

总的说来，客户倾向于使用更高级别的服务来摆脱管理非差异性活动的业务。例如，最近，我和对使用Fargate感兴趣的客户进行了交谈。Fargate符合ISO、PCI、SOC和HIPAA的标准，这对于他们来说可以节省大量的时间和金钱，因为在审计过程中它更容易指向一个AWS文档，而不需要为一个DIY容器数据平台构建合规配置。

总结一下，这是我们的可视化呈现，其中包含所有可用的抽象：