亚马逊CTO沃格斯：AWS如何通过自定义硬件提升云端性能

在re:Invent大会上，亚马逊的CTO沃格纳·沃格尔斯（Werner Vogels）详细介绍了AWS如何通过部署自定义硬件来创建与裸金属性能相近的实例。

AWS reInvent已经成为每年最值得关注的科技盛会之一，对于技术人员而言，尤其是Amazon CTO Dr. Werner Vogels的keynote值得关注，每年的keynote都会讲到一些技术的发展趋势，那么来看看在刚刚过去的reInvent 2019上Dr. Werner Vogels讲了些什么。

1. 虚拟化技术的发展

---

Vogels表示，虚拟化“从一开始就一直是云环境中计算部分的基础”。随着时间的推移，AWS已经“突破”了这项技术的界限。传统虚拟化的问题是，所有用户操作系统都在争夺相同的资源，这通常会导致计算环境出现噪音，有时甚至不可靠。“我们开始思考如何从根本上改变这一点，”Vogels说，因为“旧式虚拟化”确实阻碍了用现代软件架构构建的应用程序的性能。

AWS希望向其客户提供云中裸金属的性能，尽可能减少传统云构建软件的资源消耗。解决方案来自于亚马逊在软件开发方面取得的创新，然后将其应用于构建新的硬件。“如果我们从微服务、小型模块中吸取经验，并将其应用到硬件领域，会怎么样”，Vogels说，“或许我们可以改变虚拟化的世界。”

于是AWS思考该怎么来改进虚拟化技术，出发点是怎么能让用户的虚拟机尽可能获得和用一台物理机同样的性能，在设计这个新的虚拟化系统（代号为Nitro）的时候，AWS想的是软件从单一的系统演进到微服务带来的灵活度的优势，他们希望同样可以把这个优势带入到新的虚拟化系统中，使得这个系统更加模块化，而不是像以前的虚拟化技术一样，只能由hypervisor去对接所有的硬件。

按照这个思想，AWS首先在2013年的c3实例上，采用了将网络模块从原来的虚拟化技术体系offload到一块单独的硬件卡上，AWS用了差不多两年的时间才让这个技术得以成熟，有了这个为基础，在之后的c4实例上，接着讲ebs storage也offload到了单独的硬件卡上，在c5实例上，则把local storage也offload了，也就意味着到了c5所有的io操作都offload到了单独的硬件卡上，不用再消耗卖给用户的机器上的cpu了，最后一步是把management的部分也offload了，同时写了新的更为轻量级的Nitro Hypervisor。

从效果上，也很清楚的可以看到到了c5的版本，相比之前经典的虚拟化，无论在网络io，storage io上都有明显的性能提升，在整个机器的性能上，也能看到c5相比c4，已经更为接近物理机的性能。

除了性能以外，开始讲到之前的虚拟化体系中最大的一个风险，就是安全，dom0其实就是一个linux，所以是可以登录进去的，登录进去后其实就拥有了巨大的权力，例如管理机器上所有的虚拟机，做个内存dump，而Nitro则把dom0去掉了(讲到这观众席一阵掌声)，其实现的核心机制是只有通过Nitro Controller才能操作Nitro Hypervisor，并且是单向的，其他扩展出来的controller也只能通过Nitro Controller来操作，同样Nitro Controller也不能反向操作扩展出来的Controller。

WS与以色列的Annapurna实验室合作，开始研究Nitro，将网络嵌入到一个单独的卡中，并在2013年为一类新的C3实例提供动力。Annapurna的下一个任务是将处理过程也转移到Nitro卡上，从而实现C4架构。这次合作非常成功，Annapurna加入了AWS。

2015年收购以色列芯片设计公司后，“我们开始研究C5，新的目标是将I/O装载到单独的卡上。”AWS还着眼于移动其虚拟机监控程序的一部分，并将其放在Nitro上，把硬件组件发展成一个全面的系统。

