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