牛逼，CTO点名要搞个灰度发布系统

“

互联网产品须要快速迭代开发上线，又要保证质量，保证刚上线的系统，一旦出现问题能够很快控制影响面，就须要设计一套灰度发布系统。

 

图片来自 Pexels

 

 

灰度发布的定义

 

灰度发布系统的做用，能够根据配置，将用户的流量导到新上线的系统上，来快速验证新的功能，而一旦出现问题，也能够立刻的修复，简单的说，就是一套A/B Test系统。 灰度发布容许带着 Bug 上线，只要 Bug 不是致命的，固然这个 Bug 是不知道的状况下，若是知道就要很快的改掉。

简单灰度发布系统的设计

灰度简单架构如上图所示，其中的必要组件以下：

• 策略的配置平台，存放灰度的策略

• 灰度功能的执行程序

• 注册中心，注册的服务携带 ip/Port/name/version

有了上面三个组件，才算一个完整的灰度平台。

灰度的策略

灰度必需要有灰度策略，灰度策略常见的方式有如下几种：

• 基于 Request Header 进行流量切分

• 基于 Cookie 进行流量切分

• 基于请求参数进行流量切分

举例：根据请求中携带的用户 uid 进行取模，灰度的范围是百分之一，那么 uid 取模的范围就是 100，模是 0 访问新版服务，模是 1~99 的访问老版服务。

灰度发布策略分为两类：

• 单策略：好比按照用户的 uid、token、ip 进行取模。
  

• 组合策略：多个服务同时灰度，好比我有 A/B/C 三个服务，须要同时对 A 和 C 进行灰度，可是 B 不须要灰度，这个时候就须要一个 tag 字段，具体实如今下文详述。

灰度发布具体的执行控制

在上面的简单灰度发布系统架构中咱们了解到，灰度发布服务分为上游和下游服务。

 

上游服务是具体的执行灰度策略的程序，这个服务能够是 Nginx，也能够是微服务架构中的网关层/业务逻辑层，下面咱们就来分析一下不一样的上游服务，如何落地。

Nginx

若是上游服务是 Nginx，那么就须要 Nginx 经过 Lua 扩展 Nginx 实现灰度策略的配置和转发，由于 Nginx 自己并不具有灰度策略的执行。

 

经过 Lua 扩展实现了灰度策略的执行，可是问题又来了，Nginx 自己并不具有接收配置管理平台的灰度策略，这个时候应该怎么办呢？

 

解决方案：本地部署 Agent（须要本身开发），接收服务配置管理平台下发的灰度策略，更新 Nginx 配置，优雅重启 Nginx 服务。

网关层/业务逻辑层/数据访问层

 

只须要集成配置管理平台客户端 SDK，接收服务配置管理平台下发的灰度策略，在经过集成的 SDK 进行灰度策略的执行便可。

灰度发布复杂场景

下面举例两个稍微复杂的灰度发布场景，灰度策略假设都按照 uid 取模灰度百分之一的用户，看一下如何实现。

 

场景 1：调用链上同时灰度多个服务

 

功能升级涉及到多个服务变更，网关层和数据访问层灰度，业务逻辑层不变，这个时候应该如何进行灰度？

 

解决方案：通过新版本网关层的请求，所有打上 tag T，在业务逻辑层根据 tag T 进行转发， 标记 Tag T 的请求所有转发到新版数据访问层服务上，没有 tag T 的请求所有转发到老版数据访问层上。

场景 2：涉及数据的灰度服务

 

涉及到数据的灰度服务，必定会使用到数据库，使用到数据库就会涉及到你使用数据库先后的表字段不一致，我老版本是 A/B/C 三个字段，新版本是 A/B/C/D 四个字段。

这时新版的灰度，就不能往老版的数据库进行修改了，这个时候就须要把数据 copy 一份出来作这个事情了。

 

数据库其实并无灰度的概念，这个时候咱们只能把数据从新拷贝一份出来进行读和写。

 

由于这时你的写必须是全量的（双写），不能说 90% 的数据写入到老版本，10% 的数据写入到新版本，由于这个时候你会发现两个数据库的数据都不是全量的。

 

离线全量复制数据的过程当中必定会有数据丢失，这个时候就须要业务逻辑层写一份数据到 MQ 中。

 

等数据同步完成以后，新版的数据访问层再将 MQ 的数据写入到新版本的 DB 中，实现数据的一致性，这个也是引入 MQ 的主要目的。

灰度过程当中须要对两个数据库的数据进行对比，观察数据是否一致。这样无论是灰度失败，放弃新版 DB，仍是灰度成功切换到新版 DB，数据都不会产生丢失。

 

做者：小杨互联网

编辑：陶家龙

出处：toutiao.com/i6910008843955192323/