做過APP產品的技術人員都知道，APP應用屬於一種C/S架構的，所以在做多版本相容，升級等處理則比較麻煩，不像web應用那麼容易。下麵將帶大家分析幾種常見的情況和應對方式： 小改動或者新加功能的 這種情況，資料庫結構和API程式一般是可以相容多版本的，所以不用強制升級，可以坐到多版本共存。 儘量採用 ...
做過APP產品的技術人員都知道，APP應用屬於一種C/S架構的，所以在做多版本相容，升級等處理則比較麻煩，不像web應用那麼容易。下麵將帶大家分析幾種常見的情況和應對方式：
小改動或者新加功能的
這種情況，資料庫結構和API程式一般是可以相容多版本的，所以不用強制升級，可以坐到多版本共存。
儘量採用資料庫層面新增欄位和API的方式，應用程式層面就可以相容了。當然，API層面也可以部署多個版本來同時提供，但這個不是必須的
但最重要的是資料庫層面的表結構那些能夠相容到。
或者： 
總結：
資料庫層面，儘量採用新增欄位，而不是修改欄位的原則，避免影響以前的業務。
而服務端程式層面，API層儘量設計靈活，接入層可以支持“路由”最佳。主要有幾種思路，1. 在API方法中通過新增參數或者直接新增API方法（也可以理解為重載）。
較少的改動可以這樣去做處理，但是改動多了會比較麻煩，不利用擴展。
2. 代碼分不同分支版本，API部署不同子站點。通過api.xx.com/V1 和api.xx.com/V2方式訪問，或者通過apiV1.xxx.com，apiV2.xxx.com等方式區分訪問。當然，也可以在APP不同版本中請求時傳入標識，服務端通過Nginx或者APIGateWay等來實現服務路由。
這種直觀上更加清晰，工作量也會大一些，會增加一定的維護和管理成本。
後端的原子服務，也需要儘可能支持多版本。
如果是大改動，底層數據結構都不相容，那隻能提示強制升級了
如果是強制升級，就不會有多版本共存的問題了，
也不會有多套資料庫，也不會存在數據同步的問題。
只需要這樣操作：
在蘋果提交審核之前，我們事先準備好“新版本的數據結構和對象（view、proc、function等）腳本、遷移腳本或者程式、程式發佈文件”等。
1. 部署1個具有新表結構和對象的測試資料庫（預發佈環境）。
2. 部署1個新的API站點（不同功能變數名稱，建議功能變數名稱中使用版本號區分。或者採用不同子站點的方式），配置連接測試庫和測試的（API站點、DB、緩存、ES、Nosql …這些單獨有一套預發佈環境）
3. 等蘋果審核通過之後，更新最新的程式，資料庫結構等到生產環境，並將API地址的功能變數名稱的指向切換到生產環境中（網站、admin後臺等等可以直接發佈了），運營人員在蘋果商店點擊上架操作，服務端升級完成（APP端會有強制更新的提示）。當然，這個過程中可能會造成短暫的停機時間，所以一般是選擇在晚上操作。
4. 提前將安卓最新APK放到我們的下載站或鏡像站，在3步服務端程式等都發佈完成後，在運營後臺開啟安卓版本的強制升級提示（從我們的下載站或者鏡像站下載APK升級）。
這樣，舊版本的安卓用戶，會強制升級到新的版本，不會影響到使用。
與此同時，運營人員也需要在各大安卓市場去分發和上架最新的apk包，提供最新的其他渠道下載，避免用戶下載到舊程式，然後又提示強制升級影響體驗。
- 如果是大改動，資料庫結構和API程式都不相容， 又不想去做強制升級，就會有多版本共存的問題
那就只能去部署兩套（或者更多個版本）資料庫，而且對於用戶產生內容和時效性要求較高的，需要雙向（甚至多向）去做同步。核心問題其實是資料庫有狀態，這種是很困難的。
這種很容易出問題，容易出現衝突和數據不一致。
而且數據結構不一樣的情況下，是很難去相容的。
所以，對於改動較大的，產品新增了重量級新功能的，業務層面或者底層表結構上都不相容的，建議是要做強制升級的。
或者：
2.如果是大改動，底層數據結構都不相容，那隻能提示強制升級了
如果是強制升級，就不會有多版本共存的問題了，
也不會有多套資料庫，也不會存在數據同步的問題。
只需要這樣操作：
在蘋果提交審核之前，我們事先準備好“新版本的數據結構和對象（view、proc、function等）腳本、遷移腳本或者程式、程式發佈文件”等。
1. 部署1個具有新表結構和對象的測試資料庫（預發佈環境）。
2. 部署1個新的API站點（不同功能變數名稱，建議功能變數名稱中使用版本號區分。或者採用不同子站點的方式。通過api.xx.com/V1 和api.xx.com/V2方式區分），配置連接測試庫和測試的（API站點、DB、緩存、ES、Nosql …這些單獨有一套預發佈環境）
3. 等蘋果審核通過之後，更新最新的程式，資料庫結構等到生產環境，並將API地址的功能變數名稱的指向切換到生產環境中（網站、admin後臺等等可以直接發佈了），運營人員在蘋果商店點擊上架操作，服務端升級完成（APP端會有強制更新的提示）。當然，這個過程中可能會造成短暫的停機時間，所以一般是選擇在晚上操作。
4. 提前將安卓最新APK放到我們的下載站或鏡像站，在3步服務端程式等都發佈完成後，在運營後臺開啟安卓版本的強制升級提示（從我們的下載站或者鏡像站下載APK升級）。
這樣，舊版本的安卓用戶，會強制升級到新的版本，不會影響到使用。
與此同時，運營人員也需要在各大安卓市場去分發和上架最新的apk包，提供最新的其他渠道下載，避免用戶下載到舊程式，然後又提示強制升級影響體驗。
3.如果是大改動，資料庫結構和API程式都不相容，
又不想去做強制升級，就會有多版本共存的問題
那就只能去部署兩套（或者更多個版本）資料庫，而且對於用戶產生內容和時效性要求較高的，需要雙向（甚至多向）去做同步。核心問題其實是資料庫有狀態，這種是很困難的。
這種很容易出問題，容易出現衝突和數據不一致。
而且數據結構不一樣的情況下，是很難去相容的。
所以，對於改動較大的，產品新增了重量級新功能的，業務層面或者底層表結構上都不相容的，建議是要做強制升級的。
