实现一套灰度发布系统需要考虑哪些问题？

仔细考虑一下灰度发布系统要达到哪些目的，基本就能有答案了。需要注意的是，客户端应用（无论PC端还是移动端）的灰度发布要比Web应用的灰度发布更为复杂，因为应用运行在用户持有的终端上，数据采集和回滚都更为困难（但可采集的数据类型要更加丰富）。

注：本人缺乏移动客户端产品的经验，下述内容可能不适用于移动客户端产品。

我所理解的灰度发布系统，主要任务是从产品用户群中按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的显式反馈（论坛、微博）或隐式反馈（应用自身统计数据），对新版本应用的功能、性能、稳定性等指标进行评判，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。从上述描述可以得出灰度发布系统需要具备的一些要素：

用户标识

用于区分用户，辅助数据统计，保证灰度发布过程中用户体验的连贯性（避免用户在新旧版本中跳变，匿名Web应用比较容易有这个问题）。匿名Web应用可采用IP、Cookie等，需登录的应用可直接采用应用的帐号体系。

目标用户选取策略

即选取哪些用户先行体验新版本，是强制升级还是让用户自主选择等。可考虑的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）。对于细微修改（如文案、少量控件位置调整）可直接强制升级，对于类似新浪微博改版这样的大型升级，应让用户自主选择，最好能够提供让用户自主回滚至旧版本的渠道。

对于客户端应用，可以考虑类似Chrome的多channel升级策略，让用户自主选择采用stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承担试用风险。

数据反馈

用户数据反馈：在得到用户允许的前提下，收集用户的使用新版本应用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对比，决策后续是继续扩大新版本投放范围还是回滚。

服务端数据反馈：新版本服务端性能、服务端稳定性等，作用与用户数据反馈类似。

新版本回滚策略

当新版本灰度发布表现不佳时，应回滚至旧版本。
对于纯粹的Web应用而言，回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用，如果期待用户自行卸载新版本另行安装旧版本，成本和流失率都太高。可以考虑通过快速另行发布新版本，利用升级来“回滚”，覆盖上次灰度发布的修改。

对于移动客户端，新版本发布成本较高，需要Appstore、Market审核。本人没有移动客户端产品的经验，不太确定移动客户端产品如何处理灰度发布及回滚。但尽量将客户端打造成Web App，会更有利于升级和回滚。（不过苹果对纯Web App类的App有较强的限制，好像已经不允许在Appstore上发布这类应用了？）

新版本公关运营支持

对于改版级别的大型升级，需要配合公关运营支持，用于及时处理用户在微博、博客等渠道给出的“显式反馈”。对比通过隐式数据反馈得到的结论后，综合考虑应对策略。

要了解一个灰度发布系统的功能，个人觉得有必要先了解灰度发布的概念定义和灰度发布流程，从概念和流程中明确灰度的目的并梳理出流程中系统工具可以支撑的地方，那么实现一套发布系统需要考虑的地方也就清楚了。灰度发布的目的首先是为了应用从老版本升级到新版本的时候能做到平滑升级，升级过程中通常会先按照一定发布策略选取部分用户流量，先行请求新版本的应用，通过收集这部分用户对新版本应用的反馈，以及新版本应用实例本身的日志、性能、稳定性等指标来评审新版应用。根据评审情况，决定是否继续增加新版本的应用实例和流量占比，直至全量升级，或者发现问题回滚至老版本。对应的灰度发布流程图如下：

根据以上的灰度发布的概念和流程定义，一套灰度发布系统需要我们考虑的问题也就一目了然。

1.发布策略定制

新版本应用的部署在灰度发布流程中往往会分多个阶段，并逐渐增加实例数，例如一次灰度发布一共分3个阶段，新版本的部署实例数量会在3个阶段中逐渐增加，从10个、50个一直增加到100个。这样做是为了保证应用整体功能的稳定运行，在每个阶段结束时我们都可以观察评审新版本的效果，根据阶段发布效果来决定是否继续增加新版本的实例，或者在发现问题的时候采取策略回滚。另一方面，为了增加发布流程的自动化程度，灰度发布系统会考虑支持在不同阶段之间增加自动化执行的功能，当然用户也会有阶段之间加入人工审核的需求需要灰度发布平台支持。因此支持定制多阶段发布策略的功能对灰度发布系统来说是必要的。

