用了 Serverless 这么久，这里有其底层技术的一点经验

关注 TencentServerless 公众号，回复「PPT」，即可领取本届大会演讲 PPT。

无服务器背后的一个关键技术称作 microVMM。Firecracker 就是用于创建和管理 microVMM的开源项目。Firecracker 运行在用户空间，使用 KVM 来创建实例。其快速启动和低内存特性尤为关键。本议题将介绍 Firecracker 的基础、最小设备模型，以及它所带来的快速启动、性能、安全性和利用率的提升。本文由 Amazon Web Services 首席开发者布道师费良宏在 Techo TVP 开发者峰会 ServerlessDays China 2021 上的演讲《microVMM — Serverless 核心技术揭秘》整理而成，向大家分享，本次分享完整视频请见文末。

01. Serverless 的发展现状

今天跟大家分享一个有意思的话题，Serverless 背后核心的技术 — microVMM。我们一起见证和经历了很多开源技术、开发技术、软件架构技术不断的变化，很难相信在今天有如此多可以选择的技术栈，让我们去开发、运维、部件和部署，它们让我们觉得这个时代变得更加美好。其中就包括了今天我们谈论的主要话题：Serverless 无服务器，我最早接触它是在2014 年 Amazon Lambda 发布时，当我写下第一行「Hello World」，感到如此简单——将业务逻辑简单分装，只需几秒钟，就部署到云的环境中，我迅速获得一个 Endpoint 端点，就可以调用它获得一切的能力。这与以往的开发经历相比，简直是天壤之别，虽然那个时候 Serverless 还有很多不方便的地方、有很多技术上的限制。但过去几年里，这些技术的发展已经突飞猛进，给我们全新的感觉和认知。

Serverless 究竟发展到怎样的程度？今年的 5 月份，DataGog 公司针对 Serverless 市场发布了一份分析报告，可以让我们一睹在今天的市场当中 Serverless 技术发展的情况。

这个报告谈到几个有意思的观点：

第一，Serverless 的火热程度。以 Amazon Lambda 平台为例，对比 2019 年 Q1 与 2020 年 Q1，从全球的使用量来看，有了 3.5 倍的提升，这是非常了不起的进步，在绝大多数企业中，每天调用 Serverless 技术的函数时间大概达到 90 小时以上。甚至不仅 AWS Lambda，包括像 Azure Functions 和 Google Cloud Functions 等这些技术都有了长足的进步，用户的使用量和规模也越来越大。这一切都揭示着一个事实 — Serverless 技术变得越来越活跃，并且被广泛地接受。接受 Serverless 的用户，不仅仅是个体的开发者、创业公司、企业用户，甚至遍及到各行各业、在各种业务场景当中，我们甚至可以把 Serverless 看作是一种「胶水」一样的工具，把很多原来不可想象的运维、数据处理、机器学习的推理包括移动端的调用等都通过这样一个简单的技术加以贯穿起来。

同时，我们注意到开发者在使用 Serverless 技术本身上，也有了很大的变化。例如，每一个开发函数的调用时间，从 2019 年到 2021 年，这个变化明显地在于函数运行时间大致下降一半左右。以中位数为例，今天我们看到的绝大多数 Serverless Function 运行时间大概是 60 毫秒左右，这说明什么问题？第一点，开发者越来越成熟，可以更好地驾驭 Serverless 技术，用最佳实践方法进行函数开发。同时，我们看这张表格，也注意到它的尾部比较长，这也说明了虽然 Serverless 函数有运行时间的限制，以 Amazon Lambda 为例，有 900 秒的限制。但我们越来越多地不仅把 Serverless Function 用在短任务上，也用于一些长任务的执行和处理上，Serverless 的应用范围和领域是越来越丰富了。其实如果细分，这个报告中还有一些有意思的话题。例如 Amazon Lambda 所支持的 6 个语言中，最活跃的开发语言 Python 和 Node.js 大致占了 90% 的份额，其中，Python 大致占比达 58%，Node.js 占 31% 左右。对于不同规模的企业来说，规模越小的企业选择 Node.js 的比例越高，大型企业更多选择 Python。选择语言本身是一个非常值得探讨的话题，今天时间原因，没有办法展开这个探讨，但这一点也值得大家关注。

