原文链接：http://click.aliyun.com/m/13996/

前言

按照百科词条的解释：灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。降低发布上线的风险。

灰度发布的关键是选择合适的灰度策略，把符合策略的流量引入到新版本上。灰度策略的选择需要考虑待发布对象在链路或系统中的位置角色（如客户端、移动APP、服务后台等）、用户属性和发布需求目标等。本文将对MaxCompute的Task灰度发布系统进行介绍。

MaxCompute Task灰度发布

MaxCompute flighting（Sprint21）实现了MaxCompute框架和Task的解耦，MaxCompute框架和Task可以根据各自的研发规划进行独立的发布。同时对Task引入了版本化管理（大版本/小版本），MaxCompute框架支持同种Task的多个大版本并存且独立提供服务。这些特性为Task灰度发布提供了基础支持。
MaxComputer_framework
图 MaxCompute flighting 架构图 
MaxCompute目前支持SQL_RELATIVE_TASKS, PS_TASK等Task Package类型, Task的灰度发布便是对这些Task Package发布，希望：
1） 各Task Package独立进行灰，互不干扰；
2） 发布过程对用户透明；
3） 灰度范围、影响面和结果可控；
4） 具有快速可靠的灰度结果评估机制；
5） 操作简单，可自动化/半自动化运维；
6） 版本管理简单，易于进行版本维护；
7） 特殊场合，允许开发线上进行基于灰度测试；

MaxCompute Task灰度发布原理

在介绍MaxCompute的Task灰度原理前，先了解下其业务流程。用户提交作业后，请求首先到worker，worker为每个job创建instanceId，然后RPC到Executor进行TryRun，TryRun时由支持该taskType的Package处理，如果是同步Task，则直接处理并将结果返回，如果为异步Task则返回给Worker，Worker发送给Scheduler，在Executor轮训请求Task时发送给其并继续处理。如下图所示：
screenshot
图 MaxCompute flighting 请求业务逻辑
注：

  • 同步Task： 1 -> 2 -> 3

  • 异步Task： 1 -> 2 -> 3 -> 4 -> 5 -> 6

为了保证Task执行一致性，Worker向Executor发送请求前需要选定package的版本，并且后续请求（异步）也需要该版本package提供，绑定过程在第二步完成。考虑以上事实，可通过在Worker读取灰度流量配置，根据用户属性特征和流量配置决定执行Task的package版本选择结果。灰度原理图如下：
screenshot
图 Task灰度发布原理
灰度发布前，PE或者开发人员初始化灰度配置，灰度配置信息包含预进行灰度发布的版本、参与灰度的用户特征以及灰度时的流量分配，详见Task灰度元数据。准备工作完成后可进行灰度发布。在灰度发布过程中，Worker定时与OTS同步灰度配置并根据当前灰度配置，选取满足特征要求的用户请求参与灰度；按照灰度流量配置引导流量到灰度发布的Package版本上，在灰度发布过程中，PE或者开发人员根据灰度进展状况决定继续灰度还是停止灰度，决定将反应在灰度配置的修改。

Task灰度元数据

基于如上的考虑，MaxCompute设计了各Task独立的灰度发布流程，体现在独立的灰度元数据设计上，如下：

