更新时间:2023-10-11 GMT+08:00

函数初始化入口Initializer

概述

Initializer是函数的初始化逻辑入口,不同于请求处理逻辑入口的handler,在有函数初始化的需求场景中,设置了Initializer后,FunctionGraph首先调用initializer完成函数的初始化,之后再调用handler处理请求;如果没有函数初始化的需求则可以跳过initializer,直接调用handler处理请求。

适用场景

用户函数执行调度包括以下几个阶段:

  1. FunctionGraph预先为函数分配执行函数的容器资源。
  2. 下载函数代码。
  3. 通过runtime运行时加载代码。
  4. 用户函数内部进行初始化逻辑。
  5. 函数处理请求并将结果返回。

其中123是系统层面的冷启动开销,通过对调度以及各个环节的优化,函数服务能做到负载快速增长时稳定的延时。4是函数内部初始化逻辑,属于应用层面的冷启动开销,例如深度学习场景下加载规格较大的模型、数据库场景下连接池构建、函数依赖库加载等等。

为了减小应用层冷启动对延时的影响,FunctionGraph推出了initializer接口,系统能识别用户函数的初始化逻辑,从而在调度上做相应的优化。

引入initializer接口的价值

  • 分离初始化逻辑和请求处理逻辑,程序逻辑更清晰,让用户更易写出结构良好,性能更优的代码。
  • 用户函数代码更新时,系统能够保证用户函数的平滑升级,规避应用层初始化冷启动带来的性能损耗。新的函数实例启动后能够自动执行用户的初始化逻辑,在初始化完成后再处理请求。
  • 在应用负载上升,需要增加更多函数实例时,系统能够识别函数应用层初始化的开销,更准确的计算资源伸缩的时机和所需的资源量,让请求延时更加平稳。
  • 即使在用户有持续的请求且不更新函数的情况下,系统仍然有可能将已有容器回收或更新,这时没有平台方的冷启动,但是会有业务方冷启动,Initializer可以最大限度减少这种情况。

initializer接口规范

各个runtime的initializer接口有以下共性:

  • 无自定义参数

    Initializer不支持用户自定义参数,只能获取FunctionGraph提供的context参数中的变量进行相关逻辑处理。

  • 无返回值

    开发者无法从invoke的响应中获取initializer预期的返回值。

  • 超时时间

    开发者可单独设置initializer的超时时间,与handler的超时相互独立,但最长不超过 300 秒。

  • 执行时间

    运行函数逻辑的进程称之为函数实例,运行在容器内。FunctionGraph会根据用户负载伸缩函数实例。每当有新函数实例创建时,系统会首先调用initializer。系统保证一定initializer执行成功后才会执行handler逻辑。

  • 最多成功执行一次

    FunctionGraph保证每个函数实例启动后只会成功执行一次initializer 。如果执行失败,那么该函数实例执行失败,选取下一个实例重新执行,最多重试3次。一旦执行成功,在该实例的生命周期内不会再执行initializer,收到Invoke请求之后只执行请求处理函数。

  • initializer入口命名

    除Java外,其他runtime的initializer入口命名规范与原有的执行函数命名保持一致,格式为 [文件名].[ initializer名],其中initializer名可自定义。Java需要定义一个类并实现函数计算预定义的初始化接口。

  • 计量计费

    Initializer的执行时间也会被计量,用户需要为此付费,计费方式同执行函数。