Serverless over Storage

什么是 Serverless？

从英文的字面意思，跟 Serverful 对比，看起来好像是无服务器？但这显然不可能，毕竟无论如何，任何的程序最终都要在机器上执行。

要想理解 Serverless，我们有必要回顾一下我们通常的 Serverful 服务运行方式。

从 Serverful 到 Serverless 的演变

物理机的使用方式似乎从来都没有变化，无论是 10 年前，还是现在。典型的流程就是硬件采购、拆箱、上电、做 Raid、插网线、调整交换机、做全面的配置检查，顺便还得检查一些内存、硬盘、固件的质量等等，因为说不定跑两天就挂了。整个环境上线，就是体力活。

虚拟化

感受到了痛苦，就会促使工程师们去改变。

已经辛苦地准备了硬件，当一个开发小哥需要一台机器的时候，作为 IT 管理人员，难道还要再次重复这个过程？

可以说虚拟化解放了 IT 管理者，通过在一台物理机上运行更多的虚拟机，提升了资源利用率以达到更好的财务收益之外，虚拟化还给部署以及运行一台 “机器” 提供了极大的便利。

通过操作系统虚拟化一套硬件，再结合虚拟机模板镜像的机制，意味着在物理机上创建和移动虚拟机也只是分分钟的事情而已。

以往的机器上线繁重、重复的体力工作消失殆尽。

云

单机的虚拟化无法满足大规模的场景，包括对调度，网络虚拟化的需求等等。此时，云横空出世，你既可以选择公有云，也可以选择自己搭建私有云，如 OpenStack。

甚至你都不需要关心底层的硬件，只要是通用的架构即可，操作系统、网络、存储等均可以自动化安装、扩展出来。

然而，即使在云时代，应用软件的运行方式也没有变化，无非是软件看到的是一个虚拟的硬件环境而已。对于使用者而言，不同的一点只是为软件准备基础环境的过程变快了。

容器化

尽管虚拟化充分利用了资源，极大的提高了便利性，但技术发展的车轮滚滚向前，工程师们总是得陇望蜀。虚拟化依旧存在比较 “重” 的问题，镜像太大，多个虚拟机基本都包含重复的操作系统，物理机上无法运行过多的虚拟机。

容器化，尤其是 2017 年以来 Kubernetes 的流行，又一次带来了改变。容器只是一个轻量级的进程，而软件提供者只要维护一个 Dockerfile , 生成一个小得多的镜像，在容器平台部署即可。应用的上线不再关心依赖、冲突，以及诸如 “我这里运行没问题，肯定是你的环境问题” 等等困扰。

Serverless，更容易理解的一个名字是 functions-as-a-service，我想这样起名的一个初衷是让你不再关心服务器，也不需要考虑他们，只要执行你的代码就好。

设想一下即使是在容器化加持的情况下，应用开发者依然要关注诸如 RestAPI 框架如何搭建、工作流怎么处理、压力来了怎么进行负载均衡、消息中间件如何处理等问题，有可能还要关心安全升级、漏洞扫描这些与业务逻辑关联不大的琐事。

2019，UC 伯克利大学发表了一篇“ Cloud Programming Simplified: A Berkeley View on Serverless Computing”的论文(https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf)，论文中有一个很形象的比喻，描述如下：

In the cloud context, serverful computing is like programming in low-level assembly language whereas serverless computing is like programming in a higher-level language such as Python. An assembly language programmer computing a simple expression such as c = a + b must select one or more registers to use, load the values into those registers, perform the arithmetic, and then store the result. This mirrors several of the steps of serverful cloud programming, where one first provisions resources or identifies available ones, then loads those resources with necessary code and data, performs the computation, returns or stores the results, and eventually manages resource release. The aim and opportunity in serverless computing is to give cloud programmers benefits similar to those in the transition to high-level programming languages.

那么总结起来什么是 Serverless 呢？其实就是你只需要关心的业务逻辑，所有其他的全部交给外围所运行的平台工具等去处理。

实现方式

各大公有云有各自的实现方式，例如 AWS Lambda, 阿里的 BatchCompute, Azure Function 等等， 但每家都有不同的使用方式，存在 Lock-in 的风险。那么如果在私有环境上实现，有什么选择呢？

Fn project

Fn project 是 Oracle 开源的一个项目，看起来是非常简单直接的，有一个 Docker 即可运行起来。问题就是不够活跃，半年内似乎都没有新的 commit。

Kubeless

听起来最正统的名字，是由 Bitnami 贡献的一个项目，基于原生的 Kubernetes ，通过自定义资源 CRD 的方式来实现，但由于受到 Knative 的影响，前途不太明朗，连创始人都建议关闭掉这个项目。

由 Platform9 贡献的一个项目，它既可以利用到 Kubernetes 的丰富功能，也可以在需要时候获得更好的性能，例如冷启动。这个也是笔者在 Fn project 之后跑起来的第二个项目。

Fission

Knative

名门出品，集大成者。Google 开源的项目，目前参与的公司主要是 Google、Pivotal、IBM、RedHat, 基于 Kubernetes 以及 Istio。

Serverless Over 存储

阿里王坚博士的《在线》里有一句话说的特别好，“需求才是竞争力”，想到，做到；做到，用到。在与 AI 的同仁交流过程中，压榨整个工作流过程中的每一点性能，都是对整个结果的很大提升，这不禁促使我们思考如何才能更加高效的存储和处理数据。

先不提 Computable Storage , 以 AI 的场景为例，AI 作为一种新的数据处理技术，它涵盖了采集、准备、训练和推理四个阶段，每个阶段都伴随着数据的流动以及处理。

数据采集阶段：数据从不同来源聚拢并存储起来，数据的大小和格式存在各种差异，数据类型往往是文件形式的非结构化数据。

数据准备阶段：由于数据的大小和格式不一样，为了便于进行 AI 模型训练，必须改为统一格式，以便后续训练阶段使用，这一过程要对不同格式和尺寸的数据进行规范化处理。

训练阶段：AI 训练过程的工作负载非常密集，往往需要高性能的 GPU 或者加速器等来执行一系列的数学函数，对资源要求非常高，在做特定训练时，AI 训练所需的时间更加取决于所部署的存储的性能。

推理阶段：推理过程是检验人工智能的阶段。推理基础设施根据不同的场景，所需配置的处理器、内存、存储不尽相同。

通常的数据准备阶段，都是利用 Hadoop 等批量处理工具对数据进行清洗，在 Hadoop 计算节点与分布式数据存储节点分离的情况，一个典型的过程就是，读出、计算、写入，意味着数据要流出存储集群，再流入存储集群，能否尽量避免数据的流动，让计算离存储更近一些呢？

基于 Serverless 框架，我们在 YRCloudFile 的基础上，可以运行更加实用的功能，例如数据复制，数据压缩，数据解压等等更适合发生在存储端的操作。

以下示例演示了向 Serverless 框架提交一个数据拷贝的请求（函数），让这个请求在后端存储自动执行，提交请求者无需关心后端数据的处理过程。

利用对应的框架创建 Function 以及 Trigger 之后，只要访问对应的 URL 即可完成相应的动作。

如果你的动作够快，进入到对应的 Function 容器内，你会看到里面存在的对应的目录对存储的引用。

这只是一个最简单的数据拷贝例子，我们可以编写更复杂的数据处理函数（Function），并直接提交到 Serverless 框架上，由后端的数据存储去针对复杂操作完成相应优化和处理。工程师们可以快速地实现用户需要的功能，甚至可以完成工作流你 Pipeline，从而赋予应用更多可能。