归纳起来，作为一个函数的运行环境，一个 Serverless 平台，我们需要提供怎样的功能给到开发者？归纳起来，无非这三个最基础的功能和需求：

第一，安全的特性。代码以及运行的数据需要在安全的环境当中运行，毕竟云计算提供多租户的环境，如果不能有很好的解决数据和执行代码的安全问题，那这一切的基础将不再存在。

第二，启动时间。大家谈到 Serverless 技术的时候经常遇到一个问题，就是冷启动，我们需要利用一切可能，将冷启动的时间减少，让我们代码的响应时间越来越快，甚至接近于运行在裸机主环境中的原生代码。

第三，利用率。对于平台是非常重要的一点。我们运营很多个机器，构成一个集群，在集群上运行不同用户的多个甚至数以海量计的函数时，需要在每台物理机器上运行尽可能多的函数，这样确保我们的经济效益以及运营的效率。

所以，归纳起来，安全、启动时间和利用率成为运行一个好的 Serverless 平台最重要的三个问题。如果解决这三个问题的话，我们相信提供给开发者的将是一个非常优良的 Serverless 平台。

如果我问大家，今天选择技术栈去构建一个这样的平台，你会怎样考虑去实现这些技术目标？如果大家对 Linux 的 kernel 环境有所了解，我相信大家第一时间跳出的都是这样的词汇：Cgroups（资源限制）、Namespaces（可见性限制）……这些在过去几十年中已非常成熟地用于资源管理、隔离和安全控制的技术手段。不瞒大家说，当 2014 年 Amazon Lambda 出现的时候，最初的版本就是使用 Cgroups、Namespaces 这样成熟的隔离机制来实现基础的隔离和资源的控制，但是这一切能够满足真正生产环境当中 Serverless 的需求吗？

或许还有其他的选择，例如我们会在一个物理的环境当中去部署 Serverless 环境，或者考虑选择在一个虚拟机的环境中构建 Serverless 环境。利用虚拟机所提供的隔离机制达成这些效果，再或者用今天大家所熟悉的容器技术，实现资源的分割以及容器化的隔离。这些或许都是选择，但事实上这些选择都不是一个非常完美的答案，因为毕竟这些技术的出现，针对的问题以及解决问题的角度跟我们今天所面对的 Serverless 有很大的差异。设想一下，今天我们所需要的是在一台物理机里面运行不同用户许多个不同的函数，这些函数对于资源的开销有很大的不同，有不同语言的运行时，那么它们的峰值对于 CPU、对于网络、对于存储的要求也有不同的差异。是不是用刚才谈到的资源管理和隔离的技术可以满足这一切？

坦率说，现有的许多技术并不能够满足。这也意味着我们需要一种新的隔离技术或者资源管理的技术，去达成一个好的 Serverless 运行环境的最基本的要求。那这样的一个环境，我们可以把它简单称为「microVMM」，之所以称之为「microVMM」，是因为强调它与我们传统意义上的虚拟环境 VM 有很大不同，它针对的就是 Serverless 环境，而不是通用的虚拟化的环境。这就是我想为大家介绍的 microVMM 的背景。

02. Serverless 为何需要一个 microVMM

microVMM 只是一个概念，实现的方法会有很多，其中一个就是今天我想为大家介绍的非常有效的一个开源的实现 — Firecracker（鞭炮）。它的出现为大家提供了参考范本，让我们了解，当我们试图打造一个好的 Serverless 环境时，一个真正意义上的可以商业化运营的、在生产环境中提供实现的 microVMM 究竟是怎样的。

