做过APP产品的技术人员都知道，APP应用属于一种C/S架构的，所以在做多版本兼容，升级等处理则比较麻烦，不像web应用那么容易。下面将带大家分析几种常见的情况和应对方式：
小改动或者新加功能的
这种情况，数据库结构和API程序一般是可以兼容多版本的，所以不用强制升级，可以坐到多版本共存。
尽量采用数据库层面新增字段和API的方式，应用程序层面就可以兼容了。当然，API层面也可以部署多个版本来同时提供，但这个不是必须的
但最重要的是数据库层面的表结构那些能够兼容到。
或者：
总结：
数据库层面，尽量采用新增字段，而不是修改字段的原则，避免影响以前的业务。
而服务端程序层面，API层尽量设计灵活，接入层可以支持“路由”最佳。主要有几种思路，1. 在API方法中通过新增参数或者直接新增API方法（也可以理解为重载）。
较少的改动可以这样去做处理，但是改动多了会比较麻烦，不利用扩展。
2. 代码分不同分支版本，API部署不同子站点。通过api.xx.com/V1 和api.xx.com/V2方式访问，或者通过apiV1.xxx.com，apiV2.xxx.com等方式区分访问。当然，也可以在APP不同版本中请求时传入标识，服务端通过Nginx或者APIGateWay等来实现服务路由。
这种直观上更加清晰，工作量也会大一些，会增加一定的维护和管理成本。
后端的原子服务，也需要尽可能支持多版本。
如果是大改动，底层数据结构都不兼容，那只能提示强制升级了
如果是强制升级，就不会有多版本共存的问题了，
也不会有多套数据库，也不会存在数据同步的问题。
只需要这样操作：
在苹果提交审核之前，我们事先准备好“新版本的数据结构和对象（view、proc、function等）脚本、迁移脚本或者程序、程序发布文件”等。
1. 部署1个具有新表结构和对象的测试数据库（预发布环境）。
2. 部署1个新的API站点（不同域名，建议域名中使用版本号区分。或者采用不同子站点的方式），配置连接测试库和测试的（API站点、DB、缓存、ES、Nosql …这些单独有一套预发布环境）
3. 等苹果审核通过之后，更新最新的程序，数据库结构等到生产环境，并将API地址的域名的指向切换到生产环境中（网站、admin后台等等可以直接发布了），运营人员在苹果商店点击上架操作，服务端升级完成（APP端会有强制更新的提示）。当然，这个过程中可能会造成短暂的停机时间，所以一般是选择在晚上操作。
4. 提前将安卓最新APK放到我们的下载站或镜像站，在3步服务端程序等都发布完成后，在运营后台开启安卓版本的强制升级提示（从我们的下载站或者镜像站下载APK升级）。
这样，旧版本的安卓用户，会强制升级到新的版本，不会影响到使用。
延伸阅读
- ssh框架 2016-09-30
- 阿里移动安全 [无线安全]玩转无线电——不安全的蓝牙锁 2017-07-26
- 消息队列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 论文笔记【图片目标分割】 2017-07-26
- 词向量-LRWE模型-更好地识别反义词同义词 2017-07-26
- 从栈不平衡问题 理解 calling convention 2017-07-26
- php imagemagick 处理 图片剪切、压缩、合并、插入文本、背景色透明 2017-07-26
- Swift实现JSON转Model - HandyJSON使用讲解 2017-07-26
- 阿里移动安全 Android端恶意锁屏勒索应用分析 2017-07-26
- 集合结合数据结构来看看(二) 2017-07-26
学习是年轻人改变自己的最好方式