针对移动应用的灰度发布系统

  • 概述

    1. 什么是灰度发布

      如果两个Release版本的Version分别是 ‘黑’ 与 ‘白’ , 灰度发布就是介于这两个版本之间的版本。通过定向推送灰度版本,可以实现在目标范围内进行采样,获取反馈数据,借助这些数据又可以影响版本决策。

    2. 为什么要进行灰度发布
      • 移动产品设计依赖用户、市场反馈,通过灰度发布可以检验、管理产品设计
      • 快速迭代将不可避免的会导致一些缺陷，希望缺陷只暴露在小范围内,使得产品看起来更稳定
      • 有些需求是有针对若干维度上的用户的,如分版功能、定制化需求、手机适配,这些问题不应该推送全部用户
      • 借助灰度发布可以做一些定向运维的工作
      • ......
    3. 与升级服务的关系

      灰度发布的版本号与应用的版本号应该隶属于两个系统，互相逻辑之间没有关系，相对独立的版本更容易设计升级逻辑，便于管理。

    4. 设计原则

      真正的灰度发布系统要考虑很多内容，要能够支持全平台的A/B Test,这不但增加了整体系统的复杂性，还要求各平台在架构上进行重构来适应此系统,本设计目的是用最简单的方式实现符合当前产品要求的简易灰度发布系统。

  • 支持灰度发布策略

    1. 概率发布
    2. 白名单发布
    3. 关键词发布 (分版)
    4. 版本维度发布 (灰度版本、应用版本)
    5. 企业维度发布
    6. 区域维度发布
    7. 设备维度发布 (固件、厂商)

  • 关键属性

    1. 产品编码
      产品编码主要是用来区分不同的产品线，如外勤、对讲应用等。

    2. Max版本序号

      对应应用程序版本序号。该字段是过滤版本号上限。
如果安装的应用版本大于Max版本序号，则不参加推送。

    3. Min版本序号

      对应应用程序版本序号,该字段是过滤版本号下限。
如果安装的应用版本小于Min版本序号，则不参加推送。

    4. Case序号

      每一个大版本下的灰度子版本称作一个Case，Case序号建议设计成Integer类型，该序号越大，选择优先级越高。
如果Case序号小于安装应用对应的Case序号，则不参与推送。
Release版本的Case序号并不是从0开始，而是应该大于当前所有Case序号。

    5. 失效日期

      每一个Case的失效时间。
如果当前时间大于Case失效时间，则不参与推送。
    6. URI
      灰度版本下载连接地址
    7. 版本描述
      灰度版本描述

    8. 策略规则

      策略是指的版本推送的策略，当灰度版本在要满足版本号、Case号符合推送要求同时，还要满足概率、白名单、关键词3种子策略。
概率策略和其他子策略之间是"与"的关系，白名单和关键词之间是"或"的关系。
如果其他非概率策略不存在，则不进行策略校验。

      • 概率

        通过概率的方式决定是否参与推送。

      • 白名单

        只有手机号码或者用户名不存在白名单中，则不参与推送

      • 关键词

        关键词未匹配成功，则不参与推送

  • 回滚策略

    灰度发布系统需要考虑回滚策略。针对一个灰度版本回滚，大概可以分为以下两种情况：

    1. 灰度A回滚到灰度B

      这其实不叫做回滚，只是因为灰度A版本存在版本缺陷，所以发布灰度B来替换灰度A。如果希望能够全面覆盖灰度A版本，那么可以通过两种方式去做：

      1. 通过白名单策略发布。把所有A相关的手机号配置给B。
      2. 通过关键字策略发布。在灰度A中预置灰度版本的版本号作为关键字。

    2. 灰度A升级到Release版本

      由于灰度版本的版本号可能和Relesase版本相同，那么灰度版本向Release版本升级还是需要通过灰度升级服务。针对收集所有灰度版本号,使用关键字策略,可以完成发布。需要注意的是，Release版本的Case序号一般来讲是当时最大的。

  • 设计

    1. 流程设计

      时序图

    2. 选择策略

      选择策略

    3. 数据库设计
    4. 协议设计

results matching ""

    No results matching ""