APP多版本共存，服务端如何兼容？

作过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升级）。 
这样，旧版本的安卓用户，会强制升级到新的版本，不会影响到使用。 
与此同时，运营人员也须要在各大安卓市场去分发和上架最新的apk包，提供最新的其余渠道下载，避免用户下载到旧程序，而后又提示强制升级影响体验。

• 若是是大改动，数据库结构和API程序都不兼容， 又不想去作强制升级，就会有多版本共存的问题

那就只能去部署两套（或者更多个版本）数据库，并且对于用户产生内容和时效性要求较高的，须要双向（甚至多向）去作同步。核心问题实际上是数据库有状态，这种是很困难的。 
这种很容易出问题，容易出现冲突和数据不一致。 
并且数据结构不同的状况下，是很难去兼容的。

因此，对于改动较大的，产品新增了重量级新功能的，业务层面或者底层表结构上都不兼容的，建议是要作强制升级的。

或者：

2.若是是大改动，底层数据结构都不兼容，那只能提示强制升级了 
若是是强制升级，就不会有多版本共存的问题了， 
也不会有多套数据库，也不会存在数据同步的问题。 
只须要这样操做： 
在苹果提交审核以前，咱们事先准备好“新版本的数据结构和对象（view、proc、function等）脚本、迁移脚本或者程序、程序发布文件”等。 
1. 部署1个具备新表结构和对象的测试数据库（预发布环境）。 
2. 部署1个新的API站点（不一样域名，建议域名中使用版本号区分。或者采用不一样子站点的方式。经过api.xx.com/V1 和api.xx.com/V2方式区分），配置链接测试库和测试的（API站点、DB、缓存、ES、Nosql …这些单独有一套预发布环境） 
3. 等苹果审核经过以后，更新最新的程序，数据库结构等到生产环境，并将API地址的域名的指向切换到生产环境中（网站、admin后台等等能够直接发布了），运营人员在苹果商店点击上架操做，服务端升级完成（APP端会有强制更新的提示）。固然，这个过程当中可能会形成短暂的停机时间，因此通常是选择在晚上操做。 
4. 提早将安卓最新APK放到咱们的下载站或镜像站，在3步服务端程序等都发布完成后，在运营后台开启安卓版本的强制升级提示（从咱们的下载站或者镜像站下载APK升级）。 
这样，旧版本的安卓用户，会强制升级到新的版本，不会影响到使用。 
与此同时，运营人员也须要在各大安卓市场去分发和上架最新的apk包，提供最新的其余渠道下载，避免用户下载到旧程序，而后又提示强制升级影响体验。

3.若是是大改动，数据库结构和API程序都不兼容， 
又不想去作强制升级，就会有多版本共存的问题 
那就只能去部署两套（或者更多个版本）数据库，并且对于用户产生内容和时效性要求较高的，须要双向（甚至多向）去作同步。核心问题实际上是数据库有状态，这种是很困难的。 
这种很容易出问题，容易出现冲突和数据不一致。 
并且数据结构不同的状况下，是很难去兼容的。

因此，对于改动较大的，产品新增了重量级新功能的，业务层面或者底层表结构上都不兼容的，建议是要作强制升级的。