关于腾讯云:权威指南Serverless-未来十年发展解读-伯克利分校实验室分享上

编者按

本文整顿自 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 须要满足上面三个要害个性：

1. 暗藏了服务器 的概念。尽管服务器仍然存在，但开发者不感知，也 无需针对服务器进行繁琐开发和运维 操作
2. 提供了一种 按需付费 的计费模型，并且在 资源闲暇时不免费
3. 提供极致的 弹性伸缩 能力，从而让资源的提供完满适配业务需要

如果举例说明，能够将传统服务器和 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 钻研方向：

1. 具体利用的形象：选取一个场景，将其 Serverless 化，不会做太多通用层面的形象。例如针对大数据检索并生成报表等，只有用 Serverless 解决该场景下的问题即可。
2. 通用的形象：我认为这个层面的钻研最有意思，并且本人也在做这方面的钻研。即通过满足一些条件，即可让任意业务适配 Serverless 架构。实质上说，这就波及到怎么针对分布式系统进行开发模式的简化。
3. 实现层面：当函数即服务刚推出的时候，在效率等方面有很多待晋升的中央。目前尽管曾经有一些改善，但从学术层面仍然有十分多可深刻优化的中央，例如 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 中文网！