{        "grayInfo": {            "MaxComputeServiceTest1": {                "reserved": {},                "taskVersion": {                    "defaultVersion": "default",                    "flightingVersion": "flighting"},                "tierGrayInfo": {                    "DEFAULTTIER": {                        "grayInfo": {                            "defaultVersion": 100,                            "flightingVersion": 0},                        "reserved": {}
                    }
                },                "MaxComputeServiceTest2": {                "reserved": {},                "taskVersion": {                    "defaultVersion": "default",                    "flightingVersion": "flighting"},                "tierGrayInfo": {                    "DEFAULTTIER": {                        "grayInfo": {                            "defaultVersion": 10,                            "flightingVersion": 90},                        "reserved": {}
                    }
                }
            }
        },        "projectTier": {            "DEFAULTTIER": [                "admin_task_project",                "algo_public",                "algo_test"]
        },        "reserved": {},        "taskType": "SQL_RELATIVE_TASKS"}

每种Task都有独立的用户特征分组信息（Tier）；考虑MaxCompute的多控场景和各控制集群独立的包管理器方式，灰度配置信息上多加了一层控制集群维度，每个控制集群对Task灰度发布共享Tier分组信息，独享灰度配置信息；

Tier配置

Tier是MaxCompute灰度配置的最小粒度，可以对每个Tier设置不同的流量分流信息grayInfo和控制集群维度下的共享Mapping信息。grayInfo信息配置了流量在不同版本上的分流情况，所有隶属于该Tier的project的该种job都按照这个配置进行流量分流；Mapping信息设置了版本Tag到实际的Task Package version的映射，特别的，每个Tier也可以设置独立的Mapping信息，Load灰度配置时，优先使用Tier的Mapping信息。Tier的私有Mapping设置是通过保留字段进行扩展的，如下：

"tierGrayInfo": {    "DEFAULTTIER": {        "grayInfo": {            "defaultVersion": 80,            "flightingVersion": 20},        "reserved": {            "defaultVersion": "tom",            "flightingVersion": "jerry"}
    }
}
升级/回滚

鉴于线上MaxCompute多控集群现状，且每个控制集群都有独立的包管理器，在升级/回滚时需要考虑MaxCompute框架和Task package的兼容性等问题，需要对灰度元信息进行一定的处理：

元数据升级&回滚
Tier分组信息保留
Tier流量分流重置目标集群

版本管理

MaxCompute flighting解耦了MaxCompute框架和Task，理论上各功能块可独立管理发布，这给MaxCompute的发布管理带来了挑战， 考虑兼容性，MaxCompute对版本管理做了如下约定：
1） MaxCompute框架随Sprint大版本进行发布，并且在Sprint发布时强行进行一次与各Task的版本对齐，携带各Task Package的default版本；
2） 后发布的对兼容性负责；
3） 每种Task有两个正式大版本default和flighting，default随每个sprint发布，flighting在需要对Task进行灰度发布时发布；
4） 固定使用default记录Task发布历史，灰度发布成功的版本需要重新提交成default的一个新的小版本；

配套设施

MaxCompute Task灰度发布涉及到多个工具，包括Task Package的部署工具，灰度配置工具（Admin Task）以及灰度过程中衡量灰度结果的统计工具和监控报警工具。

包部署工具：

OPDS flighting开发了独立的Task Package部署工具package_util，可用于管理Task的控制集群包和计算集群包；通过它可对Task Package进行deploy & rollback等操作；

灰度配置工具：

OPDS的Task灰度配置元信息存储在OTS中，需要使用Admin Task命令实现对灰度配置修改的目的，目前支持的命令如下：

  • 初始化某类型的Task灰度配置；

  • Tier的CRUD；

  • 修改集群标签下的共享Mapping；

  • 修改Tier的流量配置；

  • 修改Tier特定的Mapping；

  • 升级/回滚时是否清楚灰度进度信息；

衡量灰度的指标和监控报警：
MaxCompute Task灰度发布的结果衡量有两个层面，一个是框架层面普遍一般的统计，如task的成功率/失败率，通过与default版本的对比，来进行评估；另一个是Task层面做的专业的评估。框架层面的评估会比较笼统简单，更专业、复杂的评估需要Task层面去进行。MaxCompute框架使用shennong”实时“的输出统计，如下：
screenshot
screenshot

灰度使用场景

Task灰度发布：

1） PE初始化灰度信息；对project进行Tier分组；制定灰度发布方案和应急回滚方案；
2） PE使用flighting版本，部署预进行灰度发布的Task Package；
3） PE按照方案操作更新Tier灰度配置，按部就班的实施灰度发布
4） 开发和PE通过统计和监控工具实时关注灰度进展，根据灰度结果判断继续灰度还是停止灰度；

线上灰度测试：

1） PE初始化灰度信息；创建灰度测试专用的Tier分组，制定测试方案和应急回滚方案；
2） PE部署预进行灰度测试的Task Package；
3） PE按照测试方案设置Tier灰度配置，包括Mapping，分流信息；
4） 开发通过统计和监控工具实时关注灰度测试进展，根据灰度结果判断测试继续还是停止灰度

开发环境可以使用set忽略灰度配置，指定使用固定版本

set MaxCompute.task.major.version=tom;
灰度信息使用：

MaxCompute MaxCompute_worker定时读取灰度配置到灰度判决cache中，间隔为1 min，当有job请求到MaxCompute_worker时，在向executor发出TryRun前使用灰度缓存中的信息判断该请求去往的具体Task package版本，使用规则如下：
1） 优先判断是否使用SET optin 设置task版本，如是使用指定版本进行后续请求；
2） 未使用SET，根据project所在的Tier，获取Tier的Mapping和分流信息，根据分流信息比例确定目标Task版本；
3） 如果目标版本未部署则会对到default

结语

MaxCompute 的Task灰度发布总的来说，配置灵活操作便捷，能够满足目前MaxCompute的Task的灰度发布需求，灰度元数据在设计上考虑了后续的扩展，保留了足够的扩展的能力；在MaxCompute Task灰度发布实践上，MaxCompute发布管理团队提出了流量桶的灰度发布方式，固定个Tier的流量配置信息，将需要灰度的project逐批次的修改归属的Tier，形象点就是将不同的project放入不同流量的桶中。MaxCompute 灰度发布的后续展望，希望开发能够在一定审核下自主的部署日常灰度测试的package，简化当前审批部署流程，提高效率。