Serverless平台

在云计算时代，我们所需要的算力能够唾手可得、按需使用，这极大地提升了我们的效率。我们可以在云厂商的控制台界面上购买一个虚拟的服务器，整个过程几分钟就可以完成。而购买后，我们就可以在其中部署服务，进行资源的编排和发布。

但你有没有想过，这种购买服务器部署服务的方式，虽然有按量付费的模式，但其实还是在一段时间内的长时租赁，比如我租一星期、一个月。你会发现，如果你的业务不是全天 24h 在运行，而是只在白天运行，那么夜晚的资源其实是闲置的，但你仍然需要为夜晚的使用付费。那么有没有一种方式，能够让我们在白天且使用到的时候付费，而夜晚不使用的时候不付费，或者更进一步，有没有可能，只在这个函数触发运行的时候计算使用时长，而非触发运行的时候不记录使用费用呢？

有的，这种模式就是全新的 Serverless 模式，即“无服务器”架构。

Serverless架构

Serverless 是一种全新的系统架构的思想和方法，它的核心是用户绝对的无需关注支撑其服务的底层，而是把精力百分之百地放在业务的设计上来。

在传统的场景下，用户完成一个业务的开发上线，通常需要以下几个关键步骤：

• 购买服务器
• 部署开发、生产、测试环境
• 部署业务
• 部署监控
• 持续跟踪业务状态
• 更新发布

根据业务的场景，开发会申请一定数量的服务器，判断服务器所需要的 CPU、内存等。业务上线后，需要部署监控系统进行监控，一旦监控到高流量，则需要进行资源扩容。在版本更新迭代的时候，还需要进行蓝绿部署、金丝雀部署等部署测试转换，一旦有异常，就可能进行回滚等一系列复杂操作。在上述场景下，我们需要关系服务器的资源是否充足、服务是否达标、升级是否正常、运行是否稳定等等一系列的管理与维护。

而在 Serverless 模式下，情况则截然不同。当我们开发完成后，直接将我们的应用部署在 Serverless 指定的平台之上即可，而无需关心我们的底层虚拟机计算资源，云平台会自动为我们激活加载相关的环境。同时会在秒级的时间粒度内进行动态的扩缩容，当我们的函数较长时间不用时，云平台会自动帮我们卸载此函数，进入冷冻期，不进行收费。

通过上述两种部署模式的对比，我们容易得出以下几个结论：

相比于传统部署，Serverless 模式能够：

1. 降低投入成本：用户不再为服务器整体付费，而是为算力付费。只有在真正处理事件的时候才会加载运行，进行计费，在空闲状态下不收取费用。
2. 降低使用和维护成本：用户无需提前规划申请服务器的数量和规格，只需要关心服务的整体状态及使用情况。
3. 缩短迭代开发时间：在 Serverless 模式下，应用功能被拆分到具体函数，各功能模块之间的耦合度大大降低，这使得开发人员可以针对单个函数进行小步的开发，进而实现快速的迭代，缩短整体更新时间。

FaaS与BaaS

目前，由于 FaaS 的快速普及，很多人将 FaaS 等同于 Serverless，其实这个说法是不严谨的。如前所言，Serverless 是一种全新的系统架构的思想和方法，它并不是某个 FaaS 或 BaaS 的代表。而目前业界较为主流的是 Serverless=FaaS+BaaS，函数即服务与后端即服务的支持。下面我来逐一解释一下。

FaaS-Function as a Service

FaaS 提供了一个计算的平台，平台支持多种开发语言，用户无需部署环境，直接上传代码即可。在此平台上，应用被以一个或者多个函数的形式进行开发、运行和管理。函数可由多种事件进行触发，如 HTTP、定时器、云产品等进行触发执行。执行结束后，可联动事件执行后续的操作。根据预定的事件触发函数的逻辑思想，被称为“事件驱动”的思想。

img

Baas-Backend as a Service

如果说在函数部分实现了无服务化，而函数执行中所调用的服务还是有服务器的话，那么在整体上并不能说实现了完美的 Serverless 化。系统整体 Serverless 化的价值体现在背后的后援团——Backend 后端服务化的鼎力支持。

为了实现整体的 Serverless 化，就要使 FaaS 调用的后端服务也要 Serverless 化，所以 BaaS 就此诞生。BaaS 将后端服务化变为无服务的模式，将其发布以供 FaaS 调用。Backend 并不指某个服务，而是后端服务的集合，如数据库、存储、身份认证等。任何能够提供无服务化的服务我们都可以称之为 BaaS。

