服务灰度发布设计

灰度发布(又叫金丝雀发布)是互联网产品发布常用的一种方式，顾名思义，就是在黑和白之间平滑过渡的一种产品产品发布方式，产品发布者根据某种规则，让一部分用户继续使用原来的产品功能，另一部分用户逐渐启用新功能。在过渡过程中，可能还会对产品做进一步的完善，灰度发布完成后，所有的用户都将使用新的产品功能。[1]

在服务发布的时候很难保证一点问题都不出，出问题在所难免，如何保证在出了问题的时候影响最小呢，灰度发布就可以让我们提前知道发布是否有问题，先用小部分流量看看效果。

灰度发布系统架构

1 配置中心配置，哪些服务进行灰度发布，灰度发布中的流量划分

2 上游服务接收客户端请求之后，根据配置中心的配置将请求转发到新老服务中

3 注册中心负责新老服务的注册

4 下游服务负责处理用户请求的业务服务系统

设计中的难点： 灰度发布系统中的协议设计

• 数据协议
  • 定长header
  • 变长body
  • 设计灰度发布字段
    • uid
    • token
    • ip
    • tag
• 灰度发布策略
  • 单策略
    • uid/token/ip
  • 基于上下文灰度发布策略
    • 模块AC同时灰度
    • tag

灰度发布场景

只更新下游某服务

上游如果Nginx：

• 可使用Openresty，Tengine等nginx扩展，可以嵌入 lua 脚本，进行转发
• 服务器配置agent进行动态更新nginx配置，比如consul + consul-template。

上游如果是RPC服务：

• 可集成配置管理平台的客户端SDK，实时更新服务端的配置，执行灰度发布策略，判断是否要开启新版本服务。

下游服务：

• 新老服务一般都会注册到服务注册中心，服务一般都带有自己的版本号。

同时灰度多个模块

网关层与数据访问层同时进行灰度发布。

根据文中上面提到的协议字段中，给新来的流量进行打标签，所有走到新网关的请求都打上tag，在业务逻辑层根据tag再次转发到不同的数据访问层。

• 所有经过新gateway的请求都有标签
• 有标签的请求在业务层都会转发到新的数据访问层

数据库的灰度升级

比如SqlServer迁移到MySQL，或者数据库字段修改。

• 首先数据全量复制，双写
• 再双写一段时间
• 去掉旧版本的DB，只写新数据库

客户端灰度发布

Android灰度发布，不要一次性把包上架到应用市场，如果上架了就不受控制了，可以通过自己的后台接口，尝试更新一批用户，然后逐渐的增加用户比例。等灰度发布完毕之后，再提交到应用市场

IOS的App Store有灰度发布机制，但是又比较严的规则。可以提前终止发布，但是已经更新的用户则无法降级。默认是7天进行全部的灰度升级。