关于接口升级版本的一些思考

关于接口升级版本的一些思考

在一次需求开发的过程中,涉及了整个链路中多个服务的接口改动,因为涉及接口还是线上访问的主接口,改动需要慎重,于是对接口发版的顺序引发了自己的一些思考。

什么样的接口改动可以直接发版,不用关注顺序

应该是保持”前后向兼容“的接口可以直接发版。

对于接口,有两个概念:调用方和被调用方,接口改动肯定指的是被调用方的改动。无论什么样的接口改动,我们应该有如下的约束:

  1. 不限制调用方什么时候进行升级。

即调用方调用改版前的接口和改版后的接口,都可以正常的访问。

在这样的约束的情况下,保持”前后向兼容“的含义是指:请求新增字段(特殊)、返回新增字段、请求删除字段。

  1. 请求新增字段:请求新增字段的情况下,被调用方必须能够同时处理拥有这个字段(新版)和没有这个字段(旧版)的情况。对于http请求来说需要自行判断有无数据传入;对于idl来说,要使用optional​进行约束,而不能使用required​。

  2. 返回新增字段:基本不用考虑什么东西,直接丝滑的新增就行了,无论http请求方式还是idl请求方式都是如此。

  3. 请求删除字段:同样基本不用考虑什么东西,直接丝滑的修改升级就行了。唯一要注意的是idl的序号,后续如果需要对这个请求改动,尽量不要复用原来的那个序号,毕竟虽知道使用方还有没有再调用呢?

  4. 其它:除了上面两种情况之外,还有一种情况:返回删除字段,这个是不兼容的。对于http请求来说,要求调用方已经完全废弃掉这个字段的使用;对于idl来说,肯定是会出现解析响应失败而导致请求失败的情况。

在上面的说法中idl其实是有不严谨的地方,大概指的是生成json请求响应格式的idl(JSON-RPC / XML-RPC等)。至于是生成二进制格式的idl(Protobuf、Thrift、Avro等),其兼容性也是类似考虑,不过还需要额外考虑idl结构体中的序号不要复用的问题。

总结一下:本质上就是需要提供需求方更多的数据就可以了

如果不兼容的接口改动应该怎么发版

虽然我们很想所有接口都保持兼容,但是在某些升级或者重构的时候其就无法兼容,这时候应该如何处理呢?

答案就是不如新增一个接口吧,对上层通报原来的接口已经渐渐不再维护,建议迁移吧。虽然听起来比较离谱,但是这是一个比较好的方式了。

当然,在某些情况下(流量很低之类的),我们也可以考虑停机升级,或者上下游约定一个统一的切换时间(比如用配置中心来切换),这样统一的切流用技术之外的方式解决这个问题。

posted @   思wu邪  阅读(24)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 10亿数据,如何做迁移?
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 推荐几款开源且免费的 .NET MAUI 组件库
· 易语言 —— 开山篇
· Trae初体验
点击右上角即可分享
微信分享提示