App 多版本服務端相容

xianyunyehe發表於2018-11-27
APP服務端

APP 多版本服務端相容

移動網際網路時代，APP軟體迭代非常頻繁，由於APP充當一個客戶端，釋出新的APP版本的時候，勢必導致出現多版本，這樣服務端就會導致多個不同的客戶端請求。這區別於我們傳統的B/S 瀏覽器是固定的，使用者通過瀏覽器訪問的地址也是一樣的。但是APP不同的版本，我們訪問的介面地址就不一定一致了。強制使用者升級APP，可能會導致使用者流失，因此採用多版本共存就是必須的

多版本控制策略

API的版本控制策略通常有3種模式：

  • 第一種：The Knot：無版本，即平臺的API永遠只有一個版本，所有的使用者都必須使用最新的API，任何API的修改都會影響到平臺所有的使用者。甚至平臺的整個生態系統。

img

  • 第二種：Point-to-Point：點對點，即平臺的API版本自帶版本號，使用者根據自己的需求選擇使用對應的API，需要使用新的API特性，使用者必須自己升級。

    img

  • 第三種：Compatible Versioning：相容性版本控制，和The Knot一樣，平臺只有一個版本，但是最新版本需要相容以前版本的API行為。

    img

多版本共存的方案

  • URL中加入不同版本的路徑
/v1/user
/v2/user
  • 使用子域名
v1.xx.com
v2.xx.com
  • URL中請求中加入不同的版本資訊 
xxx.com/api.php?version=v1
xxx.com/api.php?version=v2
  • 在請求頭中加入版本號資訊
api_version:1.0

幾種方案的優缺點

  • 方案1中的。使用不同的路徑進行控制，這種方法比較簡單有效，相互隔離，不同的APP版本訪問不同的程式碼，但是缺點就是會導致程式碼冗餘，當版本一多的時候，就會發現維護多個版本的痛苦.

    --v1
-- controler
-- model
--v2
-- controler
-- model

  • 方案2，方案2可以利用git 的 分支和標籤功能將不同的程式碼打上版本號，然後把不同的版本釋出到不同的子域名下，不至於在程式碼庫裡出現大量的版本的程式碼，還可以利用減輕覆蓋，但是缺點就是增加了運維維護的困難，而且域名解析可能涉及到不同的部門，這個溝通也麻煩。釋出一次解析一次，導致子域名越來越多。

    v1.xx.com 1.1.1.1
v2.xx.com 2.2.2.2

  • 方案3和方案4中的好處就是不至於出現大量的版本目錄結構，但是缺點就是增加了大量的判斷版本資訊，和不同的邏輯方法。這樣的程式碼邏輯會越來越長，混亂不堪

    public function index()
{
  $version = request()->get('version');
  if($version == '1.0') {
      $this->v1();
  }else if($version == '2.0') {
      $this->v2();
  }
}

總結

web環境和APP介面不一致，即使你提示使用者更新了，但是使用者還是不更新，這樣就遺留多個版本。APP版本不是特別嚴重的BUG，一般不進行強制更新，可能會導致使用者流失。所以維護一個相容多個版本的APP介面，需要做到相容不容易，個人比較傾向於方案2，這種通過git 管理不同的tag，同時也可以將流量分到不同的版本伺服器上。但是缺點就是部署麻煩。

在寫介面的時候，儘量做到擴充性高一點，把一些潛在的功能預留一下。比如獲取商品列表。v1你可能就直接把所有的商品查出來了。但是v2可能會有limit，v3可能會有order、group、sort等

資料庫方面，儘量加欄位。不要更改原來的欄位，以免影響之前的業務邏輯。要對老版本使用者進行監控，當使用者數少於0的時候，可以進行放棄老版本。萬不得已的時候，可以強制更新。

維護版本介面是災難的，尤其是版本多了之後，還有不同版本的文件維護。如果是內嵌HTML5.那麼就沒有這些問題了。所以為了PWA 應該是主流。

參考資料

閒雲野鶴

相關文章