api如何设计才能支撑多个不同版本的app共存

记得去年面试电商的移动端架构师职位时，被问过一个问题：“当我们的app存在多个版本，1.1，1.2，1.3，2.0,2.1,2.1时，设计系统架构满足不同用户不同版本的app同时可以使用，这个问题如何思考？”

我并没有实际遇到过这样的情况，我一直工作在传统软件公司，多数传统软件公司只有一个答案，强制升级api和app版本才可以使用。所以这个问题当时我并没有回答的很好。这件事情过去很久了，最近在看一本书“iOS网络高级编程”，其中一句话“设计良好的api可以适应灵活的变化”，引起了我的一些思考，其实这个问题很简单。如果再问一次上面的问题，我会这么回答。

首先，对于兼容多版本app这个问题，解决的核心方向在于服务端api的多版本管理，api首先要有v1.1,v1.2 … ，（这些版本并不一定需要和app有一一对应关系），这样不同版本的app调用对应的api，就可以满足多版本app同时可以使用的问题。调用的方式可以直接写在代码中，复杂写的情况也可以使用服务定位器。

接下来考虑服务端api的多版本设计，主要有2种方案：

1：同一套代码，兼容不同版本的api。根据请求中的版本信息区分，返回不同的数据。
2：严格区分个版本api的代码，使用不同的分支或是tags，分布部署不同版本api对应的服务

方案1的优点在于简单，缺点在于容易造成代码混乱，产生bug。

方案2是我比较推荐的，使用git的tags进行api版本管理，每个api单独部署，逻辑清晰代码易于维护，还能减少单个节点的负载压力。

其他的思考

如何设计出优雅的多版本api接口？这个问题在于通过什么方式传递api的版本号数据，主要有这么几种

1：api版本号放在url路径中 www.xxx.com/v1.api.xxx
2：api版本号放在url参数中 api.xxx.com/api?version=v1&..
3：api版本号放在请求的header中
4：api版本号放在二级域名中。 v1.api.xxx.com

因为之前我推荐的是方案2，分开部署，所以更倾向于选4。

远程门面模式

对于一个应用来说，可能会涉及到一些第三方的接口，那么这些第三方的api接口为了满足api的多版本设计（第三方的api接口也会常常有所变动），可以考虑使用远程门面模式，即app不直接访问第三方的api，而是通过服务端api简介访问第三方api。

举个例子，如果app中需要得到城市的气象数据，气象数据是一个第三方公司提供的，那么app不应该直接访问第三方的接口，而是通过api从自己的服务端获取数据，自己服务端通过调用第三方接口获取气象数据。

这样做的好处很明显。

1：第三方的api可以纳入版本管理，并且在第三方接口变动时，课通过修改api来应对，免去修改app导致重新审核的问题
2：保证接口的稳定性和统一性（比如api的接口是rest json，但是第三方的接口有可能是xml，soap等，这样可以通过服务端统一封装接口，而app统一调用api的rest json接口）
3：简化客户端逻辑和代码，这个符合客户端尽可能轻的开发准则

维护多少个版本比较合适

如果维护的app或者说是api版本过多，必然会导致维护成本大大提高。我们应该在在api端统计每个版本的使用量，把使用量较少的api版本给干点。另一方面，一些过时的api我们也并不希望用户继续使用时，也可以考虑强行干掉，对于app端使用了一些被干掉的api可以提出用户升级提示，用户可以根据自己情况选择升级，如果不升级，其他的api也能够使用。强制用户因为单个api升级客户端会造成不好的用户体验，除非这个api真的值得真么做。

服务定位器

多版本api策略对于客户端来说，api请求的地址可以直接写在app代码中，也可以通过服务定位器，去动态获取请求服务的url地址，使用服务定位器可以使多版本api的策略更加灵活，可以考虑在每次app启动时候调用服务定位器接口

[{
    "name":"v1",
    "url":"v1.xxx.com/",
    "vsersion":"v1",
    "other":"..."

},
{
    "name":"v2",
    "url":"v2.xxx.com/",
    "vsersion":"v2",
    "other":"..."

},
{
    "name":"天气服务",
    "url":"weather.xxx.com/",
    "vsersion":"v1",
    "other":"..."

}]

最后

感谢收看，如果对大家有帮助，请github上follow和star，本文发布在刘彦玮的技术博客，转载请注明出处