全链路灰度发布系统

1 背景

灰度发布是业界一种规避发布风险的有效手段，常见的做法基本都需要进行灰度环境隔离，不管是硬件隔离还是软件隔离，在实施的时候都代价高昂，维护成本极高，同时因为机票业务的复杂性，因发布导致的故障层出不穷，迫切需要一种简单可行的灰度发布方案。

2 业界常用方案

为了灰度环境的可评估性，灰度环境必须是隔离的，在实现这种隔离性上，主要有以下两种方式。

灰度机器隔离

实施描述：物理隔离一整套灰度环境，并且承接线上流量。

优点：对应用改动少，支持监控隔离，流量路由，人工验证；

缺点：实施成本高，后续维护成本高难度大。

软路由流量隔离

实施描述：利用软负载路由逻辑隔离灰度环境。

优点：不增加额外成本，支持监控隔离，流量路由，人工验证；

缺点：应用改造大，风险高。

3 我们的方案

鉴于硬件隔离在复杂系统的不可维护性，我们还是主要考虑软路由隔离，只是方式我们有很多不一样的地方。

3.1 思考过程

从目标开始：小流量尽可能发现发布风险。

如何定义小流量？常用的有用用户，航线等具体业务属性或随机流量来划分比例。比如 1%，5%，10%等。

这样势必会考虑流量路由到指定环境，有什么办法能避免这个呢？我们的答案是把流经灰度机器的流量视为小流量。

流经灰度机器 B1 的流量都认为是灰度流量。那接下来怎么自动识别灰度流量的业务情况正常与否呢？我们的答案是业务监控。只要把灰度流量的监控能单独区分，通过灰度监控的波动即可判断灰度发布是否正常。

正常核心监控都有哪些监控？看上图，图 4：业务量监控 ；图 5：业务结果监控 灰度监控应该关注哪些监控？灰度监控更应该关注的是业务结果监控。

以上构成方案的两大理论基础：

1、灰度流量用流经特定机器的流量标识

2、监控更关注业务结果监控

3.2 总体方案成型

方案整体接入只需要 0.5pd，就让系统具备灰度发布的能力。

灰度发布流程：如下图-7，发布必须发布灰度机器，并且灰度监控必须正常才能发布全量机器。

灰度发布自动化监控：如何判断灰度监控是否正常呢？我们提供自动化监测手段。

只要你发布了灰度机器，灰度系统会自动监测并开始分析发布前后的灰度指标，如果通不过自动化监测，会给出如下提示，并且拦截全量发布。

3.3 原理介绍

灰度流量标识如何在系统间传递？

向下传输借助全局 trace 组件

向上传输（协议相关）：

Dubbo：attachment Http：http head

mq：不需要向上传输

灰度流量标识如何在系统内传递？不传递，申请 trace 级全局内存。

全局内存如何避免内存泄漏或 OOM 呢？考虑这块全局内存的实际场景，我们有两个措施保证：

1、总量控制，这个总量就是最大单机并发数，我们默认设置为 5124。

2、超时清理，一次用户端 RPC 最多忍受也就是 30s，我们默认设置为 60s。

为啥不通过请求开始和结束管理这块内存的生命周期呢？答案是比较难，底层请求可能是同步，异步，回调，mq 等各种形式，不能早删不能晚删不如不删。

依赖以上两点，摆脱对底层请求方式复杂性的依赖。

灰度流量如何监控隔离？借助监控系统的 tag 功能，灰度流量打上特定 tag 即可。效果如下：

4 方案总结

头图：Unsplash

作者：李连勇

原文：全链路灰度发布系统

来源：Qunar 技术沙龙 - 微信公众号 [ID：QunarTL]

转载：著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。