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