文章首发于微信公众号【我的小碗汤】，关注我，了解更多资讯

大家好，我是小碗汤，今天分享一篇PaaS vs FaaS的对比选择，欢迎兄弟们留言讨论~

我们都知道微服务是分布式进程，必须独立发布、部署和扩展。乍一看，平台即服务(PaaS)和函数即服务(FaaS)，又称无服务器。这两种云计算模型也能够在软件开发过程中，提供非常短的交付时间[1]，从而促进创新和持续研究[2]。

然而，当深入研究它们的技术细节时，会很快意识到它们并不总是适用在相同的场景。

PaaS

Platform-as-a-Service(平台即服务)是一种云模型，你提供源代码，平台将打包、发布、供给、部署、运行、监控和扩缩微服务。我能想到的最好的例子是Cloud Foundry[3]， Heroku[4]和谷歌 App Engine[5]。

你的应用程序在 PaaS 上至少有一个实例在运行。当需要通过SSE (Server-Sent-Events)、Websockets或RSocket[6]实现通知推送时，这很方便。还有很多其他的好处，例如：及时处理传入的请求，在内存中保存数据(也称为进程内数据缓存)，实现断路器模式[7]处理部分故障，或者利用连接池来调节工作负载和减少响应时间。

FaaS

Function-as-a-Service(函数即服务)指的是计算模型，在这个模型中，你的代码将被平台打包，并作为一些可配置事件(如 HTTP 请求、消息到达、文件上传)的结果，在有限时间内按需运行，之后可能随时被处理。这里的优秀代表有AWS Lambda[8]， Azure 函数[9]和谷歌云函数[10]。

我们可以用大量的functions来组装应用程序，但每个functions需要单独配置和部署。这就是为什么FaaS有时被称为纳米服务。

如上所述，function生命周期在用户请求激活时开始，在返回时结束。处理时间通常受到平台的限制。
FaaS的自动扩展几乎是无限的，它允许我们无缝地处理工作负载峰值。另一方面，大量的函数实例可能会给我们的体系结构带来巨大的压力，直到某个地方出现了问题，我们最终将DDoS[11]作为我们自己的后端，即:数据库、内部服务或第三方 API。
functions往往比services粒度更细，因此我们最终需要协调、集成和管理大量的部署单元。需要实现的特性越多，成熟的 FaaS 应用程序就越复杂。

考虑下面的图表，比较了使用无服务器框架(Lambda + API 网关)实现的项目和使用纯 Node.js 实现的项目之间的代码行。对于添加到软件系统中的每一个重要的功能，当使用无服务器架构时，维护项目所需的配置代码行数将以陡峭的线性速度增长。简而言之，从短期来看，无服务器架构的前景似乎不容乐观。

上图摘自：The Real Cost of Serverless Architecture

如果没有用户请求需要处理，function将不会运行。这个特性就是众所周知的scale-to-zero，它是FaaS计算的标志。当工作负载较低时，它可以节省基础设施成本。
另一方面，在稳定的工作负载下，运行functions的成本可能更昂贵。下面的图表比较了AWS Lambdas和EC2虚拟机每个工作负载的价格。

上图摘自：Economics Of Serverless[12]

注意: 上面的图片比较的是Lambdas和重量级VM，而不是 PaaS，后者在 Kubernetes 出现之前就已经使用了容器。以 Cloud Foundry 为例，我看到客户在高度规范和非常严格的生产环境中，在每个 VM 上运行 20 多个不同的微服务。这意味着之前的收支平衡将发生在平均每秒 5 个请求由 m4.4xlarge VM 支撑的平台。