关于灰度发布的探讨

前言

灰度发布，大家可能并不陌生，这是很多互联网行业上线的必经一环，但是这里说的广义的“灰度”发布，可能并不仅仅是发布上线，比如配置的灰度变更等等，这里主要对于笔者遇到的情况做一个整理。

前端的灰度

这个很好理解，比如京东、滴滴打车等这些微信小程序，在开发完成后进行发版本，可以控制放量，比如先灰度 10%的人群，那么只有10%的人群可以看到最新的小程序功能，剩余的还是看不到。

也正是这种方式，在前端也可以做验证、回滚。
笔者认为，这也是小程序优于APP的地方，可以灰度，可以随时回滚。

服务端的灰度

这里重点说两部分：
一个是服务端正常灰度发布上线 和 另一部分服务端配置变更，各个业务上游如何灰度同步。

服务端正常灰度发布上线

先看服务端正常灰度发布，这个很好理解，服务端代码做了变更，我有500+台机器要发布，虽然经过了严格的测试，但是仍然可能有没有测试到的地方，所以必须灰度部署。即按批次，先部署一台，观察一段时间，再部署10台，观察一段时间，再部署100台…
千万不要小看这个灰度发布，虽然简单，但是笔者的工作这些年间，不下3起由于没有灰度发布，导致资损的情况。

如图大家也知道，如果发布过程中，有问题，则可以第一时间回滚少量机器，将损失降到最小。

服务端配置内容灰度

大家可能会比较奇怪啊，上线都上完了，为啥还要对配置内容进行灰度呢？
其实这里场景主要源于两种：

一种是特别需要关注的配置，一个配置的改动可能对上游业务造成影响，从技术角度的影响比如由于一个配置的变动导致对某个服务的压力增大导致下游流量剧增甚至打挂。从业务角度讲，比如营销活动，改了一个配置我预期是在xx城市xx群里的人才能享受促销补贴，但是可能变动之后居然所有城市都享受了补贴，这种情况，可以在少数机器上验证，然后快速回滚到之前的配置，及时止损`。

另一种是类似平台的服务，我提供的策略、数据，完全是配置化的，上游拿到这些数据会做相关的业务处理，由于双方配置都比较灵活，所以必须在修改完配置，需要灰度生效。

在这些场景的背景下：也有两种灰度方式。

服务器集群灰度  和  上游调用方灰度。

服务器集群灰度 ：
这里针对所有的上游的情况，服务器要对所有上游调用的配置内容，做灰度配置，一旦生效，会生效所有的上游。

如上图，运营人员修改了配置，对于该服务机器集群，通过相应的灰度策略，只让服务器集群中个别机器，能够生效到配置的修改。观察一段时间：上游有没有反馈问题，服务器灰度机器是否有异常。一旦发现问题，可以一键操作配置回滚。

常用的策略比如按比例灰度／按照IP灰度等等。

客户端（调用方）集群的灰度
这种情况是，客户端集群之前是配置隔离的，且此刻是一个客户端集群需要变更自身配置，此时服务端已经确认无影响，就两套配置都存在，根据相关策略（比如客户端请求IP）进行灰度处理，保证客户端对新配置生效，当客户端全量配置无问题后，服务端将新配置替换掉旧配置，中间如果出问题，立刻回滚旧配置。

总结

这里主要跟大家介绍了一些常用灰度方案的系统，以及什么场景，这里并没有讲具体的实现，其实具体的实现，并不困难。欢迎大家拍砖交流～～