作为国内第一款云原生 Serverless 数据库，TDSQL-C 目前仅在微信生态上就为超过 50W 小程序开发者提供数据库底座，凭借按量计费、超强弹性、存算分离等特性，能有效降低用户的数据库使用成本。

本次ArchSummit 2022全球架构师峰会（深圳站）邀请了 TDSQL-C Serverless 研发负责人杨珏吉老师与大家分享。老师将会与大家分享云原生数据库在关键技术的多维突破，在实践应用中遇到的挑战及解决方案，以及在内外部用户业务上云过程中的典型应用场景及收益。

什么是 TDSQL-C Serverless ？

TDSQL-C Serverless 是腾讯自研的云原生数据库。TDSQL-C Serverless 的特色是能够让企业像使用水、电、煤一样使用云数据库的服务。用户不需要为闲置的数据库而付费，用多少算多少。这项技术在很多业务场景下都能帮助企业极大的节省成本。

TDSQL-C 在腾讯内部的使用案例

微信小程序

开发微信小程序面临的问题

1. 云服务成本高

云服务器虽然方便，但价格并不便宜。目前常见的服务器有两种：按时付费和包年包月。按时付费价格有点高，包年包月不灵活。

2. 资源利用率低

根据数据来看，大部分小程序的用户规模小，数据库的资源使用率很低。而且大多数在活动期间会高一点，活动结束后，资源就用不上了。

3. 后端配置复杂。

云产品为了使用的通用性，配置会非常多。企业需要花很长时间去学习，去配置，运维成本很大。

基于以上的问题，微信和腾讯云一起推出了微信云托管服务。简化小程序开发运维的流程。开箱即用，按使用收费，不使用不收费。能极大减少开发者的成本。感兴趣的到官网试用一下：微信云托管

下面是微信云托管整体架构图。整个服务都在腾讯的网络里，能保证数据的安全性。

在实现整个架构的时候，腾讯云托管遇到了数据库选择的问题。下图左边的方案，所有的小程序都访问同一个小程序，通过 DB 来隔离。这种方案的隔离性很差，安全性也很差。后来选择了下图右边的 TDSQL-C 方案来解决，每个小程序都有自己独立的 TDSQL-C。

腾讯乐享

腾讯乐享是腾讯内部的论坛、文档等，已经服务腾讯员工 10 多年了。下图是腾讯乐享的架构图。

不同员工通过外部应用防火墙到 CLB，然后进入到腾讯乐享的业务逻辑层。这是一个典型的 SaaS 服务架构。因为要面对不同的企业用户，所以在数据上要做隔离。同时，很多 ToB 企业用户很少，所以并不会频繁使用这个数据库，导致它的整个负载比较低。经过几次成本优化之后，腾讯乐享就会把很多负载低的客户合并到一个数据库实例里，也就变成了前面微信云托管那样一个架构了。同样，它也会面临云服务器资源浪费的情况。最后，还是使用了 TDSQL-C 来代替原来的云上数据库。

TDSQL-C Serverless 数据库最大的特点是，计费跟负载是强相关的，负载高，计费就高，负载低，计费就低。替换后，乐享这边测算数据库的成本降低了 80%。

TDSQL-C Serverless 的技术实现？

通过把计算和存储进行分离来达到按使用收费。

传统数据库实现 Serverless 的难点

传统云数据库并没有实现自动扩缩容、按使用量计费、无使用无费用。这就导致，我就算只用了 10%的计算资源，另外 90%的闲置计算资源也无法分配给其他用户。我还需要为此而付费。同样，存储资源也一样。基于这种存储跟计算绑定的架构，用户需要提前购买好对应 CPU 和内存的这样一个数据库。而且买完后就算没用也需要因此而付费。

TDSQL-C 架构图

而我们 TDSQL-C Serverless 做了计算、存储分离的这么一个架构。下面有个存储层、存储层如果不够，我们可以水平扩展，加机器、加存储。上面是计算层，如果计算资源不够，也可以按自己的需要去动态扩容，而且不用在意存储层是不是满了。计算和存储分离后的每一部分资源都可以按照自己的需求去做资源的分配。

我举个例子来解释下。现在我们面前有两个房子，一个是两房没有客厅，一个是两房一厅。客厅里有个电视可以方便我们一起玩游戏。但因此每个月要多花 2000 元。但问题在于我也不是每天打游戏，只有周末才有时间打。这就是现实里经常碰到的两难问题。如果这时候有个传送门，我可以直接从房间里传送到一个客厅里，一小时收费 10 块，是不是这个问题就解决了？

有同学会觉得，如果我两房旁边就有一个游戏厅呢？这个游戏厅是不是也能解决我的问题？这样我就不用去解决传送门的问题了。实际上很难，如果这个游戏厅只为你服务，它迟早倒闭。物理位置的限制，让它没办法服务更多人。所以本质上，它要么服务人群足够多，要么就是单价很贵。在现实里，如果游戏厅就在你房间旁边，你房租的价格也会比其他地方的更贵。

计算跟存储分离，就是让房子和客厅解耦。只要解决传送问题（自动扩缩容）就可以让这个房间的成本回归到它本身的价值。

虽然传送门在物理上不存在，但我们 TDSQL-C Serverless 做了一个传送门，也就是计算存储分离架构，让所有的计算节点和所有的物理层，所有存储层能够相互进行访问。

TDSQL-C Serverless 数据库特点

1. 自动扩缩容

2. 按使用量计费

3. 无使用无费用

我们希望你想要请求的时候，这个水资源能像瀑布一样倾泻而下，不需要业务提前感知。我们希望我们的云服务能像使用水资源一样精准，你的账单一定是来自你所使用的 CPU 和内存资源。如果你不使用，就像关上的水龙头，不收费。

