Serverless 简介

如果你关注云计算的技术趋势，你应该已经听说过 Serverless 这个 buzzword。从 2012 年这个词出现，2014 年 AWS Lambda 发布之后 Serverless 日益流行。现在 Serverless 已经从概念、愿景走向落地。国内也有多家公司应用了 Serverless 计算。

我将在本文介绍 Serverless 的基本概念、优势和适用场景。

什么是 Serverless

顾名思义， Serverless 就是无服务器。

传统的应用部署在服务器上运行。而在 Serverless 云计算模式中，应用程序的运行不需要使用服务器。应用程序一般细化为一个或多个 Function，上传至云计算平台。由平台负责在无状态的计算容器中可靠执行代码。对于平台，最终的计算资源自然不可能是无源之水，还要通过服务器落地。但是对用户确实屏蔽了服务器，用户只需要上传代码。因此所谓的 Serverless 是针对用户的 Serverless。

Serverless 有时会与 FAAS (function-as-a-service) 和 BAAS (backend-as-a-service) 的概念 混用，但它们不是一回事。

FAAS

在 FaaS 中，业务逻辑由开发人员负责实现，但是服务器端逻辑实际上在无状态计算容器中运行。这些容器由一个事件触发，通常是短暂的，并由第三方供应商完全管理。开发人员的代码被上传到服务中，平台负责运行处理细节，比如提供资源、实例化虚拟机和管理进程。

BAAS

在 Serverless 的架构下， 基础或领域通用的组件可以使用第三方云托管服务，应用通过 API 的方式调用依赖的后端服务。这种使用后端远程组件的模式被称为后端即服务。典型的 BAAS 包括数据库、认证等。他们可能是公共云服务商提供的，也可以是第三方厂商提供的。云认证和大型应用程序的使用通常依赖于这些应用程序。

我们可以这样理解：Serverless 包括两部分： 自己实现的业务逻辑 FAAS 和 第三方提供的 BAAS。以普通应用程序类比，FAAS 类似我们自己写的代码，BAAS 类似第三方类库。

Serverless 的优点

上一节提到‘所谓的 Serverless 是针对用户的 Serverless’。这样有什么好处呢？

根据业界的总结和个人体会，主要有以下优势：

成本

在 Cost 方面，Serverless 在合适的场景使用会有很大提升。

首先，Serverless 按需收费，有更精细的收费粒度，用多少收多少。在微服务流行趋势下，经常可能一些冷门服务 TPS 寥寥。如果传统服务器或 EC2 按月计费，对比同样的服务使用 Serverless，就会带来立竿见影的账单改善。尤其是根据现在主流的云计算厂商的计费模式，一定限额内的调用时免费的。

其次，Serverless 还会有额外的收益， 例如操作系统成本，包括：许可证、安装、依赖性、维护、支持和修补等。

最后，如果恰当地选用 BAAS 组件，可以降低开发成本。

但是，需要注意的是，Serverless 运行成本不一定必然降低。例如 TPS 稳定在 1000 的一个服务，迁移到 Serverless 按需收费几乎必然带来更高的成本。做个简单的类比，现实生活中包月和按次收费就好比有服务器和 Serverless。如果使用使用次数频繁，一般包月更划算了。

扩展性

from prototype to production to planet-scale -- 谷歌广告语

快来用 Serverless 啊！ 从原型开发，到系统上线， 到发展壮大成全球巨无霸，扩展无忧！

这些厂商宣传方面好像没什么改进。最开始云计算的一个卖点就是快速上线，无须提前确定服务器数量和规格：创业者上云吧，先来两台普通 EC2；产品大火，流量激增，好， 再来 XX 台；无人问津，茕茕自立，哎，停了服务器，前期损失也不大。

Serverless 其实更进一步，开发工程师不需要过多考虑扩展性问题。流量增加也不需要手动修改配置，增加机器。云计算平台会负责根据实际需求自动伸缩、扩容。

但是需要注意的是，一般云计算厂商的 Serverless 调用 TPS 缺省有限制的。例如 AWS Lambda，缺省限制是 3000。如果你预计应用每秒调用超过了厂商限制，需要及时申请提升限额。

设计细化

Serverless 倒逼应用程序的功能被细化拆分成细颗粒度的无状态函数。这带来了两个副作用：首先设计上功能划分清晰，其次天然的无状态函数

降低了模块耦合度。

这同时也是一把双刃剑，大量细粒度函数给管理和部署都带来了挑战。

运维

读者也许只负责开发，没有服务器运维管理的经验。我们是开发运维一体，数年前服务器还在传统机房，从硬件故障到操作系统升级，琐碎繁杂。虽不容忽视，但确实没有技术含量也缺乏成就感。Serverless 消除了基础设施管理任务，例如服务器或集群配置、打补丁、操作系统维护和容量预置。亚马逊作为业界开发运维一体化的标杆企业，SDE 深受其苦，这也许是一个在各云计算厂商中率先推出 Serverless 的内因吧。

当然，应用 Serverless 并非没有运维。我们仍然需要监控、部署等任务。

Serverless 的局限

Serverless 不是银弹，也存在局限：

冷启动

Serverless 平台收到请求后，在初始化函数的实例需要一些时间准备运行环境，启动资源。这个启动延迟可能在几毫秒到几秒的范围内，这就是冷启动问题。针对频繁调用的函数，平台会复用已创建的环境资源来优化，即热启动。而脉冲式或零星调用的函数就容易遇到冷启动性能问题。

