随着移动云业务的快速发展，移动云省公司和区域的迁移实施团队对于上云迁移标准化能力的需求日益旺盛，为满足上述发展的需求，自2021年以来云迁移产品的迭代非常迅速，上线也较为频繁。若基于传统的上线发布方式，比较容易暴露出上线失败、发布时间长、晚上测试发布等情况，云迁产品研发团队，为了提高迁移产品的上线发布效率且保证上线后的功能稳定，自加难度，开展了“全链路灰度发布”的研究与落地实践。
云迁移产品的全链路灰度发布过程覆盖了如下四个关键环节：
通过全链路灰度发布与自动化部署，云迁移产品在上线过程的各方面有了显著的提高与改善，本文将回顾云迁移产品全链路灰度发布与自动化部署改造历程，并对云迁移产品全链路灰度发布方案进行总结分享。
一、全链路灰度发布-方案篇
云迁移产品的架构为前后端分离架构，服务部署通过容器化实现Kubernetes集群部署，数据交互全部通过服务间调用，这为云迁移产品实现全链路灰度发布与自动化部署提供实施基础。
云迁移产品全链路灰度发布能力通过对业务流量进行染色，联合网关、负载均衡、服务框架等多个组件，实现染色流量按标签进行路由，支持跨应用、跨节点的全链路灰度路由能力。
1 用户服务层，流量染色
用户终端、迁移主机、迁移对象存储在云迁移产品中统称为用户服务层，该层为业务流量的起点，所有请求流量在这进行流量染色，实现业务上的正常流量与灰度流量的区分。
2 请求接入层，流量流转
统一中心网关/属地网关、云迁移产品负载均衡为第二层：请求接入层。
在这里，请求流量会首先经过统一中心网关，中心网关根据识别到的特点请求头部对流量进行属地识别，之后转发至各属地网关。
请求流量在到达属地网关后，依据请求的地址，属地网关会将流量转发至云迁移产品负载均衡地址中，以此实现了网关的流量转发。
云迁移产品负载均衡在收到请求流量后，将流量转发至Kubernetes的Ingress服务中，此时染色流量到达产品业务服务中。
3 业务服务层，流量识别
业务服务层是云迁移产品业务所在的最后一层。云迁移产品灰度发布通过Kubernetes的Ingress服务实现了业务服务、数据服务的正常业务与灰度业务环境。通过识别已染色的流量，将染色流量提交灰度服务进行处理，未染色的流量提交正常服务处理。
同时，灰度服务对接灰度的数据服务，正常服务对接正常的数据服务。正常服务的数据会每隔一段时间同步至灰度数据服务中（灰度服务的数据多为测试数据，不再会同步至正常数据服务中）。
二、全链路灰度发布-落地篇
1 接入层–流量灰度路由
云迁移产品Kubernetes的Ingress服务通过识别流量中的灰度标签，把灰度流量路由发送至对应标签的灰度环境，实现灰度流量的第一级分发。
Ingress配置（样例）：
nginx.ingress.kubernetes.io/canary-by-header: "XXX"
nginx.ingress.kubernetes.io/canary-by-header-pattern: "XXX"配置文件中的nginx.ingress.kubernetes.io/canary-by-header与nginx.ingress.kubernetes.io/canary-by-header-pattern是灰度流量的然后规则，依据请求流量中的标签是否与Kubernetes的Ingress服务一致来区分流量是否是灰度流量。
2 核心层–业务灰度路由
灰度请求流量流转到云迁移产品的业务层服务节点后，后续流量就由服务框架代管，通过Django框架内部协议流转，服务框架的标签路由层会自动识别本次请求是否携带灰度流量标识，并筛选特定的灰度环境并转发请求。
同时，云迁移产品实现了数据端灰度与配置端灰度，灰度/正常数据完全区分，实现了现网影响程度更低的全链路灰度发布。
业务YAML配置（样例）：
kind: XXX
apiVersion: v1
metadata:
name: ssc-backend-cm-gray
namespace: ssc以上配置中，主要是对metadata.name参数进行不同的命名，以此来区分不同的环境，同时，通过配置的灰度，实现灰度环境与现网环境连接不同的数据服务。
数据连接配置（样例）：
# 使用Mysql作为数据库
DB_NAME: db_example
# Redis配置
REDIS_CELERY_BROKER_DB: 1
REDIS_CELERY_BACKEND_DB: 2
REDIS_DB_CACHE: 3
# MQ配置
ROCKET_MQ: False数据连接配置中，通过对Mysql的DB_NAME、Redis的REDIS_CELERY_BROKER_DB、REDIS_CELERY_BACKEND_DB、REDIS_DB_CACHE配置不同的数据地址，实现灰度数据的访问。其中，为确保订购数据准确，灰度环境通过配置ROCKET_MQ为False，禁止了订单数据的获取，保证灰度环境不发生订购，保证订购数据只在正常环境产生。
3 组件级别的灰度支持
云迁移产品在实践中发现，产品的每次发布上线，不一定要求所有业务服务都需要更新，部分业务模块的更新需要支持，即需要解决灰度流量和原业务流量共存兼容的问题。另外，如果每次都需要全部更新所有的业务，灰度发布工作也会变得十分繁杂，为此，云迁移产品实现了灰度环境与正常环境兼容研究，采取了降级的“组件级的服务灰度发布方案”。
基本的思路：当链路中存在服务节点灰度标识无法匹配灰度请求标识，则灰度请求在该节点通过正常节点处理，保证灰度标识能继续向下游传递。保障系统高可用能力，防止流量找不到对应标识节点而出现流量流转失败的情况。
三、全链路灰度发布-集成自动化部署
自动化部署即部署的过程中所有的操作全部自动化，无需人工手工干预。在没有接入统一自动化部署前，云迁移产品的上线发布的部署方式，存在众多缺点：
- 整个过程都需要人员参与，占用大量的时间，效率低下
- 上线、更新、回滚速度慢
- 存在一定的管理混乱，人为误操作的机率增大
今年8月，云迁移产品接入统一自动化部署平台，结合当前的全链路灰度发布至自动化部署后，产品的上线效率和成功率得到进一步的提升。
- 收益良多：
完成了全链路灰度发布和自动化部署，云迁移产品线当然受益良多，在上线成功率、问题暴露、上线时长等方面均得到全面明显的提升。
维度 | 实践前 | 实践后 |
上线成功率 | 98% | 100% |
上线问题暴露 | 0.1/次 | 0 |
上线时长 | 2-3小时 | 1小时以内（包含验证） |
灰度支持 | 无 | 100%灰度发布 |
四、总结与展望
目前云迁移产品基于“全链路灰度发布”的机制已稳定运行至今。截止目前，云迁移产品已实现本年度10余次发布全部通过灰度发布流程，并实现了其中5次发布通过全链路灰度发布，3次全链路自动化灰度发布，灰度发布覆盖目前全部13个资源池节点。降低了各应用实现灰度发布的改造人力成本及灰度环境建设难度，提高了研发效率，最终实现了跨应用、跨服务的一致性灰度发布能力。
随着云迁移产品架构的持续推进，云迁移产品将持续构建以主机和平台双核心的迁移保障系统，保证迁移服务的稳定运行，支撑迁移业务快速增长。以“开放性、高容量、易扩展、成本可控、安全稳定、便捷研发”为研发理念，在全链路灰度发布领域积极推动技术创新、管控升级，覆盖云迁移核心链路场景，持续完善全链路灰度发布模式，减少应用发布成本，提升全链路灰度发布中各组件兼容适配能力，以适应复杂的业务场景，为移动云的业务迁移上云提供有力支撑。
