Serverless应用引擎SAE(Serverless App Engine)提供了多种API接口,从命名空间和VPC、应用信息、弹性伸缩、微服务等多个维度进行划分,其中发布单是贯穿整个SAE的流程处理引擎。本文介绍SAE发布单的基本概念、接口调用场景说明和发布单流程设计逻辑。
什么是发布单
基本概念
发布单是贯穿整个SAE的流程处理引擎。您在使用SAE运维您的应用时,必定会接触到发布单相关的功能。当前SAE同一应用的发布单为应用级别的串行执行,即同一个应用的发布单尚未完结前,不允许再运行这个应用的另外一个发布单流程。
为什么同一应用的发布单不支持并行
- 弹性场景
在SAE应用的发布、扩缩容场景下需要禁用弹性规则,否则会出现一系列不可预期的问题。如果此时有多个发布单并行,就会出现A发布单禁用了弹性,在A发布单未完结之前,B发布单又启动了弹性的情况。如果启用弹性规则的期间,发生了扩缩容的动作,发布单本身的扩缩容会表现出与预期不符的现象。
- 发布和回滚场景
发布和回滚场景都会产生一个版本的底层资源描述文件。如果此时有多个发布单并行,可能会让您部署的应用出现超过2个版本,不符合SAE预期最多只出现2个版本的要求。
发布单接口调用场景说明
发布单接口调用主要针对需要通过API部署到SAE的场景。本文以发布场景为例,介绍如何确认发布单操作是否成功。发布场景是最复杂的发布单场景,如果您想确认其他场景的发布单是否操作成功,方法基本一致。
0
:准备中。1
:执行中。2
:执行成功。3
:执行失败。6
:终止。8
:等待手工确认分批。9
:等待自动确认分批。10
:系统异常执行失败。11
:等待审批。12
:审批通过,等待执行。
确认发布单操作是否成功
- 调用CreateApplication或DeployApplication等接口,如果返回数据中Success参数值为
true
,Code参数值为200
,则同时会返回ChangeOrderId参数。 - 调用DescribeChangeOrder接口,传入对应的ChangeOrderId参数,获取返回数据。
- 根据返回数据中的Status参数进行判断,如果值为
2
(执行成功),则说明发布单操作成功。
需要回滚的发布场景
- 单批发布
单批发布失败或者中止时,SAE不会进行自动回滚。您可以按需自行调用RollbackApplication接口实现回滚。当您调用DescribeChangeOrder接口,获取的返回数据中Status参数值为
3
(执行失败)或者10
(系统异常执行失败)时,则说明发布单执行失败。 - 灰度或者分批发布
发布单失败,会触发自动回滚到上一个版本的操作。
需要人工介入的场景如下:当发布单获取的Status参数值为
1
(执行中)、SubStatus参数值为1
(发布异常)时,您需要自行调用AbortAndRollbackChangeOrder接口去中止发布单。
操作灰度和分批发布
此场景仅适用于分批发布策略手动分批的情况。调用了灰度或者分批发布后,您需要等待多批发布的上一批完成后,才能进行下一批次的操作。
- 调用DeployApplication接口,获取ChangeOrderId。
- 调用DescribeChangeOrder接口,传入对应的ChangeOrderId,获取返回数据。
- 返回的Status参数值为
8
时(等待手工确认分批),可调用ConfirmPipelineBatch接口继续发布。ConfirmPipelineBatch接口需要PipelineId参数(开始下一批次的参数)。DescribeChangeOrder接口的返回数据中,包含CurrentPipelineId和Pipelines两个参数,其中Pipelines是一个集合。该步骤可进行循环,循环内的PipelineId和CurrentPipelineId相同的下一个PipelineId即ConfirmPipelineBatch所需的参数。
发布单流程设计逻辑
为什么发布单失败不能恢复弹性
- 发布和回滚场景
发布单的执行顺序是先禁用弹性,等发布单执行成功时,再恢复弹性规则。如果发布单执行失败,则SAE不会自动恢复弹性规则。因为发布过程中存在多个版本,SAE无法判断需要运行新版本还是旧版本。
- 扩缩容场景
发布弹性规则可能会和您的扩缩容操作冲突。例如当前应用内有10个实例,您想手动缩容到5个,但是弹性规则检测到此时需要扩容到15个,便会引起冲突。因此扩缩容场景需要禁用弹性规则。
为什么多批发布失败会自动回滚
多批发布存在多个批次,如果一次发布成功了一部分,那么此时便有两个版本共存的实例了。如果此时发布单失败,但是仅中止不回滚的话,那么下次再发布的时候,可能会存在三个版本的实例,会出现预期外的情况。因此SAE必须保证您的实例最多存在两个版本。