FaaS进程模型

从运行函数实例的进程角度来看,就有两种模型。

用完即毁型:函数实例准备好后,执行完函数就直接结束。这是 FaaS 最纯正的用法。

常驻进程型:函数实例准备好后,执行完函数不结束,而是返回继续等待下一次函数被调用。这里需要注意,即使 FaaS 是常驻进程型,如果一段时间没有事件触发,函数实例还是会被云服务商销毁。

 

触发器就是一个常驻进程型模型一直在等待,这个触发器是由云服务商处理。

在用完即毁型中,只要将 MVC 的 Control 层部署到函数执行就可以。这也意味着要将MVC 架构的 Control 函数一个个拆解出来部署,一个 HTTP 请求对应一个 Control 函数;Control 函数实例启动时连接 MongoDB,一个请求处理完后直接结束。

如果要提升 Control 函数的冷启动时间,Model 层同样要考虑 BaaS 化改造。

 

FaaS 的收费标准,主要有两个维度:调用函数次数和函数耗时。调用函数次数,函数每次被事件触发,计数器加一。这种模式因为不占资源,所以资源利用率高、收费低。

函数耗时,说的是函数执行的运行时长,它的计算单位是 CU-S,也就是 CPU 运行了多少秒。

常驻进程型改造后主要占用的是内存,而 FaaS 收费的是 CPU 计算时间,也就是说常驻进程的模式并不会持续收费。但常驻型应用的冷启动时间会增加,所以要尽量避免冷启动,避免冷启动通常又需要做一些额外的工作,比如定时触发一下实例或者购买预留实例,这地方就会增加额外的费用了。

用完即毁型改造后,同样冷启动时间会增加,但是冷启动时间是云服务商负责的。 Control 函数的执行时间,和 MVC 部署在 FaaS 中 Control 的执行时间是一样的。每个请求都增加了冷启动时间,响应时间会更长一些,但不用考虑额外的成本。

 

posted @   muzinan110  阅读(64)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
· 上周热点回顾(2.24-3.2)
点击右上角即可分享
微信分享提示