应用程序开发在过去几年发生了转变，为云构建的软件大规模地服务于来自全球分布用户的高度不稳定的工作负载。无服务器计算发展为支持这些应用程序，完全消除了传统的性能和容量管理问题。

久负盛名的关系数据库模型今天仍然支持全球数百万个应用程序，必须跟上无服务器计算的进步。这就是亚马逊创建其 Aurora 云原生关系数据库系统的无服务器版本以支持不断变化的客户需求的原因。

“越来越多的客户希望构建对最终用户重要的应用程序，而不是专注于管理基础设施和数据库容量，”Amazon Web Services 首席技术产品经理 Chayan Biswas 解释道。“无服务器计算是他们可以轻松实现这一目标的一种方式。”

无服务器计算的历史
亚马逊于 2014 年首次推出其 Lambda 无服务器计算概念。这是之前虚拟化趋势的自然演变，通过将操作系统从硬件中抽象出来，无需在单独的物理服务器上运行每个应用程序。

虚拟机比专用硬件服务器效率高得多，可以压缩应用程序的计算空间。但是很多应用程序并不会一直运行，只需要响应其他事件而运行。当您将单体应用程序分解为基于容器的服务时尤其如此。

Lambda 无服务器计算在底层使用 Amazon 的 Firecracker microVM 框架。它使开发人员无需在服务器上运行即可调用函数并检索结果。底层框架负责其余的工作。

这提供了至少两个好处。首先是不为该功能运行专用的虚拟机或容器会降低运营成本。第二个是基于容器的底层基础设施可以快速扩展函数的容量，即使调用它的事件量增加也能保持性能。

无服务器数据库的诞生

Lambda 支持基于云的应用程序，但客户想要下一个合乎逻辑的步骤：支持无服务器数据库。AWS 于 2018 年将 Aurora MySQL 的无服务器版本全面推出，随后于 2019 年推出了 PostgreSQL 版本。

Amazon Aurora Serverless 将成本和性能优势转化为数据库，使客户能够在不中断的情况下快速扩展其关系数据工作负载。他们还只为他们使用的数据库资源付费，这对于不经常调用数据库的应用程序特别有用，例如小容量博客或开发和测试数据库。

除此之外，无服务器数据库操作还使 DBA 不必配置和管理数据库容量。这是亚马逊称之为“无差别的繁重工作”的工作负载的一部分，这是一种没有充分利用 DBA 技能的平凡工作。使用无服务器自动化将其抽象化，使 DBA 能够专注于更重要的任务，例如数据库优化和数据治理。

在迁移到 Aurora Serverless 之前，客户必须通过手动更改运行系统的虚拟机类型来扩展他们的数据库。这产生了额外的管理开销，并使数据库停机长达 30 秒，这对许多用户来说是不可接受的。

相反，客户会不断地为高峰工作负载配置他们的数据库。这是昂贵且浪费的资源，导致他们为长时间处于部分空闲状态的大型虚拟机付费。

Aurora Serverless 的工作原理

Amazon Aurora Serverless v1 让客户能够在不中断数据库的情况下调整其 VM 大小，从而改变了一切。它将寻找事务流中的差距，以便有时间调整 VM 的大小。然后它会冻结数据库，在幕后移动到不同的虚拟机，然后再次启动数据库。

Biswas 解释说，这是一个很好的起点，但发现交易缺口并不总是那么容易。“当我们有一个非常健谈的数据库时，我们正在运行一堆重叠的并发事务，”他解释道。“如果它们之间没有差距，那么我们就找不到可以扩展的点。”

因此，扩展过程可能需要 5 到 50 秒才能完成。如果找不到适当的事务间隙，它有时最终会破坏数据库。这将 Aurora Serverless 实例限制为零星、不频繁的工作负载。

“我们从客户那里听到的一条反馈是，他们希望我们使 Aurora Serverless 数据库适合他们最苛刻、最关键的工作负载，”Biswas 解释说。这包括那些具有严格服务水平协议和高可用性需求的人。

改进无服务器数据库服务

