APP多版本共存,服务端如何兼容?

时间:2021-09-14 01:57:17

做过APP产品的技术人员都知道,APP应用属于一种C/S架构的,所以在做多版本兼容,升级等处理则比较麻烦,不像web应用那么容易。下面将带大家分析几种常见的情况和应对方式: 
小改动或者新加功能的 
这种情况,数据库结构和API程序一般是可以兼容多版本的,所以不用强制升级,可以坐到多版本共存。 
尽量采用数据库层面新增字段和API的方式,应用程序层面就可以兼容了。当然,API层面也可以部署多个版本来同时提供,但这个不是必须的 
但最重要的是数据库层面的表结构那些能够兼容到。

APP多版本共存,服务端如何兼容? 
或者: 
APP多版本共存,服务端如何兼容?

总结: 
数据库层面,尽量采用新增字段,而不是修改字段的原则,避免影响以前的业务。 
而服务端程序层面,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包,提供最新的其他渠道下载,避免用户下载到旧程序,然后又提示强制升级影响体验。

APP多版本共存,服务端如何兼容?

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

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