什么是Serverless呢？简单理解，Serverless 分为 FaaS 和 BaaS 两个部分，其中 FaaS 指的是函数即服务，BaaS 是后端即服务。
不过，咱还是要默默的问自己一声。万一爆红，你的数据库做好准备迎接业务访问量暴涨、计算或存储的需求量激增了吗？
那，用户当然要问了，到底我要选择多大规格的呢？在 TDSQL-C 这儿，完全不用纠结。
TDSQL-C MySQL版的无服务器、全 Serverless 架构版。TDSQL-C 推出的 Serverless 服务基于计算与存储分离的理念，满足了客户在公有云计算环境下根据业务发展弹性扩展集群的刚性需求，让用户不再纠结实例资源问题，让用户像使用自来水一样使用数据库。总结其特性，可分为以下三点：
自动扩缩容：用户不需要过度关注规格，访问量上来时自动扩容，降低时自动缩容，且实现扩缩容的过程中做到业务无感知；
实用实付：按秒计量，按小时结算，按照实际使用的资源付费；
不使用不计费：如果没有访问，不应该收费，帮助业务极大程度地节省成本；
一、头脑风暴
在一些极限的测试场景下，实例会频繁的自动启停，这时候如何保证实例停止后快速恢复呢？如何保证在恢复实例时无需用户重复链接，直到恢复访问？
为了实现这一能力，我们做了众多探索，最后选定了通过在接入层增加一个恢复感知器来实现秒级冷启动这一方案。同比于通过 proxy 来实现链接的保持和转发能力的方案，我们采用的方案更加贴合 Serverless 服务为用户提供低成本的理念。这是因为采用 proxy 模式需要支付额外的成本，整体设计会更加复杂，并且还需要设计多租户的能力。
二、建连流程
这一方案的核心要点是在 TDSQL-C 的接入层增加了一个恢复感知器（下文简称：perceptron），通过 perceptron 模块来实现请求转发，perceptron 在和客户端握手之后，不断开与用户连接，恢复实例后，与 TDSQL-C 握手，后续转发四层报文。以下为 perceptron 与 TDSQL-C 建连的具体过程：
校验 “登录解答 A” 将由 TDSQL-C 计算层（下文简称：TDSQL-C）来完成，preceptron 通过管控唤醒 TDSQL-C 后（P3），开始下一步的登录校验流程。
preceptron 的回复是一个我们实现的特殊的 MySQL 报文（P6），首先它用 “随机数 B” 和 preceptron 自身的鉴权机制计算得到 “登录解答 B” 并放入报文中，其次它也将 “随机数 A” 和 “登录解答 A” 捎带在此报文中。
两次校验，第一次是 “随机数 B” 和 “登录解答 B” 的正确性以及 preceptron 的身份，通过后再进行第二次的 “随机数 A” 和 “登录解答 A” 的正确性，通过即以用户身份进行登录，并回复 preceptron 登录成功（P7）。
比较巧妙的点在于整体流程设计采用了两个挑战随机数进行鉴权，这样做的优势在于：
实现中继模块 preceptron 不存储用户名密码的情况下也可以完成用户名密码验证；
保证了用户密码的安全性，也不会引入存储的密码不一致的问题；
Rust 语言进行研发，相比使用垃圾回收机制管理内存的语言，Rust 具有更稳定的响应时间。同时基于 Rust 内存管理特点，使得 preceptron 更安全，占用的内存资源更少，最大化降低成本。
其实，选择 serverless 的用户更在意低成本，而不是读写分离和链接保持能力。因此我们在设计 preceptron 模块时，只会把触发恢复的请求链接接路由到 preceptron 上，当实例恢复后，新增的请求会直接发给 TDSQL-C。
通过 VIP 权重来实现路由的定向转发。当实例处于暂停状态时，仅保留 preceptron 的路由；当实例恢复后时，同时保留 preceptron 的路由和 TDSQL-C 的路由，并设置 preceptron 的路由权重为 0，以实现新增连接直连到 TDSQL-C，同时存量与 preceptron 已经建连的链接依然能够通讯。
三、测试一下
累加内核侧、管控侧、perceptron 侧的总体冷启动时间，整体重连时间约在 2000ms 左右。浅放一张今天下午测试的结果，欢迎大家来体验秒级的快乐！
同时，我们为了进一步降低用户的存储成本，我们在持续探索新型的存储能力，在实例暂停状态下将数据转存到对象存储COS，并保证实例在恢复时不影响数据的读取，更大程度帮助用户降低成本。