现在云计算行业无服务器的情况就像《星星之火，可以燎原》里面的描述：虽然未来的发展变化无法预测，但是对于云计算来说是一个相对确定的方向。

从Google Trends中Serverless关键字的趋势可以看出，Serverless的搜索量一直居高不下，而且未来还会保持相当的热度。2015年以来，以AWS为代表的国外大云计算公司一直在布局无服务器相关产品，如AWS Lambda、阿里云FAAS、极光无服务器、红移无服务器、Azure SQL数据库等。在数据库字段中。

学术界对无服务器的研究和工业界对商业方案的追求一样热烈。文末列出了一些相关文章，以供参考。学术界对云计算向无服务器演进也经历了一些质疑。2018年的文章《无服务器计算3360前进一步，后退两步》[3]曾经表达了对无服务器的发展对当前IT基础设施的影响的担忧，但在2019年，同样的人表现出了对这一方向的支持和乐观。从无服务器领域被频繁引用的论文可以看出，主流科研机构对无服务器的趋势和方向趋于一致，研究重点也逐渐从“为什么”转向“如何”[6]。

什么是无服务器？为什么Severless是一种趋势？《云编程简化3360 a Berkeley view on server less computing》[5]一文对代表做了全面的分析和预测。Berkeley在2009年发表的另一篇文章“About the Clouds 3360 a Berkeley View of Cloud Computing”[7]预测了云计算作为IAAS基础设施的前景。本文延续了之前的风格，分析了现状和困难，预测了云计算2.0无服务器作为下一代基础设施的形式，也定义了无服务器的三个主要特征。

1.资源的解耦和服务

削弱了存储和计算之间的联系。服务的存储和计算是分开部署和收费的，存储不再是服务本身的一部分，而是演变成了一个独立的云服务。这使得计算无状态，更容易调度和扩展，同时降低了数据丢失的风险。

2.自动弹性伸缩

代码的执行不再需要手动分配资源。不需要指定所需的资源(如使用多少台机器、多少带宽、多少磁盘等。)对于服务的运营，只需要提供一个代码，剩下的交给无服务器平台。现阶段的实现平台在分配资源的时候，也需要一些来自用户端的策略，比如单个实例的规格和最大并发，单个实例的最大CPU利用率。理想情况下，应该使用一些机器学习算法来执行全自动自适应分配。

3.按使用量计费。

无服务器根据服务的使用情况(通话次数、持续时间等)收费。)，而不是按照使用的资源(ECS实例、VM的规范等)收费。)像传统的Serverful服务。

值得一提的是[5]这篇文章有很多云计算厂商的背书，包括AWS、Micorsoft、Google、阿里巴巴等。同时，文章还直接用AWS Lambda服务作为模型来分析无服务器的问题。无服务器本身的技术难度，本文列举了多项内容，在此不再赘述。可以具体看文章。

无服务器的技术实现[3]给出了一个可行的系统实现，还是基于FAAS。其中，无服务器关键技术路径包括：

统一标准运行时环境支持多语言运行时统一管理；

轻量级/轻量级安全容器(安全和隔离的重要性在[4]中另外提到)

冷热容器池被设计为最终的多租户重用能力；

高效的功能调度能力。

其中，函数计算的实现与数据库无服务器密切相关。

无服务器数据库

数据库有很多种。自1979年E. F. Codd描述关系模型[7]以来，后来者大多只是模仿，还没有超越用户接受度和规模。

数据库不仅是一个“有状态”的应用程序，也是一个“重状态”的应用程序。数据库是无服务器最不友好的应用之一，包括云原生基础设施kubernates对有状态应用的支持，只有在StatefulSet和operator之后才有更好的解决方案。在此之前，数据库是作为无服务器解耦状态和下沉状态的工具，也是全栈无服务器解决方案的最后堡垒。

对于无服务器的定义，文章给出了一个公式：无服务器=FAAS BAAS。设置FAAS(作为服务的功能)

e)定义为事件、API、消息驱动的计算层;将BAAS(Backends as a Service )定义为类似数据库、消息队列等后端服务。

“State-heavy applications will remain as BaaS”是目前对于数据库的一个基本认知，但这与数据库本身是否具备一定程度的Serveless能力其实是两回事。前者强调的是在应用向Serverless做架构转型的过程当中，数据库的大量状态存储做不到FAAS这样即开即用的能力，只能作为“+”来对接Serverless生态;后者说的是在某种程度上也能够满足“资源解耦”、“自动弹性”、“按使用量付费”的特点，某种程度上也可以认为是Serverless。

数据库Serverless的难点究竟在哪里?

数据库做Serverless有若干难点[4]，总结如下：

Serverless没有内置的持久化存储，需要依赖远端存储，这就会导致在延时上较高;

客户端是基于连接的方式访问数据库，在客户端往往会维护连接池的方式供应用访问，而函数计算往往具备飘忽不定的网络地址，与数据库传统的IP+User+password鉴权的方式迥异;

很多高性能的数据库使用共享内存技术，而FAAS本身不具备共享内存的能力，会使得计算和数据库之前的资源动态扩展能力不一致。

其中尤其要注意的是第2点，在应用进FAAS之后，当前的数据库访问方式已经不适用于Serverless生态：

服务器与DB做连接保持，这就意味着访问状态是由客户端和数据库共同维护，而FAAS无法做到连接持续保持的能力;