回到刚才的主题，我们会去思考这样一个问题：Serverless 环境当中究竟需要怎样的一个 microVMM？如果不能回答这个问题，恐怕接下来的内容将无从谈起。如果回答这个问题，我们可以从最基础的要求进行尝试。例如在一台服务器上运行函数，可以选择一台裸金属服务器，在 EC2 环境中一款规格为 M5 的实例，有 384G 内存，64 颗核心。当我们试图在这台物理服务器上运行 Serverless 的时候，即使是今天 Amazon Lambda 最小的一个函数，它的开销也需要 128 兆内存。当然，在管理上 CPU 的资源与内存的多少存在一定的映射关系。这意味着我们要在一台这样的服务器里面尽可能多地装下这样的一个又一个的Serverless VM。我们达成的效果就意味着能够提供的资源环境和利用的效率能提升到怎样的高度，并且在这样的环境当中，彼此要是安全的隔离，我们要对资源进行有效的管理和分配，这就是我们所面对最主要的问题和挑战。

简单归纳一下，刚才谈到的几个关键点：

第一个需求，隔离技术。在一台物理机器当中，需要运行数千个 Serverless 函数的时候，每个函数之间是隔离，而且是有效隔离。我们要减少攻击面，减少我们的应用和数据被泄露或被攻击的可能性。

第二，在这个环境当中，我们要解决负载的问题，让每一个函数能够公平地得到所需要的 CPU、内存、网络等相关的资源；甚至我们需要在这样的环境当中尽可能多地运行更多的 Serverless 函数以确保经济效益，完成平台运营的目标。

第三，性能的问题。当我们开发一个 Serverless 函数的时候，需要这个函数尽可能多地跟我们在原生环境中运行函数的效果一致。大家使用程序都有这样的感觉：当我们开发调试的时候，我们对一个函数运行的效果、执行的时间和资源的开销会有一个预判，如果运行环境和开发环境有很大出入，这对我们实现一个算法、功能会有很大的差异。没有办法使得所设想的目标在一个无服务器环境当中被很好地执行。所以，我们希望提供的运行环境是跟原生的环境尽可能多地趋于一致的。

后一点，谈到兼容性的问题。在历史上曾经出现过类似这样的机制，例如 Google 的 APP Engine 大概在 2008 年出现。那个时候在选择这个平台的时候，很多人抱怨原有的开发习惯、开发工具和语言等等没有办法很好地运行在这个新的平台之上，需要为新的平台重新打造一套新的轮子，这显然跟今天的开发理念是违背的。所以，我们希望尽可能保持在 Linux 环境中一致的兼容性，这种兼容性包含二进制文件、库函数以及系统调用等等，都保持跟现有的开发和原有的知识一脉相承。唯有如此，我们的开发效率才可以提升，让我们的代码可以随意部署在相关的环境当中。

再有一点，资源分配。毕竟众多的函数运行在同一台物理机上，需要有效地针对用户所订阅的不同配置来进行合理的分配。甚至在某种情况下，我们要提供一种超额订阅的机制，这才能使得平台的经济性表现得最好。原有的许多技术，例如像 KVM 技术，KEMU 等等，它们的计算密度和负载的问题显然不能满足这一点。仅举一例，QEMU 的代码规模是 140 万行，无疑是非常强大、功能完备的。但是显然开销也太大了，所以计算的密度和负载的性能本身满足不了我们的需要。其他的技术，像容器化技术，它的隔离的能力也受到了诟病。为了解决隔离问题，我们甚至会限制一些系统调用，这就跟兼容性的要求有很大的出入。坦率地说，今天我们所面对的，已经成熟的那些隔离和分配的技术，不能很好地满足 Serverless 环境，这就是为什么我们要打造一个新的 microVMM，也就是 Firecracker 的主要原因。

03. 什么是 Firecracker？

什么是 Firecracker？Firecracker 是面向无服务器环境的、开源的 microVMM 的实现。这个实现的目的就像大家看到的示意图一样，它运行在一个物理的服务器之上，跟我们传统架构不同的是，没有所谓的 Hypervisor 就起到了相应的作用。在 Firecracker 之上运行了一个一个实例，是标准的 Linux Guest OS，也支持 Osv Guest 的操作系统。在每一个 Firecracker 实例当中，它提供了一组 RESTful 的 API，我们可以通过命令行、应用、控制面板来对每一个 microVMM 的实例来进行控制。例如启停资源分配、销毁等等。在整个资源环境当中，需要针对我们的网络、存储、Metadata 等等进行管理。包括不同的运行环境当中，对资源的消耗等等也需要 Rate Limiting 来进行限制，这就是最标准的一个架构示意图。当我们在环境当中去创建这样的一个实例的时候，我们会按照用户所指定、订阅的不同的类型，去分配相关的 CPU 和内存，以确保我们的函数可以在正确配置的实例当中运行。那这样的运行环境，就是我们心中一个理想的 Serverless 环境。

