【架构师系列】真正的灰度发布
究竟什么才是灰度发布其实并没有一个严格的标准，因为这个东西不是黑的也不是白的是个中间过渡地带，这类的东西定义都会比较麻烦。由于工作的原因看到好多友商所谓的灰度发布产品，有意思的是他们实现的是完全不一样的功能，对外都说自己是灰度发布。我看到的有三种：
1. 更新过程可以暂停，停在一个既有新版本又有旧版本的状态，然后选择升级或者回滚
2. 支持流量比例分配，可以把百分之几的流量分配给一个服务，剩下的给另一个服务
3. 支持 url 路径流量分配，一个路径下的流量给一个服务，另一个路径流量给另一个服务
那究竟哪个才能算是灰度发布呢？抛开具体的技术实现，让我们从需求的角度来考虑一下为什么要有灰度发布？灰度发布究竟是要做什么？从目的出发再来看技术实现就会清晰很多。
既然要灰度就是不希望所有人都看到，就是为了控制影响范围，之所以要做这种限制就说明发布的人心里对这个发布的版本就是不确定的，害怕影响范围太大风险不可控。也就是说这个风险因素在开发和测试环境都没有办法控制，只能在生产环境来观察，那究竟是怎样的因素会导致必须要上线观察而不是在开发测试环节来解决呢？主要有从运维和产品两大方面的考量因素。
【架构师系列】真正的灰度发布
从运维的角度讲，任何一次上线都是有风险的，或者有一些步骤的遗漏，流程的不规范，或者有一些隐藏的代码 bug都会导致线上的不稳定。控制风险的办法就是小批量上线，验证之后在全部更新。此外一些稳定性和性能的问题在开发测试环境很难复现，因此这一类的修复和功能只能到生产环境来验证，同样由于效果的未知也不可能全量更新。再有一些大的重构，比如编程语言的变化，框架的变化，基础库的更新，操作系统的更新都会有未知的影响，而这些影响也需要生产的检验。
从产品的角度讲，有一些产品设计，交互，界面展现形式都不是坐在办公室里拍桌子就可以定出最佳实践的。产品经理的视角和用户的视角是不同的，即使是产品经理之间的风格，偏好也是不一致的。小到按钮的顺序，弹框展示的位置，大到页面整体的布局，广告位的展示策略，究竟用哪种设计更好并没有理论上的最佳实践。而这种情况就需要大家分别作出自己的方案，去线上收集真实的用户数据作对比。也就是硅谷里常说的 A/B testing，也可以归到灰度发布的范畴。本质上就是基于数据驱动来作抉择，在用户的投票中选择哪种方案，而不是传统的看谁嗓门大会拍桌子，看谁官大来做决策。
了解了需求，我们就很容易推导出所有人都在说的灰度发布真正是什么了。
【架构师系列】真正的灰度发布
1. 精确的流量分发控制
这是一切的核心，从运维风险控制的角度，需要把受影响的流量控制在一个精确的范围内，在上线前就知道哪部分用户会有问题，而不是真出问题谁受到影响都不知道。一个常见场景是新版本只让公司内部的员工能访问到，再一个市，一个省的一点点推上去。从产品角度看要做 A/B test，就需要控制测试样本，哪些用户是 A 版本，哪些用户是 B 版本，在发布后应该就是固定的，而不是一个用户一会儿访问 A，一会儿访问 B。而传统的负载均衡器策略只能做到粗犷的比例分配，并没有细粒度的流量规则控制。而一个理想的灰度发布系统应该有很细粒度的流量规则，比如匹配 android 用户，匹配某个地区的用户，甚至能组合多种条件匹配到特定的人群。
2. 监控系统的支撑
流量精确分配只是第一步，接下来更重要的是获得多个版本的关键指标。对运维来说可能是看错误率，吞吐量，延迟，cpu 内存消耗这些系统层面指标。对于产品来说可能是要看点击率，pv，uv 等业务指标的变化。这些都需要能把数据收集并作展示，来方便后续决策：全量推还是回滚？使用方案 A 还是 B？不然的话灰度发布带来不了更多业务方面的促进，也不能帮你更好的了解业务的状态和用户行为。
3. 灵活的发布系统
从上面的介绍可以看出灰度发布并不是个短暂的过程，可能会持续很久。例如某个重大的框架或者系统更新可能会持续很久，有可能整个服务在几个月内都是新旧并存，甚至有可能需要两个版本分别各自迭代。而从产品的角度来看可能就会更灵活，很有可能线上有五六个方案都在收集数据，每天有了一些新想法都要上一些小版本看效果，每个版本上线后可能都要再各自做优化调整观察效果。这种情况可能线上就永远不会有一个统一的版本灰度反而是个常态来应对不断变化的需求和挑战。而发布系统也需要做相应的调整，不在把每个服务看成一个单一版本的运行体，只在更新的短时间内出现多版本共存，只允许全量推和回滚这种粗粒度策略。而是应该将多版本共存看成常态，允许每个版本各自迭代，版本之间又能区分对应的监控日志信息，这样灵活的发布系统才能配合灵活的灰度策略。
说了这么写灰度系统要做的事情其实就是流量控制和数据收集，来控制风险并帮助产品做决策。再看一下最开始提出的三个所谓的灰度发布：更新过程可以暂停，流量比例分配，url分流。它们充其量也只是做到了流量精确分配的某几个特殊情况，而且还都是不很精确的分配。而如果结合使用场景就会发现，这几种在实际中是很难用起来的，因为没有流量的精确控制很难控制风险范围，如果风险都不可控，那还要灰度发布干什么呢？更不要提后面的监控数据收集和灵活的发布了。
【架构师系列】真正的灰度发布
所以说一个真实好用的发布系统是十分复杂的，绝对不是页面上点两三下就可以完成的，而后面的实现更需要一整套体系来支撑。如果你想打造一个灰度发布系统，希望这篇文章能对你有所启发。
