50W+ 小程序开发者背后的数据库降本增效实践

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

腾讯云 TDSQL-C 这款云原生数据库相比于传统数据库有哪些技术突破？在场景实践过程中遇到过哪些问题？又是如何解决的呢？在 ArchSummit 2022 全球架构师峰会（深圳站）上，腾讯云 TDSQL-C Serverless 研发负责人杨珏吉发表了《50W+ 小程序开发者背后的数据库降本增效实践》的主题分享，围绕 TDSQL-C 在关键技术的多维突破、在实践应用中遇到的挑战及解决方案，以及在内外部用户业务上云过程中的典型应用场景及收益等问题给出了解答。

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

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

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

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

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

计算跟存储分离，就是让房子和客厅解耦。只要解决传送问题（自动扩缩容）就可以让这个房间的成本回归到它本身的价值。虽然传送门在物理上不存在，但我们 TDSQL-C Serverless 做了一个传送门，也就是计算存储分离架构，让所有的计算节点和所有的物理层，所有存储层能够相互进行访问。

TDSQL-C 在腾讯内部有比较多的应用场景，这里选取了两个比较典型的例子跟他大家聊聊：

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

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

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

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

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

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

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

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

TDSQL-C Serverless 数据库的三大特点是：自动扩缩容、按使用量计费、无使用无费用。我们希望你想要请求的时候，这个水资源能像瀑布一样倾泻而下，不需要业务提前感知。希望云服务能像使用水资源一样精准，你的账单一定是来自你所使用的 CPU 和内存资源。如果你不使用，就像关上的水龙头，不收费。

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

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

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

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

第一步是低负载的情况，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 秒内。

我们希望把数据库服务做成一个跟水资源一样的。让初创企业用这个水资源去灌溉自己的农田。目前我们做到了一些，未来我们还有更多可以去做。如果说中小企业是一片片沿溪而耕的农田，那么我们 TDSQL-C Serverless 的愿景就是建一座大坝来管理好上游的水资源，用来灌溉下游企业。

杨珏吉，腾讯云高级工程师 TDSQL-C Serverless 研发负责人，拥有多年云数据库研发经验，负责设计和研发 TDSQL-C Serverless 产品形态。

2022 年，数字化转型成为了全行业关注的焦点，数字经济的价值进一步凸显。云计算作为数字时代的关键要素之一，在行业数字化解决方案、产业链数据流转、资源动态配置、业务创新等方面正产生着难以估量的价值。

为了帮助更多中国互联网行业的同仁一窥云计算领域最前沿趋势与实践，腾讯云连续两年推出《腾讯云技术实践精选集》，收录了腾讯云最新实践经验和研究成果。2022 年的技术实践精选集覆盖云原生、大数据、数据库、中间件、基础设施等热门技术领域，近 100,000 字的技术汇编，26 位专家的真知灼见，倾囊相授！扫描二维码，即可获取全部精彩内容！