关注 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 看作是一种「胶水」一样的工具，把很多原来不可设想的运维、数据处理、机器学习的推理包含挪动端的调用等都通过这样一个简略的技术加以贯通起来。
<img src=”https://main.qcloudimg.com/raw/856148401311d21796a7e5760e9cc922.png” width=”700″/>
同时，咱们留神到开发者在应用 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。抉择语言自身是一个十分值得探讨的话题，明天工夫起因，没有方法开展这个探讨，但这一点也值得大家关注。
<img src=”https://main.qcloudimg.com/raw/4f9f033d9fa47f0a9d7f95dad3bceb2d.png” width=”700″/>
归纳起来，作为一个函数的运行环境，一个 Serverless 平台，咱们须要提供怎么的性能给到开发者？归纳起来，无非这三个最根底的性能和需要：
第一，平安的个性。代码以及运行的数据须要在平安的环境当中运行，毕竟云计算提供多租户的环境，如果不能有很好的解决数据和执行代码的平安问题，那这所有的根底将不再存在。
第二，启动工夫。大家谈到 Serverless 技术的时候常常遇到一个问题，就是冷启动，咱们须要利用所有可能，将冷启动的工夫缩小，让咱们代码的响应工夫越来越快，甚至靠近于运行在裸机主环境中的原生代码。
第三，利用率。对于平台是十分重要的一点。咱们经营很多个机器，形成一个集群，在集群上运行不同用户的多个甚至数以海量计的函数时，须要在每台物理机器上运行尽可能多的函数，这样确保咱们的经济效益以及经营的效率。
所以，归纳起来，平安、启动工夫和利用率成为运行一个好的 Serverless 平台最重要的三个问题。如果解决这三个问题的话，咱们置信提供给开发者的将是一个十分低劣的 Serverless 平台。
如果我问大家，明天抉择技术栈去构建一个这样的平台，你会怎么思考去实现这些技术指标？如果大家对 Linux 的 kernel 环境有所理解，我置信大家第一工夫跳出的都是这样的词汇：Cgroups（资源限度）、Namespaces（可见性限度）……这些在过来几十年中已十分成熟地用于资源管理、隔离和安全控制的技术手段。不瞒大家说，当 2014 年 Amazon Lambda 呈现的时候，最后的版本就是应用 Cgroups、Namespaces 这样成熟的隔离机制来实现根底的隔离和资源的管制，然而这所有可能满足真正生产环境当中 Serverless 的需要吗？
或者还有其余的抉择，例如咱们会在一个物理的环境当中去部署 Serverless 环境，或者思考抉择在一个虚拟机的环境中构建 Serverless 环境。利用虚拟机所提供的隔离机制达成这些成果，再或者用明天大家所相熟的容器技术，实现资源的宰割以及容器化的隔离。这些或者都是抉择，但事实上这些抉择都不是一个十分完满的答案，因为毕竟这些技术的呈现，针对的问题以及解决问题的角度跟咱们明天所面对的 Serverless 有很大的差别。构想一下，明天咱们所须要的是在一台物理机外面运行不同用户许多个不同的函数，这些函数对于资源的开销有很大的不同，有不同语言的运行时，那么它们的峰值对于 CPU、对于网络、对于存储的要求也有不同的差别。是不是用方才谈到的资源管理和隔离的技术能够满足这所有？
<img src=”https://main.qcloudimg.com/raw/007355edc5ddcff3e6e3c1220389b96d.png” width=”700″/>
坦白说，现有的许多技术并不可能满足。这也意味着咱们须要一种新的隔离技术或者资源管理的技术，去达成一个好的 Serverless 运行环境的最根本的要求。那这样的一个环境，咱们能够把它简略称为「microVMM」，之所以称之为「microVMM」，是因为强调它与咱们传统意义上的虚拟环境 VM 有很大不同，它针对的就是 Serverless 环境，而不是通用的虚拟化的环境。这就是我想为大家介绍的 microVMM 的背景。
<img src=”https://main.qcloudimg.com/raw/c26aa6662ef5ac7b5828e4cbf5dd38a4.png” width=”700″/>
02. Serverless 为何须要一个 microVMM
microVMM 只是一个概念，实现的办法会有很多，其中一个就是明天我想为大家介绍的十分无效的一个开源的实现 — Firecracker（鞭炮）。它的呈现为大家提供了参考范本，让咱们理解，当咱们试图打造一个好的 Serverless 环境时，一个真正意义上的能够商业化经营的、在生产环境中提供实现的 microVMM 到底是怎么的。
<img src=”https://main.qcloudimg.com/raw/9f6b660e1e2b1814a39e4ce49fd9af9c.png” width=”700″/>
回到方才的主题，咱们会去思考这样一个问题：Serverless 环境当中到底须要怎么的一个 microVMM？如果不能答复这个问题，恐怕接下来的内容将无从谈起。如果答复这个问题，咱们能够从最根底的要求进行尝试。例如在一台服务器上运行函数，能够抉择一台裸金属服务器，在 EC2 环境中一款规格为 M5 的实例，有 384G 内存，64 颗外围。当咱们试图在这台物理服务器上运行 Serverless 的时候，即便是明天 Amazon Lambda 最小的一个函数，它的开销也须要 128 兆内存。当然，在治理上 CPU 的资源与内存的多少存在肯定的映射关系。这意味着咱们要在一台这样的服务器外面尽可能多地装下这样的一个又一个的 Serverless VM。咱们达成的成果就意味着可能提供的资源环境和利用的效率能晋升到怎么的高度，并且在这样的环境当中，彼此要是平安的隔离，咱们要对资源进行无效的治理和调配，这就是咱们所面对最次要的问题和挑战。
<img src=”https://main.qcloudimg.com/raw/fa13eb415c34863ec9f9d6bebc5821ae.png” width=”700″/>
简略演绎一下，方才谈到的几个关键点：
第一个需要，隔离技术。在一台物理机器当中，须要运行数千个 Serverless 函数的时候，每个函数之间是隔离，而且是无效隔离。咱们要缩小攻击面，缩小咱们的利用和数据被泄露或被攻打的可能性。
第二，在这个环境当中，咱们要解决负载的问题，让每一个函数可能偏心地失去所须要的 CPU、内存、网络等相干的资源；甚至咱们须要在这样的环境当中尽可能多地运行更多的 Serverless 函数以确保经济效益，实现平台经营的指标。
第三，性能的问题。当咱们开发一个 Serverless 函数的时候，须要这个函数尽可能多地跟咱们在原生环境中运行函数的成果统一。大家应用程序都有这样的感觉：当咱们开发调试的时候，咱们对一个函数运行的成果、执行的工夫和资源的开销会有一个预判，如果运行环境和开发环境有很大出入，这对咱们实现一个算法、性能会有很大的差别。没有方法使得所构想的指标在一个无服务器环境当中被很好地执行。所以，咱们心愿提供的运行环境是跟原生的环境尽可能多地趋于统一的。
后一点，谈到兼容性的问题。在历史上已经呈现过相似这样的机制，例如 Google 的 APP Engine 大略在 2008 年呈现。那个时候在抉择这个平台的时候，很多人埋怨原有的开发习惯、开发工具和语言等等没有方法很好地运行在这个新的平台之上，须要为新的平台从新打造一套新的轮子，这显然跟明天的开发理念是违反的。所以，咱们心愿尽可能放弃在 Linux 环境中统一的兼容性，这种兼容性蕴含二进制文件、库函数以及零碎调用等等，都放弃跟现有的开发和原有的常识一脉相承。唯有如此，咱们的开发效率才能够晋升，让咱们的代码能够随便部署在相干的环境当中。
再有一点，资源分配。毕竟泛滥的函数运行在同一台物理机上，须要无效地针对用户所订阅的不同配置来进行正当的调配。甚至在某种状况下，咱们要提供一种超额订阅的机制，这能力使得平台的经济性体现得最好。原有的许多技术，例如像 KVM 技术，KEMU 等等，它们的计算密度和负载的问题显然不能满足这一点。仅举一例，QEMU 的代码规模是 140 万行，无疑是十分弱小、性能齐备的。然而显然开销也太大了，所以计算的密度和负载的性能自身满足不了咱们的须要。其余的技术，像容器化技术，它的隔离的能力也受到了诟病。为了解决隔离问题，咱们甚至会限度一些零碎调用，这就跟兼容性的要求有很大的出入。坦率地说，明天咱们所面对的，曾经成熟的那些隔离和调配的技术，不能很好地满足 Serverless 环境，这就是为什么咱们要打造一个新的 microVMM，也就是 Firecracker 的次要起因。
<img src=”https://main.qcloudimg.com/raw/8c94b445ac3e79d04a172749ae139587.png” width=”700″/>
03. 什么是 Firecracker？
什么是 Firecracker？Firecracker 是面向无服务器环境的、开源的 microVMM 的实现。这个实现的目标就像大家看到的示意图一样，它运行在一个物理的服务器之上，跟咱们传统架构不同的是，没有所谓的 Hypervisor 就起到了相应的作用。在 Firecracker 之上运行了一个一个实例，是规范的 Linux Guest OS，也反对 Osv Guest 的操作系统。在每一个 Firecracker 实例当中，它提供了一组 RESTful 的 API，咱们能够通过命令行、利用、控制面板来对每一个 microVMM 的实例来进行管制。例如启停资源分配、销毁等等。在整个资源环境当中，须要针对咱们的网络、存储、Metadata 等等进行治理。包含不同的运行环境当中，对资源的耗费等等也须要 Rate Limiting 来进行限度，这就是最规范的一个架构示意图。当咱们在环境当中去创立这样的一个实例的时候，咱们会依照用户所指定、订阅的不同的类型，去调配相干的 CPU 和内存，以确保咱们的函数能够在正确配置的实例当中运行。那这样的运行环境，就是咱们心中一个现实的 Serverless 环境。
<img src=”https://main.qcloudimg.com/raw/f45dfde68aac82406a78542ead0a8555.png” width=”700″/>
这个我的项目在 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 和内存组合的应用环境，有充沛的资源管理和调配的机制。它容许超额订阅，这意味着当咱们在一台物理服务器上反对这个个性的时候，咱们能够极大水平下来超售相干函数的资源。那么超额订阅的后果，并不会影响咱们具体函数的执行，只是让单台的物理服务器的利用效率得以晋升。
<img src=”https://main.qcloudimg.com/raw/9c2b6306ae01627d0da7e55ca07a668d.png” width=”700″/>
渐变的个性是指当创立新增 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。
<img src=”https://main.qcloudimg.com/raw/913af02ace35491ac8a4b98f37339311.png” width=”700″/>
对于 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，能够运行更多的函数。
<img src=”https://main.qcloudimg.com/raw/553e8867a7fb699c3b909c9da2eee96e.png” width=”700″/>
谈到所有的所有，通过这样一张图能够理解管理机制。在治理方面，最简略的办法就是利用咱们的管理人员，通过咱们的 API 对整个 VM 的实力进行登记、启动、资源分配和管制。咱们有足够隔离的边界，针对资源进行通信。这些技术存在于之前已有很多的实现当中，那在这个环境当中，具体说在 Firecracker 的 VM 当中，更多实现的是简化，更平安以及性能的晋升。
<img src=”https://main.qcloudimg.com/raw/50503181447ec85230d75bf65abd1337.png” width=”700″/>
性能的体现到底如何？这想必是大家十分关怀的一点。咱们能够看到这样一张图，这张图就是 Firecracker 的串行启动提早的体现，咱们抉择的是 Firecracker 以及传统的 VM 进行比照的成果。所谓 Preed Firecracker 就是加载了 Firecracker 的守护过程，提前预热好这样的一个实例。咱们会看到，Firecracker 简直是在 150 毫秒左右的区间去实现这样一个指标，远远优于传统 VM 技术 200 毫秒以上的开销。在并行启动的环境当中，咱们看到 Firecracker 以及 Firecracker Preed 这样的技术带来的劣势也远远超过传统的虚拟化技术。这就是在启动方面，Firecracker 带来最间接的变动。
<img src=”https://main.qcloudimg.com/raw/8fe99e5d1e6caf39f2a2180a7ba77d8b.png” width=”700″/>
在 IO 方面，看一下 QD1 深度是 1，4K 的读取性能。从比照性能来看，在 4K 读的环境当中，跟传统的 QEMU 十分靠近，当然在 128K 的场景下还有很多的晋升空间须要改善。当达到队列深度位 32 的时候，吞吐量也能够看到跟传统的虚拟化技术包含跟裸机之间的比照，事实上在 IO 这个吞吐方面还须要性能上一直的晋升。
最初想总结一下，到底 Firecracker 为 Serverless 环境提供了哪些不一样的技术，以及带来了哪些劣势？首先就是平安隔离机制。它的隔离的深度会更好，防御能力更强，最小的设施模型能够减小这个攻击面，所以平安隔离机制是满足生产环境。它是一个简化的设施模型，无限的设施导致性能的晋升以及裸露给使用者的是受控的空间和环境，带来的间接益处就是它的启动工夫以及疏导进入 OS 的加载工夫的微小劣势。第三点，高效扩大，强调的是它的内存开销，在足够小的环境下，能够在一个物理环境当中尽可能多地容许更多的 Serverless 环境被执行。
<img src=”https://main.qcloudimg.com/raw/56dac3120e3c23c7e53c33a0ee4cc0b0.png” width=”700″/>
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，这也是一个十分有意思的我的项目，兴许会对将来整个开源的虚拟化带来微小的影响。
<img src=”https://main.qcloudimg.com/raw/f1d20918f36a56d23634a4a70a884ed7.png” width=”700″/>
2019 年，INTEL 也主导了一个 Cloud Hypervisor 的技术，将来十分心愿云上的 Hypervisor 可能被对立到一个新的架构下，兴许是咱们明天谈的技术，兴许是其它新的技术。如果那样的一天到来，咱们的无服务器以及虚拟化技术将变得无比美妙。将来 Firecracker 还有很多问题须要解决，在性能方面的限度、在 IO 方面的有余等等，明天的 IO 个性更多依赖于一些 Hypervisor 的非凡的实现，比如说 EC2 对于 Nitro 的依赖，能够通过将网络以及存储的相干负载卸载到专用的芯片当中实现，将来这种优化还会继续，IO 性能肯定会有更大的晋升。
调度尤其是对尾部的提早，还有很大的晋升空间，心愿每一个实例的加载，VM 运行的开销越来越小，提早越来越低，这才是咱们谋求的指标。正确性的证实是十分有意思的话题。整个 Serverless 的 Function 运行在一个齐全托管的环境当中。对于开发者来说，意味着这是一个黑盒，咱们须要理解运行环境的正确性与否，所以对于无服务器的环境来说，将来须要有更好的正确性证实的无效伎俩和工具，以确保咱们的调试、部署和监控。在快照、内存的 ballooning 方面须要有很大的晋升，以确保咱们虚拟机总体内存的开销不可能超过物理机的理论内存等等，以确保每一代物理机可能被无效、正确地运行起来。
<img src=”https://main.qcloudimg.com/raw/99c143f0a5e95319b3a29a36eb30e639.png” width=”700″/>
rust-VMM 也是十分值得关注的方向，兴许有一天 rust-VMM 会改写整个云计算环境的基础设施，对于将来的倒退咱们充斥了各种心愿，也心愿这些开源的技术可能扭转这所有！在 Firecracker 的网站当中可能看到这样一个景象，明天正在致力解决和减少新的个性，也心愿更多的开发人员将你们的智慧、致力跟这样的一个开源我的项目联合起来，让这所有变得更美妙，让这样一个 microVMM 成长更为迅速，对整个开源社区有更大的奉献。心愿给大家带来一些启发，谢谢大家。
分享嘉宾
费良宏，Amazon Web Services 首席开发者布道师。20 多年始终从事软件架构、程序开发以及技术推广等畛域的工作。常常在各类技术会议上发表演讲进行分享，是多个技术社区的热心参与者。善于 Web 畛域利用、挪动利用以及机器学习等的开发，也从事过多个大型软件我的项目的设计、开发与项目管理。目前专一于云计算以及互联网等技术畛域，致力于帮忙开发者构建基于云计算的新一代的互联网利用。
点击查看本次分享残缺视频
One More Thing
立刻体验腾讯云 Serverless Demo，支付 Serverless 新用户礼包 👉 腾讯云 Serverless 老手体验。