本发明涉及计算机技术领域，尤其涉及一种jar包的运行方法及系统。
背景技术：
jar包是其他人或组织已经写好的一些类，然后将这些类进行打包。用户可以将这些jar包引入对应的项目中，然后就可以直接使用这些jar包中的类和属性以及方法。jar包依赖是java项目开发过程中的必须品，当用户的项目中需要用到一些功能时，就会考虑去引用提供这些功能和能力的jar包。但是，当前版本的jar包有可能存在bug、或者会添加新功能，此时新版本的jar包就诞生了，需要在项目中去升级这些jar包。目前，现有技术是借助maven(软件项目管理工具)的snapshot(快照版本)功能去做升级。snapshot本身用途是指该版本jar包处于测试中，因此是一个不稳定的版本，可以持续覆盖、持续更新。除此之外，目前多个jar包之间的合理搭配、jar包重复依赖都是通过人工去排查，即当运行出错时，人工查找问题去排包。
现有的jar包升级、发布方式存在以下弊端：一方面，snapshot版本本身就代表该版本处于测试中、不稳定，真正提供给用户和项目使用的应该是release(稳定)版本，使用snapshot版本会导致项目存在不可控的风险。如果每次项目打包都从snapshot库拉取最新时间的jar包，此时这个jar包可能已被修改，导致应用启动不起来或运行出错，而就算某几个项目没问题，也保证不了所有项目没问题；另一方面，jar包冲突和重复依赖问题通过人工去排查非常费时费力，而且每个项目的项目人员都得去做这样的事情，成本非常高，严重情况可能导致项目延期。
技术实现要素：
基于此，本发明提供了一种jar包的运行方法及系统，以解决现有技术中无法保证项目中使用jar包的统一性，以及jar包版本冲突的问题。
本发明提供的一种jar包的运行方法，包括以下步骤：
s100、对需要加载的jar包进行规范性检查，并将通过所述规范性检查的jar包合成一个jar包集合，并对所述jar包集合进行集成测试和灰度处理；
s200、将通过所述集成测试、同时满足灰度要求的jar包集合放置在应用服务器上，供自定义加载器加载。
作为一种可实施方式，本发明提供的jar包的运行方法，还包括以下步骤：
在应用启动后，启动jar包隔离容器，利用所述jar包隔离容器初始化所述自定义类加载器，并在所述自定义类加载器中定义加载的jar包及其路径。
作为一种可实施方式，步骤s100包括以下步骤：
s110、添加jar包的maven属性；
s120、从maven仓库下载jar包；
s130、对下载的jar包进行扫描，检查jar包的规范性；
s140、将符合规范的jar包集成在一起，合成一个jar包集合，并将jar包集合的状态设置为测试中；
s150、在样本项目中运行状态为测试中的jar包集合；
s160、判断状态为测试中的jar包集合在样本项目中是否成功启动并运行，若判断为是，进入步骤s170；若判断为否，则进入步骤s180；
s170、对状态为测试中的jar包集合进行环境测试，进入步骤s190；
s180、提示当前jar包集合存在问题，并删除当前jar包集合；
s190、判断状态为测试中的jar包集合环境测试是否正常；若环境测试结果正常，则进入步骤s191，若环境测试结果不正常，则进入步骤s180；
s191、将当前的jar包集合的状态修改为灰度中；
s192、对状态为灰度中的jar包集合进行灰度发布；
s193、判断状态为灰度中的jar包集合的灰度是否正常；若判断灰度正常，则进入步骤s194；若判断灰度不正常，则进入步骤s195；
s194、将当前的jar包集合的状态修改为已发布，并设置为基准版本；
s195、应用回滚到上一版本，进入步骤s180。
作为一种可实施方式，步骤s200包括以下步骤：
s210、在应用启动后，启动jar包隔离容器；
s220、检查本地是否存在jar包集合；如果本地存在jar包集合，则进入步骤s230；如果本地不存在jar包集合，则进入步骤s240；
s230、判断本地的jar包集合版本是否是基准版本，若是基准版本，则进入步骤s260；若不是基准版本，则进入步骤s240；
s240、下载基准版本，进入步骤s250；
s250、解压并加载jar包集合，进入步骤s260；
s260、控制jar包隔离容器启动应用。
作为一种可实施方式，所述自定义加载器加载jar包集合时，将应用名称和环境作为参数请求jar包集合的地址。
相应地，本发明提供的一种jar包的运行系统，包括集成模块和发布模块；
所述集成模块，用于对需要加载的jar包进行规范性检查，并将通过所述规范性检查的jar包合成一个jar包集合，并对所述jar包集合进行集成测试和灰度处理；
所述发布模块，用于将通过所述集成测试、同时满足灰度要求的jar包集合放置在应用服务器上，供自定义加载器加载。
作为一种可实施方式，本发明提供的jar包的运行系统，还包括初始化模块；
所述初始化模块，用于在应用启动后，启动jar包隔离容器，利用所述jar包隔离容器初始化所述自定义类加载器，并在所述自定义类加载器中定义加载的jar包及其路径。
作为一种可实施方式，所述集成模块包括添加单元、jar包下载单元、扫描单元、集成单元、试运行单元、安全性判断单元、环境测试单元、删除单元、环境测试判断单元、灰度状态设置单元、灰度发布单元、灰度判断单元、已发布状态设置单元以及返回单元；
所述添加单元，用于添加jar包的maven属性；
所述jar包下载单元，用于从maven仓库下载jar包；
所述扫描单元，用于对下载的jar包进行扫描，检查jar包的规范性；
所述集成单元，用于将符合规范的jar包集成在一起，合成一个jar包集合，并将jar包集合的状态设置为测试中；
所述试运行单元，用于在样本项目中运行状态为测试中的jar包集合；
所述安全性判断单元，用于判断状态为测试中的jar包集合在样本项目中是否成功启动并运行，若判断为是，进入所述环境测试单元；若判断为否，则进入所述删除单元；
所述环境测试单元，用于对状态为测试中的jar包集合进行环境测试，进入所述环境测试判断单元；
所述删除单元，用于提示当前jar包集合存在问题，并删除当前jar包集合；
所述环境测试判断单元，用于判断状态为测试中的jar包集合环境测试是否正常；若环境测试结果正常，则进入所述灰度状态设置单元，若环境测试结果不正常，则进入所述删除单元；
所述灰度状态设置单元，用于将当前的jar包集合的状态修改为灰度中；
所述灰度发布单元，用于对状态为灰度中的jar包集合进行灰度发布；
所述灰度判断单元，用于判断状态为灰度中的jar包集合的灰度是否正常；若判断灰度正常，则进入所述已发布状态设置单元；若判断灰度不正常，则进入所述返回单元；
所述已发布状态设置单元，用于将当前的jar包集合的状态修改为已发布，并设置为基准版本；
所述返回单元，用于应用回滚到上一版本，进入所述删除单元。
作为一种可实施方式，所述发布模块包括容器启动单元、本地检查单元、基准版本判断单元、基准版本下载单元、加载单元以及启动应用单元；
所述容器启动单元，用于在应用启动后，启动jar包隔离容器；
所述本地检查单元，用于检查本地是否存在jar包集合；如果本地存在jar包集合，则进入所述基准版本判断单元；如果本地不存在jar包集合，则进入所述基准版本下载单元；
所述基准版本判断单元，用于判断本地的jar包集合版本是否是基准版本，若是基准版本，则进入所述启动应用单元；若不是基准版本，则进入所述基准版本下载单元；
所述基准版本下载单元，用于下载基准版本，进入所述加载单元；
所述加载单元，用于解压并加载jar包集合，进入所述加载单元；
所述加载单元，用于控制jar包隔离容器启动应用。
作为一种可实施方式，所述自定义加载器加载jar包集合时，将应用名称和环境作为参数请求jar包集合的地址。。
与现有技术相比，本技术方案具有以下优点：
本发明提供的jar包的运行方法及系统，通过对需要加载的jar包进行规范性检查，并将通过规范性检查的jar包合成一个jar包集合，并对jar包集合进行集成测试和灰度处理，最终将通过集成测试、同时满足灰度要求的jar包集合放置在应用服务器上，供自定义加载器加载。经过统一测试jar包，保证了jar包的安全可靠性；进一步地，jar包集合进行集成测试和灰度处理后发布，方便jar包的升级；同时保证了项目中在使用jar包的统一性，实现了统一加载jar包，避免了多版本冲突问题。
附图说明
图1为本发明实施例一提供的jar包的运行方法的流程示意图；
图2为本发明提供的实现图1所示的jar包的运行方法的系统的结构示意图；
图3为图2所示的系统的工作原理示意图；
图4为图3所示的系统集成zan包的流程示意图；
图5为图3所示的系统加载zan包的流程示意图；
图6为本发明实施例二提供的jar包的运行系统的结构示意图。
具体实施方式
以下结合附图，对本发明上述的和另外的技术特征和优点进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的部分实施例，而不是全部实施例。
参见图1，本发明实施例一提供了一种jar包的运行方法，包括以下步骤：
s100、对需要加载的jar包进行规范性检查，并将通过规范性检查的jar包合成一个jar包集合，并对jar包集合进行集成测试和灰度处理；
s200、将通过集成测试、同时满足灰度要求的jar包集合放置在应用服务器上，供自定义加载器加载。
本发明实施例一提供的jar包的运行方法可以通过如图2所示的系统实现，该系统包括jar包集合存储服务器10、运维管理系统20和jar包隔离容器30；其中，jar包集合存储服务器用于存储集成后的jar包集合，运维管理系统用于jar包集合的集成、测试、灰度、以及发布等，jar包集合容器用于jar包集合的加载和应用的启动加载。为了容易区分jar包和jar包集合，下面实施例中均将jar包集合定义为zan包，以免引起表述错误。
具体地，在应用启动后，先启动jar包隔离容器，利用jar包隔离容器初始化自定义类加载器其重新加载启动应用，并在自定义类加载器中定义加载的jar包及其路径，由此实现jar包加载的完全可控(默认一个应用的类加载都是由jvm提供的默认类加载器加载)。另一方面，运维管理系统会生成一个jar包集合，通过jar包检查、集成测试、灰度等能力，保证同一jar包的版本唯一、以及jar包集合的可用性和可靠性，然后发布jar包集合；最终，将jar包集合放置在应用服务器上，供自定义类加载器实现了jar包的统一测试和统一发布，保证了jar包的安全可靠性，方便升级，并对于项目开发人员是透明的，同时也帮项目开发人员解决了jar包冲突问题，大大提升了项目开发的效率。
本发明通过对需要加载的jar包进行规范性检查，并将通过规范性检查的jar包合成一个jar包集合，并对jar包集合进行集成测试和灰度处理，最终将通过集成测试、同时满足灰度要求的jar包集合放置在应用服务器上，供自定义加载器加载。经过统一测试jar包，保证了jar包的安全可靠性；进一步地，jar包集合进行集成测试和灰度处理后发布，方便jar包的升级；同时保证了项目中在使用jar包的统一性，实现了统一加载jar包，避免了多版本冲突问题。此外，利用运维管理系统和jar包隔离容器对jar包进行管理和加载，使得每一个开发人员从jar包管理及相关问题解决中解放出来，节省了大量时间，而且避免了依赖人工去推动jar包升级的问题，打造了jar包发布升级的标准渠道。
参见图3，结合上述系统，定义jar包集合为zan包，例如aladdin.zan，zan包里面是很多的jar包以及一些版本相关的信息，这样子的一个压缩包称之为zan包。本发明提供了一种jar包的运行方法，其基本流程可概括如下：
步骤1，集成zan包；
步骤2，上传zan包；
步骤3，更新zan包版本；
步骤4，请求zan包地址；
步骤5，返回zan包地址；
步骤6，下载zan包；
步骤7，启动应用；
步骤8，确认启动。
具体的，在步骤1中，集成zan包过程中，有很多的步骤，这个过程是一个jar包的集合和集成过程，会对jar包进行规范检查、安全检查等，并会进行集成测试、灰度整个过程，最终发布上传。zan包集成其实是添加jar包的过程，同时也是一个非常复杂且又完善的系统性流程，来保证最终发布的zan包是安全可靠的。
进一步地，作为一种可实施方式，如图4所示，集成zan包步骤也就是上述实施例一种的步骤s100，可通过以下步骤实现：
s110、添加jar包的maven属性；
s120、从maven仓库下载jar包；
s130、对下载的jar包进行扫描，检查jar包的规范性；
s140、将符合规范的jar包集成在一起，合成一个jar包集合，定义为zan包，并将zan包集合的状态设置为测试中；
s150、在样本项目中运行状态为测试中的zan包；
s160、判断状态为测试中的zan包在样本项目中是否成功启动并运行，若判断为是，进入步骤s170；若判断为否，则进入步骤s180；
s170、对状态为测试中的zan包集合进行环境测试，进入步骤s190；
s180、提示当前zan包存在问题，并删除当前zan包；
s190、判断状态为测试中的zan包环境测试是否正常；若环境测试结果正常，则进入步骤s191，若环境测试结果不正常，则进入步骤s180；
s191、将当前的zan包的状态修改为灰度中；
s192、对状态为灰度中的zan包进行灰度发布；
s193、判断状态为灰度中的zan包的灰度是否正常；若判断灰度正常，则进入步骤s194；若判断灰度不正常，则进入步骤s195；
s194、将当前的zan包的状态修改为已发布，并设置为基准版本；
s195、应用回滚到上一版本，进入步骤s180。在集成的zan包出现问题时，迅速做到全网回滚。
一般一个jar包里会包含文件manifest.mf，这个文件会有一些关于这个jar包的信息，如包名、作者、等信息，添加jar包时会让提交者填写这些基础信息，和manifest.mf里的这些基础信息进行对比，除此之外如groupid(项目组织唯一的标识符)、artifactid(项目唯一的标识符)这些信息还会去遍历具体的class(类)查看是否对应，如果这些检查都通过，才能说明这个jar包是正确合法的，否则这个jar包就不合格，无法集成。这样做的好处是从源头上统一控制了每一个jar包的质量。
虽然jar包经过了严格的检查和校验，但是无法保证这个jar包内部的逻辑和代码是否存在问题，所以接下来会先合成一个测试版的zan包(即前述的jar包集合)用于测试，经过灰度发布的过程(灰度：是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行a/btesting，即让一部分用户继续用产品特性a，一部分用户开始用产品特性b，如果用户对b没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到b上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度)，一旦灰度出问题，马上回滚到上一版本的zan包，所以这样的zan包集成可以最大程度的保证zan包安全、稳定、可靠的发布。
具体的，在步骤4中，请求zan包地址，其实这个步骤中或者这个步骤之前做了很多操作。在请求zan包地址时，会将appname(应用名称)、env(环境[qa、dev、prod、pre])作为参数进行请求，运维管理系统根据这些参数返回正确的结果，即指定版本的zan包下载地址。一般情况下，运维人员会设置某个应用在某个环境下的zan包版本，如果不设置就返回基准版本的zan包，这样充分保证了灵活性，也支持了灰度的能力。此外，当出现问题时，可以很方便的回滚到原来版本。
具体的，在步骤7中，启动应用过程中，整体启动流程如图3所示，jar包隔离容器会先启动，然后会去检查本地zan包：
如果本地存在就会检查版本是否是基准版本，否就重新下载；
如果本地不存在就直接向运维管理系统下载zan包。
然后jar包隔离容器启动应用的过程中，jar包隔离容器会设置应用的类加载器为自定义的类加载器。再接下去java类的初始化和调用过程中，自定义类加载器会负责加载。
进一步地，作为一种可实施方式，如图5所示，加载zan包的步骤也就是上述实施例一种的步骤s200，可通过以下步骤实现：
s210、在应用启动后，启动jar包隔离容器；
s220、检查本地是否存在zan包；如果本地存在zan包则进入步骤s230；如果本地不存在zan包，则进入步骤s240；
s230、判断本地的zan包版本是否是基准版本，若是基准版本，则进入步骤s260；若不是基准版本，则进入步骤s240；
s240、下载基准版本，进入步骤s250；
s250、解压并加载zan包，进入步骤s260；
s260、控制jar包隔离容器启动应用。
基于同一发明构思，本发明实施例二还提供了一种jar包的运行系统，该系统与前述jar包的运行方法原理相同，具体实施过程可参照上述方法实现，重复之处不再冗述。
如图6所示，本发明实施例二提供的jar包的运行系统，包括集成模块100和发布模块200；集成模块100用于对需要加载的jar包进行规范性检查，并将通过规范性检查的jar包合成一个jar包集合，并对jar包集合进行集成测试和灰度处理；发布模块200用于将通过集成测试、同时满足灰度要求的jar包集合放置在应用服务器上，供自定义加载器加载。
进一步地，实施例二提供的jar包的运行系统，还包括初始化模块；初始化模块用于在应用启动后，启动jar包隔离容器，利用jar包隔离容器初始化自定义类加载器，并在自定义类加载器中定义加载的jar包及其路径。
具体地，集成模块100包括添加单元、jar包下载单元、扫描单元、集成单元、试运行单元、安全性判断单元、环境测试单元、删除单元、环境测试判断单元、灰度状态设置单元、灰度发布单元、灰度判断单元、已发布状态设置单元以及返回单元。
添加单元用于添加jar包的maven属性；jar包下载单元用于从maven仓库下载jar包；扫描单元用于对下载的jar包进行扫描，检查jar包的规范性；集成单元用于将符合规范的jar包集成在一起，合成一个jar包集合，并将jar包集合的状态设置为测试中；试运行单元用于在样本项目中运行状态为测试中的jar包集合；安全性判断单元用于判断状态为测试中的jar包集合在样本项目中是否成功启动并运行，若判断为是，进入环境测试单元；若判断为否，则进入删除单元；环境测试单元用于对状态为测试中的jar包集合进行环境测试，进入环境测试判断单元；删除单元用于提示当前jar包集合存在问题，并删除当前jar包集合；环境测试判断单元用于判断状态为测试中的jar包集合环境测试是否正常；若环境测试结果正常，则进入灰度状态设置单元，若环境测试结果不正常，则进入删除单元；灰度状态设置单元用于将当前的jar包集合的状态修改为灰度中；灰度发布单元用于对状态为灰度中的jar包集合进行灰度发布；灰度判断单元用于判断状态为灰度中的jar包集合的灰度是否正常；若判断灰度正常，则进入已发布状态设置单元；若判断灰度不正常，则进入返回单元；已发布状态设置单元用于将当前的jar包集合的状态修改为已发布，并设置为基准版本；返回单元用于应用回滚到上一版本，进入删除单元。
发布模块200包括容器启动单元、本地检查单元、基准版本判断单元、基准版本下载单元、加载单元以及启动应用单元。
容器启动单元用于在应用启动后，启动jar包隔离容器；本地检查单元用于检查本地是否存在jar包集合；如果本地存在jar包集合，则进入基准版本判断单元；如果本地不存在jar包集合，则进入基准版本下载单元；基准版本判断单元用于判断本地的jar包集合版本是否是基准版本，若是基准版本，则进入启动应用单元；若不是基准版本，则进入基准版本下载单元；基准版本下载单元用于下载基准版本，进入加载单元；加载单元用于解压并加载jar包集合，进入加载单元；加载单元用于控制jar包隔离容器启动应用。
自定义加载器加载jar包集合时，将应用名称和环境作为参数请求jar包集合的地址。
上述实施例二提供的jar包的运行系统，可以实现jar包的统一测试和统一发布，保证jar包的安全可靠性，方便升级，同时也解决了jar包冲突问题，大大提升了项目开发的效率。
本发明虽然已以较佳实施例公开如上，但其并不是用来限定本发明，任何本领域技术人员在不脱离本发明的精神和范围内，都可以利用上述揭示的方法和技术内容对本发明技术方案做出可能的变动和修改，因此，凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化及修饰，均属于本发明技术方案的保护范围。