共计 6031 个字符，预计需要花费 16 分钟才能阅读完成。
简介：看到现在 Serverless 在云计算行业喷薄欲出的态势，像极了《星星之火，能够燎原》中的形容：尽管不能预测将来的倒退和变动，但对于云计算来说这是个绝对确定的方向。本文从产业界和学术界登程，聊聊关系型数据库和 serverless 技术之间的林林总总。
它是站在海岸遥望海中曾经看得见桅杆尖头了的一只航船，它是立于平地之巅远看西方已见光芒四射喷薄欲出的一轮朝日，它是躁动于母腹中的快要成熟了的一个婴儿。
— 星星之火，能够燎原
一、对于 Serverless
看到现在 Serverless 在云计算行业喷薄欲出的态势，像极了《星星之火，能够燎原》中的形容：尽管不能预测将来的倒退和变动，但对于云计算来说这是个绝对确定的方向。
从 Google Trends 的 Serverless 关键字的趋势能够看到，对于 Serverless 的搜素始终居高不下，并且在将来的一段时间内也会放弃相当的热度。从 2015 年开始，以 AWS 为代表的国内外云计算大厂也在一直的布局 Serverless 相干的产品，AWS Lambda、Aliyun FAAS，数据库畛域的 Aurora Serverless、RedShift Serverless、Azure SQL Database 等。
serverless1.png
学术界对 Serverless 的钻研热度也不亚于工业界对商业化计划的谋求，文末列出了一些相干文章作为参考。对于云计算往 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 的问题。而联合 AWS 之后在 Serverless 方向上推出的各种服务上能够看出，这篇文章在事实上贴合了 AWS 在 Serverless 上的演进打算，这个前面会有具体分析。Serverless 自身的技术难度，这篇文章列举了多项内容，这里不做赘述，能够具体读一下文章。
对于 Serverless 的技术实现 [3] 给出了一个可行的零碎实现形式，当然还是以 FAAS 为背景。其中提到 Serverless 关键技术门路包含：
对立的规范运行环境反对多语言的运行时对立治理
轻量级 / 蝇量级平安容器（在 [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 的难点到底在哪里？
数据库做 Serverless 有若干难点[4]，总结如下：
Serverless 没有内置的长久化存储，须要依赖远端存储，这就会导致在延时上较高；
客户端是基于连贯的形式拜访数据库，在客户端往往会保护连接池的形式供给用拜访，而函数计算往往具备飘忽不定的网络地址，与数据库传统的 IP+User+password 鉴权的形式迥异；
很多高性能的数据库应用共享内存技术，而 FAAS 自身不具备共享内存的能力，会使得计算和数据库之前的资源动静扩大能力不统一
serverless2.png
其中尤其要留神的是第 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 的能力目前还是看重这个理念，各个厂商也在以本人的产品状态去向贴近这个理念，至于说一统行业标准的产品化计划，还为时过早，这一畛域大有可为。
另外，AWS 始终未在 RDS 下来实现 Serverless 能力。据外部人士走漏，RDS MySQL 的内核研发人数远远少于 Aurora 的内核研发人数，次要岗位还是以 DBA 为主。能够看出，在开源托管产品上要做到 Serverless 的能力，要比在云原生自研产品上的难度大很多。联合 AWS 自身产品策略，开源托管 RDS 的 Serverless 化咱们或者永远也等不到那一天。
四、将来可期
从 2009 年开始，云的能力一直加强，云的实质是资源的池化，而这些资源不仅仅蕴含硬件资源，更蕴含业余的技术人才、以及外围的技术专利规范等。通过了十来年在规模和老本上的强烈竞争，IAAS 资源也在一直的向 Serverless 的方向演进，以阿里云自身为例，包含弹性的存储 AutoPL、弹性的容器 ECI、Serverless 服务引擎 SAE。底层能力的加强也意味着下层 PAAS 层和 SAAS 服务有了更快的向 Serverless 演进的门路，阿里云数据库就是其中受害的一方 PAAS。
从艾瑞 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 当中。
阿里云 RDS MySQL 也在 4 月份推出了 Serverless 版本，咱们将在后续的文章中做重点的介绍，咱们会以一个规范的网站利用（前端页面 +API 服务器 + 数据库）为样板，介绍如何在 FAAS+BAAS 的架构下一步步做全栈 Serverless 的革新，真正做到“0”服务器。
参考文献
2016: “Emerging Technology Analysis: Serverless Computing and Function Platform as a Service”, Gartner, Tech.
2017: “Serverless Computing: Current Trends and Open Problems”, IBM Research
2017: “Serverless Computing:Design, Implementation, and Performance”，IEEE 2017 ICDCSW
2018: “Serverless Computing: One Step Forward, Two Steps Back “, CIDR 2019
2019: “Cloud Programming Simplified: A Berkeley View on Serverless Computing”, EECS 2019
2020: “Serverless Applications: Why, When, and How?”, IEEE Software
2009: “Above the Clouds: A Berkeley View of Cloud Computing”，EECS 2009
1970: “A relational model of data for large shared data banks”, Commun. ACM 1970
2022: https://www.iresearch.com.cn/… 艾瑞征询
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载。
