作者｜David Yahalom译者｜无明用于无状态应用程序的无服务器 （serverless）解决方案在下一代软件架构中将得到普及，这将给关系型数据库留有多少余地？

无服务器计算（Serverless Computing）过去两年的发展势头迅猛，其概念在于转向不需要基础设施管理的应用程序，这些应用程序只在活跃的时候才会消耗资源。在公有云领域，无服务器通常是指供应商根据工作负载动态地管理服务器资源。AWS Lambda 是无服务器计算的领头羊，微软 Azure Functions（及其他）也迅速迎头赶上。无服务器框架的定价通常基于应用程序消耗的实际资源量，而不是预先购买的容量。用于无状态应用程序的无服务器解决方案在下一代软件架构中将得到普及，那么这将给关系型数据库留有多少余地？关系型数据库对于很多（如果不是大多数）应用程序来说仍然是一个关键组件。

在过去几年中，当说到部署关系数据库时，完全可以参考那些可靠且经过验证的模型：从庞大的单体应用到微服务，再到 PaaS 解决方案。我们既可以部署单个“大型”服务器，运行一个大型单体或可供数十个应用程序使用的数据库，也可以选择微服务架构，开发一系列独立的小型模块化服务，每个服务都可以实现独特的功能和业务目标。云解决方案为我们提供了通过基础设施即代码来部署数据库的能力，我们甚至可以利用平台即服务解决方案，从而大大降低数据库的运营开销和复杂性。

然而，所有这些模型仍然依赖数据库服务器，无论是在本地、云端还是使用 PaaS。我们可以基于预测的工作负载特征来调配数据库容量，这些特征决定了服务器的大小和配置。当然，我们可以根据实际工作负载（取决于所使用的数据库技术）来伸缩数据库，不过这一过程并不一定需要经常进行。

相反，我们应该根据周期性事件进行伸缩，例如即将到来的假日，节假日将为电子商务应用程序生成额外的交易，或者为公司的 SaaS 产品新增的客户而伸缩。如果工作负载是相对可预测或相对稳定的，那么使用专用数据库服务器就说得过去。尽管流量可能会出现高峰和低谷，但它们通常遵循可预测的模式。我们可能需要在一年中对数据库进行多次伸缩，但并不会在一天中进行多次。不经常进行伸缩的数据库模型最适合传统应用。

下一代应用程序引入了下一代挑战。我们所面对的工作负载可能是零星、间歇性的，而且难以预料。例如，数据库查询或事务的流量高峰可能每天（甚至每个月）只持续几分钟或几小时。以之前的电子商务应用程序为例，为了以防万一，我们的数据库如何在不必事先过度配置资源的情况下应对限时抢购事件？对于其他工作负载也存在类似的挑战，从在线游戏到股票交易，甚至是数据分析（分析套件可能在一天中的几个小时产生大量的数据库负载）。大多数数据库管理员告诉我们，我们应该根据预测的高峰工作负载调整数据库的大小。如果说伸缩数据库是一项繁杂而琐碎的工作，那么这绝对算得上是一种传统的智慧和正确的范式。

无服务器数据库意味着什么？

要在数据库领域应用无服务器计算范式，首先需要解耦数据架构的存储层和处理层。解耦存储和计算并不完全是一个新概念。这个想法已经在 NoSQL 和大数据分析领域（Amazon EMR、微软的 Azure DLS 和 DLA 等）以及各种关系数据库技术（Oracle RAC、NuoDB）中得到一定程度的实现。

然而，纯粹的存储和计算解耦并不完全算得上是无服务器。要达到完全的无服务器，在不处理数据的时候就不应该运行任何计算，同时还能按需提供自动伸缩。

实质上，就是要部署这样的一个数据架构——数据库层将根据应用程序工作负载自动启动、关闭和伸缩，同时具备服务器、实例或集群的概念。我们只需要定义好数据库端点并连接应用程序，底层数据库技术将根据应用程序需求扩展存储和计算资源。

除了性能和灵活性方面的优势外，无服务器数据库模型还可以提供高水平的成本效益。例如，按秒支付数据库容量的费用，并且仅在数据库处于活跃状态时才需支付，而不是事先选择数据库实例的大小。

无服务器数据库技术的发展状况

现在有很多可伸缩的关系数据库技术提供了读取或读写伸缩功能（Oracle RAC、Amazon Aurora、Percona XtraDB、ClustrixDB、NuoDB 等）。不过它们都不是本地无服务器产品。当然，现在也有针对无服务器数据库的创新解决方案，其中就包括 FaunaDB（无服务器和全局复制的 NoSQL 数据库）、Google Cloud Spanner（强一致的分布式关系型数据库）或 Microsoft Cosmos DB（具有灵活一致性模型的无模式的多模型数据库）。但是想要使用这些数据库技术的传统应用程序将不得不进行大量的重写或重新平台化。例如，尽管 Google Spanner 是一个具有完整 ACID 功能的关系型数据库（并且拥有独特的数据库技术），但它依赖定制客户端库来实现连接，并提供了一种 SQL 变体，通过自定义的 API 来处理事务。

支持真正无服务器的关系型数据库，一方面要具有完整的服务器抽象和伸缩能力，另一方面要完整地支持 ANSI SQL 和 ACID，这是一个相对较新的创新解决方案。

例如，亚马逊在去年的 Re:Invent 大会上发布了令人兴奋的 Aurora MySQL 数据库无服务器版本，该版本将于 2018 年晚些时候可用。根据亚马逊的说法，Aurora Serverless 专门针对“可变性大的工作负载，这种新的配置可以基于实际使用数据库资源的数量按秒付费。”亚马逊表示，Aurora Serverless 用户只需要为数据库处于活跃状态时所使用的资源支付费用。亚马逊本质上构建了一个基于事件驱动的计算平台数据库。用户提供端点，该端点充当了一个代理的角色，它将查询流量路由到可快速伸缩的数据库资源上。根据 Amazon 提供的信息，即使是在进行伸缩操作时，仍然可以保持连接的活动状态。伸缩速度很快，新资源将在几秒钟内就能上线。

未来会怎样

技术的发展推动了开发和应用程序部署模式的变化，这一切都是那么不可思议。支持 API 驱动的操作和伸缩对于下一代数据架构来说变得越来越重要，无服务器数据库将成为一个重要组件。

当前 RDBMS 技术的亮点之一是将无服务器计算的优势与灵活的关系型数据模型以及现有应用程序兼容的 ANSI SQL 和 ACID 结合起来。无论哪个数据库供应商先达到顶级水平，并发布完全关系型和完全无服务器的数据库引擎，那么肯定会在市场上留下重要的标记。因此，对于亚马逊、甲骨文、微软、谷歌和其他公司来说，一场数据库创新战开始打响了！