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. 數據庫處理

此方法只針對小修改，添加字段，功能不影響的迭代