需要自动扩容的业务场景

1. 慢查询

我们大部分业务都有慢查询，比如执行一个不带索引的 SQL。或者你有一个多表查询的场景。或者说前端有运营同学在做数据分析，那么他就会查很多的数据。慢查询会引发一个比较高的 CPU 负载，但如果我们买一个大的规格，就需要承担比较高的成本，如果买一个小的规格，那么可能会因为这些慢查询而影响到在线服务。

2. 活动场景

在活动期间会有一个比较高的负载，但活动过去之后，负载就会降低。同样如果我们买一个大的规格，就需要承担比较高的成本，如果买一个小的规格，那么就支撑不了活动的使用了。当然你也可以选择在活动前扩容，活动后缩容。但这总的也不方便，而且并不是所有的活动都有足够的时间去规划。所以这时候就需要一个自动扩缩容的能力。

3. 定时任务

很多业务都会有定时任务的需求。比如在夜间去计算一下当天业务数据的情况汇总为一个报表。或者是用户的一个账单。那么在这个任务执行的时候会有一个比较高的负载。虽然你也可以根据计划去手动扩缩容。但有些计划使用的计算资源不可控，时间也不可控。少了速度慢，可能还会影响到线上业务，多了话又是浪费。

TDSQL-C Serverless 自动扩缩容技术

业内常见扩容方案如下图：

第一步的时候是低负载的情况，CPU 使用了 0.1 核，Buffer pool 使用了 1G，其他内存 100M。 第二步，用户来负载了，也就是高负载触发扩容前，CPU 分配了 1 核其他内存 500M。然后第三步高负载触发扩容后，CPU 使用 1.8 核，Buffer pool 2G，其他内存 500M。

但这能满足用户的需求吗？实际上并不能。因为从第二步到第三步得有个持续监控发现它高负载了，发现它超过了阈值，才会自动扩容。比如 5 分钟高负载才扩容。而且它还是阶梯式的，比如我规格最小 1 核，最大 16 核，如果是阶梯式扩容，而我一开始就需要 16 核，你得反应 4 次才能扩容到 16 核，等扩容完成的时候，活动都已经结束了。比如有些报表一两分钟就计算完了。所以这个扩容根本就不能满足业务的需求。

我们之前也想过，想办法把 5 分钟扩容缩短成十秒甚至更低。但后来我们决定不这样做。我们干脆直接把规格放到最大，也就是如果最大规格是 2 核 4G，我们就直接放大到 2 核 4G。用户可以一开始就使用 1.8 核，然后我们在持续监控这个 CPU 的高负载的情况下，对内存进行一个自动扩容。

计费的业务场景

1. 问题 - 计费近似

这种计费方式其实对用户很不友好。比如说，我只有了 0.6 核，但是确要为 1 核付费。如果我控制不好，超出一点，用了 1.1 核就需要为 2 核付费。这也太难了。

2. 小规格实例

现在其实有很多小数据服务，它的负载是低于 1 核的。但市面上大部分数据库，提供的最小规格就是 1 核。现在市面上有很对微服务，它对应的数据库也是非常小的。

计费模式的说明

我们是每 5 秒进行一次资源使用采样，我们的计算单位为：CCU（TDSQL-C Compute Unit）= max(CPU, MEM/2, 最小规格) 。按实时的 CCU 进行计费。其实并不复杂，就是为了保证按使用计费，我们做了一个算法。能够保证是按照你使用的资源来进行计算。账单也会提现你资源的每一时刻的使用。

无使用不收费的场景

1. 归档数据库

比如，在发论文的时候，有很多训练数据需要存储，这时候会需要去访问这个数据库，去取里面的训练数据，去做实验。这时候 CPU 会使用比较多，但我发完论文后，就基本不需要使用数据库了。这就是归档数据库的场景。

2. 场景-低频访问的业务

像个人博客、垂直论坛、微信小程序等低频访问的场景。如果它每天的请求就十几二十次，我们还按 0.25 核去进行收费。是不太合适的。

3. 开发测试环境

开发测试环境大多数只在工作日的白天才会用。周末和晚上基本不用。这种时候，其实我完全可以在不使用的时候把你数据库关掉。

如何是实现不使用不收费？

用户通过接入层反问我们的计算层，计算层通过存储层取数据返回给用户。管控平台监控计算层和存储层的资源消耗，包括 CPU、内存以及存储量进行计费。如果持续十分钟没有任何请求，我们就会通过管控层进行计算层的资源回收。这样就不会采集资源消耗了。而当新的 sql 来了后，我们接入层能够感知并通知管控平台进行恢复，这个时候又会开始资源的计算。

这里面有一个很重要的指标就是从暂停到再一次启动的时间。我们花了很多时间来优化这个冷启动的时间。目前大概还需要 2 秒，我们未来计划做到 1 秒内。

总结和展望

我们希望把数据库服务做成一个跟水资源一样的。让初创企业用这个水资源去灌溉自己的农田。企业希望有什么述求，我们就想办法去满足。

1. 降低成本：可以按使用量收费，无使用不收费。

2. 减少运维成本：单个节点高可用，并且提供智能管家诊断，SQL 分析。

3. 迭代试错快：发货速度快，回档 GB 每秒。如果项目觉得做不下去了，直接关掉计算进程就可以了。后面你要是觉得有价值，直接恢复进程就可以了。

4. 用户数激增：自动扩缩容。

5. 小微项目：小规格实例

......

目前我们做到了很多，未来我们还有很多可以去做。如果说中小企业是一片片沿溪而耕的农田，那么我们 TDSQL-C Serverless 的愿景就是建一座大坝来管理好上游的水资源，用来灌溉下游企业。