2.流量配比

在灰度发布流程中，当流量入口的负载均衡策略是简单的按实例数均衡分配的话，那不同应用版本处理的流量比就是实例数量比，但在一定场景下这样实现就限制了用户流量配置的使用方式，例如假设用户受到资源限制想用较少新版实例来处理较大的流量比例就做不到了。灰度发布平台还是需要考虑应用新旧版本流量配比的功能，这样结合上一点中提到的定制发布策略的功能，用户能够对新版版本处理的用户流量比实现更加精确的控制。像网易轻舟产品实现的灰度发布功能，已经实现了与服务网格（service mesh）技术的协同，能够精确控制每个应用版本的流量配比。

3. 日志与监控

在灰度发布流程的每个阶段，发布人都需要根据当时新版本的运行情况来决定后续是继续升级流程还是发现问题直接回滚，而灰度发布系统就需要为用户提供尽可能多的判断指标和参考数据，例如需要支持用户查看部署实例的运行日志，以及提供CPU、内存使用率、网卡流量等监控数据来为新版应用的功能和稳定性判断提供依据。

4.快速回滚

对部署系统来说，应用的任何一次上线升级都需要具备快速回滚的能力，以便当出现问题能够及时恢复老的稳定版本，控制损失。回滚功能具体要实现新版实例的下线或删除，老版实例的重新创建，以及流量重新切换到老版本。

5.告警功能

发布系统需要对整个发布流程负责。在对接用户的过程中，本人也碰到过用户反馈灰度过程新旧版本共存时间较长，希望对未完成的灰度流程给出即时告警的需求，例如一些移动端app的新版本上线后，需要运行一段时间，来调研获取用户对新功能的反馈，这时候发布系统如果能够及时提醒用户当前未完成的灰度发布流程，以及流程中的新旧版本应用信息就显得十分必要了。另一方面，发布系统也需要及时对监控指标给出告警，比如由于新版本上线导致的CPU使用率、内存使用率上升的情况能够及时通知发布人员进行处理。

从网易云多年的devops产品设计和开发经验来看，以上五点是一个灰度发布系统必不可缺的，目前网易轻舟devops产品正是按着这些要求实现了主机和容器的灰度发布功能，当用户在轻舟平台上进行灰度发布的时候，能够定制发布时每个阶段新老版本实例比例和流量比例，同时控制每个阶段结束时系统自动入下一阶段或者人工审核操作的关键节点，一旦发现问题，支持用户快速回滚，同时系统也对接了应用日志和监控数据查看、告警通知、应用版本管理、制品管理等功能，实现了应用发布的闭环管理。

实现一套灰度发布系统需要考虑那些问题？在回答这个问题之前需要注意的是：以产品迭代优化为主要目的的灰度发布系统和以流程质量控制为目的的运营性质的灰度发布系统是不太一样的。

如果是以产品优化为目的，那么一个比较完善的 A/B 测试系统是必须的，它包括了三大部分：
1.一个用户分流和功能（灰度）发布系统，可以控制哪些用户看见/体验哪些新功能；
2.一个在线试验平台，和发布系统结合，可以同时创建和运行多个测试，验证产品的 idea；
3.一个数据分析系统，帮你科学地分析试验结果，得出正确的结论；

先别管用户体验，那些都是后话，最关键的是这两点：

1.回滚的时候不脏数据库

2.灰度导致的线上多版本不引起调用链出错。

如果被灰度的业务是个独立的，不影响其他系统的简单业务，其实很简单。

灰度系统需要尽可能的灵活，因为其最终目的主要是为了收集前端的用户体验。之前也看到基于后端的灰度方案，其实这个相对来说并不是灰度的本意。灰度系统的使用场景，无非是为了配合高节奏的产品上限频率，没有时间进行传统的穷尽是测试，所兴起的测试方法。所以，灰度系统的灵活性，对现有系统的很小的侵入性，是其最重要的特征。吆喝科技的灰度平台充分的体现了上述特征。http://www.appadhoc.com