Serverless Database

相信你可能或多或少了解过 Serverless，甚至已经使用了 Serverless 计算服务 FaaS，在之前的 Serverless 浅析一文，也已经聊过了 Serverless 的定义：

Serverless 架构允许用户直接按需使用 服务，而不必担心底层基础架构

既然 Serverless 是一种架构，那么一些常见的服务都可以变成 Serverless 模式的。这里我们将一起探索后端必备服务：数据库，在 Serverless 模式下的发展。

什么是 Serverless 数据库

在了解什么是 Serverless 数据库以及为什么用它之前，我们可以思考注意一个常见的业务问题。

相信大多数人都能意识到测试软件的重要性，在测试环境会使用到测试数据库，它们通常很少使用，负载也比较低。然而，测试数据库不可避免，我们还是要在测试数据库上投入大量资金。

2018 年 8 月，AWS 推出了 Aurora Serverless，改变了这一现状。

AWS Aurora Serverless

传统的云数据库，如阿里云 RDS，腾讯云 TencentDB for MySQL，AWS Aurora，它们与MySQL或 PostgreSQL 兼容，完全托管并可以自动扩展。创建数据库时，需要选择实例大小（CPU 和内存），这要求我们要预测请求数量，负载以及所需的资源。

但是，大多数情况下，请求是不可预测或则分布不均匀的：有少量时间出现大量请求，其他时间则只会有少量请求，如下类似。调整数据库配置可能需要大量工作，同时，持续支付高配置的价格可能不是好的解决方案。

Amazon Aurora Serverless 是 Amazon Aurora 的一种按需自动扩展配置版本。Amazon Aurora Serverless 会根据应用程序的需求自动启动、关闭以及扩展或缩减容量，让你无需管理任何数据库实例，即可在云中运行数据库。对于不频繁、间歇性或不可预测的工作负载，这是一个简单且经济高效的选择。

近期，Amazon 推出了 Amazon Aurora Serverless v2 预览版本，进一步增强了 Serverless 数据库的能力。 Amazon Aurora Serverless v2 预览版本可以在不到一秒的时间内完成扩展，瞬间将处理能力从数百个事务扩展到数十万个事务。在扩展过程中，系统会以极为精细的增量调整容量，从而确保恰好提供应用程序所需的数据库资源量。只需为您的应用程序使用的容量付费。与按照峰值负载来预置容量相比，最高可以节省 90% 的数据库成本。

Serverless 数据库

根据上述的背景，我们可以这样描述 Serverless 数据库：Serverless 器数据库是 Serverless 架构在数据库下的实现，它允许我们按秒或请求次数 为使用的数据库资源付费，专为不可预测且可能快速变化的场景而设计。

工作原理

Serverless 数据库在运行时会根据应用程序的需求扩展容量，并且在不使用时自动关闭。

Serverless 器数据库模型建立在存储和处理分离的基础上，我们可以创建一个代理节点，根据需要设置最小和最大容量，并向数据库发出查询。此代理节点充当频繁扩展的数据库资源队列的代理。这使得我们的连接能够保持完整，同时在代理节点背后进行扩展操作。

存储和处理的分离也带来了另一个好处，计算资源可以轻松缩小到零，只需为存储资源付费。当应用程序需要时，快速从资源池中为请求分配计算资源。

产品形态

根据数据库伸缩的维度和计费方式，可以将目前的 Serverless 数据库产品大致划分为两种形态

计算单位型：使用此类 Serverless 数据库仍然会感受到计算资源的存在，如 CPU、内存或计算单位等，此类 Serverless 数据库本质上是增加了自动扩缩容功能的云数据库。虽然有一定的伸缩性，但是还是会存在计算资源闲置或大于实际需求的情况，对计算容量的控制较差，可能无法应对突发的海量请求。
请求次数型：此类 Serverless 数据库对用户屏蔽了底层架构，如计算资源、数据库分片、存储规划等。通常是按请求次数计费，不会暴露计算单位的存在。在架构允许范围内，理论上可以处理无限的并发请求，可以应对突发的海量请求，是一种较为理想的 Serverless 数据库形态。

我个人认为，当前阶段，请求次数型的数据库才是 Serverless 数据库的最佳形态。能提供极致的按需使用，最大程度的利用计算资源，减少用户的使用成本，才能发挥 Serverless 最大的优势。

使用场景

一些 Serverless 数据库很好的使用场景

新应用程序

在一天或一周内可能只使用几分钟的应用程序，例如，有一个低容量的博客站点，只需要为用户访问站点的时间付费，而不是支付长时间运行的费用。

不常用的应用程序

偶尔会使用的应用程序，或者无法确定会有多少人使用的应用程序，按需付费会是一个不错的选择。

动态负载应用

只会在一些特定时期会存在大量请求的应用，如秒杀活动，运营报告等应用程序具有高度不可预测的高峰时间，保留实例处理会花费较多的费用。

测试数据库

测试数据库，只会在部分工作时间使用。

优势与局限

优势

1. 可扩展性

Serverless 数据库具有理论上的无限可扩展性，能够处理从 0 到数十万并发的请求，可以按需分配资源，按量计费。

当然这只是理论上的说法，具体的情况要看服务提供商的架构以及处理能力，部分服务提供商可能无法应对过于庞大的并发。

2. 高可用性

Severless 数据库本质上是一种托管数据库，相对于自建的数据库，有专业的工程师负责运维、解决问题，拥有更高的可用性，出现故障停机的概率更小。

3. 安全性

Severless 数据库限制了访问数据库的协议、方法，减少了攻击面，提供了更高的安全保障。

4. 降本提效

使用 Serverless 数据库只需为使用的数据库资源付费，减少了资源的闲置情况，能显著降低企业的数据库使用成本。同时，Serverless 数据库使用简单，不再需要进行复杂的数据库容量预置和管理运维工作，降低了企业的运维成本，提升开发效率。

局限性

1. 学习成本

Serverless 数据库可能会使用全新的 API 或操作方式，不兼容常用的 MySQL、MongoDB 等数据库，存在一定的上手学习成本。

2. 网络耗时

使用云数据库时，通常会将计算服务和数据库部署到同一个机房内，应用程序和数据库在同一个私有网络下，应用程序访问数据库时网络延时很低，基本可以忽略不计。

Serverless 数据库一般只会提供公网的 API 入口，与同机房的内网访问相比，网络耗时会较高。

3. 资源成本不可预测

Serverless 数据库按量计费的特性会导致使用资源的成本不可预测，如果受到攻击、恶意访问时，会导致资源成本急剧上升，带来巨大的损失。

4. 不可移植

Serverless 数据库很大程度上依赖于 Serverless 平台的实现，不同服务提供商提供的 Serverless 数据库服务和具体实现并不相同。当我们选择一个平台时，应用程序的实现就会与平台绑定，迁移成本会较高，甚至无法迁移到其他的平台上。

当然，在选择服务提供商时，我们也可以选择兼容性较好的提供商，具体要视平台而定。

服务提供商

当前常见的 Serverless 数据库服务提供商

总结

Serverless 数据库是一个重大的变革，也是未来云数据库的一个重要发展方向。如同 FaaS 一样，它可以让开发者更关注应用本身，而不是被烦杂的数据库运维工作束缚。

虽然 Serverless 数据库的前景很美好，但是国内 Serverless 数据库的发展并不好，当前阶段的选择也十分有限。现在，我们还不能直接抛弃已有的数据库，仍然要学习了解传统的数据库。

未来可期，持续关注。