服務端兼容多個不一樣APP版本

www.cnblogs.com/yeyun/p/628…

一、實現目標

　　發佈第N版APP，不影響N版本以前APP的正常使用，不強制用戶升級APP版本，兼容多個版本的APP的正常使用。

二、解決思路

　　服務端維護不一樣版本APP的api（例如版本參數 v一、v二、v3…），根據手機端傳遞的URL及版本信息，動態調用對應的api。

三、常見的方案

　　3.1 常見的URL請求傳遞版本信息的4中方式

url+版本參數： www.xxx.com/api.xxx?version=v1

　　　　　　　　www.xxx.com/sys/user/getUserByName?version=v1.0

　　　　　　　　www.xxx.com/sys/user/getUserByName?version=v2.0

url post： header中添加版本參數（相似token使用）

　　　　　 url路徑： www.xxx.com/v1.api.xxx。

　　　　　　　　www.xxx.com/v1.0/sys/user/getUserByName

　　　　　　　　www.xxx.com/v2.0/sys/user/getUserByName

二級域名： www.v1.xxx.com/api.xxx

　　　　　　　　www.v1.0.xxx.com/sys/user/getUserByName

　　　　　　　　www.v2.0xxx.com/sys/user/getUserByName

　　3.2 服務器APP代碼版本管理

　　 　 每一個APP版本對應一個project，發佈時獨立部署不一樣版本的app。可使用SVN分支功能管理不一樣版本的project。

　　　　　　下降耦合性，杜絕版本之間的依賴，易於維護。版本獨立部署，減小單個節點的負載壓力。可是會出現大量重複代碼。

　　　　同一個project兼容不一樣APP版本的api。根據請求的版本信息的調用不一樣的api（常見的路由、請求轉發方式）。

　　　　　　減小重複代碼的重複，可是不恰當的維護，容易形成代碼的臃腫，增長版本之間依賴、bug，下降代碼的可維護性，不支持每一個版本獨立部署。

4 我的推薦

　　二級域名 + 每一個APP版本對應一個project。需求在變化，同時APP版本也在變化，同一個API會通過多人修改，原先精簡的API隨着時間的流逝變得臃腫，API之間過分依賴，修改某處代碼，致使其它未知的錯誤，代碼變得難以維護。所以隔離各個版本的APP代碼是很是有用的。

　　

　　4.1APP端如何動態調用服務器的API

　　　　每次APP啓動時調用服務器版本api，獲取url及版本信息。客戶端根據系統默認的版本號version獲取對應的URL。例如傳遞version爲v2.0,則返回www.v2.0.xxx.com

1 2 3 4 5 6 7 8 9 10 11 12

[ { "name": "APP V1.0版本", "version": "v1.0", "url": "www.v1.0.xxx.com" }, { "name": "APP V1.0版本", "version": "v2.0", "url": "www.v2.0.xxx.com" } ]

五、app版本的數量

　　維護的app版本過多，增長維護成本。對於一些過期的app版本、使用量較少的老版本、數據庫不兼容、重大功能升級等建議強制用戶升級。