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

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

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

1. 发布策略定制

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

2. 流量配比

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

3. 日志与监控

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

4. 快速回滚

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

5. 告警功能

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

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