Hybrid平臺

需求說明

離線包管理平臺主要負責對須要接入Hybrid平臺的應用進行管理，經過這個平臺能夠實現對應用的靜態資源進行構建、發佈、生成離線包，版本控制等，核心場景以下：

1. 將須要作預加載的應用在平臺上註冊，主要包括項目名稱，源碼的地址，構建目標目錄
2. 前端同窗開發好應用後，提交代碼到Git，QA同窗登陸平臺，構建應用，該過程具體包括：
   1. 項目構建
   2. 和歷史版本比對、生成增量或全量的的離線包
   3. 離線包推送到CDN
   4. 發佈版本信息到測試庫
3. 啓動APP測試，發起版本檢查請求
4. 版本檢查接口返回：
   1. 版本升級須要的離線包的包名
   2. 這個包的MD5版本號
5. APP端根據離線包名下載離線包，作包完整性校驗，覆蓋到本地
6. 測試結束後，發佈版本到生產庫
7. 回滾，若是新的包有問題，須要進行回滾，提供進行回滾的離線包

系統設計

應用管理

應用管理對接入平臺的應用進行統一的維護，包括以下功能：

1. 應用註冊
   信息包括應用名，源碼地址（git），構建輸出目錄
2. 應用更新、刪除等

構建和發佈流程

構建

構建過程與目前在Jenkins的Node服務發佈流程相似，這個過程也能夠考慮在Jenkins實現，過程以下：

1. 從Git獲取新版的代碼
2. 執行構建，輸出目標代碼（注意，不用作md5的文件名替換）
3. 將多個項目的代碼輸出到目標目錄release

離線包生成

1. 針對release目錄的代碼和歷史版本進行diff，生成離線包、包中的version.json保存當前版本信息
2. 針對生成的離線包計算md5值，保存到manifest文件

發佈

1. 將離線包推送的CDN回源服務器
2. 將版本信息和離線包信息維護到版本信息庫（mysql），測試過程推送到測試庫，正式上線推送到生產庫
3. 離線包維護
   離線包狀態包括：待發布，測試中，已上線，
4. 離線包刪除
   若是已經上線，不能刪除，只能刪除未發佈的離線包

回滾

回滾暫時沒有作，能夠考慮兩個方案：

1. 利用git的tag標記，從新發佈一個高版本
2. app端備份舊版本，若是版本檢查接口返回的版本比當前版本低，回滾到歷史版本

版本檢查接口

版本檢查服務提供給APP端調用，針對APP端的當前版本，提供合適的離線包下載選擇，包括升級和回滾，同時也能夠經過該接口檢測當前用戶的版本分佈狀況，清除過時的版本。

APP端發起版本檢查狀況，附帶當前的版本做爲參數，從更目錄下的version.json文件獲取。

請求格式：

http: //10.0.1.51:7102/version/check?v=[version]&app=[app_version]

示例：

http: //10.0.1.51:7102/version/check?v=0.2&app=5.6

返回內容：

{      "code" : 0,      "data" : {          "version" :  "0.4" ,          "pkg" :  "0.2_0.4.zip" ,          "link" :  "http://cdn/version/download?pkg=0.2_0.4.zip" ,          "hash" :  "0ce3580a8c1b35bedad056d7d5f5ca1f"      },      "message" :  "" }

 

異常信息：

{      code: 1，      message:  '異常信息' }

 

說明：

1. code==0
   請求調用成功，data存儲了版本信息，link是包的下載路徑，下載對應的升級包，覆蓋本地目錄。
2. code==1
   請求調用異常，message存儲異常信息
3. code==2
   最新版本，不須要更新。
4. code==3
   提示用戶升級APP
   APP和離線包之間可能有兼容問題，好比舊的app加載新的離線包，版本檢查接口須要作判斷，若是app的版本比較舊，給用戶提示升級app版本。

離線包下載

經過離線包檢查接口，返回離線包的下載連接以及離線包的md5結果，app經過這個連接下載離線包，對離線包進行完整性校驗，若是無問題，則覆蓋到本地。

對於須要刪除的文件，版本檢查接口返回須要刪除的文件列表，app端刪除。

監控

版本檢查接口

經過對版本檢查接口的監控，瞭解當前用戶的版本分佈，對長時間沒有請求的版本作清除處理，避免生成無用的離線包，佔用磁盤空間。

離線包大小

離線包的大小須要作監控，建議不用大批量的修改後在發佈，若是離線包過大，離線包下載須要佔大量的帶寬。

版本兼容問題

app發版後，若是用戶沒有升級，有可能有離線包和APP版本不兼容的問題，針對這個問題解決思路：

1. 版本檢查請求攜帶當前app版本號，版本檢查服務判斷新版離線包是否可用，app端若是發現新版離線包不可用，提示用戶升級app。
2. 在接口調用時，若是接口不可用，提示用戶升級APP

系統架構圖

目錄結構

 根目錄

    cp

    ...

    lib

    version.json

說明：

一、按模塊劃分目錄

二、version.json文件是當前的版本信息，內容：

     {

         version:0.2

     }

版本檢查

APP端發起版本檢查狀況，附帶當前的版本做爲參數，從更目錄下的version.json文件獲取。

請求格式：

http://10.0.3.67:7100/version/check/[version]

示例：

http://10.0.3.67:7100/version/check/0.2

返回內容：

0.2_0.3

這個是升級包的包名，拿到包名後，訪問cdn路徑，下載對應的升級包，覆蓋本地目錄。

若是返回的內容是當前的版本號，則不須要更新。

離線包下載

請求格式：

http://10.0.3.67:7100/version/download/[包名]/

示例：

http://10.0.3.67:7100/version/download/0.1_0.2/

包名由版本檢查接口返回，後續離線包會推送到CDN，經過CDN的URL下載，這個下載連接供測試使用。

離線包構建

版本映射文件生成

版本比對，獲取變化的文件，打包

離線包發佈

將打包文件發佈到靜態資源服務器

APP端版本檢查接口，

輸入：當前版本，返回：是否須要更新，更新後的版本文件

從靜態資源服務器加載新的離線包，覆蓋到本地

注意：跨版本升級，須要提供各個版本升級須要的離線包。

 

發佈平臺

提供hybrid的靜態資源管理UI

管理離線包的版本

提供版本校驗接口

離線包構建，發佈管理，回滾

性能監控

錯誤日誌收集

版本映射文件

主版本文件設計

package.json

{

version:'main',

modules:{

"cp":"abcd",

"aa":"cdef"

}

}

 

模塊的版本設計

package.json

{

version:'',

dependens:{

"a.js":'aaa',

"c/b.js":'bbb'

}

}

優先比對主版本號，若是主版本號未變，不更新

主版本號更新，返回靜態資源包的url，編碼規則：pkg_v1_v2

 

構建過程生成包

檢查模塊，若是模塊有更新，獲取改版的資源，打包，包名的命名規則，pkg_from_to