冷启动的时间延迟与很多因素有关，包括编程语言、类库数量、代码大小等。例如 NodeJS 相对启动迅速，而 Java 程序则存在臭名昭著的冷启动问题。

为了解决性能问题，云计算厂商会针对语言进行优化，例如提高 JVM 启动加载效率。用户也可以定时触发函数进行预热，缓解冷启动问题。

执行时间

Serverless 函数每次调用运行时间通常受到限制。例如 AWS Lambda 函数运行的超时最多为 5 分钟，然后被强制终止。因此长期任务不适合采用 Serverles 架构。

推荐的解决方案是创建多个函数，确保每个函数的执行时间不超过限制，各个函数协调执行来完成长期任务。例如在 AWS 中创建 StepFunction 协调多个 Lambda 函数的执行。

性能调优

Serverless 代码的性能或资源问题相比传统代码更难定位。虽然平台提供了函数运行的计时，但很难通过 Profiling 工具、调试器或 APM 工具来深入了解更多细节。而云端运行 Serverless 代码的环境通常不是开源的，因此不能在本地环境中精确复制性能特征。

工具支持

首先，虽然存在 Serverless 的 Web IDE，但是目前最主要的开发方式还是在本地进行开发。现在还不方便直接开发、调试云端函数。

其次，代码运行于无状态的计算容器内，实时日志通过云平台输出。首先没有细粒度的日志分级，其次还没有工具支持方便地查看查找日志信息。

最后，缺乏完善的工具支持持续集成、系统发布。

厂商锁定

因为现在还没有统一的 Serverless 标准，不同云计算平台提供了个性化的 Serverless 服务。这就导致了厂商锁定的问题：为一个平台开发的代码，不能平滑迁移到其他平台。同时维护多个平台代码耗时费力，专一钟情于一家厂商可能存在风险。这里不只是说云计算厂商倒闭的风险（其实这个应该是最低的风险），还可能有其他意想不到的风险。例如字节跳动之前签了谷歌的大单，现在可能又不得不用甲骨文的云平台。

目前比较通用的解决方案是借助 Serverless 框架。业界流行的 Serverless 框架有 Serverless Framework、Apex 等。这些框架的可以屏蔽不同 Serverless 服务中的差异，基于框架开发的的函数可以方便的发布到各个云计算平台。

最佳实践

作为新生事物，Serverless 还没有完全成熟。具体的应用模式和最佳实践都还在探索中。现在采用 Serverless 可能会作为先行者踩一些坑。

为了避免踩坑，推荐在了解局限性的前提下，在已经证明的场景使用 Serverless，具体见下节的应用场景。

适用场景

Serverless 不是万金油，需要合适的场景才能发挥优势。现阶段 Serverless 已经有一些比较成熟的应用场景。

UI 驱动

UI 驱动表示应用的执行主要由前端 UI 的输入触发。常见的这类应用包括 Web 和 APP。UI 事件触发 API 网关，网关调用后端业务逻辑。结合 BAAS 提供基础服务，通过这种模式可以快速搭建具备高可用性和扩展性的 Web 或 APP 应用。

上图是一个简单的 AWS 应用示例，用户通过 APP 或浏览器访问应用。身份认证是通过第三方 BAAS 服务（例如 Auth0）提供的。客户端可以直接访问 BAAS 存储。用户操作通过 API 网关触发后端任务执行。

这里值得关注的是数据库访问模式。传统的应用中数据库访问都是通过服务器端执行，然后把结果转换为可用视图传给前端。在 BAAS 模式下，通过安全配置文件设置客户端数据库和服务器的权限，允许前端直接访问我们数据库。

国内现在很多小程开发其实多少采用了这种模式。支付宝、微信、百度小程序都提供了云开发功能。这些平台将后端服务封装以 BaaS 的方式提供 SDK 给开发者。一方面推销自己的云计算平台，一方面确实也给开发者提供了便利，并且也推动了 Serverless 在国内的实践。

消息驱动

异步消息处理是 Serverless 技术非常流行的应用场景。

在改场景下，生产者发布消息到消息队列，应用程序异步处理队列中的消息。从抽象架构上看，基于 Serverless 的异步处理可能没有什么变化。关键是通过 FAAS 函数替换了之前的消息处理程序。传统的消息处理程序部署在服务器上，函数代码部署在云端，通过实例化多个副本并行执行。Serverless 提供了更好的弹性。

一般云平台供应商同时提供了消息触发和 FaaS 环境，可以一站式集成开发。例如 AWS 平台的 Lambda 函数内置提供了基于 DynamoDB、S3、SNS、Kinesese 等的更新驱动。

定时任务

现在流行的介绍文章基本都推荐了前两个场景。在具体实践中，个人觉得定时任务也可以通过 Serverless 实现。例如 AWS 环境下，可以通过 CloudWatch 设置定时触发 Lambda 函数。比较常用的是批处理任务，可以通过 CloudWatch + Step Function + Lambda 的方式定期执行。

产品

各大云厂商 Amazon、Microsoft、Google、阿里云等相继推出 Serverless 产品。

• AWS Lamba

• Azure Functions

• Google Cloud Functions

• 阿里云函数

此外，也可以基于开源产品支持 Serverless，比较流行的是 Kubernetes 上无服务器框架 Fission。

小结

本文简要介绍了 Serverless 的基本知识，包括概念、特点、优缺点、应用场景等等。

如果有时间精力，下一步计划写 Serverless 系列文章。后期将以 AWS 为例，用实际的代码实现逐步深入介绍 Serverless 的开发、部署、运维等。