[发明专利]一种可扩展的高效APP渠道包打包平台

说明书

技术领域

本发明设计一种打包平台，尤其涉及一种可扩展的高效APP渠道包打包平台。

背景技术

当前APP的种类多,渠道包打包方式各异，各APP自己实现各自的渠道打包系统，打包效率低，自动化水平低，占用人力多，维护成本高。另一个方面，每个APP都有很多的推广渠道，渠道包打包耗时大，占用存储空间大，无法实现历史版本管理和问题版本的回滚。

发明内容

鉴于上述现有技术存在的缺陷，本发明的目的就是提出一种可扩展的高效APP渠道包打包平台，采用分布式打包服务技术，每个服务都可以多线程同时打包，有效提高了打包的效率，扩展了打包性能。

本发明的目的，将通过以下技术方案得以实现：一种可扩展的高效APP渠道包打包平台，包括Web管理后台、公共任务队列、分布式打包服务模块、分布式存储模块、下载站模块和CDN存储模块；

Web管理后台，用于启动打包任务，将打包渠道写入公共任务队列，设置APP的存储空间、打包方式，查看打包进度和打包结果；

公共任务队列，用于存储要打包的渠道列表，并能够提供原子性的渠道抓取接口，供分布式的多个打包服务竞争，消费打包列表；

分布式打包服务模块，用于监控公共任务队列和竞争消费公共任务队列，并根据打包任务在各自服务器中开启多个打包线程进行并行打包，并将已完成的渠道包输出到分布式存储模块；打包服务可以根据实际任务需求，拓展服务数量。

分布式存储模块，用于为渠道包提供可扩展的分布式存储，存储各APP的各版本渠道包；

下载模块，用于为各APP提供资源输出服务，并将Web管理后台发布的渠道包输出到CDN存储模块；

CDN存储模块，用于缓存渠道包，并为用户提供安装包下载资源。

本发明进一步限定的技术方案是：公共任务队列具备能够原子性获取渠道号的接口，为多个打包服务同时进行打包提供数据支持。

作为本发明的进一步改进，更进一步，公共任务队列可以不受存储数据库的限制，以要求必须实现抓可原子获取渠道号的接口，存储数据库可以采用Sql Server、MySql数据库队列或Redis高速缓存队列。

作为本发明的进一步改进，进一步，分布式打包服务模块的打包原理为：

PackingService为每个APP启动一个AppService，将不同App的打包任务，托管给有App标识的一个AppService对象；

AppService根据打包任务，启动相应的Module,将具体的打包任务，托管给Module；

Module通过公共任务队列的数据抓取实现；从公共队列中原子性的批量抓取渠道号，并存储在内存队列中；同时启动多个Handler线程，并管理这些Handler线程，将消费内存队列的任务，托管给已经启动的Handler线程，实现一个服务多线程并行打渠道包；

Handler线程，消费自己所在的打包服务内的内存渠道号队列，并在打包时，根据APP的不同，装载不同的打包器，将具体的打包托管打包器；来实现打包服务能支持任意多个APP的打包任务，使得打包服务可支持打包的App类型数量可以不受限制的扩展。

作为本发明的进一步改进，进一步，分布式存储模块可以存储大量App打包生成的高数量渠道包；分布式存储方式可以拓展存储空间和备份文件。

作为本发明的进一步改进，进一步，下载站根据Web管理后台的设置借助分布式存储模块和CDN快速发布新版本，新版本可以快速回滚旧版本。

本发明的突出效果为：

1、采用分布式打包服务，拓展了打包服务的数量，且每个服务内采用多线程同时打包，有效提高了打包的速度和效率。

2、打包器可以针对接口进行拓展，支持的APP数量不受限制，也可以有效的整合多APP的渠道包打包，并将之管理起来。

3、可扩展的存储性能，可以存储各版本的渠道包，实现问题版本的快速回滚，同时采用备份机制增强了存储的安全性。

4、利用第三方CDN存储可以为用户提供了高速率的安装包下载资源，很好的提高终端用户的客户体验度。

附图说明

图1为本发明的平台结构示意图；

图2为本发明的打包服务原理示意图。

具体实施方式

实施例一

为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。