关于云函数冷启动优化的思考

关于云函数冷启动优化的思考

​ 随着容器技术的广泛应用,XaaS形式的概念层出不穷。从IaaS(Infrastructure as a Service)、PaaS(Platform as a Service)、SaaS(Software as a Service)到容器云引领的CaaS(Containers as a Service),再到火热的微服务架构,它们都在试着将各种软、硬件资源等抽象为一种服务提供给开发者使用,让他们不再担心基础设施、资源需求、中间件等等,在减轻心智负担的同时更好地专注于业务。FaaS是Functions as a Service的简称,它往往和无服务架构(Serverless Architecture)一同被提起。

​ 小程序开发云函数正是FaaS形式的架构,微信官方对其推崇至极。但是实际的应用情况我们有目共睹,云函数的冷启动对客户端带来的是高延迟的糟糕体验。一个云函数冷启动,需要经过资源调度,代码下载,代码部署几个步骤。还没等到执行代码逻辑,用户已经退出程序了。如果仅仅从云函数现在的表现出发进行分析,想要去撼动现在市场格局是远远不够的。

​ 本人技术水平有限,也不知道云开发的完整的技术框架,只从可能的几个角度进行分析,找寻可能存在的优化方向,如果错误,希望各位不吝斧正。

# 思路一

​ 在云函数中调用另一个云函数逻辑,假设执行 \(A\) 云函数逻辑需要 \(T_1\) 时长,冷启动需要 \(C_1\) 时长,执行 \(B\) 云函数逻辑需要 \(T_2\) 时长,冷启动需要 \(C_2\) 时长。

那么执行这个逻辑的需要总时长大概是 \(T_1 + C_1 + T_2 + C_2\)

​ 那么是否可以对上传的云函数代码进行上下文分析,如果云函数中存在对其他云函数(如 \(B\) 云函数)的调用,在冷启动 \(A\) 云函数时,也调度资源给 \(B\) 云函数。

思路简述如下:

  1. 对上传代码分析,将上下文出现的对其他云函数的调用记录下来,记作 link_container_list
  2. 在调用云函数之前,检查该云函数的 link_container_list,冷启动该云函数同时,对link_container_list中的云函数也进行冷启动(资源调度)。

那么执行这个逻辑的需要的总时长大概是 \(T_1 + T_2 + max\{C_1,C_2\}\)

该思路可以进行拓展,即使有\(N\) 个相关的云函数,那么理想情况下最终执行的逻辑时长,也是 \(\sum_{i=1}^{n}T_i + max\{C_1,...,C_n\}\)

# 思路二

​ 云函数创建对应资源容器时,装载的资源包括号称比黑洞更重的node_modules依赖文件等。这或许是影响冷启动速度的原因之一。

那么服务提供商是否可以维护这样一个容器池,容器池中存放着已经装载完依赖环境的半完成态容器。

如何维持半完成态的容器?

​ 用户第一次调用云函数时,以nodejs云函数为例,判断package.json文件中的依赖,容器池中是否有满足的半完成态容器,将对应容器直接分配该用户,半完成态容器直接装载业务逻辑代码,跳过装载依赖文件和环境这一步。

# 思路三

​ 考虑业务上的相关联,比如说对于购物小程序来说,当用户调用查询商品详情云函数 \(A\) 时,那么下一步用户可能就要调用 统一下单云函数\(B\) 。显然,在调用 \(A\) 云函数时,对 \(B\) 云函数进行资源容器预装载是合理的,一般习惯称这种方法叫预热。 这是业务逻辑上的关联,然而不同的程序有不同的关联逻辑,服务提供商是否可以提供一个配置文件,由开发者指定预热的云函数资源容器。

​ 例如对于查询商品详情的云函数\(A\) , 假定其关联预热云函数文件名为trigger.json

{
	"uniOrder",//统一下单
	"addCart",//加入购物车
	"addFavor"//加入手册
}

​ 当调用云函数 \(A\) 时,就会预热 uniOrder等云函数。

​ 现在对于这种预热方法的实现方式,是在调用云函数 \(A\) 的时候,在执行代码逻辑内部 cloud.callFunction() 来提前预热云函数,这种写法方式不够优雅,而且如果对正常触发和预热触发逻辑处理不够完善,还可能会引起其他问题。

# 思路四

​ 既然冷启动的原因是因为资源容器会被销毁,再次触发需要重新创建,那么为什么不能一次创建长期维持呢?保持最小的资源消耗的情况下,使得云函数容器不被销毁,相比较于每次冷启动对用户端明显的交互影响,这些微不足道的资源消耗简直不值一提。服务商可以给愿意付出资源消耗量的开发者提供配置,由开发者指定每次创建容器的存活时间。

​ 例如在config.json文件中新增配置项keep_alive:60,就代表容器如果60分钟内无操作才会被销毁。配置为 0 代表永不销毁,然后为开发者提供个主动销毁容器的方法调用。

​ 现阶段,开发者们常用维护容器状态的思路是配置定期器,每隔一段时间触发一次,以维持容器不被销毁,这样子对资源的消耗量其实是比较大的。而且是不够优雅,属于空逻辑,还需要为触发器实现专门的空逻辑处理部分,防止对业务代码产生干扰。

# 思路五

​ 既然客户端开发可以使用插件,可以依赖于第三方服务,那么为什么云函数不可以呢?云服务商可以提供常驻的通用的云函数服务,如提供一个用户角色权限管理云函数,不需要用户自己设计部署,由官方提供调用方式即可。

亦或者是提供一个地址管理云函数,与官方数据打通,使用云函数提供调用方法等等,不胜枚举。

​ 总而言之,言而总之,我是很喜欢FaaS架构的开发形式,如果能解决冷启动对交互体验的影响,我相信会有更多的开发者投身于这个生态中。

参考文献

[1] 苗立尧. Faas,又一个未来? [EB/OL] 求知

[2] Linux中国. 如何提升你的云函数性能 [EB/OL] 小程序官方社区

posted @ 2021-12-04 01:02  Kindear  阅读(125)  评论(0编辑  收藏  举报