2019 年，Gartner 在一份报告中将 Serverless 选为最有潜力的云计算技术发展方向，称其为云原生时代的 必然发展趋势之一。Serverless 从底层开始变革计算资源的形态，为软件架构设计与应用服务部署带来了新 的设计思路。 在各类 Serverless 应用中，数据库的 Serverless 化被认为是颇具挑战性的一大类别。曾几何时，业内 只有亚马逊 AWS 发布了较为成功的 Serverless 数据库产品。2020 年 4 月，腾讯云发布了国内第一款 Serverless 数据库，填补了国内这一领域的市场空白，在数据库市场获得了大量关注与期待。为了让更多 IT 从业者更深入了解腾讯云 Serverless 数据库。在 2021 年 QCon 全球软件开发大会【上海站】中，腾讯 云数据库高级工程师巫旭东发表了《云原生 Serverless 数据库的设计与实践》的主题演讲，分享了腾讯云 Serverless 数据库的诞生背景、设计理念与落地实践。
传统数据库常见问题与解决方案 在 IT 行业，新概念的诞生与崛起往往是为了解决现有方案长期存在的问题和挑战，Serverless 数据库亦是如此。随着行业快速向云原生架构转型，传统数据库的一系列缺陷变得愈加突出，逐渐成为系统架构中不可 忽视的瓶颈环节：
1. 业务系统转向微服务架构后，由于每个微服务需要单独搭配数据库，当微服务比较多时，轻量化数据库的 数量也随之增加，开发环境预发布与线上微服务的相乘结果将呈爆发式增长，其成本很容易陷入失控状态；
2. 很多新服务上线时，很难准确预估其计算资源需求，传统的云端预付费模式容易导致资源购买过量和浪费； 部分数据库呈现平时低频，短时高频的访问特征，传统模式不仅会造成浪费，还很难及时完成资源扩容， 带来业务损失；
3. 传统数据库的存储与计算在同一台服务器上完成，当用户存储与计算需求不匹配时，传统购买模式会大幅 增加扩容成本；
4. 服务数据库容量可能超过单机上限。当业务早期没有准备好分布式能力，或需要开发分布式事务时，传统 数据库的这一瓶颈会对业务产生较大冲击。
之所以传统数据库会遇到上述问题，最主要原因在于其计算层与存储层耦合于同一台服务器上，很难灵活分 配资源。传统数据库缺乏自治能力，用户尚不清楚数据库服务负载时就要先购买固定的计算与存储能力；当 服务器负载升高时，数据库无法自行感知资源不足情况并进行应对。与此同时，数据库主机的计算与存储资 源比例固定，售卖时只能遵循这一固定比例，多余成本需要用户买单。另外，传统数据库的扩容依赖人工响应，跨机迁移速度非常缓慢。最后，单机存储上限大大限制了传统数据库的水平扩展能力。 针对上述问题，行业提出了一些针对性的设计理念。例如成本问题可以通过按量计费模式解决，资源预估问 题和低频服务需求可以通过自治能力、自动扩缩容来处理。存储池化概念能够突破单机存储能力瓶颈，实现 动态扩缩容。
综合来看，新一代数据库需要做到：第一，计算与存储分离，不再受限于某一台服务器的计算与存储资源； 第二，实现服务自治，能够自动计算服务器负载，实现资源动态扩缩容。
Serverless 数据库架构与设计理念
腾讯云 Serverless 数据库就是基于上述理念打造而成的新一代云原生数据库。这款数据库的架构基石就是“存算分离”，所有计算节点共享同一份存储层数据。对于用户来说，不管在集群里购买多少计算节点，都只需 要一份存储资源。 计算与存储分离在不同机器上，就需要网络 IO 来交换数据。若使用传统的网络 IO 技术，数据库的计算与 存储节点交互的日志会非常庞大，且延迟很明显。所以腾讯云自研了 Txstore 分布式存储内核，将所有日志 统一到了 redolog 的功能上。TXstore 会接收发送过来的 redolog ，这样既能把计算与存储剥离开，又可以达到最高性能。
在 Serverless 数据库的自动驾驶架构中，分为五个层次——用户、管控、数据流、计算和存储。用户层就 是控制台的一些模块。管控模块分为两个部分，其一负责管控计算模块的分配、回收、暂停操作。其二是副 驾驶决策模块，负责实时采集计算模块的当前负载，根据实时负载及之前分配的计算节点资源来做评估；如 果当前分配的资源不足以处理当前的负载，该模块会向管控模块发起扩容请求；如果计算节点负载较低，分 配的资源有冗余，决策模块会发起收容请求。
极端情况下某些计算节点可能完全没有负载。例如共享充电宝一般放在商场里面，商场晚上 10 点后就关门 了，这时充电宝不会发来请求。如果数据库还在运行，资源就会浪费一整夜。此时系统发现数据库超过十分 钟没有任何新连接，就会回收计算资源。但存储资源是有状态的，不会回收。到早上 10 点商场开门了，用 户进来扫充电宝，其客户端就会向集群的 proxy 发出连接请求。此时 proxy 发现计算节点不在，就会向管控模块发起请求，请它唤醒计算节点。管控模块会重新拉起计算节点，并通过路由表来关联存储节点。之后 proxy 发现计算节点已经拉起，会把连接重新打给计算节点。这就是数据库具备的，从启动到暂停再到启动 的完整自动驾驶能力。
架构对比
腾讯云 Serverless 数据库的存储池化架构是核心要素之一。传统架构使用的是母机概念。上图中的三个母机， 蓝色部分是计算资源，绿色加红色是存储模块，其中红色是已经使用的模块。母机是格式化分配，必须要对 计算与存储做相应比例的分配。绿色的模块没有使用，但用户也要付费；没有使用的空间都是预付费的能力， 必须提前付费。且传统架构中增加计算资源时，用户必须要重新购买完整的计算与存储母机，就可能为多余 的存储成本买单。
在存算分离架构中 Master 跟 Slave 共享同一份存储，存储是按照 shard 分片这一最小单元做分配，每个分 片固定为 2G。如果数据库只用到 10G 的数据就只需要为 10G 付费，用到 11G 就只需为 12G 空间买单。并 且因为存储是分布式，容量不受单机存储限制，最大可达 128T。
存储池化涉及路由表的概念。存储池的实际物理存储单元 page 为 16K，每个 page 有自己的编号。一 批 page 的集合就是 shard ，其地址都会存在 DBMaster 模块里。读写请求需要找到 page 时，系统找到 page 后计算得到分片号，基于分片号通过路由表找到物理位置；再计算 page 在 shard 上的偏移量，有了 物理地址和偏移量可以做 page 寻址，完成一次读写请求的数据查找。
下面是关于计算自治部分，首先是扩缩容场景。
数据库启动时，首先需要用户主动填写期望的数据库最小与最大规格。因为有些用户对成本比较敏感，不希 望数据库无限扩容，希望到一定的阶段就停止；还有用户希望数据库启动时最小规格保持在较高水平。为此 腾讯云提供了一些规格列表供选择。
扩缩容时，CPU 容量不限于数据库当前使用的数量，数据库启动时可以使用的 CPU 上限是规格最大的上限。 因为如果系统限制用户的 CPU 数量，那么超过限制值时性能就会下降；但扩容本身有一定延迟，在 30 秒左 右，也就是说决策模块发现业务使用的 CPU 数量超过当前的规格限制 30 秒之后才会扩容。所以腾讯云决 定 CPU 数量不受当前使用数量限制，并承担 30 秒以内的多余成本，因此用户侧是无感知的。
与 CPU 相比，内存是有参数限制的。数据库的内存使用上涨后不会自动缩容，必须有参数动态限制数据库 的内存。另一方面，当用户实际使用的 CPU 超过了当前计费值 30 秒后，系统就会向下一个规格扩容，例 如从 0.25 扩容到 0.5、1 核，从而实现服务灵活自治，实际性能不受计费规格限制，且超出部分由厂商买单。 但这样一来单台服务器可能扩容到超过主机资源上限，出现母机资源超载问题。
解决母机超载问题就需要跨机迁移。这里的算法假设母机的所有计算资源总量是 S，当前母机上所有实例规 格总规格是 M，扩容后规格计做 N。当 M 加 N 大于等于 S，意味着一台母机的计算资源不够用了。这时存 储是足够的，只需迁移计算节点，需要新找一台机器拉起计算节点，初始化表结构。此过程可以在两秒内完成， 相比传统架构的迁移耗时（可达数十小时）有巨大飞跃。
关于计算节点的暂停与冷启动方面，当某个实例连续十分钟没有连接时，系统算法会将其回收，进入“暂停中”状态。客户端再发起连接请求时不会直接打到实例上，而是会打到 proxy 上。后者发现数据库暂停，就会发 起唤醒请求到管控模块，管控模块拉起 Serverless 的计算节点。从 proxy 发起唤醒到计算节点被拉起的时 间就是冷启动时间。
传统数据库的冷启动必须要加载所有存储数据，时间非常漫长。但 Serverless 数据库只需要处理计算节 点，只需加载路由表，所以启动速度非常快，可以优化到 1.6 秒到 2 秒。冷启动完成后，proxy 会正常向 Serverless 数据库发起连接请求，成功连接客户端并进行正常的读写操作。
CCU计算单元
上图是 Serverless 数据库按量计费方案，其计算计费单位是 CCU 。系统每秒钟在母机上采集 CPU 当前值 和五秒前的值，做减法除以 5 就得到每一秒平均 CPU ；内存与存储的使用量每秒上报。这样 Serverless 的 指标可以做到秒级采集。最终计费的单元是 CCU 和存储，这两个指标按小时上报扣费系统，给用户看到按照小时计费的帐单。
Serverless 数据库落地场景
腾讯云 Serverless 数据库已上线 10 月左右，用户量累计较多。其中较典型的应用场景是同腾讯云开发的深度合作。
很多小程序开发者的云服务托管在腾讯云开发上，后者与 Serverless 数据库做了深入耦合。一些云开发用户对成本和业务性能非常敏感，过去他们会报告数据库成本非常高，现在得到了明显的成本下降效果。腾讯云函数也是 Serverless 数据库比较早的实践者。云函数将代码托管到容器里，当用户使用时拉起容器，不 使用的时候把容器关掉，以提供无服务化的产品。过去计算节点在不提供服务时也会收费，而 Serverless 数据库就填补了这块拼图。
上图是实际使用中的效果展示。可以看到左上角的 CPU 使用核数与右上角的 CCU 呈现比较完整的耦合状态， CPU 用量增加，CCU 也跟着涨了上来；10 点 16 分 CPU 降下来的时候，CCU 也会按照预期一半一半往下缩。
监控管理方面，腾讯云 Serverless 数据库与智能管家做了一些深度合作的监控管理，可以从不同的维度监 控数据库。其中包括一些 SQL 预防操作，系统感知风险后会给用户提供操作建议。性能分析模块发现数据 库的 CPU 或者内存出现瓶颈，会建议把最大规格再调大一点。数据库的告警机制也比较完善，可以支持 70 多个监控指标的告警。此外还有问题快速定位，可以给用户提出一些比较好的处理建议、分析复盘和优化建议。
总结
回顾历史，可以看到数据库技术经历了四个时代。最早是自建时代，开发者在购买服务器自建数据库。这个 时代的数据库和硬件生命周期完全绑定，且运维方式比较原始。第二个是 paas 租用数据库的时代，出现了 一些运维层面的改进，且节省了硬件购买成本，但因为存算一体化所以资源弹性比较差。接下来是云原生数 据库时代，做到了存算分离，所以资源弹性有大幅改善，可以高效扩缩容。但这一代数据库没有自治能力， 所以腾讯云在云原生数据库的基础上进一步设计了第四代 Serverless 数据库，完美利用了存算分离特性。 第四代数据库可以进一步提升资源弹性，可以做到纯粹按量计费，且服务更加自治，有了秒级扩缩容，服务 更加稳定。
摘录自：infoq: 腾讯云技术实践精选集2021