由于虚拟化系统的许多主要组件现在都在silicon上运行，AWS基础设施软件设计师能够通过剥离hypervisor，使EC2实例更精简、更可靠、更安全，只需运行最低限度的所需功能。这导致了功能上的下一次飞跃——新一代的EC2实例实现了AWS“几乎像裸金属一样”的目标。

Vogels告诉与会者：“虚拟机监控程序很小，几乎不影响用户操作系统。”将功能装载到硬件上不仅提高了性能，而且大大提高了安全性，限制了组件之间的通信，能够方便的阻止不需要的功能和不良程序。

“Nitro成为了创新的基础，”Vogels说，它允许AWS“做很多我们以前做不到的事情。” 由于Nitro平台支持最新和最好的AWS计算环境，使得提供软件实时更新、打补丁、虚拟机监控程序，以及创建诸如Outposts本地服务这样的新系统都成为可能。

Nitro不仅支持虚拟机，还支持容器和无服务器服务。这一努力催生了Firecracker，它被用来提高AWS Fargate服务的效率，该服务为容器工作负载提供动力。AWS的首席软件工程师Clare Liguori说，这种先进的方法允许Fargate在“虚拟化的框架下”运行由容器组成的应用程序的每个副本，从而更好地隔离客户。

Ligouri在周四的主题演讲中告诉与会者，AWS最初使用EC2实例来隔离Fargate上运行在无服务器模型中的容器化工作负载的空间，但这些实例通常“太重”。Firecracker是一种速度更快、重量更轻的高效容器平台。Ligouri 说，“随着我们在Firecracker上运行更多的Fargate，我们的效率越来越高”。

2. 持续演进的架构

亚马逊目前正在开发一个新的数据平台，直接在Nitro上运行，核心代码在GitHub上向开发者开放。这个项目利用了containerd，一个开源项目，它是开放容器计划的一部分。

Vogels指出，AWS Lambda无服务器系统也运行在Firecracker上，随着无服务器越来越受欢迎，这将带来更多的创新。当AWS首次推出Lambda时，它预计无服务器计算将主要吸引年轻的、有预算意识的公司。后来发现并非如此：“企业中正在迅速采用无服务器，”Vogels说。”

EBS讲了后，总结了下三种典型架构：

1. Regional Architecture

   这个简单说就是用一个集群支持所有用户，坏处就是如果集群出问题，所有用户就全部受影响了。

2. Cell-Based Architecture

   每个集群支持部分用户，其中一个集群故障，只会影响其对应服务的用户。
   

3. Shuffle Sharding Architecture

   用户群体复制N份，sharding后组合，每个集群服务组合后的用户group，这样就意味着每个用户其实有多个集群在提供服务，而每个集群服务的又是不同的用户group，所以组合情况够多的情况下，每个集群故障影响的面就会大幅减少。

这三种架构确实是比较典型的降低故障影响面的架构体系，但说起来容易做起来其实非常难，尤其是这里面涉及到的数据一致性问题，感兴趣的也可以去翻翻网上关于阿里异地多活的技术分享，对于大多数的场景，我认为能够做到有两个Region（可以是同一地域）同时服务所有用户，在任何一个Region出问题都能快速切换，这基本就可以大幅降低blast radius，相对实现难度和代价也不会太大。

接着讲到设计一个分布式系统是非常具备挑战的，Amazon在过去这么多年积累了非常多的经验，于是Amazon对这些进行了总结，对外提供了一个library，里面有很多Amazon自己实际的经验的文章，讲到这一片掌声，我也简单翻了下这网站，还是挺值得看的。

最后一个部分是讲工业制造方面，在和云、AI结合后带来的一些变化，这块我觉得更偏case一些，不过可以看到的是AWS也越来越强调相应的技术在Amazon的使用。

整个keynote看下来给人的感觉还是很不错的，可以看到AWS对技术的思考，创新，也会更让技术人员认可AWS的技术领先性，推荐大家自己也去看看，尤其是技术人员，更尤其的是做基础技术的，扩充视野是非常重要的，不能坐井观天，而AWS reInvent现在显然是扩充视野不可错过的科技盛会。

编译：若画