战狂粗人张

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  228 随笔 :: 0 文章 :: 12 评论 :: 20万 阅读
< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

前言:

iOS和android 要不断开发新版本,很多服务端开发都是在以前接口的逻辑上进行修改。

新的APP和接口开发后,接口如何兼容老的APP?

有的公司每次发布完APP,就强制用户更新到最新版本。不推荐这样,因为用户体验太差。

就算是用强制更新,在苹果审核期间,新的APP接口和老的接口也必须能同时使用。

一、客户端做兼容,接口不用做兼容

1、APP强制更新(不建议)

接口URL:api.xxx.com/v1.0/xxxx.java

接口的URL中加入版本号,如上:v1.0。

每次发布新APP版本就强制更新。

灰度服务器部署正在审核中的接口版本(如:v1.1)。等审核通过后,将老版本的APP设置强制更新,这样老的接口就不用了。

然后把线上服务器重新部署上最新的代码,再去掉灰度服务器。这样APP接口全部访问正式的线上服务器。

 

2、热更新

紧急的小需求可以用热更新,大的需求建议还是用原生的代码,因为你用热更新修改完(用JS或Lua),最后还要在原生代码里修改。

网游用热更新的比较多,因为网游的APP太大,不可能加个小关卡 就要求用户重新下载,并且游戏更新比企业级APP更频繁,用热更新可以不断新加关卡、场景、活动推广。

 

二、服务端做版本兼容

全部接口版本是否统一:

所有的接口都用相同的版本号:这样要发一个APP新版本就统一修改版本号,好修改,但是如果想修改其中一个接口的版本号就不行了。

每个接口的版本号可以不一样:这样比较灵活,建议这样做。

 

1、每个接口逻辑里加if 判断(不建议)

 接口URL:api.xxx.com/api?version=v1&.。

  if (version == ‘1.5.0’) {

    do_something

  } else if (version ==‘1.4.0‘) {

    do_something

  }

优点:实现简单

缺点:不同版本的逻辑都在一个方法里,在于容易造成代码混乱,不利于维护。

 

2、不同的文件夹

相当于每个接口版本都是一个独立的项目。放到服务器的独立文件夹里。

例如:

  接口URL:api.xxx.com/v1.0/xxxx.php

  文件夹位置:Controller/V1.0/

  -----------------/xxxx.php

  文件夹位置:Controller/V2.1/

  -----------------/xxxx.php

优点:版本逻辑分开维护。看url就能知道哪个版本。删除多余版本 不用修改代码。

缺点:同个接口不同版本文件是重复的。并且如果有个接口前几版就有问题,一直遗留到现在,就需要改好几套一样的代码。

 

3、不同版本用不同的方法 :

类似:

  接口URL:api.xxx.com/v1.0/xxxx.php

  class XXXX{

    public funcTIonV1_0() { }

    public funcTIonV2_0() { }

  }

java或者C# 都有路由配置,可以用路由配置不同版本的URL跳转到不同的方法里。

 

4、用继承的方式

采用继承的方式,既可以利用之前的接口代码,又可以采用override的方式修改部分接口的实现。

这样是可以的。但是如果你上个版本(也就是父类)修改了代码,就会影响后面的所有版本。

在线上有bug或者需求变更的时候很可能会修改基类。

 

5、部署到不同的服务器

不同版本不同分支,部署在不同的服务器上。如果某个版本用不到了,直接干掉服务就好了。

例如:

现在的API要从1.x升到不兼容的2.0版本了,那就给当前的发布分支打个Tag。等哪天1.x版的API需要fix bug,就能很简单地从这个Tag切一个1.x的分支出来fix bug后进行测试发布,

而且这个分支不会合并到任何分支,所以不会影响其他版本。这个方案不好的地方在于,如果2.0也有同样bug的话,也要在2.0分支上改一遍。如果版本很多的话,这活就不好干了。

所以呢,一般不会同时发布两个以上的版本,在升级不兼容的第三个版本前,一定会把第一个版本干掉。

但是比如 淘宝、微信 ,有的时候忘记更新了,你会发现淘宝已经升级过4、5个版本了,然后老版本还能用。也就是有的APP确实需要兼容4、5个版本。

另外,如果要兼容过多的版本,服务器也需要够多才行。同时,因为老版本的人用的少,也就是有的服务器访问量很少,有的服务器访问量很多。不能真正的负载均衡,浪费了服务器资源。

 

6、混合使用

服务端的几种方法混用:

第3种和第4种方法一起用。先用继承,如果新版本和以前的版本无法复用,就用路由设置新的方法。

第1种方法和第3中方法一起用,简单的小改动用 第1种,加个if判断。改动较大的用 第3种,新开个方法。

 

posted on   战狂粗人张  阅读(436)  评论(0编辑  收藏  举报
编辑推荐:
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
阅读排行:
· Manus重磅发布:全球首款通用AI代理技术深度解析与实战指南
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
点击右上角即可分享
微信分享提示