做過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.如果是大改動，底層資料結構都不相容，那隻能提示強制更新了
2. 部署1個新的API站點（不同域名，建議域名中使用版本号區分。或者采用不同子站點的方式。通過api.xx.com/V1 和api.xx.com/V2方式區分），配置連接配接測試庫和測試的（API站點、DB、緩存、ES、Nosql …這些單獨有一套預釋出環境）
3.如果是大改動，資料庫結構和API程式都不相容，
又不想去做強制更新，就會有多版本共存的問題