深入浅出FaaS应用场景之数据编排
通过上一篇深入浅出FaaS的两种进程模型了解到FaaS 的进程模型有两种：常驻进程型和用完即毁型。常驻进程型是为了适应传统 MVC 架构设计的，它看起来并不自然；如果你从现在开始玩 FaaS 的话，我当然首选推荐用完即毁型，它可以最大限度发挥 FaaS 的优势！
接下来，我们就继续把焦点放到用完即毁型上，来具体看看它可以用在哪些更加自然的场景里。
数据编排
我们做开发的多多少少都知道，目前最成功最广泛的设计模式就是 MVC 模式。但随着前端 MVVM 框架越来越火，前端 View 层逐渐前置，发展成 SPA 单页应用；后端 Control 和 Model 层逐渐下沉，发展成面向服务编程的后端应用。
这种情况下，前后端更加彻底地解耦了，前端开发可以依赖 Mock 数据接口完全脱离后端限制，而后端的同学则可以面向数据接口开发，但这也产生了高网络 I/O 的数据网关层。
Node.js 的异步非阻塞和 JavaScript 天然亲近前端工程师的特性，自然地接过数据网关层。因此也诞生了 Node.js 的 BFF 层 (Backend For Frontend)，将后端数据和后端接口编排，适配成前端需要的数据结构，提供给前端使用。
我们的程序员好朋友小程也跟进了这个潮流，将“待办任务”Web 服务重构成了第二个版本。他将原先的应用拆解成了 2 个项目：前端项目采用 React+AntDesignPro+Umi.js的单页应用，后端项目还是采用 Express。我的示例也采用这个技术架构一步一步教你在云上部署 SPA+FaaS 混合框架演进。
BFF 层通常是由善于处理高网络 I/O 的 Node.js 应用负责。传统的服务端运维 Node.js 应用还是比较重的，需要我们购买虚拟机，或者使用应用托管 PaaS 平台。
因为 BFF 层只是做无状态的数据编排，所以我们完全可以用 FaaS 用完即毁型模型替换掉 BFF 层的 Node.js 应用，也就是最近圈子里老说的那个新名词 SFF（Serverless For Frontend）
好，到这儿，我们已经理解了 BFF 到 SFF 的演进过程，现在我们再串下新的请求链路逻辑。前端的一个数据请求过来，函数触发器触发我们的函数服务；我们的函数启动后，调用后端提供的元数据接口，并将返回的元数据加工成前端需要的数据格式；我们的 FaaS 函数完全就可以休息了。具体如下图所示。
另外，除了我们自己的后端应用数据接口，互联网上还有大量的数据供我们使用。比如疫情期间，你要爬取下各个地区的疫情数据、天气数据，这些工作，也都可以放到 FaaS 上轻松搞定，并且基本还能免费，因为目前各大云服务商都提供了免费的额度，这个我刚给你讲过了。
编排后端接口，编排互联网上的数据，这俩场景我想你也很容易想到。不过，我觉得，编排云服务商的各种服务才能让你真正体会到那种触电的感觉!
Servless 专栏学习
