# 函数初始化入口Initializer
#### 初始化入口Initializer概述
Initializer是函数的初始化逻辑入口，不同于请求处理逻辑入口的handler，在有函数初始化的需求场景中，设置了Initializer后，FunctionGraph首先调用initializer完成函数的初始化，之后再调用handler处理请求；如果没有函数初始化的需求则可以跳过initializer，直接调用handler处理请求。
#### 适用场景
用户函数执行调度包括以下几个阶段：
1. FunctionGraph预先为函数分配执行函数的容器资源。
2. 下载函数代码。
3. 通过runtime运行时加载代码。
4. 用户函数内部进行初始化逻辑。
5. 函数处理请求并将结果返回。
其中[1]、[2]和[3]是系统层面的冷启动开销，通过对调度以及各个环节的优化，函数工作流服务能做到负载快速增长时稳定的延时。[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的执行时间也会被计量，用户需要为此付费，计费方式同执行函数。