综上所述，Serverless 与 FaaS、BaaS 并不是等价关系，而是包含与被包含的关系。FaaS 是 Serverless 应用的标准运行环境，BaaS 是 Serverless 应用访问第三方服务的标准途径。

img

Serverless的技术特性

搞清楚 FaaS、BaaS 与 Serverless 的关系之后，接下来我们再看看 Serverless 的技术特性。

由于其各函数与函数之间、应用与应用之间高度解耦，和传统的有服务架构相比，Serverless 有以下多个明显的特点。

1. 真正按需使用：函数的生命周期为部署 - 加载 - 执行 -（扩容 - 缩容）- 闲置 - 卸载 - 加载，在没有请求到来的时候，函数处于卸载状态，既不耗费资源，也不耗费金钱。
2. 秒级弹性伸缩：相比于服务器分钟级别的伸缩，函数可以实现秒级自动扩缩容。
3. 毫秒级响应：函数可以精确到毫秒级，提供精确的计算时间和内存使用。
4. 事件驱动：函数由一个或多个事件进行关联驱动触发，通过不同的 source 和 target 与之关联，对不同的事件作出不同的反应，实现事件驱动。
5. 非持久化保存：由于函数底层服务器对用户“黑盒”，所以数据无法保存在服务器上。
6. 无状态应用：同非会话保持一样，应用不与特定服务器相关联，所以不适合作为有状态应用。但不适合不代表其不可以，我们可以通过特定手段进行会话保持，但对于 Serverless 我还是优先推荐无状态应用。
7. 应用函数化：由于应用被拆分为“函数”粒度的单位，所以调用应用其实是调用各函数的组合。
8. 后端服务化：仅靠 FaaS 无法实现真正意义上的 Serverless，所以 Serverless 中很重要的一个特性就是后端服务化，将我们熟知的各类云服务，完全后端化，与 FaaS 共同组成 Serverless。

Serverless的最佳使用场景

在我们搞懂了 Serverless 的技术特性后，我们就可以得出 Serverless 的最佳使用场景了。下面我们对应不同的服务进行连线，来将使用场景与特性“对号入座”。

img

• Web 应用——应用函数化、事件驱动、毫秒级响应

Web 应用有明显的 RESTful API，我们可以将各类动词 GET/PUT/POST/DELETE 与函数一一对应，实现 y=f(x) 映射关系。

• 物联网——事件驱动、非持久化保存、无状态应用

物联网由于有成百上千的设备与之对接和数据收集，各设备独立运行且单向传输，Serverless 可以很好地满足其要求。

• 流媒体服务——无状态应用、秒级弹性伸缩、按需使用

一些多媒体公司进行直播、视频处理等，需要做到实时不间断的渲染、转码等，且这些信息不保存状态，所以可以使用 Serverless 来联动处理。

以上只是 Serverless 服务使用场景的冰山一角，其使用场景远不止这些，通过恰当的排列组合和场景控制，可以达到 1+1>2 的神奇效果。

Serverless的局限性

当然 Serverless 也并不只有优势，正所谓“金无足赤，人无完人”，Serverless 也有一定的局限性。

在会话保持和持久化这方面，由于 Serverless 的自身特性，无法做到有服务器化的传统保存模式，虽说有一定的解决方案，但转换成本较高。

在性能方面，由于函数由生命周期控制，所以当服务处于卸载状态的时候，再次启动，需要的时间会更久一些，需要通过预热或设定冷却时间来解决。

另外它不适合长时间执行的场景，对于函数来说，大多数云厂商都有 5min 的运行时间限制（AWS 现在已提升至 15min），超出这个时间就强制终止，所以，我们在设计的时候还要考虑到函数执行时间的限制。

目前 Serverless 还处在发展阶段，距离我们最早的 FaaS 服务是 2014 诞生的，也仅有不到 8 年的时间，还属于“少儿”期，各平台的解决方案和标准暂不统一，且其整个生态还较为脆弱，尤其是 BaaS 部分，比如，AWS 推出了兼容 MySQL 的 Aurora 数据库的 Serverless 版本，但国内一些云厂还未推出同类型的兼容 MySQL 数据库的 Serverless 版本。当然随着时间的推移，云厂商正在快速迭代升级中，我们乐见，云厂商推出更多类型的服务。

一个完整的 Serverless 平台必定要包含 API 网关、数据库、消息队列、监控、安全等一系列的配套设施，如果没有这些的加持，我们在无服务化的道路上必定会困难重重。当我们对 Serverless 平台进行选择的时候，除了重点关注其本身的执行能力外，还要了解所在的生态系统是否完善。