服务器通过driver和连接池的方式访问数据库，每次的连接初始化相对较重，FAAS上无法承受如此重的连接初始化工作;

服务器访问鉴权通过user/password/ip的方式访问数据库，而FAAS多租户场景所有用户共享IP地址池，user/password内置到FAAS当中也暴露了极大的安全风险;

数据库需要一种新的访问方式，直接影响到数据库能否作为Serverless生态当中的一部分，直接影响到当前Serverless应用做全栈Serverless改造。其重要程度甚至大于数据库Serverless(资源解耦、极致弹性、按使用量付费等)本身。

当然数据库本身要做的事情远远不止如此，数据库本身要实现高效的弹升弹降，涉及到更多的管控和内核紧密的联动。

他山之石

行业翘楚AWS在Serverless相关的布局从2015年推出Lambda开始，引领着这个方向的发展。这里更多的关注在数据库方面，结合AWS在Aurora Serverless上的取舍，洞察AWS对于数据库Serverless的理解。

从Aurora Serverless V1发表于2018年，在Serverless的理念上做了大胆的创新，做了几件事情：

以ACU的方式去统一底层的资源，不再对上层暴露底层具体的机型和代数。1ACU“相当于”2GiB的RAM，统一对底层资源做了标准化和规范化的处理。这与Serverless理念中资源的解耦、以及对底层资源的屏蔽一致;

支持自动启停，在无负载的情况下支持将计算节点降低至“0”。将Serverless中按资源使用量付费体现到极致，但也带来了另外的问题。自动启停在一般场景下首次拉起需要30s左右，牺牲了部分auto scale的能力;

数据库弹性过程中内核相关buffer pool等参数随着资源配合的变化而发生变化，这也是数据库这种特殊的应用场景需要做的一些特殊处理;

2019年推出Data API功能，补全了数据库作为BAAS接入FAAS的能力，解决了前面提到的生态兼容的问题。

2020年发布的Aurora Serverless V2的介绍视频并提供内测申请，而在前不久V2也正式GA。从Aurora Serverless V2的能力来看，在Serverless能力上做了增强和取舍：

将V1中弹性能力继续提升至秒级，做极致快速的弹性。将V1中跨机升级的能力优化为本地升级的能力，保证业务在弹性过程中不受损。从Aurora Serverless只在3.0.2这一个版本上支持可以看出，内核层针对Serverless场景也做了大量的优化;

去除了V1中关于自动启停的能力，用户可以手动启停实例;更加关注实例的auto scale能力，最小资源降低至0.5ACU而非0，牺牲了部分按使用量付费的能力，这也是一种取舍;

将弹性缩容的策略做得更加保守，以保证业务压力情况下对业务的影响尽可能小。

从V1到V2的变化，对比V2和V1的User Case可以看出，Aurora Serverless V2主要解决的是从“开发测试环境”到有限场景下的生产环境的转变，至于底层的实现原理，可以从一丝丝蛛丝马迹中去探究。结合其他云的做法，Serverless的能力目前还是看重这个理念，各个厂商也在以自己的产品形态去向贴近这个理念，至于说一统行业标准的产品化方案，还为时过早，这一领域大有可为。

未来可期

从2009年开始，云的能力不断增强，云的本质是资源的池化，而这些资源不仅仅包含硬件资源，更包含专业的技术人才，以及核心的技术专利标准等。经过了十来年在规模和成本上的激烈竞争，IAAS资源也在不断的向Serverless的方向演进，底层能力的增强也意味着上层PAAS层和SAAS服务有了更快地向Serverless演进的路径。

如果开源托管产品RDS可以看成是云数据库服务1.0，自研产品如PolarDB和Aurora可以看成是云数据库2.0，那么Serverless将会是云数据库服务的3.0。其中，客户应用跟数据库交互方式的改变(例如，从JDBC/ODBC向Restful API转变)，将会具有重要意义。

从艾瑞2022年初对数据库云管平台的发展趋势预测[9]、以及结合云的趋势和Serverless本身，我们可以对Aurora Severless未来的发展方向做一些大胆的预测：

智能化加持

从re:Invent2021发布的Devops Guru产品上看到，AWS正在智能化场景下进行追赶。内置的智能化引擎对Serverless的场景可以做出更多的精准预测，让“响应式”扩容升级为“响应式兜底，智能化加持”的双引擎驱动。

资源解耦和极致的弹性

共享内存技术、Brust IO能力等会推着Serverless将更多的资源进行解耦，以及进行独立的升降配。

更多的Serverless手段

扩容是最有效直接应对数据库流量的方式，但是有了更多智能化的手段之后，单纯的“扩容”已经有更多选择，自动索引优化、智能调参会是很好的选项。

自动的横向扩展能力

scale out和scale up同样可以应对业务流量的变化，但scale out的复杂程度要远远高于scale out本身，也是个可能的选项。

低成本硬件大规模使用

ACU的单位定义屏蔽了底层资源属性，ARM、x86还是RISC-V已经不是那么重要，标准化归一化的算力能力让更多类型的硬件无缝无感的接入到Serverless当中。

目前，在国产云数据库领域，各大国产厂商也正在加大研发力量。期待未来我们的国产云数据库能在Serverless领域取得更多的成绩，赶超国际一流水平。