App 多版本服务端兼容

APP 多版本服务端兼容

移动互联网时代，APP软件迭代非常频繁，由于APP充当一个客户端，发布新的APP版本的时候，势必导致出现多版本，这样服务端就会导致多个不同的客户端请求。这区别于我们传统的B/S 浏览器是固定的，用户通过浏览器访问的地址也是一样的。但是APP不同的版本，我们访问的接口地址就不一定一致了。强制用户升级APP，可能会导致用户流失，因此采用多版本共存就是必须的

多版本控制策略

API的版本控制策略通常有3种模式：

第一种：The Knot：无版本，即平台的API永远只有一个版本，所有的用户都必须使用最新的API，任何API的修改都会影响到平台所有的用户。甚至平台的整个生态系统。

第二种：Point-to-Point：点对点，即平台的API版本自带版本号，用户根据自己的需求选择使用对应的API，需要使用新的API特性，用户必须自己升级。
第三种：Compatible Versioning：兼容性版本控制，和The Knot一样，平台只有一个版本，但是最新版本需要兼容以前版本的API行为。

多版本共存的方案

URL中加入不同版本的路径

/v1/user
/v2/user

使用子域名

v1.xx.com
v2.xx.com

URL中请求中加入不同的版本信息

xxx.com/api.php?version=v1
xxx.com/api.php?version=v2

在请求头中加入版本号信息

api_version:1.0

几种方案的优缺点

方案1中的。使用不同的路径进行控制，这种方法比较简单有效，相互隔离，不同的APP版本访问不同的代码，但是缺点就是会导致代码冗余，当版本一多的时候，就会发现维护多个版本的痛苦.
```
--v1
-- controler
-- model
--v2
-- controler
-- model
```
方案2，方案2可以利用git 的分支和标签功能将不同的代码打上版本号，然后把不同的版本发布到不同的子域名下，不至于在代码库里出现大量的版本的代码，还可以利用减轻覆盖，但是缺点就是增加了运维维护的困难，而且域名解析可能涉及到不同的部门，这个沟通也麻烦。发布一次解析一次，导致子域名越来越多。
```
v1.xx.com 1.1.1.1
v2.xx.com 2.2.2.2
```
方案3和方案4中的好处就是不至于出现大量的版本目录结构，但是缺点就是增加了大量的判断版本信息，和不同的逻辑方法。这样的代码逻辑会越来越长，混乱不堪
```
public function index()
{
  $version = request()->get('version');
  if($version == '1.0') {
      $this->v1();
  }else if($version == '2.0') {
      $this->v2();
  }
}
```

总结

web环境和APP接口不一致，即使你提示用户更新了，但是用户还是不更新，这样就遗留多个版本。APP版本不是特别严重的BUG，一般不进行强制更新，可能会导致用户流失。所以维护一个兼容多个版本的APP接口，需要做到兼容不容易，个人比较倾向于方案2，这种通过git 管理不同的tag，同时也可以将流量分到不同的版本服务器上。但是缺点就是部署麻烦。

在写接口的时候，尽量做到拓展性高一点，把一些潜在的功能预留一下。比如获取商品列表。v1你可能就直接把所有的商品查出来了。但是v2可能会有limit，v3可能会有order、group、sort等

数据库方面，尽量加字段。不要更改原来的字段，以免影响之前的业务逻辑。要对老版本用户进行监控，当用户数少于0的时候，可以进行放弃老版本。万不得已的时候，可以强制更新。

维护版本接口是灾难的，尤其是版本多了之后，还有不同版本的文档维护。如果是内嵌HTML5.那么就没有这些问题了。所以为了PWA 应该是主流。