Serverless 学习笔记 (6): Serverless应用场景

Serverless应用场景

Serverless 引擎盖下的运作机制，FaaS 依赖分层调度和极速冷启动的特性，在无事件时可以缩容到 0。那么它的应用场景是什么呢？我们需要先理解 FaaS 的进程模型。

FaaS 进程模型

1. 用完即毁型：函数实例准备好后，执行完函数就直接结束。这是 FaaS 最纯正的用法。
   在用完即毁型中，我们只要将 MVC 的 Control 层部署到函数执行就可以了。这也意味着我们要将我们的 MVC 架构的 Control 函数一个个拆解出来部署，一个 HTTP 请求对应一个 Control 函数；Control 函数实例启动时连接 MongoDB，一个请求处理完后直接结束。你如果要提升 Control 函数的冷启动时间，Model 层同样要考虑 BaaS 化改造。
2. 常驻进程型：函数实例准备好后，执行完函数不结束，而是返回继续等待下一次函数被调用。这里需要注意，即使 FaaS 是常驻进程型，如果一段时间没有事件触发，函数实例还是会被云服务商销毁。

FaaS 应用场景

数据编排

目前最成功最广泛的设计模式就是 MVC 模式，但随着前端 MVVM 框架越来越火，前端 View 层逐渐前置，发展成 SPA 单页应用；后端 Control 和 Model 层逐渐下沉，发展成面向服务编程的后端应用，这种情况下，前后端更加彻底地解耦，BFF(Backend For Frontend) 层充当了中间胶水层的角色，粘合前后端。BFF的工作就是将有用的数据组合起来，并且加工数据，让数据具备价值与可读性。对于元数据的组合和加工，我们称之为数据编排。
由于 BFF 层只是做无状态的数据编排，所以我们完全可以用 FaaS 用完即毁型模型替换掉 BFF 层的 Node.js 应用，也就是最近圈子里老说的那个新名词 SFF（Serverless For Frontend）。最终，请求链路及逻辑如下：

前端的一个数据请求过来，函数触发器触发我们的函数服务；我们的函数启动后，调用后端提供的元数据接口，并将返回的元数据加工成前端需要的数据格式；我们的
FaaS 函数完全就可以休息了。

另外，除了我们自己的后端应用数据接口，互联网上还有大量的数据供我们使用。比如疫情期间，你要爬取下各个地区的疫情数据、天气数据等。编排后端接口，编排互联网上的数据，以及编排云服务商的各种服务，就是数据编排的场景。

服务编排

服务编排和数据编排很像，主要区别是对云服务商提供的各种服务进行组合和加工。