App接口版本迭代后台处理方案

1. 部署多服务，通过ng配置版本号转发到特定服务，如

2. 单个服务只部署服务就可以，如果是cloud服务，每次还要多部署一个网关

（优点：一个服务宕机，其他版本app不会受到影响，可正常使用，部署不停服，不影响线上服务，出现问题可立马回滚

缺点：服务器资源消耗多，每次部署必须配置ng转发）

 

1. 接口处理

2.1，通过接口路径多传递公共参数，代码做判断，来做代码迭代，同一个接口路径，同一个controller，但是后面的service，mapper都是单独新的@

@RequestMapping({"/list"})
public Response orderList(@RequestParam(value = "version") String version）｛
switch (version) {
    case "1":
该版本代码
case "2":
case "3":
case "4":
｝
｝
｝

（优点：可以用现阶段移动端的公共参数version来区分版本，每次也只部署一个服务，做更新操作，

缺点：单独接口代码量大，不易阅读，每次更新必须在服务用户少的阶段才能更新，一个服务出问题，会影响所有版本app）

 

2.2，服务部署和代码接口结合，大版本服务部署，小版本接口迭代

2.3，原服务新增api接口，不影响原接口代码，如原接口是list，新接口是newList

2.4 拦截器拦截转发，思路：用户请求url ---> 拦截器拦截 ---> 转发到真正处理类和方法 ---> 返回结果

来源连接：https://blog.csdn.net/zsr_251/article/details/53419387

（优点：统一管理，统一处理，缺点，每次部署都要修改拦截器配置）

 

1. 数据库处理

此方法只针对小修改，添加字段，功能不影响的迭代