FaaS，未来的后端服务开发之道

说 FaaS 先要说说 PaaS

平台即服务（Platform as a Service）是一种云计算服务，提供运算平台与解决方案堆栈即服务。在云计算的典型层级中，平台即服务层介于软件即服务与基础设施即服务之间。 平台即服务提供用户能将云基础设施部署与创建至客户端，或者借此获得使用编程语言、程序库与服务。用户不需要管理与控制云基础设施，包含网络、服务器、操作系统或存储，但需要控制上层的应用程序部署与应用托管的环境。

引用自维基百科

简单来说，PaaS 就是把计算能力放在线上，你只管写代码就行了，目的也是为了减少后端维护的成本，让开发者更关注到开发本身。国内有 Sina App Engine，国外有 Heroku、Google App Engine、Amazon Web Services，但是这类服务被真正用来做产品的并不多，大多是当作开发的试验田跑一下，而且跑起来的成本比独立部署个服务器也差不多，你要理解很多服务的相关性，应用运行时还有提供各种服务的桥接，就造成你需要去理解一大堆东西才能把他们五花大绑到一起，所以这类服务并没有成为真正的主流，更多的是还是用原生的计算能力，比如 Amazone EC2、AWS 这类 IaaS 平台，国内的阿里云、UCloud 等。

PaaS 有不少缺点。

1、对计算能力不可掌控

PaaS 将自己的运行时封装成了一个黑盒子，你要用他你就要基于这些黑盒子的约束和条件去自行判断，需要了解每个模块或者函数的可用性和限制是什么，才能更好的开发，为了避免应用有太高的权限造成安全问题，服务商往往的做法是裁剪，将限制的能力来提供给你，那么如果你要开发一个应用，本地能用，部署了可能会有各种兼容问题。

一个完整的应用，在基于 PaaS 去开发的时候，势必会有服务的依赖，对于这些服务的依赖，你也是没有掌控能力的，你只能基于给出的环境变量是去配置，但是往往在复杂应用中，对于服务的依赖非常深入，可能会有比较深入的使用和调优，这个只能束手无策。

2、线上开发调试模型复杂

一个完整的应用就是一个功能集合，开发调试起来是很麻烦的，想象一下如果一个很庞大的网站，有一大堆的功能，你依赖可能十几个甚至二十几个服务，跑在你不太知道的黑盒子，你的调试该多麻烦。如果是你自己的环境，你可以随意的开启 DEBUG 参数、去查看系统调用栈、去看硬件参数、去看系统优化参数、去分析运行时的细小问题、而在 PaaS 你能做的仅仅是通过服务商提供的一个后台来做一些简单的查看，日志的分析。这个决定了 PaaS 不适合一个有规模的产品去使用。

FaaS - 函数即服务

FaaS 最终目的和 PaaS 类似，让开发者关注在开发本身，服务由服务商提供。那 FaaS （Function as a Service）是什么呢？我为什么觉得它是未来开发的一个趋势。现在 FaaS 的说法还不太一致，但是可以明确的是** FaaS 是 PaaS 能力的一种缩放，缩放到 Function 级别**。FaaS 可以将函数作为一个线上服务、远程计算服务，可以通过 API 执行、通过邮件执行、通过 Iot 执行，通过队列执行。你只需要写统一的函数就行了。FaaS 的入口是事件，下面是 AWS Lambda 的事件流图。

我认为 FaaS 有以下几个特点：

1、函数粒度小易于调试

对于 FaaS 来说，你要写的就是一个个函数，它就是一个功能。你要做的只是写下如下这样的函数，然后再用配置文件告诉服务器如何让他运行，就完事了，你的所有工作都在这个函数内完成。而函数本身只需要负责处理输入和输出。（输入和输出是基于事件而不同的。）

在 FaaS 中函数的执行是无状态的，函数运行时本身是封装在一个容器内，执行完后所有的的状态都会被销毁（当然为了优化，可能会缓存一段时间），但是最终不要期望通过有状态的方式来运行函数，这是对于函数本身的限制。试想只需要定义好输入，就能来调试函数了，测试来说会非常方便，而 PaaS 是一个复杂的合集，你的调试的方便性由你的写法决定。

2、函数可配置性

每个函数都是一个功能，这个功能如何执行，依赖是什么，是可以通过配置文件来完的成，如果一个函数可配置如何执行，那么就可以让他达到共享的目的。试想一下，你写了一个视频处理的功能，传入的是一个视频地址或者URL，传出的是一个 GIF，那么这个函数你只需要先写好功能，然后用配置文件定义如何运行，如果这是个 API 服务，那么定义出来 HTTP 请求什么路径，什么方法来实现它；如果他需要基于队列去执行，那我只需要定义用什么队列来执行。

这是一个通过队列读取 S3 的 ZIP 文件解压缩成 PNG 并上传 S3 的例子，源代码可以点原文看

对于 AWS Lambda 来说，可以抽象为以下配置（这是一个基于 AWS Lambda 的一个框架的配置）。正是这种机制，可以真正的实现函数级别的共享。

3、初始化非常容易

如果要写一个简单的 API 服务，就写一个函数就够了，省去了以前去折腾框架，弄路由、搞一大堆配置，这还不够简单么。

4、FaaS 不确定的缺点：基础和 PaaS 是一致的

如果真算缺点，就是和 PaaS 是类似的：FaaS 对资源的掌控是不够的。但是，PaaS 的缺点导致掌控性是一个较大的问题；而 FaaS 本身函数运行是比较独立的，所有的成本都涵盖在一个函数内，复杂性就大大降低。

还有一个缺点，如果开发一个复杂的应用，函数之间的调用和管理是一个棘手的问题，现在已经有框架在着手解决这些问题，可以看下面相关资源的推荐。

相关资源

现在已经有不少知名服务商提供此类服务，大家的实现各不相同，但是思路是一致的。比如最著名的 AWS Lambda、Azure Functions、Google Cloud Functions、IBM OpenWhisk。

如果觉得平台本身复杂性略高，可以通过以下几个框架去玩：APEX、Serverless 等

作者：hfcorriez
链接：https://www.jianshu.com/p/6e86c42f85bd
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。