AWS Lambda 的工作原理

AWS Lambda 是一款非常棒的产品。你提供代码，AWS 为你处理基础设施和执行。

但是你的代码实际上在哪里执行呢？AWS 是如何做到的？

我最近尝试自己寻找答案，这篇文章就是我所学到的知识的成果。

思考 Lambda

我们知道可以编写如下所示的脚本，然后将其上传到 AWS，他们会处理其他所有事情。
但从代码来看，它看起来不像我们在 Express 中实现的常规 API 方法。

exports.handler = async (event) => {
  return {
    statusCode: 200,
    body: JSON.stringify({ msg: "Hello from Lambda!" })
  };
};

我们正在导出一个函数，因此其他东西必须获取我们的代码，导入它，然后处理其他所有事情。

结论一：
一定有什么东西在运行我们的代码。

我们也知道臭名昭著的冷启动问题，虽然随着时间的推移有所改善，但仍然存在。有时环境会关闭，然后重新启动。

结论二：
无论运行什么代码都可以关闭并重新启动。

你有没有注意到，实际上根本无法访问主机系统上的任何东西？如果没有，那就试一试，你会发现环境会阻止你这样做。

结论三：
环境相当安全。

思考 Lambda 所基于的技术

AWS 可以通过多种方式实现 Lambda（考虑到其首次发布年份为 2014 年）：

• 集装箱化
• 虚拟化
• 在裸机上运行的东西

我们可以快速排除“在裸机上运行”的可能性。AWS 当时已经有了 EC2，并且对虚拟化有一定的了解。AWS
放弃虚拟化，不利用现有基础设施，这实在不合理。
他们基本上已经准备好了所有可以即时配置虚拟机的资源。

那么容器呢？
它们可以快速启动并再次丢弃。AWS
可以提取代码，用某种东西包装起来，然后放入容器中。
这本来是个好主意，但对当时的 AWS 来说也是一件全新的事情。
此外，这也无法解释（旧的）冷启动问题，因为容器通常启动速度很快。

那么虚拟化呢？
这很有道理。
在启动 Lambda 时，AWS 已经拥有 EC2 和所有可以动态配置虚拟机的基础设施。这也解释了为什么冷启动的 Lambda 函数有时需要很长时间才能最终处理请求。但他们是如何将冷启动时间缩短到今天的呢？

在深入探讨之前，我先告诉你答案：
Lambda 自发布以来就一直基于虚拟化技术。没有花哨的容器，也没有自研的东西。

AWS 这样做是最合理的。正如您上面所读到的，他们拥有所有的知识，并且拥有提供这些知识的基础设施。他们只需要添加一些组件来包装用户函数，一些组件来调用它们，以及一些可以处理事件的支持服务。

现在我们知道了它是虚拟化，我们可以看看现在具体使用什么。

进入 Firecracker

Firecracker是一种虚拟化技术，或者更确切地说，是一种由亚马逊开发（现已开源）并用 Rust 编写的虚拟机监视器（VMM）。

它是为所有 Lambda 函数提供动力的引擎。

Firecracker 的基本功能是创建和管理大量基于 Linux 内核的虚拟机 (KVM)，这些虚拟机是比传统虚拟机更快、更安全的微型虚拟机。

这些微型虚拟机的有趣之处在于，它们在内存占用和启动时间方面实际上与容器相当，同时由于 KVM 提供的高级功能而提供更高的安全性。

您可以在此处阅读有关 KVM 的更多信息。

Firecracker 带有一个 REST API，可用于创建、删除、管理虚拟机等。
每当您创建一个新的 lambda 函数并上传代码时，都会在后台调用 Firecracker REST-API 来创建一个具有您函数的 CPU 和内存设置的 microVM。

AWS 保留包含特定语言/运行时引导代码的基础镜像。
这些代码实际上会调用您的处理程序，向其传递请求，并获取响应并将其返回给调用者。
这些代码还会测量各种指标，然后用于计算您的账单。

您可以将代码想象为包含一个无限循环，等待请求，将它们传递给您的函数，返回响应，并收集执行指标。

Firecracker 创建了一个新的 microVM（包含特定语言的运行时）后，您的代码将被放入其 /var/runtime/bin 文件夹中。引导代码也位于此处。
现在，您的函数基本上可以运行并接受请求了。

然而，AWS 会在一段时间后关闭虚拟机以节省资源。
这又一次调用了 Firecracker API。

传入的请求（例如通过 API 网关）导致 Firecracker 被要求重新启动 VM，以便它可以处理该请求。

周边基础设施及配套服务

当然，还有很多周边系统和服务发挥作用，使 AWS Lambda 成为现在的样子。

Firecracker 周围有一些服务和系统，负责向其 API 发出所有这些请求。
有些服务负责路由请求。有些服务负责决定何时调用 Firecracker 关闭或暂停某个虚拟机，以及何时重新启动它。
当然，Firecracker 还有很多其他服务，例如队列、异步消息调度等等。

结论

看看 AWS 是如何将 Lambda 打造成如今的样子，这本身就很有意思；更让人感兴趣的是 Firecracker 如何解决无服务器功能给服务提供商带来的诸多问题。Firecracker 是其中不可或缺的一部分，它是一项非常令人兴奋的技术，它没有走常见的容器路线，而是使用了 Linux 内核的另一个很棒的特性：KVM。

离开之前

如果您喜欢我的内容，请访问我的Twitter，也许您会喜欢您所看到的内容。