版本兼容管理 尝试版

公司的产品是ToB的,而且客户端和服务端是分离的(这里的分离是指,有的客户还在用低版本产品,有的新客户用的是新版本),即客户端存在v1.0、v2.0,服务端也存在v1.0、v2.0。

这样就会存在如下问题:

1.高版本客户端 低版本服务端兼容问题

2.低版本客户端高版本服务端兼容问题

而大多数公司对于软件的版本管理,可能主要面临第二个问题。这种版本兼容问题主要是在小版本改动时会出现,例如:

一个业务的原版本在服务端接口是仅一个主键参数:

GetMessage(object key)

后来服务端接口需要传两个参数

GetMessage(object key,DateTime date)

这种情况下,低版本的客户端在调用高版本服务端接口方法时就会参数不匹配了。


对于高低版本的方法兼容:

客户端在发送请求时,都带上此客户端的版本号

https://api地址/v版本号/接口路由

服务端在接收请求后,先握手检查请求的版本在此服务端中是否兼容。

即服务端有相关的版本兼容列表,里面可能存入了[v1,v2]等版本信息,解析请求的版本参数,对比筛选

对于服务端的兼容方法 可以分为 高低两种,即新方法一分为二

ToHigh GetMessage(object key)//由低版本客户端 向高版本服务端请求时 补全参数
{
    //一些补全参数或修正类型等转换逻辑 例如 补充date=现在时间
    GetMessage(key,date);
}

ToLow GetMessage(object key,DateTime date)//由高版本客户端 向低版本服务端请求
{
    //向低版本转换逻辑 例如去除date
    GetMessage(key)
}

而客户端则可能部分由于服务端返回值不同,也可能需要做同样的 高低版本兼容方法。

对于实在不兼容的,例如相关业务逻辑大动,或者存储结构变动很大,就需要强制升级高版本了。

对于版本号,简单点的可以用日期来标识 v+年末两位+月份+日 如: v200422。复杂点的 可以加版本规则 beta alpha 之类的,或者是一些自定义规则,只要是符合自己产品,且好掌控判断兼容版本的规则即可

 以下有几点想法:

  1. 对于服务端方法的变更,尽量是增加参数,而非删减或变动参数类型
  2. 服务端返回的参数尽量用键值对形式,方便前后动态调整
  3. 任何版本的兼容都有一定时效性,多次补丁式兼容后就容易出现代码冗余难以重构
©️2020 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值