共计 3009 个字符，预计需要花费 8 分钟才能阅读完成。
上一篇 咱们通过一个 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 最纯正的用法，必定还是有它的用武之地的。
举荐浏览
深入浅出 FaaS 的两种过程模型