做 APP - API 的同志，询问下版本号管理的问题

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 2808 天前的主题，其中的信息可能已经有所发展或是发生改变。

版本号格式： 1.0.1

如果说第一版上线后有些 UI 和界面功能上的改动，使得老接口不可用。发布 1.1.0 版，为了 APP 能支持老接口，服务器上的项目是 copy 一份然后将 git branch checkout 为 1.1.0 。并新增一个 Apache/nginx 虚拟机来接收请求吗？

http://api.aaa.com/v2/[controller]/[action]

19 条回复 • 2017-04-20 18:03:33 +08:00

airyland

2017-04-19 18:35:22 +08:00

为什么不能同个项目 v1 v2 并存。

ytmsdy

2017-04-19 18:52:29 +08:00 via iPhone

通过 url 进行区分！
api/v1/news/
api/v2/news/
前台进行区分

luoyou1014

2017-04-19 20:58:10 +08:00

建立 module 1.1.0 ， 1.1.0 中的 controller 全部继承 1.0.0 ，这样既保证老接口的访问，又避免新接口去把老接口的功能实现一遍。

tlday

2017-04-19 21:00:28 +08:00 via Android

可以用 nginx 的负载均衡模块区分 url 转发，不用开新虚拟机 /host 。

tlday

2017-04-19 21:03:38 +08:00 via Android

@luoyou1014 这样处理的话，未来版本多了，继承层级不会爆炸吗？

luoyou1014

2017-04-19 21:11:04 +08:00

@tlday 分三位版本号，最小位变动不加 module ，中间位变动根据接口的是否与老接口重合的情况来决定是够加 module ，最高位变动必加 module 。
我们公司差不多有了七层继承，开启 opcache 性能不是问题，偶尔调试有点麻烦，不过这样的好处就是新版本代码绝对不会影响老版本代码。
如果你们公司业务做的真的非常好，可以定期重构，减少继承层级。

tlday

2017-04-19 22:01:29 +08:00 via Android

@luoyou1014 好吧，虽然不太能认同你们的做法，但是确实是继承的新姿势 get√，我从来都是开两套…旧的打个 tag/branch ，只做 bug fix ，不再添加新功能。新的继续迭代。因为我觉得版本更新时覆盖更新是大忌。

Immortal

2017-04-19 23:27:44 +08:00

app 的网络库底层可以封装点标志信息到 header 头里
然后用 nginx 反向代理到各个后端服务
这样不好的一点是偶尔改了一个接口整个都要反代过去除非配置里加判断
不过一般也就维护几个版本迭代几次强更一次

2017-04-20 00:03:50 +08:00

apigateway

willakira

2017-04-20 05:47:43 +08:00

不需要，直接在旧接口的基础上开发新的服务
你这才从 1.0.0 到 1.1.0 就不想兼容旧接口了么…

如果每次版本升级都是一个新的 repo ，一些影响多个版本的旧 bug 的修复和部署会非常非常痛苦。

yimity

2017-04-20 06:37:08 +08:00

如果只是继承好处理，但是后端的 model 数据库字段等怎么处理？

ltye

2017-04-20 08:50:24 +08:00

也可以在 header 里增加版本号~

blacklee

2017-04-20 08:59:02 +08:00

1.0.0 到 1.0.1 绝对需要 API 方面的兼容，这种兼容都做不到，构架师好辞职了。

tshwangq

2017-04-20 09:30:34 +08:00

@luoyou1014 你这是真遗传，真继承啊。不过真实需要继承场景的东西都被版本号给废了

tshwangq

2017-04-20 09:39:48 +08:00

我的建议，变动不大的，没有根本冲突的。不需要维护几个 api 。
代码累积改动大，已经有不可兼容或者兼容代价太大，考虑发布不同的版本。
并且做好 api 生命周期，设定好旧版本死亡时间。

luoyou1014

2017-04-20 10:31:18 +08:00

@tshwangq 同样的接口，因为新版需要的参数和返回值不同，正好使用继承重写对应的 action ，对应的 model 如果没有改动，直接用，改动一样继承，这样来解决稳定性问题，项目大了之后，稳定性永远是最重要的，挂一次的成本谁都受不了。

复用已有接口很容易产生 bug ，小 bug 改下就可以了，万一是导致大规模出错的问题就很头疼了。

当然最好的还是做自动化测试，这点我们也才刚开始搞，之前因为项目进度压力大，一直没做自动化测试。
@tlday

realpg

2017-04-20 10:43:32 +08:00

三位版本号的话，接口发生变动，必然要修改第二位版本号的……
第三位版本号是用来修正小问题的

mhycy

2017-04-20 11:05:00 +08:00

一个大版本够了，前端请求没必要区分小版本更新，一个大版本之下再狗屎都要完全兼容

Observer42

2017-04-20 18:03:33 +08:00

学习了。。用继承

我们是 1.0 - 1.1 不允许有不兼容，只能添加 api ， 1.x - 2.0 可以不兼容，直接写新 controller 。但 1.x 的 controller 保留直到没有服务调