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

最新推荐文章于 2024-12-22 17:50:27 发布

置顶丁码农

最新推荐文章于 2024-12-22 17:50:27 发布

阅读量2.1w

点赞数 1

CC 4.0 BY-SA版权

分类专栏：大规模系统架构文章标签： app 应用数据库 api

本文链接：https://blog.youkuaiyun.com/dinglang_2009/article/details/51810496

大规模系统架构专栏收录该内容

37 篇文章

订阅专栏

本文探讨了APP产品在面对小改动或大改动时的多版本兼容策略，包括如何通过数据库新增字段、API版本管理和强制升级等方式实现新老版本的平滑过渡。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

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