这个项目在 2017 年 10 月开始启动，2018 年底宣布了开源。截止到今天，版本已经迭代到了 0.24.4，来自全球不同社区的开发人员为它贡献。简单来说，它的设计思想来自于谷歌 Cloud OS 的设计思想，而 Cloud OS 当初是为了 Cloud OS 的隔离环境实现的。Firecracker 最初源于 Google 的 Chromium OS，之后两个不同的项目分道扬镳，但是来源还是同一个来源，所以我们说它来源于开源，也是基于 Crosvm 技术来实现，但前身是 Chromium OS。开源的协议是 Apache 2.0，这也意味着可以在最大程度上充分利用开源所赋予我们的权利。更为重要的是，Firecracker 的实现不是针对通用环境下的 VM，是针对无服务器环境下的 microVMM，是小型化的，不是通用而是针对特定环境来实现的。

作为一个开源项目，它有哪些特点？

首先，它将 Firecracker 的很多实现成果回馈到社区。我们今天看到的 VMM 都已经充分集成和借鉴了 Firecracker。包括像最近因特尔主导的 Cloud 、Hypervisor 就大量地利用了Firecracker出现的一些成果，包括在容器的隔离方面，都对整个社区产生了巨大的影响。对于普通的 Serverless 函数开发人员来说，当我们理解 Firecracker 实现的机理，就可以更好地利用和充分实现函数的功能。例如 Firecracker 可以支持 AVX 指令，我们就可以在程序当中去利用这点加速我们的程序运行。例如 Firecracker 可以支持超线程（SMT）技术，可以利用超线程的方式使 CPU 的利用率达到极致，这些都是 Firecracker 能够带来的主要好处。同样，开源的实现也给我们很好的参考，当有志于打造属于自己的 microVMM 的时候，完全可以基于这样一个项目，来构造我们自己定制的一个 microVMM 的实现。

截止到目前，有来自 48 个开源社区的 147 个开发者为此做了贡献，其中很多开发人员也是 Amazon 全职的开发者，这个开发的成果不仅成为了 Amazon Lambda 这样的无服务器平台运行的基础，同样也被很多开源的社区和开源的项目所集成。这些集成的结果也使得 Firecracker 的影响力在整个开源社区变得越来越大，未来我希望 Firecracker 能够推动 Rust-VMM、Cloud Hypervisor 能够最终成为一个统一的版本，提供给我们一个更好虚拟的环境。

如果大家关心 Firecracker，我想为大家分享一下这个项目的设计原则。Firecracker 的设计目标是面向云计算环境中 Serverless 的实现，天生就是面向多租户环境的 microVMM。除此之外，不同的函数运行需要有 CPU 和内存的组合，所以它要支持各种类型不同的 VCPU 和内存组合的应用环境，有充分的资源管理和分配的机制。它允许超额订阅，这意味着当我们在一台物理服务器上支持这个特性的时候，我们可以极大程度上去超售相关函数的资源。那么超额订阅的结果，并不会影响我们具体函数的执行，只是让单台的物理服务器的利用效率得以提升。

突变的特性是指当创建新增 Serverless VM 的时候，可以保持一个固定的频率，以确保稳定持续地创建更多的 VM，去满足多租户或者大规模并发的特殊场景。对于 Firecracker 性能上的限制，我们要求它仅仅受限于硬件的环境，而尽量减少虚拟化所带来额外的开销。对于整个环境来说，对它进行管理和控制，通过一组有效的 RESTful API 实现，使用这个 RESTful API 可以通过我们的程序、命令行工具以及相关的直接对于 API 的控制达成效果和目标。整个的 VM 的环境相比较传统的 VM 来说，可以说是轻量级以及超级简化的环境，例如它的设备只有 6 种最简单的基础设备，好处就是减少了额外开销，并且让产生攻击的攻击面积减小，并且性能和效率得到良好提升。

