上一篇我们通过一个 Node.js 纯 FaaS 的 Serverless 应用，给你介绍了 Serverless 引擎盖下的运作机制，总结来说，FaaS 依赖分层调度和极速冷启动的特性，在无事件时它居然可以缩容到 0，就像我们的声控灯一样，有人的时候它可以亮起来，没人的时候，又可以自动关了
听完了原理，我估计你肯定会问，FaaS 这么好，但是它的应用场景是什么呢？今天我们就来一起看下。不过，想要理解 FaaS 的应用场景，我们就需要先理解 FaaS 的进程模型，这也是除了冷启动之后的另外一个重要概念
FaaS 进程模型
FaaS 的冷启动过程，我们知道容器和 Runtime 准备阶段都是由云服务商负责的，我们只需要关注具体的函数执行就可以了。而函数执行在 FaaS 里是由“函数服务”负责的，当函数触发器通知“事件”到来时，函数服务就会根据情况创建函数实例，然后执行函数。当函数执行完之后，函数实例也随之结束自己的使命，FaaS 应用缩容到 0，然后开始进入节能模式
其实这里会有一些疑问：函数执行完之后实例能否不结束，让它继续等待下一次函数被调用呢？这样省去了每次都要冷启动的时间，响应时间不就可以更快了吗？
是的，本身 FaaS 也考虑到了这种情况，所以从运行函数实例的进程角度来看，就有两种模型。我也画了张图，方便你理解。
- 用完即毁型：函数实例准备好后，执行完函数就直接结束。这是 FaaS 最纯正的用法。
- 常驻进程型：函数实例准备好后，执行完函数不结束，而是返回继续等待下一次函数被调用。这里需要注意，即使 FaaS 是常驻进程型，如果一段时间没有事件触发，函数实例还是会被云服务商销毁
这两个模型其实也对应两种不同的应用场景。举个例子，比如你要把我们一起在Servless群中的“待办任务”应用部署上线，还记得小程吧，他完成了第一个版本，他用 Express.js框架开发的 MVC 架构，View 层他采用流行的 React，并且使用了 Ant Design Pro React 组件库，Model 数据库采用 MongoDB。小程的第一个版本，就是一个典型的传统 Web 服务。
从可控性和改造成本角度来看 Web 服务，服务端部署方案最适合的还是托管平台 PaaS 或者自己搭服务跑在 IaaS 上。正如我上一讲所说，使用 FaaS 就必须在 FaaS 的条件限制内使用，最佳的做法应该是一开始就选用 FaaS 开发。
但是小程的运气比较好，我们查了一下文档，发现 FaaS 的 Node.js 的 Runtime 是支持 Express 的，所以我们只需少量修改，小程的第一个版本就可以使用 FaaS 的常驻进程方案部署。
这里我要做个对比。在之前，假设没有 FaaS，我们要将应用部署到托管平台 PaaS 上；启动 Web 服务时，主进程初始化连接 MongoDB，初始化完成后，持续监听服务器的 80 端口，直到监听端口的句柄关闭或主进程接收到终止信号；当 80 端口和客户端建立完 TCP 链接，有 HTTP 请求过来，服务器就会将请求转发给 Web 服务的主进程，这时主进程会创建一个子进程来处理这个请求。
这里我要做个对比。在之前，假设没有 FaaS，我们要将应用部署到托管平台 PaaS 上；启动 Web 服务时，主进程初始化连接 MongoDB，初始化完成后，持续监听服务器的 80 端口，直到监听端口的句柄关闭或主进程接收到终止信号；当 80 端口和客户端建立完 TCP 链接，有 HTTP 请求过来，服务器就会将请求转发给 Web 服务的主进程，这时主进程会创建一个子进程来处理这个请求
而在 FaaS 常驻进程型模式下，首先我们要改造一下代码，Node.js 的 Server 对象采用 FaaS Runtime 提供的 Server 对象；然后我们把监听端口改为监听 HTTP 事件；启动 Web 服务时，主进程初始化连接 MongoDB，初始化完成后，持续监听 HTTP 事件，直到被云服务商控制的父进程关闭回收
当 HTTP 事件发生时，我们的 Web 服务主进程跟之前一样，创建一个子进程来处理这个请求事件。主进程就如我们上图中绘制的那个蓝色的圆点，当 HTTP 事件发生时，它创建的子进程就是蓝色弧形箭头，当子进程处理完后就会被主进程回收
在我看来，常驻进程型就是为了传统 MVC 架构部署上 FaaS 专门设计的。数据库也可以使用原来的 DB 连接方式，不过这样做会增加冷启动的时间（我特意在图中用曲线代表时间增加），从而导致第一次请求长延迟甚至失败。比较适合的做法是我们前面所说的中，讲 Serverless 架构时说的，数据持久化采用 BaaS 服务
那么我们能否用用完即毁型来部署小程的这个 MVC 架构的 Web 服务呢？可以，但是我不推荐你这样做，因为用完即毁型对传统 MVC 改造的成本太大。
说到这里，我们再将上面对比两个模型的示意图镜头再拉远一点，加上 HTTP 触发器看看。其实从另外一个角度看，触发器就是一个常驻进程型模型一直在等待，只不过这个触发器是由云服务商处理罢了。
这里我再啰嗦强调下，还是我们上一讲说的，FaaS 只是做了极端抽象，云服务商通过技术手段帮助开发者屏蔽了细节，让他们尽量只关注代码本身。
所以，在用完即毁型中，我们只要将 MVC 的 Control 层部署到函数执行就可以了。这也意味着我们要将我们的 MVC 架构的 Control 函数一个个拆解出来部署，一个 HTTP 请求对应一个 Control 函数；Control 函数实例启动时连接 MongoDB，一个请求处理完后直接结束。你如果要提升 Control 函数的冷启动时间，Model 层同样要考虑 BaaS 化改造。这里你听着可能有点陌生，没关系，后面我会通过代码给你演示，你到时候再理解也不迟。
现在，理解了两种类型，我们再来看看 FaaS 是怎么收费的，以及常驻型进程这种模式是不是官方会多收费。云服务商 FaaS 函数服务的收费标准各不相同，但他们都会提供一定的免费额度。我给你归纳下 FaaS 的收费标准，主要有两个维度：调用函数次数和函数耗时。
- 调用函数次数，函数每次被事件触发，计数器加一。例如我们 Hello World 例子的 index.js 文件的 handler 函数，它每调用一次，计数就加一。这种模式因为不占资源，所以资源利用率高、收费低
- 函数耗时，说的是函数执行的运行时长，它的计算单位是 CU-S，也就是 CPU 运行了多少秒。
例如我们上面“待办任务”改造的常驻进程型和用完即毁型，多数情况下其实他们两个的函数耗时是一样的。这里可能有些绕，需要给你解释一下。
常驻进程型改造后主要占用的是内存，而 FaaS 收费的是 CPU 计算时间，也就是说常驻进程的模式并不会持续收费。但常驻型应用的冷启动时间会增加，所以我们要尽量避免冷启动，避免冷启动通常又需要做一些额外的工作，比如定时触发一下实例或者购买预留实例，这地方就会增加额外的费用了。这样听起来，是不是觉得常驻进程型改造 MVC 应用用起来很别扭？是的，我们前面也说了，常驻进程模式就是为了传统 MVC 架构部署上 FaaS 专门设计的，算是一种权宜之计吧。
用完即毁型改造后，同样冷启动时间会增加，但是冷启动时间是云服务商负责的。我们 Control 函数的执行时间，和 MVC 部署在 FaaS 中 Control 的执行时间是一样的。每个请求都增加了冷启动时间，响应时间会更长一些，但我们不用考虑额外的成本。那学到这儿，相信你也可以感觉到了，用完即毁型也不太适合传统 MVC 架构的改造，也是一种权宜之计，但这是 FaaS 最纯正的用法，肯定还是有它的用武之地的。
