从运行函数实例的进程角度来看，就有两种模型。
用完即毁型：函数实例准备好后，执行完函数就直接结束。这是 FaaS 最纯正的用法。
常驻进程型：函数实例准备好后，执行完函数不结束，而是返回继续等待下一次函数被调用。这里需要注意，即使 FaaS 是常驻进程型，如果一段时间没有事件触发，函数实例还是会被云服务商销毁。
触发器就是一个常驻进程型模型一直在等待，这个触发器是由云服务商处理。
在用完即毁型中，只要将 MVC 的 Control 层部署到函数执行就可以。这也意味着要将MVC 架构的 Control 函数一个个拆解出来部署，一个 HTTP 请求对应一个 Control 函数；Control 函数实例启动时连接 MongoDB，一个请求处理完后直接结束。
如果要提升 Control 函数的冷启动时间，Model 层同样要考虑 BaaS 化改造。
FaaS 的收费标准，主要有两个维度：调用函数次数和函数耗时。调用函数次数，函数每次被事件触发，计数器加一。这种模式因为不占资源，所以资源利用率高、收费低。
函数耗时，说的是函数执行的运行时长，它的计算单位是 CU-S，也就是 CPU 运行了多少秒。
常驻进程型改造后主要占用的是内存，而 FaaS 收费的是 CPU 计算时间，也就是说常驻进程的模式并不会持续收费。但常驻型应用的冷启动时间会增加，所以要尽量避免冷启动，避免冷启动通常又需要做一些额外的工作，比如定时触发一下实例或者购买预留实例，这地方就会增加额外的费用了。
用完即毁型改造后，同样冷启动时间会增加，但是冷启动时间是云服务商负责的。 Control 函数的执行时间，和 MVC 部署在 FaaS 中 Control 的执行时间是一样的。每个请求都增加了冷启动时间，响应时间会更长一些，但不用考虑额外的成本。
标签：Control,函数,模型,常驻,实例,冷启动,进程,FaaS From： https://www.cnblogs.com/muzinan110/p/17056003.html