论文学习笔记（四）：Serverless Computing: One Step Forward, Two Steps Back

原文链接：Serverless Computing: One Step Forward, Two Steps Back

---

原文提出的背景是，无服务概念逐步兴起，搜索率赶超了“MapReduce”。在这个背景条件下，来自UCBerkeley的学者们为这股热浪浇了一盆凉水。回顾这篇文章之前，先解释一些名词：

• Faas是什么？
  Functions as a service, 指将方法作为服务，是serverless的基础，他比现在流行的微服务的粒度更加细小。 Faas提供了让开发者不必再实时维护服务器的功能，比如现在做一个前后端，用户在网页上上传一个.txt文件，服务器接收到了文件，开发者打开了这个文件，发现是乱码，还需要对文件进行转码。用了Faas框架之后，开发者提前写好转码的代码，服务器收到文件后自动调用代码将文件转成可读的编码。
  还有一个重要特性，就是Faas是事件驱动型架构，意味着没有服务器，没有进程在等待用户命令。比如我们的操作系统就是事件驱动型的，我们点击鼠标发生事件，传给操作系统做出相应的响应。

AWS用户的应用举例

AWS是Amazon云，在当时是第一个开启serverless云服务的公司，同时也是第一大的云公司。
根据AWS的数据，可以将部署在AWS上的应用分为三类：

• 令人尴尬的并行功能
  在一些应用中，每个功能的调用是一个独立的任务并且不用和其他任务交互。
• 编排功能
  例如大规模分析。利用无服务器功能来编排对专有自动伸缩服务的调用。
• 功能组成
  比如这个功能的输出是另一个功能的输入，他们共同依赖于数据流

有人研究过AWS的serverless有状态的注册服务，这个服务的时间是令人惊讶的10分钟（意思是光一个注册就要花费10分钟，延迟太高）。

为什么说今天的无服务太少了？

云提供三个关键的特征：

• 无限制的数据存储
• 无限制的分布式计算能力
• 仅为消费的资源付费，而不是在高峰期买资源（意思是为了高峰期的资源够用，买了资源后一长段时间资源搁置浪费）。
  如今（指2018年）的Faas仅能提供按需付费的功能，对于前两项还是比较吃力的，它严重限制了分布式计算资源的能力。

下面是三个显著的限制（在2018年）：

• 寿命有限：函数在写的时候就必须假设状态不会保留
• I/O瓶颈：众所周知，网络传递信息还是挺慢的，至少比SSD要慢得多（不知道5G时代这样的瓶颈是否依然存在）
• 在缓慢的存储系统上交流：Lambda不能直接进行网络寻址，意味着两个lambda函数需要通过内部的中介服务进行寻址，所以慢。客户端没有粘性，需要维持状态就需要将状态写进存储系统，并在每次调用方法的时候再读出来。
• 没有专业的硬件：今天的FaaS产品只允许用户提供CPU超线程和一些RAM的时间片。专业的硬件至少在几年后才能普及

作者认为这些不足限制了serverless的发挥。
于是根据上述的缺陷，有了下述的推论：

• Faas是数据传输架构：设计之初是想将代码传给数据，而由于种种缺陷成了数据传给代码。
• Faas阻碍了分布式计算：总体的意思就是数据传输太慢了
• Faas阻碍了硬件加速的软件创新：意思是没有定制硬件特殊需求服务，比如机器学习。
• Faas阻碍了开源服务：意思是开源软件无法在Faas上运行，因为开源软件需要人工操作，他们并不是专门为Faas设计的。

未来无服务挑战

• 流体代码和数据放置：让代码适配数据而不是数据适配代码，比如MapReduce，是让数据为中心进行计算
• 异构硬件支持：要提供软硬件协同设计的创新模式
• 长时间可寻址的虚拟代理：这段没看懂。
• 无序编程：意思是代码不是从上到下依次运行的，而是根据传来的数据或者信息进行调用。
• 灵活编程，通用中间表达：意思是每种语言都有自己的堆栈系统，不能去融合每一种语言，应该做的是写一个中间体适应各种语言，然后对中间体进行编译运行。
• 服务级别目标和保证：这是产品运营方面的东西，这里就不翻译了
• 安全性

---

怎么说呢，这篇文章给了现在正火的serverless一盆冷水。由于笔者的水平，对无服务这块并不是很熟悉，无法客观评价这篇文章。但是一些观点还是有建设性意义的，比如intermediate representation(IR)。其中涉及的许多原理我也是一知半解，比如swift语言是不是就是一种无序性编程？我记得swift是根据页面跳转来选择代码的调用，后来又想了想，其基本逻辑依旧是有序的。

努力多学点东西吧，无论是微服务还是无服务，现在都是火的很，只能不断学习才能跟上时代啊。