安全性是 Firecracker 非常重点和强调的特征，如果不能解决安全的问题，我相信没有任何一个生产环境可以大胆放心地使用 Serverless。如何提升安全性？简单来说就是有限的设备，像我刚才谈到的只有 6 种最简化的基础设备，并且它的功能级不是标准操作的全级，仅仅满足不同运行时最低可运行的要求和条件。在我们的 Guest OS 和 Host OS 之间进行交互的时候，由于这种开销相对来说比较大，所以如果能够有效减少这种开销，并且把开销的性能降到最低，会提升整个 VM 的性能。沙箱机制是我们有效的管理方法，不仅仅是通过虚拟化的方式实现沙箱，还需要把每一个 VM 控制在一个相对隔离的空间范围内，也就是所谓的既有的 VMM。在实现这个产品上，选择一种安全、可靠的程序语言，也就是 Rust，这是一个非常好的实践。对于每个 Firecracker，它的实例对应的就是一个 VM，而效率方面我们强调的是快速启动的性能，这也是 Firecracker 比较传统的 VM，有很大优势的一个方面。在低内存、低开销，也就是每个 VM 的 footprint 在最小化方面，远远超过了传统的 VM。

对于 Firecracker 的实现，开发人员关注的是这样几个方面：

在文件系统上，不同于一个标准的 OS，不需要网络共享，所以它的文件系统是最小的文件系统级。也就是说没有文件共享的能力，我们并不需要在这个 VM 当中附加太多动态的设备，所以不需要去实现这个特点。在网络实现方面，由于它是一个虚拟化的网络，所以仅仅实现了 TAP 的网络接口，而不是别的接口。这样有限的接口，使我们的网络栈变得简单和容易实现。相比较 QEMU 的 140 万行代码，Firecracker 只有区区 8 万行代码，从代码数量来看，就可以了解到它的规模和精简的程度。

在跨界通讯方面，主要使用 VSOCK 的机制，这个开销足以满足我们的需要。对于整个 Firecracker 的架构，我们可以看到这样的一个示意图。我们在最基础使用了 QEMU 虚拟化的技术，使用了内核所带给我们的虚拟化的特性，在此之上，我们实现了文件和网络接口的虚拟化抽象。有 VMM 和 Seccomp 这样的实现，6 种最精简的设备去实现 Firecracker 的 VM。如果大家看到这张图，就会理解我刚才所谈到的一个精简 VM 所提供最基础的环境。虽然从功能级方面无法跟标准的 VM 相提并论，但是在它的尺寸开销、性能、加载的速度方面会远远超过传统的 VM。

在开发语言方面，它跟之前以往大家所习惯采用的语言不同，选择了 Rust 语言。之所以有这样的选择，来源于最大的挑战就是内存安全。由于指针滥用的结果，导致 C++ 或者 C 语言当中存在着内存不安全的问题。如果这个问题持续存在的话，修复它的代价一定是非常高昂的。Rust 的出现让我们获得了内存安全的机制，简单来说，Rust 语言本身所具备的没有 use-after-free 这样的机制，使得我们的内存本身可以比较安全自由的使用。我们不会去读取一个未经初始化的任何内存，也就是内存释放之后一定会被初始化，不会被误读。同样，Rust 本身存在安全的机制，没有了数据征用，这就使得我们在实现 Firecracker 的时候，由于语言的选择，降低了很多的难度。

同样，由于这样的语言选择，在内存的安全方面，由于选择了 VM 虚拟化的机制，以及 VCPU 半虚拟化的技术，这种技术已经非常成熟，所以实现难度很低，而且实现的标准应该非常好地与今天的技术相兼容。

线程安全方面，大家知道，所谓的线程就是 VCPU，VCPU 的概念跟 Rust 相结合，确保了我们的线程安全。通过模拟的技术，达成了对线程的一个实现。开发人员可以尽情地去使用所有的线程技术，而忽略掉线程背后实现具体上的物理实现。