考虑到这一点，Aurora Serverless 的第二版带来了一些重大改进，包括一种可以在几秒钟内扩展到数千个事务的新方法。AWS 通过为数据库进程提供更多资源并在后台过度配置它们来实现这一点。这消除了寻找数据库流量差距的需要，因为无服务器进程不会在不同的虚拟机之间移动以进行扩展。

对亚马逊而言，这似乎是一个失败的提议，因为该公司必须承担过度供应的成本。不过，AWS 习惯于利用其规模经济来寻找新的内部效率。为了提高 Aurora Serverless v2 的可扩展性，它在工作负载放置方面变得更加智能。

该公司现在可以将具有互补配置文件的工作负载放置在同一台机器上。例如，夜间运行的报告工作负载可以与白天运行的业务应用程序在同一虚拟机上运行。这是云的多租户运营模式的好处。

无服务器 v2 还可以更细粒度的增量进行扩展。当使用量超过设定的阈值时，V1 客户只能将他们预置的数据库计算单元（称为 Aurora 容量单元 (ACU)）数量翻倍。Aurora Serverless v2 允许增加 .5 ACU 增量。

其他领域也有改进，包括可用性。尽管存储的高可用性是标准配置，但 Aurora Serverless v1 不提供计算的高可用性。V2 提供跨多个可用区的配置。它还将支持跨这些实例的只读副本以更快地检索记录，以及对只读工作负载的 Aurora 全球数据库支持。这意味着更快的跨区域数据复制和不到一分钟的故障转移时间，以提高 Aurora Serverless 2 环境中的可靠性。

RDS 代理

亚马逊还引入了一种技术，可以调和无服务器操作模型和关系数据库原则之间的根本差异。

DynamoDB 是 Amazon 的托管 NoSQL 键值数据库，由于其底层架构，它已经是无服务器的。在设置 DynamoDB 表时，您可以直接在 Web 界面中轻松引入自动扩展规则。

Biswas 解释说，由于关系数据库建立连接的方式，Aurora 的情况有所不同。

“在无服务器环境中，Lambda 函数运行，然后它就完成了，”他指出。“关系数据库往往是持久的。”

关系数据库通常是有状态的，随着时间的推移维护与应用程序的单个连接，这样它们就不必在每次应用程序进行查询时都浪费时间重新设置。无服务器计算是一种无状态概念，可根据需要创建和断开连接。

使用现代容器架构的应用程序旨在快速扩展。如果每个基于容器的函数都打开到数据库的连接，那么关系引擎将把所有时间都花在管理连接上，而不是提供查询服务。

在 AWS re:Invent 2019 上，亚马逊推出了 RDS Proxy，这是一项解决连接问题的服务。该服务于 2020 年 6 月进入普遍可用状态，位于应用程序和数据库以及池连接之间。基于容器的应用程序不是轰炸数据库服务器，而是连接到代理，该代理可以从池中分发连接。它支持无服务器 Lambda 函数、Kubernetes 容器或任何其他本身不支持连接池的无状态应用程序。

Lambda 集成

AWS 不仅支持从 AWS Lambda 函数高效访问 Aurora Serverless；它支持反向。Lambda 集成让客户可以从数据库中调用无服务器函数。这让开发人员可以在支持各种语言的 Lambda 函数中编写业务逻辑，而不是用 SQL 的过程方言编写存储过程。

Lambda 集成不仅仅为开发人员提供了更多的灵活性。它还将计算能力置于数据库之外，使其能够专注于查询，而不是通过运行嵌入式应用程序逻辑来阻碍其性能。最后，它简化了应用程序工作流程。例如，开发人员可以让 Aurora 直接将机器学习模型作为 Lambda 函数调用，而不是将该请求编码到他们的应用程序中。

亚马逊继续在其无服务器数据库应用程序方面取得进展。具有 PostgreSQL 和 MySQL 兼容性的 Amazon Aurora Serverless v2 于上周在旧金山举行的 AWS 峰会上正式发布。“我们将通过 Aurora Serverless v2 基本上支持 Aurora 中的所有功能，”Biswas 总结道。很快，对于许多客户来说，数据库服务器的概念可能已经过时了。