admin管理员组

文章数量:1559105

前言


第一次接触接口版本的时候,应该是dubbo,就是它在配置服务端和客户端的时候需要写上对应的版本号,这也是我觉得dubbo麻烦的地方,很多公司也因此改为feign这样更加便捷的rpc。(虽然说dubbo有很高的性能,基于netty实现通讯,但是开发便捷在大部分时间还是比性能强,即使在我上家几万qps的情况下,虽然技术负责人有说过考虑换dubbo,最终还是在用feign,嘿嘿)

在第二次接触到api版本说法,是在我做全链路灰度项目的时候,当时有个老哥在讨论这个方案的用途的时候,他说应该去兼容不同api版本,其实那玩意是为了代替现有蓝绿灰度的。

到这里,我就有点奇怪了,api版本?

为啥我平时的接口都是只有一个?

对吧,在众多项目里头,基本上都是只有一个版本,而且是最新的版本,但是它也要兼容之前版本内容,当有内容冲突的时候,需要一起更新迭代。

api版本


从上面三种api版本,我们可以找到现在的api模式上版本兼容,也就是现在的版本会兼容之前版本的内容,不会说忽然出现断层,就是我上期我们俩聊得好好的东西,下一期干掉了,接口直接异常。

第一种是外部多个版本对应我们一个版本,第二种是多个版本互相对应,第三种是采用兼容的版本控制。

  • the costs of versioning an api

日常业务其实采用第三种兼容性版本已经足够解决,但是有时会出现现有的需求已经跟之前有所差异导致接口不再适用,这时一般会新起另一个接口来处理新的逻辑。

业界api做法


之前接过百度开放平台api,一开始会有一个url,过了一段时间发现出了个新的接口叫/v1/xx,就是在原有的基础上加多了个版本号,这就是另起一个接口的做法。好处当然是简单快捷,如果是采用ddd的设计,其实外层都是adapter,内层逻辑做了层层隔离,就不会说随着业务发展一直在变动,提高整体的稳定性。

前几天看了vivo的api设计文章,里面提到了在参数里头添加version做法,我觉得这个也是很好的idea,就是接口原本就支持版本扩展,只不过在代码层面做的一层分隔。优点是做到了可扩展性,可迁移,大部分api接口都可以通过加上version的属性来提高版本兼容,缺点是需要代码上去隔离,会增加复杂性。

「本人的看法」

业务前期或者发展阶段,可以采用第一种兼容版本做法,当无法满足需求的时候另开一个接口,因为这种情况是比较少的。我们做的业务一般是面向内部服务,比如说内部用户,内部应用,调用者跟提供者都是我们,这时升级版本的时候,呼一声一起上线就完事了。

但是对于有外部的开发者,这就不好升级了,比如说一个接口对了几百家,忽然说改就改,难度非常大的,推进也会很难,比如说开放平台接口,所以这时用第一个方法可以解决大部分场景。

第二种在参数加上version属性的,适合那种有很多版本的情况,比如说app,用户可能用2000年,可能有些用的最新的,像小米的死忠粉,一直拿着古老的小米6是吧,就是不肯换手机是吧,好家伙~ 那这时意味着接口会有很多版本,如果你每次都新增一个接口,完犊子了,接口文档密密麻麻~

当然有些内部员工用的app,如果版本不兼容我们会强制更新到最新版本,这就是硬气的地方,如果是客户还得考虑下用户体验,嘿嘿~

实践


之前我在搞开放平台的时候,是有个对外鉴权的算法的,但是当时设计不太好,然后对接的商家也有20来家了,
后来这个签名算法我改了一版,做到真正比较成熟的签名,这时问题就来了如果去升级这个api呢?

我的想法💡:两个系统来自,之前有想过通过灰度的手段来慢慢切过来,一部分用户用新的,一部分用旧的,其实想想不太靠谱,你升级完了,别人还在用旧的,你说逻辑上让不让它用旧的。

所以百度开放平台设计是合理的,就是新开一个接口,让对方去重新接入,当大家都升级完的时候,我们也可以看流量是否还有从旧版本溜进来,没有的话就把它下线掉。

这里又要贴下之前阿里文娱开放平台设计,我们可以看到这是一个完善的api管理,就是不会随意将接口暴露到外面去访问,是可控的。

本文标签: 版本