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

Kindear

发布于 2021-12-06 10:22:13

1.2K0

发布于 2021-12-06 10:22:13

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

随着容器技术的广泛应用，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 云函数。

思路简述如下：

对上传代码分析，将上下文出现的对其他云函数的调用记录下来，记作 link_container_list。
在调用云函数之前，检查该云函数的 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 代表永不销毁，然后为开发者提供个主动销毁容器的方法调用。

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