背景
- 小公司，技术力量一般
- 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 数据库的，不过感觉比较复杂，打算先不做
问题
- 有现成的轮子么？
- 这个做法有啥隐患？
请指教，谢谢！
Select Language