谈谈关系型数据库与Serverless

凌云时刻

看到如今 Serverless 在云计算行业喷薄欲出的态势，像极了《星星之火，可以燎原》中的描述：“虽然不能预测未来的发展和变化，但对于云计算来说这是个相对确定的方向。”

关于 Serverless

从 Google Trends 的 Serverless 关键字的趋势可以看到，对于 Serverless 的搜索一直居高不下，并且在未来的一段时间内也会保持相当的热度。从 2015 年开始，以 AWS 为代表的国外云计算大厂也在不断地布局 Serverless 相关的产品，AWS Lambda、Aliyun FAAS，以及数据库领域的 Aurora Serverless、RedShift Serverless、Azure SQL Database 等。

学术界对 Serverless 的研究热度也不亚于工业界对商业化方案的追求，文末列出了一些相关文章作为参考[1][2]。

对于云计算往 Serverless 演进的趋势，学术界也经历过一些质疑，2018 年的文章“Serverless Computing: One Step Forward, Two Steps Back”[3] 曾经对 Serverless 的发展给现在 IT 基础设施带来的冲击表示过担忧，但 2019 年同一拨人在这个方向上又表现出了支持和乐观的态度。从 Serverless 领域被引用次数较多的论文上看到，主流科研机构对 Serverless 的方向研究上趋于一致，研究重点也慢慢从“why”转变为“how”[6]。

何为 Serverless？为什么 Severless 是个趋势？“Cloud Programming Simplified: A Berkeley View on Serverless Computing”[5] 这篇文章作为代表做了一个比较全面的分析和预测。同样是 Berkeley 在 2009 年发表的另一篇文章“Above the Clouds: A Berkeley View of Cloud Computing”[7] 则预测了云计算作为 IAAS 基础设施的观点。该文章延续了之前的风格，分析了现状和难点，预测了云计算 2.0 的形态 Serverless 作为下一代基础设施，也定义了 Serverless 的主要三个特征：

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

• 自动弹性伸缩：代码的执行不再需要手动分配资源，不需要为服务的运行指定需要的资源（比如使用几台机器、多大的带宽、多大的磁盘等），只需要提供一份代码，剩下的交由 Serverless 平台去处理就行了。当前阶段的实现平台分配资源时还需要用户方提供一些策略，例如单个实例的规格和最大并发数，单实例的最大 CPU 使用率。理想的情况是通过某些机器学习算法来进行完全自动的自适应分配。

• 按使用量计费：Serverless 按照服务的使用量（调用次数、时长等）计费，而不是像传统的 Serverful 服务那样，按照使用的资源（ECS 实例、VM 的规格等）计费。

值得一提的是 [5] 这篇文章有众多云计算厂商的背书，包括 AWS、Micorsoft、Google、Alibaba 等，同时文章也直接以 AWS Lambda 服务作为样板去分析 Serverless 的问题。Serverless 本身的技术难度，这篇文章罗列了多项内容，这里不做赘述，可以具体读一下文章。

关于 Serverless 的技术实现 [3] 给出了一个可行的系统实现方式，当然还是以 FAAS 为背景。其中提到 Serverless 关键技术路径包括：

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

2. 轻量级/蝇量级安全容器（在 [4] 中额外提到安全和隔离的重要性）；

3. 冷热容器池设计做极致的多租户复用能力；

4. 高效的函数调度能力；

其中，函数计算的实现方式，与数据库 Serverless 息息相关。

数据库的 Serverless

数据库品类繁多，关系型数据库自 1979 年 E. F. Codd 对于关系模型的描述 [7] 开始，后来者大多只是模仿，而尚未在用户接受度和规模上有超越。

数据库不仅仅是一个“stateful”的应用，而且是一个“state-heavy”的应用。数据库是 Serverless 最不友好的应用之一，包括云原生基础设施 kubernates 对于 stateful 应用的支持，也是等到 StatefulSet 和 operator 之后才有一个比较好的解决方案。而在这之前，数据库都是作为 Serverless 对状态做解耦和状态下沉的工具，也是全栈 Serverless 解决方案中最难攻坚的最后一个堡垒。

对于 Serverless 的定义，文章给出来一个公式：Serverless = FAAS+ BAAS。将 FAAS（Functions as a Service）定义为事件、API、消息驱动的计算层；将 BAAS（Backends as a Service ）定义为类似数据库、消息队列等后端服务。

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

数据库 Serverless 的难点究竟在哪里？可以看参考文章 [4]，总结如下：

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

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

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

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

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

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

3. 服务器访问鉴权通过 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 的理念上做了大胆的创新，做了几件事情：

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

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

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

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

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

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

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

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

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

未来可期

从 2009 年开始，云的能力不断增强，云的本质是资源的池化，而这些资源不仅仅包含硬件资源，更包含专业的技术人才以及核心的技术专利标准等。经过了十来年在规模和成本上的激烈竞争，IAAS 资源也在不断向 Serverless 的方向演进，以阿里云本身为例，包括弹性的存储 AutoPL、弹性的容器 ECI、Serverless 服务引擎 SAE。底层能力的增强也意味着上层 PAAS 层和 SAAS 服务有了更快向 Serverless 演进的路径，阿里云数据库就是其中受益的一方 PAAS。

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

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

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

2. 资源解耦和极致的弹性：共享内存技术、Brust IO 能力等会推着 Serverless 将更多的资源进行解耦，以及进行独立的升降配；

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

4. 自动的横向扩展能力：scale out 和 scale up 同样可以应对业务流量的变化，但 scale out 的复杂程度要远远高于 scale out 本身，也是个可能的选项；

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

阿里云 RDS MySQL 也在 2022 年 4 月份推出了 Serverless 版本，我们将在后续的文章中做重点的介绍，我们会以一个标准的网站应用（前端页面+API 服务器+数据库）为样板，介绍如何在 FAAS+BAAS 的架构下一步步做全栈 Serverless 的改造，真正做到“0”服务器。

 作者介绍：

韦仁忠，当前主要负责 RDS MySQL 管控产品建设，欢迎有志之士加盟 RDS 产品部。

邮箱：[e-mail]

 参考文献

1. 2016: "Emerging Technology Analysis: Serverless Computing and Function Platform as a Service", Gartner, Tech.

2. 2017: "Serverless Computing: Current Trends and Open Problems", IBM Research 

3. 2017: "Serverless Computing:Design, Implementation, and Performance"，IEEE 2017 ICDCSW

4. 2018: "Serverless Computing: One Step Forward, Two Steps Back ", CIDR 2019

5. 2019: "Cloud Programming Simplified: A Berkeley View on Serverless Computing", EECS 2019

6. 2020: "Serverless Applications: Why, When, and How?", IEEE Software

7. 2009: "Above the Clouds: A Berkeley View of Cloud Computing"， EECS 2009

8. 1970: "A relational model of data for large shared data banks", Commun. ACM 1970

9. 2022: https://www.iresearch.com.cn/Detail/report?id=3922&isfree=0 艾瑞咨询

你可能还想看关注我们欢迎关注加星标✨每日推送不错过