炙手可热的serverless架构，或者称为无服务器架构，是最近几年新冒出来的一种技术架构趋势。
那么，被誉为云计算未来的serverless，有何优势？
在过去不久的全球分布式云大会上，腾讯云数据库专家工程师李志阳分享了【分布式数据库serverless化：深入解读无服务器架构下的数据库】的主题演讲，给出了自己的答案。
Part1 serverless数据库特点
随着业务专注度的提升，服务的抽象程度也在提高。
李志阳举了一个汽车服务的例子，以前为了出行只能购买汽车，现在可以使用打车服务，只需知道目的地即可，不再关注开车和保养，核心诉求得到了更好的满足。
计算服务的演进也是类似，从前自建机房，需要维护机房设备；后来可以在云上直接购买虚拟机，部署业务，负责服务的扩缩容；现在的函数计算，从CI/CD到服务部署，扩缩容，全部自动完成，客户可以更专注于业务代码。
狭义的serverless分为FaaS和BaaS，基本特点是无需运维、以API方式提供服务、按实际使用计费、无使用无费用等。举个例子，用户浏览网页，可能涉及CDN资源。如果是静态内容，从对象存储下载照片、视频；如果是动态内容，则触发一个函数计算，云函数将从云数据库获取相应的资源，生成用户所需的动态内容。其中，云函数为FaaS，对象存储和云数据库则为BaaS。
传统的云数据库会提供多种内存/CPU规格给用户购买。即使无法时刻用满负载，用户也需要为选中的规格付费。如果要将数据库serverless化，需要满足以下三大特性：
第一、自动扩缩容。访问量上来时自动扩容，降低时自动缩容，用户不需要关注规格。
第二、按照实际使用的资源付费。
第三、不使用不计费。如果没有访问，不应该收费。
Part2 serverless数据库选型
在讲述serverless数据库选型之前，李志阳先介绍了云数据库架构的演进。
图左侧是目前的主流架构—单体冗余架构（一主多从），是现在大部分客户使用的架构。这类架构存在扩展性问题，实例的升降级和读扩展，都通过数据搬迁实现，随着数据量的增长，迁移耗时越来越长。
为了解决这个问题，业界趋势是采用存算分离架构，衍生出两类，一类是ShareNothing架构，计算和存储均支持水平扩展，扩展能力非常强。不过，也存在一些缺点，其中最大的问题是SQL兼容性，解决之道在于持续构建和完善自己的生态，让用户更好的接受提供的用法。
另一类则是ShareStorage架构，共享存储架构并没有改变查询引擎和ACI这些基础特性，可以做到100%的兼容性。当然它也有缺点，目前计算节点没有提供写扩展能力，这个也是未来演进的方向。
随后，李志阳又关注到了Serverless数据库的用户群，主要面向中长尾用户，他们对扩展性的诉求并不强，更多关注使用的便利性，兼容性是最重要一点。
因此，腾讯云优先选择了基于共享存储架构的数据库产品TDSQL-C提供Serverless服务。
李志阳对TDSQL-C的总体架构进行了介绍：TDSQL-C是腾讯云基于共享存储架构的云原生数据库，始于2017年。由于ToB业务对稳定性的要求很高，在设计之初就定下了一个基本原则，即复用云上的成熟组件。
在计算层使用了腾讯维护的MySQL内核分支-TXSQL，复用它的bugfix和新特性；存储侧则选择了在腾讯内部有十几年历史的云硬盘CBS，把CBS的核心存储和硬盘逻辑进行剖离，打造了统一存储平台-HiSTOR。
作为存储底座，已适配了云硬盘CBS、云分布式文件系统CFS和数据库TDSQL-C等多款产品，提供副本同步、故障自动迁移、数据校验等一系列完善的数据安全保障能力，这正是TDSQL-C产品能够稳定运行数年的重要基石。
另外，它还提供丰富的特性：备份/回档速度，支持以MB为粒度并发，速度达到GB/s；除了高性能的SSD，还有混存和EC版本，应对归档类的业务，提供更低成本的存储。
除了上述两个关键组件，我们还在计算侧实现了物理复制，将innodb的redo日志准实时同步到备机，主从延时非常低（小于1毫秒）；相比传统数据库先写日志后异步刷脏，TDSQL-C只写日志到存储，存储侧通过dbstore模块将日志转化数据。日志下沉的优点很多，这里不做赘述。
由于腾讯云是国内首家提供Serverless数据库的厂家，李志阳主要对比了国外AWS的同类产品Aurora Serverless，并分析如何实现serverless数据库的三大特性。
一、自动扩缩容：
上图右侧有一个共享的虚拟机池，规格不尽相同。Aurora Serverless的扩容策略是从1核2G到4核8G逐步递增规格。例如需要从1核2G扩大到2核4G，则从池子里面找到2核4G的虚拟机，将对应的数据盘挂载到虚拟机，并将访问切到该虚拟机，即可完成自动扩容。有2个问题：1、假设用户访问本身需要4核8G，Aurora Serverless仍需要从1核2G开始逐步增加到4核8G，扩容耗时偏长；2、由于选择新的虚拟机扩容，会导致BP失效，访问将经历一次冷启动过程。
二、按使用量计费
实现比较简单，秒级粒度统计正在使用的规格，按照该规格计费。
三、不使用不计费：
如果实例超过一段时间没有访问，则关闭计算节点。由于有数据库代理节点作为接入层，如果用户再有访问请求，会先到达数据库代理节点。此时，代理节点按照上面提到的方法，从共享池里面找到对应的虚拟机提供服务。对用户而言，原有连接不受到影响，只是感觉到一次卡顿。缺点是引入了代理节点，用户需要为此付费；另外，恢复时长需要30秒，耗时也比较长。
（扩容时BP失效导致的问题）
Part3 TDSQL-C serverless
了解完业界情况，李志阳开始介绍TDSQL-C Serverless。
上图为总体架构，核心模块为中控节点（svls scheduler）。
中控节点接收计算层采集的内存/CPU/访问情况等监控数据，根据策略决定是否扩缩容，启停实例，以及按照计费规则上报云控制台计费。
相对Aurora Serverless的区别在于暂停的应对，TDSQL-C Serverless有faker模块，暂停计算节点时会把四层的vip:vport绑定到faker端口，用户请求过来后，识别为有效的MySQL协议，则通知中控模块将实例重新拉起。其优点在于用户不需要为代理节点付费。
随后，李志阳详细解释了TDSQL-C Serverless如何满足serverless数据库的三大特性。
一、TDSQL-C Serverless的自动扩缩容：
目标是做到秒级的扩缩容，并且期间对用户是平滑的，无感知的。
以上图为例子，用户在购买时选择最小规格为1核2G，最大规格为2核4G。
左边为Aurora Serverless，矩形的纵坐标是CPU，横坐标为内存。初始为1核2G，当业务访问过来，把CPU用满了，持续一段时间才扩容到2核4G。
而右侧的TDSQL-C Serverless，初始就给用户提供最大CPU规格，内存则从最小规格开始。假设用户使用的CPU超过1核，并持续一段时间，将把内存从2G扩到4G。
可以看出，TDSQL-C Serverless的CPU资源不会受限，可以在设置的最大规格内任意使用。优点是用户性能不受限，引入的缺点是可能整机出现满负载。
由于TDSQL-C采用存算分离架构，一旦监控到整机资源超过阈值，就进行快速迁移。迁移其实就是在另外一台相对空闲的机器重新拉起实例，秒级完成。在资源负载上可以精准控制。
另外，现在云数据库整机利用率偏低。基于这两点，TDSQL-C Serverless可以很好应对。
二、TDSQL-C Serverless的按使用量计费：
我们定义了一个算力单元CCU（TDSQL-C Compute Unit）=max{CPU,MEM/2,最小规格}。
其中，MEM/2的含义是，由于我们定义的规格CPU/内存比都是1/2，内存除以2相当于把内存换算成CPU。整体还是以CPU决定整个算力。我们通过计算每个小时CCU平均值给用户计费。
举例说，假设用户选择最小最大规格为0.25核-4核，从图中可以看到，业务高峰过来，一开始就能用到3核，右侧CCU也会按照3核计费，能够很好的应对业务负载。
三、TDSQL-C Serverless的不使用无计费：
自动启停的逻辑比较简单，只要10分钟（用户可配）内监测到没有访问就回收掉计算节点，访问回来就把节点重新拉起。
这里最核心的点是怎么做到快速恢复，之前提过TDSQL-C是日志下沉的，存储侧接收到日志之后会源源不断的回放，数据库计算节点在启动的过程中，不需要像传统数据库那样加载到日志然后重放，所以启动相对比较简单和快速。
具体来说，VDL表示已经持久化的日志点。在运行阶段会不断异步持久化VDL（last-vdl）。Recovery阶段，首先获取last-vdl（checkpoint点），然后广播所有相关的小表获取大于等于last-vdl的所有日志段，最后通过败者树找到最后连续的日志点作为VDL。
整个过程都是并行化的，而且没有数据重放，耗时小于100毫秒。另外，我们还对MySQL启动过程做了多处并行化处理，因此目前可以2秒内恢复实例。
Part4 展望
李志阳表示，TDSQL-C Serverless还在持续优化，不久的将来会把冷启动从2秒缩短到百毫秒级别，更贴近云函数的启动时间。
同时，为了进一步降低用户的存储成本，如果很长时间没有访问，将数据转存到对象存储COS，届时用户只需要付COS的费用即可。
最后，点击「阅读原文」，即可体验19.9一年的TDSQL-C，欢迎大家使用~
- End -
更多精彩
↓↓一年19.9特惠TDSQL-C点这儿~
