全链路灰度发布系统
点击蓝字 关注我们
作者简介
李连勇，2019年3月加入去哪儿网，现负责国内机票报价团队，此前在多家知名电商从事后端架构工作，涉及商品，订单，支付等核心系统，对高并发高性能系统有大量优化实践经验。
1 背景
灰度发布是业界一种规避发布风险的有效手段，常见的做法基本都需要进行灰度环境隔离，不管是硬件隔离还是软件隔离，在实施的时候都代价高昂，维护成本极高，同时因为机票业务的复杂性，因发布导致的故障层出不穷，迫切需要一种简单可行的灰度发布方案。
2 业界常用方案
为了灰度环境的可评估性，灰度环境必须是隔离的，在实现这种隔离性上，主要有以下两种方式。
灰度机器隔离
实施描述：物理隔离一整套灰度环境，并且承接线上流量。
图-1
优点：对应用改动少，支持监控隔离，流量路由，人工验证；
缺点：实施成本高，后续维护成本高难度大。
软路由流量隔离
实施描述：利用软负载路由逻辑隔离灰度环境。
图-2
优点：不增加额外成本，支持监控隔离，流量路由，人工验证；
缺点：应用改造大，风险高。
3 我们的方案
鉴于硬件隔离在复杂系统的不可维护性，我们还是主要考虑软路由隔离，只是方式我们有很多不一样的地方。
3.1 思考过程
从目标开始：小流量尽可能发现发布风险。
如何定义小流量？常用的有用用户，航线等具体业务属性或随机流量来划分比例。比如1%，5%，10%等。
这样势必会考虑流量路由到指定环境，有什么办法能避免这个呢？我们的答案是把流经灰度机器的流量视为小流量。
图-3
流经灰度机器B1的流量都认为是灰度流量。那接下来怎么自动识别灰度流量的业务情况正常与否呢？我们的答案是业务监控。只要把灰度流量的监控能单独区分，通过灰度监控的波动即可判断灰度发布是否正常。
图-4
图-5
正常核心监控都有哪些监控？看上图，图4：业务量监控 ；图5：业务结果监控 灰度监控应该关注哪些监控？灰度监控更应该关注的是业务结果监控。
以上构成方案的两大理论基础：
1、灰度流量用流经特定机器的流量标识
2、监控更关注业务结果监控
3.2 总体方案成型
图-6
方案整体接入只需要0.5pd，就让系统具备灰度发布的能力。
灰度发布流程：如下图-7，发布必须发布灰度机器，并且灰度监控必须正常才能发布全量机器。
图-7
灰度发布自动化监控：如何判断灰度监控是否正常呢？我们提供自动化监测手段。
只要你发布了灰度机器，灰度系统会自动监测并开始分析发布前后的灰度指标，如果通不过自动化监测，会给出如下提示，并且拦截全量发布。
图-8
3.3 原理介绍
灰度流量标识如何在系统间传递？
向下传输借助全局trace组件
向上传输（协议相关）：
Dubbo：attachment Http：http head
mq：不需要向上传输
灰度流量标识如何在系统内传递？不传递，申请trace级全局内存。
图-9
全局内存如何避免内存泄漏或OOM呢？考虑这块全局内存的实际场景，我们有两个措施保证：
1、总量控制，这个总量就是最大单机并发数，我们默认设置为5124。
2、超时清理，一次用户端RPC最多忍受也就是30s，我们默认设置为60s。
为啥不通过请求开始和结束管理这块内存的生命周期呢？答案是比较难，底层请求可能是同步，异步，回调，mq等各种形式，不能早删不能晚删不如不删。
依赖以上两点，摆脱对底层请求方式复杂性的依赖。
灰度流量如何监控隔离？借助监控系统的tag功能，灰度流量打上特定tag即可。效果如下：
图-10
4 方案总结
End