编者按
本文整顿自 Johann Schleier-Smith 在 ServerlessDays China 的演讲，是来自加州大学伯克利分校计算机科学 Riselab 团队的研究成果。
ServerlessDays 是由寰球 Serverless 开发者发动的国内技术会议。2020 年由腾讯云 Serverless 团队引入中国，并承办了首届 ServerlessDays China 会议。会上 Johann Schleier-Smith 代表伯克利计算机科学 Riselab 实验室进行了主题发言。
本次演讲次要分为四个局部：首先论述 UC Berkeley 怎么来定义 Serverless，之后会分享一些近期的研究成果和停顿，最初提出对云计算将来的一些预测和构想。
一、定义 Serverless
大家对于 Function as a Service 函数即服务应该都比拟相熟，例如腾讯的 SCF，Azure Functions 和 AWS Lambda 等等，这些服务中，你能够将一段代码（通常是无状态的利用代码）上传到云端，之后基于 API 调用或者配置触发器等形式，随时在云端执行你上传的代码。很棒的一点是，FaaS 服务是按需付费的，依据执行工夫和调用次数计费。
那么对于 Backend as a Service 后端即服务，置信大家也都据说过，但并不理解 BaaS 的精确含意。其中的一个重要起因是，BaaS 这个词对于不同的人来说含意也不同，对咱们来说，BaaS 是和 FaaS 绝对应的概念，其中“即服务”指的是不以“服务器”的形式来提供服务。例如腾讯云的 COS 对象存储服务，AWS DynamoDB 等，都算做是后端即服务。
从定义能够看出，FaaS 和 BaaS 的特点互相响应和紧密结合，例如 FaaS 是无状态的，而 BaaS 是有状态的；FaaS 基本上能够反对所有运行时的代码，而 BaaS 对编程模型的限度更严格，或者简直不波及编程模型，例如对象存储服务。但能够看到，单方的相同点在于 弹性伸缩和按需付费。
能够认为 Serverless Computing 是一种用云的简化形式。咱们能够用上面这张图来阐明。从最底下开始，在最底层你须要硬件，要有 CPU，网络，存储，和一些加速器（如 GPU 或者机器学习的加速器），在这之上云通过虚拟化技术提供了形象层，硬件服务器被分隔成了多个相互隔离的虚拟机 / 虚构公有网络，这一层的服务状态和底层架构是相似的，对于利用层面来说应用起来也有一些简单，所以呈现了 Serverless 的概念，在这一层中 Serverless 化的服务让调用基础设施变得更加简略。
接下来咱们能够看下，为什么说传统的服务器托管比较复杂呢？次要是因为有太多方面须要思考，即便对于一个简略的利用而言，你也要思考上面这些方面：可用性，多地区部署，扩缩容，监控告警和排障，系统升级和安全漏洞，迁徙策略等等。
有个十分经典的案例能够阐明传统和 Serverless 架构的区别。在这个例子中，心愿实现非常简单的性能：上传图片，对图片做压缩后，提取并存储图片的点赞和门路等信息到数据库等。如果你要用服务器来做，则须要十分长的解决和搭建流程；然而如果用 Serverless 架构来做，则只须要负责 FaaS 的代码解决逻辑即可。然而这里要强调的是，该利用的实现不只须要 FaaS 的解决，也同样须要 BaaS 服务的配合，能力实现残缺的 Serverless 架构。
总结起来，在 UC Berkeley 咱们认为 Serverless 须要满足上面三个要害个性：
- 暗藏了服务器 的概念。尽管服务器仍然存在，但开发者不感知，也 无需针对服务器进行繁琐开发和运维 操作
- 提供了一种 按需付费 的计费模型，并且在 资源闲暇时不免费
- 提供极致的 弹性伸缩 能力，从而让资源的提供完满适配业务需要
如果举例说明，能够将传统服务器和 Serverless 用租车和打车来做比照。（不开展）
云计算的进化历程能够从资源的调配和免费模型中看出，在传统的硬件时代，须要预调配物理资源来承载业务；而在服务器时代，则须要通过粒度较粗的服务器实例来进行扩缩容和计费，用于承载业务；在 Serverless 时代，能力真正做到极致弹性和按需付费。
因而，在 Berkeley 咱们认为 Serverless 是云计算的下一个阶段，不仅因为弹性伸缩和按需付费的特点，还有个重要起因是，咱们认为 Serverless 扭转了人和电脑合作的形式。
在云计算的第一阶段，极大的简化了系统管理员的职责，人们能够通过 API 的形式取得服务器，无需自建机房。这种获取资源的形式非常简略，开发者都能够轻易的实现资源的购买和配置。而在这一阶段，云服务商则负责管理并保障这些资源的稳定性。
在云计算的第二阶段，在运维 / 管理员之外，进一步简化了开发者的职责。开发者不须要关怀简单的资源分配 / 运维逻辑，只须要写好原生业务逻辑，上传到云端后就能够执行，无需放心扩缩容的问题。而云服务商则承当了系统管理员和资源管理的角色。在这阶段，云计算对开发者编程模式的扭转，就如同十年前的第一阶段中，云计算对系统管理员的职责转变一样，是非常重大的转折。这一转变也极大的激励了开发者，拓展了他们的能力边界，开发者能够专一于业务实现，无需放心底层资源的运维。
二、Serverless 研究成果和亮点
在第二局部，我想分享一些 Berkeley 最近的研究成果。咱们发现，Serverless 中 FaaS 局部很难解决所有问题，因为函数即服务从平台层面有诸多限度：
首先是运行工夫的限度，以后各云平台对于 FaaS 的运行工夫都有 10-15 分钟的限度，这种限度影响了许多场景的实现，尤其是一些强状态依赖的场景，例如长时间放弃数据库连贯的状况等。
此外，FaaS 平台只能反对短暂的有状态性（Ephemeral State），没有磁盘能够存储或者永恒保留状态信息。
第三点，以后不能间接和函数服务进行网络通信，函数即服务能够提供外访能力，但对于入流量的反对不够敌对，例如在你开发的利用中，获取到函数中的一些数据会比拟艰难，从而可能会影响软件本来的开发方式，须要做额定的适配。
最初一个限度是在硬件层面的，例如一个机器学习方面的利用利用了 GPU 硬件，在以后的 Serverless 计算层面是难以提供 Serverless GPU 计算资源的。
当新的技术趋势呈现时，学术界往往十分沉闷，从近几年的对 Serverless 方向钻研的论文数就能够看出。如下图所示，最近几年来，Serverless 方向的论文数每年都在翻倍增长，在 2020 年，已发表 + 打算发表的论文将持续翻倍，达到近 300 篇。
在分享一些具体研究成果之前，我想先简略介绍下几种不同的 Serverless 钻研方向：
- 具体利用的形象：选取一个场景，将其 Serverless 化，不会做太多通用层面的形象。例如针对大数据检索并生成报表等，只有用 Serverless 解决该场景下的问题即可。
- 通用的形象：我认为这个层面的钻研最有意思，并且本人也在做这方面的钻研。即通过满足一些条件，即可让任意业务适配 Serverless 架构。实质上说，这就波及到怎么针对分布式系统进行开发模式的简化。
- 实现层面：当函数即服务刚推出的时候，在效率等方面有很多待晋升的中央。目前尽管曾经有一些改善，但从学术层面仍然有十分多可深刻优化的中央，例如 FaaS 平台将一直谋求更低的提早，更好地状态共享，租户隔离，极致的弹性扩大等方面。
接下来我将分享 Berkeley 近期在以下五个方面的研究成果，别离是 Serverless 机器学习，以及用于反对机器学习的 GPU 相干的内核即服务，之后会分享状态性相干的云函数文件系统和 Starburst，最初会通过瞻望 Serverless 数据中心来收尾。
第一个是机器学习方面的钻研，以后其实在云端曾经提供了利用层面的 Serverless 机器学习服务，例如 AWS 的 Sagemaker 服务，用户只有输出数据，设置好模型，Sagemaker 就会帮忙做训练，并依照模型的训练工夫来计费。但这个服务仅是针对机器学习这个特定场景的，并不具备普适性，此外，对于模型有定制化需要，或者训练步骤有改变场景（例如 Berkeley 的一些新的训练算法），这个服务并不能齐全满足需要。
那么是否能够推出更加通用的机器学习解决方案呢？例如把数据或者代码作为函数的输出，并将其运行在 AWS Lambda 函数服务及 Cirrus 上进行机器学习训练。因而团队开发了 Cirrus 的机器学习库，能够让用户不便的在 Lambda 上端到端地进行机器学习训练，满足定制化需要。
Cirrus 团队在 FaaS 平台上做了很多尝试，也遇到了十分多平台的限度，例如内存过小，上传的代码包大小有限度，不反对 P2P (peer to peer) 点对点传输，没有疾速的存储介质，实例的生命周期无限，会被回收和重启等。
然而依据左边的试验后果能够看出，在越短的执行工夫内，Cirrus 的性能体现越好，甚至优于其余几种机器学习技术。因而你能够依据本人的训练模型和需要抉择要不要应用 Cirrus 作为 Serverless 机器学习的训练计划。
参考文献：
- ucbrise/cirrus
- [Cirrus: a Serverless Framework for End-to-end ML Workflows]https://people.eecs.berkeley….
第二个研究课题是对于机器学习作为容器即服务 (Kernel as a Service) 的。大家都晓得以后 FaaS 次要运行在 CPU 的硬件上，而在机器学习畛域，GPU 针对许多算法和工作流提供了十分重要的减速作用。因而 Berkeley 团队心愿提供一种计划，将 GPU 和 Serverless 计算更好地联合在一起。
因为老本 / 价格起因，目前商业化的云函数服务不提供 GPU 函数。因为 GPU 服务器价格昂扬，须要针对机器利用率做进一步优化后能力真正进行商业化应用。因而，咱们提出了 KaaS 容器即服务的概念，和 FaaS 的 Node.js 和 Python 等运行时一样，只不过 KaaS 中运行时反对的是面向 GPU 的语言如 CUDA 或 OpenCL。但以后钻研的挑战在于，是否能够齐全通过纯 GPU 语言来编写 KaaS 服务，齐全解脱对 CPU 代码的依赖呢？
下图能够进一步解释这个理念，一种形式是在函数平台中同时提供 CPU 和 GPU 的反对，即每个函数的底层架构中既有 CPU、内存卡，也有 GPU 加速器。
然而有挑战的中央在于，是否能够像下图一样，提供一个 GPU-only 的纯 GPU 底层来运行函数呢？这样能够彻底辨别 CPU/ 内存型函数和 GPU 型函数，因为以后从通信模式上还比拟难将 CPU 和 GPU 从硬件上彻底离开，这将是钻研中比拟大的一个挑战。
参考文献：PyPlover: A System for GPU-enabled Serverless Instances
第三个研究课题次要是 Serverless 文件系统 —— 状态性方面的优化，也是十分有价值的一个方向。见下篇：《权威指南：Serverless 将来十年倒退解读 — 伯克利分校实验室分享（下）》
One More Thing
立刻体验腾讯云 Serverless Demo，支付 Serverless 新用户礼包 ???? serverless/start
欢送拜访：Serverless 中文网！