一个简单的灰度发布思路，求指正

[CRH]

背景

• 小公司，技术力量一般
• to B 服务，可用性要求高
• 服务仅提供 APP 端
• 可以强制客户升级 APP 版本

目标

• 旧版本的 APP 连接至新版本的后端，可能会导致不可预知的 bug，没有人手做这方面的兼容性测试
• APP 和后端同步升级，可能会导致未测出的 bug 大面积出现
• 以前都是半夜上线，测试小哥连夜验证，如有问题再连夜回滚版本，累
• 不想修改太多代码

实现

环境

• 分生产（ prod ）、预发布（ pre ）环境
• 两个环境的 API 入口分别为 prod.xxx.com 、pre.xxx.com
• prod 和 pre 分别部署在两组不同的应用服务器上（组 1 & 组 2 ），连接至同一组数据库服务器
  

新增接口

接口 A

• APP 每次启动（登录）时，访问 prod 环境的接口 A
• 接口 A 会根据用户 ID 返回应安装的 APP 版本
• 如接口 A 返回的版本与本地版本不符，会强制客户更新 APP

接口 B

• APP 每次启动时，访问 prod 环境的接口 B
• 接口 B 根据 APP 版本号返回应该连接的环境
• 比如生产环境是 v1.0，新发布了 v1.1，那么 v1.0 访问接口 B 会返回 server:prod.xxx.com ，v1.1 会返回 server:pre.xxx.com

上线过程

• 假如生产环境在运行 v1.0 版 APP，新发布了 v1.1 版 APP
• 新版本上线时，将 v1.1 版的后端代码发布至 pre 组（组 2 ）应用服务器，此时 pre 组没有流量
• 配置 prod 环境的接口 A，给部分友好用户返回 version:v1.1，大多数客户仍然返回 version:v1.0
• 友好用户会被强制更新到 v1.1 版 APP，这部分流量由 pre 组服务器承担
• 友好用户经过一段时间的试用，如果发现问题：
  - 配置接口 A 全部返回 version:v1.0
  - 这些用户就会被强制更新回 v1.0
• 如果试用没有问题：
  - 逐日依据客户重要程度，分批配置接口 A 返回的数据，返回 version:v1.1，并相应增加第 2 组服务器资源
  - 在接口 A 对全部客户均返回新版本号后，等待数日（保证全部客户已更新），配置接口 B，对所有版本均返回 server:prod.xxx.com
  - 修改负载均衡设置，将 prod.xxx.com 指向第 2 组服务器
• 将第 1 组服务器（原 prod 组）下线

补充说明

• 其实也不是什么新思路，只是比较容易实现
• 使用推送代替接口 A，可以更好地控制客户使用的版本，避免版本分裂
• 新版本只能在数据库上新增字段，不能删除或修改已有字段
• 其实安全起见，pre 环境应该使用独立数据库 & 双写至 prod 数据库的，不过感觉比较复杂，打算先不做

问题

• 有现成的轮子么？
• 这个做法有啥隐患？

请指教，谢谢！

[ica10888]

我的，金丝雀发布是灰度发布的别名，感觉金丝雀这个比喻很合适...

[aut0man]

@guyskk0x0 我读懂你这个了 浏览下来觉得你这个是实现比较方便且靠谱的：D thanx 学到了

[Ianchen]

Istio 了解下，或者实在不行就按用户来走流量分发啊，就像内测用户与公测用户进的服务器不同，但是这个实际上是后端类似网关一类的服务去分配的。至于 App 是否升级这与灰度无关吧

[CRH]

@shuangya 谢谢哈，前面对我们的产品描述得不够仔细，我的锅

我们的产品是类似于超市里自助结账的设备，给服务员 /顾客操作的，也就是说设置在固定的地点，有固定的营业时间
强制更新可以放在半夜没有人用的时候，正常情况下可以做到无感

[shuangya]

@CRH 如果是这样的话，强制更新也是可行的，但是还是要考虑回滚、更新失败的降级措施（至少保证旧版本可以用）
总的来说，在服务端进行灰度比较可控一些，如果是推送到端上再发现问题，回滚起来很麻烦（比方说你们推送了一个新版本，白天开始用之后才发现后端的新代码没考虑到一些 case，这个时候靠强制推送来回滚比较麻烦）