归纳起来，这就是我们今天所谈到的 Firecracker 最主要的几个特点。我想跟大家重点强调一下，性能上的几个优势。例如，快速启动，在用户空间创建完整的 Firecracker 的 VM，只需要最多 125 毫秒，这个相比传统的 container 或 VM，优势是非常巨大的。如果我们从一个休眠的栈恢复到完整的 VM 环境当中，最少只需要 5 毫秒，这是一个了不起的成就了。

突变率可以达成每秒钟一个主机上创建 150 个以上的 VMs，当我们遇到大规模并发请求或者集群调度的时候，可以提供很好的调入机制。内存开销方面，每一个 Firecracker 的 VM，内存开销小于 5M，这也意味着可以在物理机上尽可能多地集成更多的 Firecracker 的 VM，可以运行更多的函数。

谈到所有的一切，通过这样一张图可以了解管理机制。在管理方面，最简单的方法就是利用我们的管理人员，通过我们的 API 对整个 VM 的实力进行注销、启动、资源分配和控制。我们有足够隔离的边界，针对资源进行通信。这些技术存在于之前已有很多的实现当中，那在这个环境当中，具体说在 Firecracker 的 VM 当中，更多实现的是简化，更安全以及性能的提升。

性能的表现究竟如何？这想必是大家非常关心的一点。我们可以看到这样一张图，这张图就是 Firecracker 的串行启动延迟的表现，我们选择的是 Firecracker 以及传统的 VM 进行对比的效果。所谓 Preed Firecracker 就是加载了 Firecracker 的守护进程，提前预热好这样的一个实例。我们会看到，Firecracker 几乎是在 150 毫秒左右的区间去实现这样一个目标，远远优于传统 VM 技术 200 毫秒以上的开销。在并行启动的环境当中，我们看到 Firecracker 以及 Firecracker Preed 这样的技术带来的优势也远远超过传统的虚拟化技术。这就是在启动方面，Firecracker 带来最直接的变化。

在 IO 方面，看一下 QD1 深度是 1，4K 的读取性能。从对比性能来看，在 4K 读的环境当中，跟传统的 QEMU 非常接近，当然在 128K 的场景下还有很多的提升空间需要改善。当达到队列深度位 32 的时候，吞吐量也可以看到跟传统的虚拟化技术包括跟裸机之间的对比，事实上在 IO 这个吞吐方面还需要性能上不断的提升。

最后想总结一下，究竟 Firecracker 为 Serverless 环境提供了哪些不一样的技术，以及带来了哪些优势？首先就是安全隔离机制。它的隔离的深度会更好，防御能力更强，最小的设备模型可以减小这个攻击面，所以安全隔离机制是满足生产环境。它是一个简化的设备模型，有限的设备导致性能的提升以及暴露给使用者的是受控的空间和环境，带来的直接好处就是它的启动时间以及引导进入 OS 的加载时间的巨大优势。第三点，高效扩展，强调的是它的内存开销，在足够小的环境下，可以在一个物理环境当中尽可能多地允许更多的 Serverless 环境被执行。

04. 经验总结

最后，总结一下，在过去几年当中，应用 Firecracker 技术支持 Serverless 环境当中运行的经验教训。

第一，兼容性是硬道理。所有做的一切工作，都是为了满足硬件的兼容性，以确保开发人员能够更快地融入和接受这样新的技术。这些兼容性有很多很细节的问题，包括超线程的技术，内存管理技术，网络技术等等，很多问题都是在不断的摸索和实践当中发现。但是，兼容性是最重要的一点，如果不能够解决兼容性，我相信开发者不会接受这样的一个工具。除了一般意义上的软件兼容性之外，性能的兼容性也需要考虑。我们尽可能提供一个跟一台物理环境相接近的性能环境，如果性能兼容，相距较大的话，这恐怕也是开发人员拒绝的一个理由。

