API服务多版本控制-CSDN博客

面对市场变化，产品必须不停迭代，一款有大量用户留存的产品，必然需要对产品多版本做兼容。

不能因为，用户不升级，而导致用户不能使用旧的版本，特别是做内容服务的，比如音视频软件平台，腾讯视频，网易云音乐，今日头条。

用户需要的不是软件本身，或者说软件好玩的地方。用户在意的是电影好不好看，有没有新音乐，今天的新闻资讯有哪些，至于app产品更新，我相信绝大部分用户都不会关心。

即便，客户端提示升级，也会取消升级。那么我们要做的是什么呢？

从产品角度，当然是做市场调查，倾听用户的心声，改变产品的使用方式，如：这个位置可以有个收藏按钮，等等，然后产品更新的时候，告诉用户有哪些好玩的，用户感兴趣的功能更新了。

去引导用户去更新，而不是强制用户去更新，要容纳旧版本的存在。

当然，我们主要说的开发部分，前面不过是，理一下为什么需要做多版本控制的，方案背景。

我们拿网易云音乐的请求music详情做case（当然这个接口是虚构）

1.0
API ： /music/:id  //获取音乐详情

METHOD：GET 

RESPONSE：{
	name:"远走高飞"，
	imageUrl:"https://xxx",//封面图
}

2.0  需求变更，需要多张图片，

imageUrl:["https://xxx","https://bbb"],//封面图
复制代码

旧版客户端是不支持数组的，所以需要做兼容处理，那么在这种情况下通常最简单的方式是，之间做版本判断，根据客户端请求，在header、所携带的版本，做判断了，输出版本差异数据。

但是随着产品迭代次数过多，项目冗余代码日益增多，代码结果变得难以维护，每次因为需求变更的时候需要考虑对旧版本兼容方案，而且一个不小心就会影响旧版本用户的使用。

就像上面的字符串，改成数组，如果客户端兼容不够优秀，这将是一个噩梦，必现的程序崩溃，闪退。

在解决API服务多版本控制的实践中，我碰到过三种方案

方案一：代码兼容，多注意些版本方面的中间件处理。

适用场景：产品初期

方案二：路由做版本控制，代码冗余

1.0: /1.0/music/:id

2.0 /2.0/music/:id

不同的版本指向不同的目录，版本迭代快的话项目冗余过多，且不好维护。

适用场景：在版本迭代频次低，业务范围，业务深度不强的可以使用

方案三：多版本部署,同时存在多个版本服务（推荐）

1.0 HOST:1_0.wangyi.com/xxx

2.0 HOST:2_0.wangyi.com/xxx

不同版本的客户端请求不同版本的服务端，接口代码相对独立，同时git等代码多版本控制工具配合使用，管理，运维多个不同版本API服务。

这样，新的版本开发（除了数据）不太需要考虑，对旧版本的影响，代码耦合，也变得非常低，当某个版本的用户数低到忽略不计的时候，就可以直接移除服务的方式，过版本过度。

使用场景：有一定的用户基数，应用有一定的规模。

总结：一个app 1.0到4.0的变化一般都会很大，有很多业务需要做版本控制，兼容旧的版本也是非常重要的一件事，不能因为我们做了版本迭代次数过多，而导致用户无法使用，必须更新。

而业务代码兼容过多版本，又会造成代码难以维护的局面，通过运维做多版本控制来处理API服务多版本控制，是一种非常值得推荐的方案。