企业发票软件系统远程升级的方法与流程

文档序号:24549798发布日期:2021-04-06 12:02阅读:86来源:国知局
企业发票软件系统远程升级的方法与流程
本申请涉及计算机
技术领域
,具体涉及一种企业发票软件系统远程升级的方法。
背景技术
:随着企业发票软件系统的发展,系统功能越来越丰富,也导致企业发票软件系统安装程序包、升级程序体积也越来越大。安装和升级过程中传输安装包的时间对应整个安装维护的时间占比也越来越大,从而导致交付周期增长,交付成本升高。因为企业发票软件系统程序包、升级程序是编译后的可执行文件,采用传统的压缩方式,压缩率较低,压缩后的代码包在传输过程中节约的时间很短,不起到缩短交付周期的作用。现有企业发票软件系统升级过程中一般采用全量安装包或增量文件。全量包虽然能保障安装程序的一致性和可靠性,但是需要重复存储和传输大量重复的依赖库文件,导致全量安装包体积较大,传输缓慢。传统的增量文件升级每次升级时由开发人员提供本次修改的增量文件,传输增量文件时间虽然能缩短,但是由于整个过程需要多次人工介入,大大增加了操作出错的可能性,安装程序的一致性和可靠性得不到保障,因此产生生产故障得不偿失。技术实现要素:本申请的目的是提供一种企业发票软件系统远程升级的方法。为了对披露的实施例的一些方面有一个基本的理解,下面给出了简单的概括。该概括部分不是泛泛评述,也不是要确定关键/重要组成元素或描绘这些实施例的保护范围。其唯一目的是用简单的形式呈现一些概念,以此作为后面的详细说明的序言。根据本申请实施例的一个方面,提供一种企业发票软件系统远程升级的方法,包括:拆解升级程序包,获得程序文件,并对拆解后的升级程序包进行分析,生成描述文件;存储所述程序文件与所述描述文件;利用程序文件以及描述文件生成传输包;发送所述传输包至远端服务器,以使所述远端服务器对所述传输包进行解析还原。进一步地,所述拆解升级程序包,获得程序文件,并对拆解后的升级程序包进行分析,生成描述文件,包括:将升级程序包进行解压,提取包内的程序文件;通过哈希算法计算每个程序文件的唯一哈希值;将所有提取出的程序文件相对于程序安装包路径与文件的哈希值进行记录生成描述文件。进一步地,所述存储所述程序文件与所述描述文件,包括:将描述文件推送至程序包存储设施中,将安装升级程序包的版本号与对应描述文件绑定;程序包存储设施采用相对与原程序安装包对的路径+哈希值+文件名方式存储。进一步地,所述发送所述传输包至远端服务器,以使所述远端服务器对所述传输包进行解析还原,包括:传输包到达远端之后,通过解压形成远端的程序包存储设施,通过分析描述文件,获取程序安装包各个组成部分的哈希值和位置信息,从而在远端的程序包存储设施中定位到安装包组成部分,根据特定顺序组合、打包重新生成程序安装包。根据本申请的另一个方面,提供一种企业发票软件系统远程升级的装置,包括:拆解模块,用于拆解升级程序包,获得程序文件,并对拆解后的升级程序包进行分析,生成描述文件;存储模块,用于存储所述程序文件与所述描述文件;生成模块,用于利用程序文件以及描述文件生成传输包;发送模块,用于发送所述传输包至远端服务器,以使所述远端服务器对所述传输包进行解析还原。进一步地,所述拆解模块具体用于:将升级程序包进行解压,提取包内的程序文件;通过哈希算法计算每个程序文件的唯一哈希值;将所有提取出的程序文件相对于程序安装包路径与文件的哈希值进行记录生成描述文件。根据本申请实施例的另一个方面,提供一种电子设备,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述处理器执行所述程序,以实现所述的企业发票软件系统远程升级的方法。根据本申请实施例的另一个方面,提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行,以实现所述的企业发票软件系统远程升级的方法。本申请实施例的其中一个方面提供的技术方案可以包括以下有益效果:本申请实施例提供的企业发票软件系统远程升级的方法,在保证安装程序的一致性和可靠性的前提下通过轻量化的传输步骤,使得企业发票软件系统升级过程中安装包、升级包的传输时间大大缩短,有效降低了交付周期,节约了交付成本。本申请的其他特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者,部分特征和优点可以从说明书中推知或毫无疑义地确定,或者通过实施本申请实施例了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。附图说明为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。图1示出了本申请的一个实施例的企业发票软件系统远程升级的方法流程图;图2示出了本申请的一个实施例的一个实施方式中的程序安装包拆解、分析、存储的流程图;图3示出了本申请的一个实施例的一个实施方式中的程序包存储实施结构的示意图;图4示出了本申请的一个实施例的一个实施方式中的程序安装包恢复、还原的流程图。具体实施方式为了使本申请的目的、技术方案及优点更加清楚明白,下面结合附图和具体实施例对本申请做进一步说明。应当理解,此处所描述的具体实施例仅用以解释本申请,并不用于限定本申请。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。本
技术领域
技术人员可以理解,除非另外定义,这里使用的所有术语(包括技术术语和科学术语),具有与本申请所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是,诸如通用字典中定义的那些术语,应该被理解为具有与现有技术的上下文中的意义一致的意义,并且除非像这里一样被特定定义,否则不会用理想化或过于正式的含义来解释。如图1所示,本申请的一个实施例提供了一种企业发票软件系统远程升级的方法,包括以下步骤:步骤01、拆解企业发票软件系统升级程序包,获得程序文件,并对拆解后的升级程序包进行分析,生成描述文件。通过将企业发票系统安装程序包进行解压,提取包内的程序文件。通过哈希算法计算每个程序文件的唯一哈希值。将所有提取出的程序文件相对于程序安装包路径与文件的哈希值进行记录生成描述文件。把提取出的文件结合描述文件与现有仓库对比差异,将仓库中不存在或损坏的文件推送至仓库中。以安装包abc.jar为例,假设安装包版本号为1.0.0,将安装包文件进行解压,提取出包内3个文件,分别计算3个文件的哈希值,得到如下信息:文件相对路径文件哈希值./lib/common.jara7da65428./config/test.confe8454631c./main.class55e160a39将上表信息写入描述文件abc.jar.digest中,将描述文件存入程序包存储设施abc.jar1.0.0版本对应的位置,完成版本号绑定。分别将3个文件结合描述文件记录的哈希值与现有仓库对比差异,将仓库中不存在或损坏的文件推送至仓库中。步骤02、将程序文件与描述文件存储至存储设备中。将描述文件推送至程序包存储设施中,将安装升级程序包的版本号与对应描述文件绑定。程序包存储设施采用相对与原程序安装包对的路径+哈希值+文件名方式存储,优点如下:1、完全相同的文件只在仓库中存储一次,不会重复存储占用存储空间。2、文件名相同但内容不同的文件因哈希值不同会分开存储,互不干预。3、已知一个文件可以通过计算一次哈希值的方式直接判断是否存在于已有的仓库中,不需要过多io操作。4、对于已存在的文件可以根据存储位置进行自我校验,发现损坏的文件。5、在已知文件哈希值与安装程序包中的路径时可以直接定位到该文件,无需进行额外的文件比较和查找。6、可避免同一个目录下存储过多文件导致系统性能下降或系统限制。图2示出了本申请的一个实施例的一个实施方式中的程序安装包拆解、分析、存储的流程图;图3示出了本申请的一个实施例的一个实施方式中的程序包存储实施结构的示意图。与传统直接存储安装程序包相比,采用该程序包存储设施存储方案,所需存储空间下降至原有空间10%以下。同样以安装包abc.jar为例,假设程序包存储设施根路径为/data/repo,则存储后的结构为:/data/repo/./lib/common.jar/a7da65428/common.jar/data/repo/./config/test.conf/e8454631c/test.conf/data/repo/./main.class/55e160a39/main.class相关名词解释:path:程序包组成部分相对路径;version:程序包组成部分哈希值;file:按照特定路径存储解包后的文件。步骤03、根据企业需求确定升级程序包版本,根据升级程序包版本从存储设备中导出对应的程序文件以及描述文件,利用程序文件以及描述文件生成传输包.在首次安装的场景中,远端不存在程序包存储设施,则通过将所需安装程序包的全部组成部分去重压缩与描述文件一并生成传输包。因为进行了去重压缩,传输包体积仅相当于安装程序包的50%左右,传输时间缩短一倍以上。在升级场景中,远端已经存在程序包存储设施,通过对比远端仓库与本次的升级程序包的文件差异,导出差异文件与本次升级程序包的描述文件生成升级传输包。因为升级传输包只包含真实存在差异的部分文件,因此升级传输包体积可压缩至升级程序包的50%-10%以下,传输时间大幅减少。在首次安装时一般会存在多个安装包,假设需要部署安装包abc.jar、efg.jar为例:abc.jar安装内容如下文件相对路径文件哈希值./lib/common.jara7da65428./config/test.confe8454631c./main.class55e160a39efg.jar安装内容如下文件相对路径文件哈希值./lib/common.jara7da65428./config/test.confe8454631c./main.class33e160a39./lib/dosomething.jare8bf9ed17传输开始前通过分析abc.jar、efg.jar全部组成部分去,可以发现./lib/common.jar和./config/test.conf两个文件重复,去重压缩后传输包内容为:因为去除了重复文件因此传输包体积变小,传输时间也因此减少。实际场景中代码包数量和重复文件数量都较多,压缩率能达到50%左右。在升级场景中,假设安装包abc.jar的1.0.1版本修改了./main.class文件,修改后的安装包内容如下:文件相对路径文件哈希值./lib/common.jara7da65428./config/test.confe8454631c./main.class35eddf0a39因为远端已经存在了./lib/common.jar和./config/test.conf,因此只需要传输./main.class,传输体积大大减少,传输时间也因此减少。步骤04、将传输包发送至远端服务器,以使远端服务器对传输包进行解析还原。在首次安装的场景中,传输包到达远端之后,通过解压形成远端的程序包存储设施,通过分析描述文件,获取程序安装包各个组成部分的哈希值和位置信息,从而在远端的程序包存储设施中定位到安装包组成部分,根据特定顺序组合、打包重新生成程序安装包。图4示出了本申请的一个实施例的一个实施方式中的程序安装包恢复、还原的流程图。在升级迭代场景中,传输包到达远端之后通过解压将差异文件更新远端的程序包存储设施,再根据描述文件与远端程序包存储设施,恢复还原出升级包,恢复步骤与首次安装场景类似。以步骤03传输包为例:在首次安装场景中根据描述文件从传输包中客户还原出abc.jar和efg.jar。在升级迭代场景中,从传输包中获取到./main.class,本地程序包存储设施中获取./lib/common.jar和./config/test.conf,形成abc.jar1.0.1版本安装包。本申请实施例提供的企业发票软件系统远程升级的方法,在保证安装程序的一致性和可靠性的前提下通过轻量化的传输步骤,使得企业发票软件系统升级过程中安装包、升级包的传输时间缩短50%-90%,有效降低了交付周期,节约了交付成本。本申请另一实施例提供了一种企业发票软件系统远程升级的装置,包括:拆解模块,用于拆解升级程序包,获得程序文件,并对拆解后的升级程序包进行分析,生成描述文件;存储模块,用于存储所述程序文件与所述描述文件;生成模块,用于利用程序文件以及描述文件生成传输包;发送模块,用于发送所述传输包至远端服务器,以使所述远端服务器对所述传输包进行解析还原。在某些实施方式中,所述拆解模块具体用于:将升级程序包进行解压,提取包内的程序文件;通过哈希算法计算每个程序文件的唯一哈希值;将所有提取出的程序文件相对于程序安装包路径与文件的哈希值进行记录生成描述文件。术语“模块”并非意图受限于特定物理形式。取决于具体应用,模块可以实现为硬件、固件、软件和/或其组合。此外,不同的模块可以共享公共组件或甚至由相同组件实现。不同模块之间可以存在或不存在清楚的界限。本申请另一实施例提供了一种电子设备,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述处理器执行所述程序,以实现上述任一实施方式的企业发票软件系统远程升级的方法。本申请另一实施例提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行,以实现上述任一实施方式的企业发票软件系统远程升级的方法。该计算机程序包含用于执行上述企业发票软件系统远程升级的方法的程序代码。需要说明的是,本申请所述的计算机可读存储介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、rf等等,或者上述的任意合适的组合。在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述,构造这类装置所要求的结构是显而易见的。此外,本申请也不针对任何特定编程语言。应当明白,可以利用各种编程语言实现在此描述的本申请的内容,并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本申请的示例性实施例的描述中,本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本申请的单独实施例。应该理解的是,虽然附图的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,其可以以其他的顺序执行。而且,附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,其执行顺序也不必然是依次进行,而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。以上所述实施例仅表达了本申请的实施方式,其描述较为具体和详细,但并不能因此而理解为对本申请专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请的保护范围应以所附权利要求为准。当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1