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

Posted 2020-08-21 沧海一滴

 

做过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程序都不兼容， 
又不想去做强制升级，就会有多版本共存的问题 
那就只能去部署两套（或者更多个版本）数据库，而且对于用户产生内容和时效性要求较高的，需要双向（甚至多向）去做同步。核心问题其实是数据库有状态，这种是很困难的。 
这种很容易出问题，容易出现冲突和数据不一致。 
而且数据结构不一样的情况下，是很难去兼容的。

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

 

http://www.cnblogs.com/dinglang/p/6092405.html