服务灰度发布设计

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

最后

学习记录

参考

• [1] 灰度发布-百度百科
• AB测试和灰度发布平台架构设计和实践
• Nepxion-Spring Cloud灰度发布神器