互联网产品既要快速迭代开发上线，又要保证刚上线的系统质量。一旦出现问题，可以快速控制影响，因此需要设计灰度发布系统。图片来自定义Pexels灰度发布。灰度发布系统功能可以根据配置将用户的流量引导至新上线的系统，快速验证新功能。一旦出现问题，可以立即修复，简单。说白了，就是一个A/BTest系统。灰度版本允许有bug上线，只要bug不是致命的。当然，如果是未知的bug，知道了一定要赶快改正。简单的灰度发布系统设计灰度的简单架构如上图所示，需要的组件如下：一个策略配置平台，一个存储灰度策略和灰度函数的执行程序注册中心，注册的服务承载ip/port/name/version有了以上三个组成部分，就算是一个完整的灰度平台了。灰度策略Grayscale必须有一个灰度策略。常用的灰度策略方法如下：基于RequestHeader的流量分割基于Cookie的流量分割基于请求参数的流量分割示例：根据请求中携带的内容对用户uid取模，灰度范围为1%，则uid取模范围为100，取模0访问新版本服务，取模1~99访问旧版本服务。灰度发布策略分为两类：单一策略：比如根据用户的uid、token、ip取模。组合策略：多个服务可以同时灰度化。比如我有A/B/C三个服务，需要同时灰度A和C，但是B不需要灰度。这时候就需要一个tag字段。具体实现详见下文。灰度发布的具体执行控制从上面简单的灰度发布系统架构我们了解到，灰度发布服务分为上游服务和下游服务。上游服务是执行灰度策略的具体程序。这个服务可以是Nginx，也可以是微服务架构中的网关层/业务逻辑层。让我们分析一下不同的上游服务是如何实现的。如果Nginx的上游服务是Nginx，那么Nginx需要通过Lua扩展Nginx来实现灰度策略的配置和转发，因为Nginx本身并没有灰度策略的执行。灰度策略的执行是通过Lua扩展实现的，但是问题又来了。Nginx本身没有接收配置管理平台的灰度策略。接收服务配置管理平台下发的灰度策略，更新Nginx配置，优雅重启Nginx服务。网关层/业务逻辑层/数据访问层只需要集成配置管理平台客户端SDK，接收服务配置管理平台下发的灰度策略，通过集成的SDK执行灰度策略。复杂的灰度发布场景下面给出两种稍微复杂一点的灰度发布场景。灰度策略假设灰度模型百分之一的用户是按照uid建模的。让我们看看如何实现它。场景一：调用链上同时升级多个服务功能，涉及多个服务变更。网关层和数据访问层变灰，业务逻辑层不变。这个时候应该怎么进行灰度化呢？解决方案：新版本之后网关层的所有请求都打上tagT，在业务逻辑层根据tagT转发。所有打上TagT的请求都转发到新版本的数据访问层服务，并且所有没有标签T的请求都被转发到旧版本的数据访问层。场景二：涉及数据的灰度服务涉及数据的灰度服务，肯定会用到数据库。使用数据库会涉及到你使用数据库前后不一致的表字段。我的旧版本是A/B/C。字段，新版是A/B/C/D四个字段。此时新版本的灰度无法修改为旧版本的数据库。这时候就需要复制数据来做这件事了。其实数据库没有灰度的概念。这时候我们只能将数据重新拷贝一遍进行读写。因为此时，你的写法必须是满的（双写）。不能说90%的数据写到老版本，10%的数据写到新版本，因为这时候你会发现两个数据库的数据都不是全量的。在离线全量拷贝数据的过程中，会出现数据丢失的情况。这时，业务逻辑层需要向MQ写入一份数据。数据同步完成后，新版本的数据访问层会将MQ数据写入新版本的DB中，实现数据的一致性。这也是引入MQ的主要目的。在灰度过程中，需要对比两个数据库的数据，看数据是否一致。这样无论灰度失败，放弃新版本DB，还是灰度成功切换到新版本DB，数据都不会丢失。作者：小杨网络编辑：陶家龙来源：toutiao.com/i6910008843955192323/