第二，不可变的环境，有运行时间的机器。Serverless 环境简单来说就是一个不可变的环境，不可变的环境意味着我们要对它进行初始化、预配置。有运行时间是强调它有一个超时的时间，这个环境当中确保整个系统的可靠与它的有效运行。有一些系统管理工具，在此实现当中已经证明会破坏我们不可变的特性。例如 Linux 中的 rpm、dpkg 都会带来巨大的脆弱性和不确定性，所以这是我们尽力避免的特性。限制机器的最大生命周期可以有良好的运营效果，当然很多人诟病函数运行存在 900 秒的限制。希望未来这可以变成参数化的方法，配置环境的时候，灵活地定制，对于应用而言那样将会更好。

第三，要解决的问题永无止境。随着现在开发技术不断发展，新的技术不断涌现，对于 Serverless 环境的要求也会越来越高，相信今天的 Firecracker 还在不断增加新的特性，解决一些遗留的问题。只有保持这样的劲头，才能让 microVMM 更好地去支持未来的开发环境和应用。

对于未来，还有很多需要解决和发展的方向。2017 年的 10 月份，Firecracker 的项目正式启动，是考虑到了 Lambda 特殊的需求创建的。2018 年的时候项目开源，2018 年 12 月产生 rust-VM，当时开源社区意识到了 Firecracker 和 Cloud OS 某种程度来说会有很多重叠的问题，需要帮社区的资源整合在一起，于是出现了 rust-VMM，这也是一个非常有意思的项目，也许会对未来整个开源的虚拟化带来巨大的影响。

2019 年，INTEL 也主导了一个 Cloud Hypervisor 的技术，未来非常希望云上的 Hypervisor 能够被统一到一个新的架构下，也许是我们今天谈的技术，也许是其它新的技术。如果那样的一天到来，我们的无服务器以及虚拟化技术将变得无比美好。未来 Firecracker 还有很多问题需要解决，在性能方面的限制、在 IO 方面的不足等等，今天的 IO 特性更多依赖于一些 Hypervisor 的特殊的实现，比如说 EC2 对于 Nitro 的依赖，可以通过将网络以及存储的相关负载卸载到专用的芯片当中实现，未来这种优化还会持续，IO 性能一定会有更大的提升。

调度尤其是对尾部的延迟，还有很大的提升空间，希望每一个实例的加载，VM 运行的开销越来越小，延迟越来越低，这才是我们追求的目标。正确性的证明是非常有意思的话题。整个 Serverless 的 Function 运行在一个完全托管的环境当中。对于开发者来说，意味着这是一个黑盒，我们需要了解运行环境的正确性与否，所以对于无服务器的环境来说，未来需要有更好的正确性证明的有效手段和工具，以确保我们的调试、部署和监控。在快照、内存的 ballooning 方面需要有很大的提升，以确保我们虚拟机总体内存的开销不能够超过物理机的实际内存等等，以确保每一代物理机能够被有效、正确地运行起来。

rust-VMM 也是非常值得关注的方向，也许有一天 rust-VMM 会改写整个云计算环境的基础设施，对于未来的发展我们充满了各种希望，也希望这些开源的技术能够改变这一切！在 Firecracker 的网站当中能够看到这样一个现象，今天正在致力解决和增加新的特性，也希望更多的开发人员将你们的智慧、努力跟这样的一个开源项目结合起来，让这一切变得更美好，让这样一个 microVMM 成长更为迅速，对整个开源社区有更大的贡献。希望给大家带来一些启发，谢谢大家。

分享嘉宾

费良宏，Amazon Web Services 首席开发者布道师。20多年一直从事软件架构、程序开发以及技术推广等领域的工作。经常在各类技术会议上发表演讲进行分享，是多个技术社区的热心参与者。擅长Web领域应用、移动应用以及机器学习等的开发，也从事过多个大型软件项目的设计、开发与项目管理。目前专注于云计算以及互联网等技术领域，致力于帮助开发者构建基于云计算的新一代的互联网应用。

点击查看本次分享完整视频

One More Thing

立即体验腾讯云 Serverless Demo，领取 Serverless 新用户礼包

• 还没有人评论，欢迎说说您的想法！