作者： 渐意
前言
使命体系中有一类很重要的概念，即使命的状况。其本质是对使命的生命周期办理。细分的状况有助于在使用时能够更清楚的了解体系发生了什么内容，便于针对性的依据业务情况进行操作。函数核算 Serverless Task 供给了多种可查询的状况，并供给了各状况间转移的时刻点。在函数的履行层面，函数核算也供给了使命的生命周期办理概念，用户能够依据需求决定当体系对使命实例进行初始化、收回等一系列动作时的履行逻辑，实现完好的运转时生命周期办理。本文将分别对使命运转状况及运转时办理这两个方面的内容进行介绍。
使命的状况及生命周期的办理
使命的状况办理
当用户提交使命并收到提交成功的返回后，使命便已经进入体系对其生命周期的办理流程中。一个使命的状况变更由内部的一个状况机担任办理，并对外透出状况支撑实时查询。整个状况转换图如下所示：
图 1
-
用户触发一次使命后，使命入队，变更为 Enqueued 状况，并返回触发成功；
-
使命在函数核算后端服务中出队，使命变为 Dequeued 状况；
-
后端会查看使命装备。如果
-
- 装备了异步音讯有效期功用，而且该音讯出队时刻与入队时刻之差已超过有效期，则使命被丢掉，变更为 Expired 状况。使命中止；
- 使命对应的函数已被删除，或创建实例呈现错误，则丢掉音讯，使命变更为 Invalid 状况；
-
查看后使命正式进入 Running 状况。此时使命已触发实践的履行；
-
使命履行完结后，依据返回会变更为以下几个状况：
-
- Retrying：用户装备了重试次数（默以为 3），且使命履行失利，这时会进入重试中状况，之后会变更为 Running 状况；
- Failed：使命履行失利，且超过了重试次数。此时会将使命状况改为 Failed；
- Succeeded：使命履行成功。
-
如果在整个状况流通过程用户触发 Cancel，则使命会先变更为 Stopping 状况，并尝试中止使命履行。当使命中止履行成功后，使命进入 Stopped 状况。
使命运转时办理及生命周期
当使命状况进入 Running 后，使命的实践履行便已交给函数核算的运转时。在安全性方面，函数核算会按照 VM 对不同账号进行隔离，同一个账号下的函数可能运转于同一个 VM 中。VM 内有一个担任办理容器的客户端，来实践触发函数的履行，并收集履行结果。
用户的运转实例有几个不同的状况：
图 2
函数核算对上述一切实例状况变化的过程均供给接口，支撑用户侧装备相应的逻辑。
- 创建完结 -> 履行恳求阶段：支撑 Initializer 功用，支撑初始化实例操作。用户能够装备比如全局变量、连接池初始化等相关操作；
- 履行中 -> 履行完结后 Pause 实例：支撑 PreFreeze 接口，支撑在函数 Pause 实例前履行用户侧的自定义逻辑；
- 履行中 -> 外部 cancel：函数核算会强制 Restart 用户实例，在 Restart 前支撑 PreStop 接口。用户能够装备高雅中止的相关逻辑，以便支撑 Cancel 时的自定义行为；
- 完结后 Pause -> 毁掉实例：当一段时刻没有恳求后，函数核算将毁掉实例。此时会调用 PreStop 接口，用户能够装备毁掉容器的行为（如关闭连接池等）。
图 3
使命的中止操作
目前阶段函数核算支撑了中止单一使命的操作。当用户操作中止时，支撑装备 PreStop 接口，在中止前进行一系列的资源收回作业。中止操作用户能够使用 SDK 或控制台来进行调用。以 Go 言语为例，中止一次履行的伪代码如下所示：
import fc "github.com/aliyun/fc-go-sdk"
func CancelJob() {
stopInput := fc.NewStopStatefulAsyncInvocationInput("ServiceName", "FunctionName", "TaskUUID")
output, err := fcClient.StopStatefulAsyncInvocation(stopInput)
...
}
总结
Serverless Task 供给了每个使命的状况细节，并会对这些细节进行实时的耐久化。用户能够依据需要对这些状况信息进行实时的查询，并依据履行及业务情况进行相应的操作。在使命的运转阶段，函数核算供给了一切实例状况转移过程中的相关接口，支撑用户自定义使命履行前后的逻辑。结合 PreStop 功用及 Cancel 中止使命功用，用户能够方便的实现使命的高雅操作。
往期回顾
函数核算异步使命能力介绍 – 使命触发去重
点击此处，查看更多函数核算相关内容！
