首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

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包,提供最新的其他渠道下载,避免用户下载到旧程序,然后又提示强制升级影响体验。

那就只能去部署两套(或者更多个版本)数据库,而且对于用户产生内容和时效性要求较高的,需要双向(甚至多向)去做同步。核心问题其实是数据库有状态,这种是很困难的。

这种很容易出问题,容易出现冲突和数据不一致。

而且数据结构不一样的情况下,是很难去兼容的。

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

或者:

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程序都不兼容,

又不想去做强制升级,就会有多版本共存的问题

那就只能去部署两套(或者更多个版本)数据库,而且对于用户产生内容和时效性要求较高的,需要双向(甚至多向)去做同步。核心问题其实是数据库有状态,这种是很困难的。

这种很容易出问题,容易出现冲突和数据不一致。

而且数据结构不一样的情况下,是很难去兼容的。

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

作者:丁码农

来源:https://www.cnblogs.com

/dinglang/p/6092405.html

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190218B0IHYS00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券