上一篇我们通过一个Node.js纯FaaSServerless应用介绍了Serverless底层的运行机制。综上所述，FaaS靠的是分层调度和极速冷启动，可以在没有事件的时候收缩到0，就像我们的声控灯一样，有人的时候开，有人的时候自动关。那里没人。听完原理，我猜你肯定会疑问，FaaS这么好，但是它的应用场景是什么呢？今天我们就来看看吧。但是，要想了解FaaS的应用场景，首先需要了解FaaS的流程模型。这是继冷启动之后的另一个重要概念。云服务商负责，我们只需要关注具体的功能执行即可。在FaaS中，函数执行负责“函数服务”。当一个函数触发器通知一个“事件”的到来时，函数服务会根据情况创建一个函数实例，然后执行该函数。函数执行完毕后，函数实例也结束了它的使命。FaaS应用收缩为0，然后进入节能模式。其实这里也有一些疑惑：函数执行完后实例是不是就结束了，这样就可以继续等待函数调用一次呢？这样就省去了每次冷启动的时间，响应时间不是更快吗？是的，FaaS本身就考虑到了这种情况，所以从运行函数实例的进程来看，有两种模型。我也画了一张图，方便大家理解。Destroyafteruse：函数实例就绪后，函数执行完立即结束。这是FaaS最纯粹的用途。永久流程型：函数实例就绪后，函数执行后并不会结束，而是返回并等待下一个函数被调用。这里需要注意的是，即使FaaS是常驻进程类型，如果一段时间内没有事件触发，函数实例仍然会被云服务商销毁。这两种模型实际上对应两种不同的应用场景。比如你要部署启动我们Servless组一起的“待办任务”应用，记得小程，他完成了第一个版本，他用Express.js框架开发的MVC架构，查看layer使用了流行的React，并使用了AntDesignPro的React组件库，Model数据库使用了MongoDB。第一个版本的程小奔是一个典型的传统网络服务。从可控性和改造成本的角度来看Web服务，最合适的服务器端部署方案是托管平台PaaS或者在IaaS上运行服务。上一讲我说了，使用FaaS必须在FaaS的约束范围内使用。最佳实践应该是一开始就选择FaaS进行开发。不过小程是幸运的。我们查看了文档，发现FaaS的Node.js运行时是支持Express的，所以只需要稍微修改一下，小城第一版就可以使用FaaS常驻进程的方案了。部署。这里我想做一个比较。以往，假设没有FaaS，我们会将应用部署到托管平台PaaS；当启动web服务时，主进程初始化与MongoDB的连接。初始化完成后，继续监听服务器的80端口，直到关闭监听端口的句柄或者主进程收到终止信号；当80端口与客户端建立TCP连接，有HTTP请求过来时，服务器会将请求转发给Web服务的主进程，主进程会创建一个子进程来处理请求。这里我想做一个比较。以往，假设没有FaaS，我们会将应用部署到托管平台PaaS；当启动web服务时，主进程初始化与MongoDB的连接。初始化完成后，继续监听服务器的80端口，直到关闭监听端口的句柄或者主进程收到终止信号；当80端口与客户端建立TCP连接，有HTTP请求到达时，服务器会将请求转发给Web服务的主进程，主进程会创建一个子进程来处理该请求。在常驻进程模式下，我们首先要修改代码。Node.js的Server对象采用FaaSRuntime提供的Server对象；然后我们改变监听端口来监听HTTP事件；完成后继续监听HTTP事件，直到云服务商控制的父进程关闭回收。当一个HTTP事件发生时，我们的主要Web服务进程创建一个子进程来像以前一样处理请求事件。主要流程就像上图中画的蓝点。当HTTP事件发生时，它创建的子进程就是蓝色圆弧箭头。子进程处理完后，会被主进程回收。因此，在我看来，常驻进程类型是专门为传统MVC架构上的FaaS部署而设计的。数据库也可以使用原来的DB连接方式，但是这样做会增加冷启动时间（我特意用图中的曲线来表示时间的增加），导致第一次请求延迟很长甚至失败。更合适的做法就是我们之前说的serverless架构，数据持久化使用的是BaaS服务，那小奔这个基于MVC的web服务是不是可以用instant-to-destroy类型来部署呢？是的，但是我不建议你这样做，因为改造传统MVC的成本太高了。话虽如此，让我们从比较上面两个模型的示意图镜头进一步缩小，并添加一个HTTP触发器来看看。其实从另一个角度来说，触发器就是一个一直在等待的常驻进程模型，只不过这个触发器是由云服务商来处理的。这里我要强调的是，我们上次说过，FaaS只是一种极端的抽象。云服务商通过技术手段帮助开发者屏蔽细节，让他们尽可能专注于代码本身。因此，在即时销毁类型中，我们只需要部署MVC的Control层来执行功能即可。这也意味着我们要将我们MVC架构的Control功能，一个一个的拆解部署。一个HTTP请求对应一个Control函数；Control函数实例在启动时连接到MongoDB，并在处理完请求后直接结束。如果要改善Control功能的冷启动时间，Model层也要考虑BaaS改造。说到这里大家可能有点陌生，不过没关系，后面我会通过代码演示给大家看，到时候大家理解也不晚。了解完这两种类型，我们再来看看FaaS是怎么收费的，常驻进程模式官方会不会收费更高。云服务商对FaaS功能服务的收费标准各不相同，但都提供一定的免费额度。我给大家总结一下FaaS的收费标准。主要有两个维度：函数被调用的次数和花在函数上的时间。函数被调用的次数。每次函数被事件触发时，计数器都会加一。比如我们的HelloWorld例子的index.js文件的handler函数，每调用一次，count就加一。由于这种模式不占用资源，资源利用率高，费用低。耗时函数是指函数执行的运行时间。它的计算单位是CU-S，即CPU运行了多少秒。比如我们上面的“待办任务”改造的常驻进程类型和即时销毁类型，在大多数情况下，这两个函数的耗时函数其实是一样的。这里可能有些混乱，我需要向你解释一下。常驻进程类型改造后主要占用内存，而FaaS按CPU计算时间收费，也就是说常驻进程模式不再继续收费。但是常驻应用的冷启动时间会增加，所以要尽量避免冷启动。避免冷启动通常需要做一些额外的工作，比如定期触发实例或者购买预留实例，这些都会增加额外的时间。费用。听起来是这样的，你是不是觉得使用一个基于常驻进程的retrofitMVC应用很别扭？是的，我们前面说了，驻留进程模式是专门为在传统MVC架构上部署FaaS而设计的，所以是权宜之计。instant-to-destroy转换用完后，冷启动时间也会增加，但是冷启动时间是云服务商的责任。我们Control函数的执行时间和FaaS中MVC部署的Control的执行时间是一样的。每个请求都会增加冷启动时间，响应时间会变长，但是我们不需要考虑额外的成本。了解了这些，相信你也能体会到。可破坏类型不适合传统MVC架构的改造。也是权宜之计，但这是FaaS最纯粹的用法，肯定还是有它的用处的。地面。推荐阅读FaaS的两种流程模型深入浅出
