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

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

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

1. 发布策略定制

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

2. 流量配比

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

3. 日志与监控

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

4. 快速回滚

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

5. 告警功能

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

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