CN106909411B - 一种文件更新方法及装置 - Google Patents

Abstract

本发明公开了一种文件更新方法及装置，用以解决系统版本在线发布及故障的修复响应时间长、影响业务连续性、以及用户感知差的技术问题。本发明包括：接收针对一个服务的文件更新请求，文件更新请求中包括请求更新的待生效文件；监控在接收到文件更新请求时已加载的针对该服务的调用请求，并缓存在接收到文件更新请求后针对该服务的调用请求；判断已加载的针对该服务的调用请求是否全部调用结束，若判断所述已加载的针对该服务的调用请求全部调用结束，则根据所述待生效文件，对所述服务进行更新处理；加载缓存的所述调用请求，调用更新后的所述服务。本发明实现了在支撑该服务调用的系统正常运行的情况下进行文件的更新和生效。

Description

一种文件更新方法及装置

技术领域

本发明实施例涉及数据更新领域，尤其涉及一种文件更新方法及装置。

背景技术

业务支撑系统(包括CRM\BOSS\BAS\BOMC等)目前在版本更新、故障修复时，代码以及配置文件在本地测试环境修改完成并充分测试后，必须等到现网业务应用较少的时刻或无业务时(比如凌晨、夜间)才能够将改动更新到生产环境，并进行应用系统的重启，等待系统重启完成，改动生效后再进一步进行真实环境的测试验证。如果遇到测试验证不通过的情况，还需要紧急回退回备份版本，并再次重启使回退动作生效。现有的业务支撑系统代码及配置文件更新方法具有以下缺点：

1、系统业务连续性无法长效保障：新业务需求上线、代码及配置文件的bug修改都需要中断系统，重启应用服务，导致0.1％的代码改造需要影响100％的业务功能，重启需要时间，在这段时间内业务无法办理，同时会影响外围系统的大量业务数据的不一致，系统业务连续性无法得到长效保障。

2、故障处理及影响时间长：当系统出现代码问题导致的故障以后，无法进行快速的在线修补及测试，需要重新上线。业务正常使用过程中发现的故障无法立即解决，只能等到夜间进行系统重启，其间目睹故障不断发生也无法实时干预。

3、客户感知较差：用户业务系统使用过程中发现的bug无法得到及时有效的修复，容易给用户带来故障响应不及时的感受，另外，系统新版本发布时需要中断应用系统，影响客户使用体验，客户感知较差。

综上，现有技术中业务支撑系统代码及配置文件的更新过程因需要应用系统重启才能完成，使得系统版本在线发布及故障的修复存在着响应时间长、影响业务连续性、以及用户感知差的技术问题。

发明内容

本发明实施例提供一种文件更新方法及装置，用以解决现有技术中系统版本在线发布及故障的修复存在的响应时间长、影响业务连续性、以及用户感知差的技术问题。

本发明实施例提供一种文件更新方法，包括：

接收针对一个服务的文件更新请求，所述文件更新请求中包括请求更新的待生效文件；

监控接收到所述文件更新请求时已加载的针对该服务的调用请求，并缓存接收到所述文件更新请求后针对该服务的调用请求；

判断所述已加载的针对该服务的调用请求是否全部调用结束；

若判断所述已加载的针对该服务的调用请求全部调用结束，则根据所述待生效文件，对所述服务进行更新处理；

加载缓存的所述调用请求，调用更新后的所述服务。

本发明实施例提供一种文件更新装置，包括：

接收单元，用于接收针对一个服务的文件更新请求，所述文件更新请求中包括请求更新的待生效文件；

监控单元，用于监控接收到所述文件更新请求时已加载的针对该服务的调用请求；

缓存单元，用于缓存接收到所述文件更新请求后针对该服务的调用请求；

判断单元，用于判断所述已加载的针对该服务的调用请求是否全部调用结束；

更新单元，用于若所述判断单元判断所述已加载的针对该服务的调用请求全部调用结束，则根据所述待生效文件，对所述服务进行更新处理；

执行单元，用于加载缓存的所述调用请求，调用更新后的所述服务。

上述实施例中，在接收到针对一个服务的文件更新请求时，为了确保服务类文件和配置文件的更新不对系统的正常运行产生矛盾，防止系统业务对象的运行过程中进行文件更新导致的代码逻辑或数据不一致的现象，本发明实施例通过确定合适时机进行文件更新，即判断已加载的针对该服务的调用请求全部调用结束时，来进行该服务的类文件和/或配置文件的更新。为了实现在支撑该服务调用的系统正常运行的情况下进行文件的更新和生效，本发明实施例制定了业务调用请求与文件更新请求的处理逻辑，在接收到针对一个服务的文件更新请求时，首先监控接收到所述文件更新请求时已加载的针对该服务的调用请求，并缓存接收到所述文件更新请求后针对该服务的调用请求；其次，判断所述已加载的针对该服务的调用请求是否全部调用结束，当已加载的针对该服务的调用请求全部调用结束时，来进行该服务的类文件和/或配置文件的更新；再次，基于更新后的所述服务的类文件和/或配置文件对所述服务进行调用；这样实现在支撑该服务调用的系统正常运行的情况下进行文件的更新和生效，与现有技术相比，并基于生效后的服务调用恢复暂停运行的业务对象，可以大大缩短系统版本在线发布及故障的修复的响应时间；对于客户来说，其反映的问题可极速得到响应，使得客户的感知得到提升；对于运营系统来说，系统不会因为频繁的修复而出现间歇性停机的状况发生，全天候无中断的提供服务的方式确保了业务的连续性，使得系统的稳定性大为提升。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种文件更新方法的架构图；

图2为本发明实施例提供的一种文件更新方法的流程图；

图3为本发明实施例提供的一种类文件更新方法的流程图；

图4为本发明实施例提供的一种配置文件更新方法的流程图；

图5为本发明实施例提供的一种文件更新逻辑流程图；

图6为本发明实施例提供的一种文件更新装置的结构图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

为了解决现有技术中存在的系统版本在线发布及故障的修复的响应时间长、影响业务连续性、以及用户感知差的技术问题。本发明实施例提供了一种结合“最末参与者算法”来实现业务支撑系统中涉及的JAVA类文件(JAVA代码)、配置文件的更新和生效的应用架构。本发明实施例中，由“最末参与者算法”确定进行文件更新的时刻，基于确定的文件更新时刻，通过自定义类加载器实现类加载缓存中的JAVA代码的自动生效，通过侦听ZOOKEEPER集群配置文件目录的异动，进行配置对象版本的替换来实现配置对象缓存中的配置文件的自动生效。

用于实现JAVA类文件、配置文件的更新和生效的应用架构如图1所示，包括服务管理侧的应用容器10，JAVA类扫描进程组20和客户端侧的ZOOKEEPER集群30。其中，应用容器10包括：应用加载总线100、缓存协调器110、自定义类加载器120、文件目录监听器130和配置对象管理器140，以及可调用的最末参与者算法150。

其中，应用容器10负责管理与服务应用程序相关的类及配置文件的整个生命周期。

JAVA类扫描进程组20，用于定时扫描缓存协调器110的类加载缓冲区是否有新的JAVA类文件。

ZOOKEEPER集群30，用于存储配置文件和维护配置文件目录，提供分布式系统的配置协调服务，将配置文件维护在ZOOKEEPER集群中，通过ZOOKEEPER程序的客户端，便于修改配置文件，还可以为分布式系统提供统一的配置协调。本发明实施例中，ZOOKEEPER集群包括检测代理，可定时扫描ZOOKEEPER集群30所维护的配置文件目录是否有变动，但是在上述架构中，由文件目录监听器130向ZOOKEEPER集群30注册对配置数据的订阅，文件目录监听器130相当于ZOOKEEPER集群30的检测代理，来监听ZOOKEEPER集群30的配置文件目录是否变动。

应用加载总线100是系统启动、运行的核心，也是服务应用程序的类文件和配置文件的加载入口。应用加载总线100还用于管理缓存协调器110和文件目录监听器130，接收缓存协调器110和文件目录监听器130上报的文件更新请求，并调用最末参与者算法来确定进行文件更新的时间，当确定进行文件更新时，向缓存协调器110或者文件目录监听器130反馈允许更新的响应消息，应用加载总线100还用于确定新文件生效后，加载新的业务请求，调用更新后的服务。

缓存协调器110，包括类加载缓冲区，类加载缓冲区用于缓存上传的JAVA类文件，当JAVA类扫描进程组20扫描到类加载缓冲区有新的类文件时，缓存协调器110向应用加载总线100发送文件更新请求，接收应用加载总线100返回的允许更新的响应消息，并向自定义加载器120下发更新指示，还用于建立和维护类文件目录索引；自定义类加载器120，用于根据缓存协调器110的更新指示，对类文件进行更新和生效；

文件目录监听器130，用于向ZOOKEEPER集群30注册对配置数据的订阅，监听ZOOKEEPER集群30的配置文件目录是否变动，若有变动，向应用加载总线100发送文件更新请求，并接收应用加载总线100返回的允许更新的响应消息，并向配置对象管理器140下发更新指示，并在配置对象管理器140完成配置对象新版本的替换，使新的配置文件生效后，向ZOOKEEPER集群30反馈配置文件生效通知；

配置对象管理器140，用于根据文件目录监听器130下发的更新指令，根据新的配置文件，生成配置对象新版本，完成配置对象新版本的替换，使新的配置文件生效。

上述架构的应用覆盖但不限于以下场景：

场景一：生产系统上仅发现有JAVA字节代码需要进行不停机上线时，如BUG修复、业务逻辑变更导致的代码调整、新业务上线等。在此情况下由上述架构实现JAVA字节代码的更新，首先是将JAVA代码上传到缓存协调器110的类加载缓冲区，当JAVA类扫描进程组20扫描到缓存协调器110的类加载缓冲区有新的JAVA类文件时，缓存协调器110将类加载缓冲区的加载标识更改为Y，通过缓存协调器110向应用加载总线100提交类文件更新请求。应用加载总线100通过缓存协调器110接收类文件更新请求，并通过缓存协调器110向自定义类加载器120发送针对该类文件更新请求的允许更新响应消息，以使自定义类加载器120加载新的JAVA类文件使得新的JAVA类文件生效，新的JAVA类文件生效后，自定义类加载器120通知缓存协调器110将类加载缓冲区的加载标识更改为N。这种场景下，在自定义类加载器120加载新的类文件之前，将类文件放在加载缓冲区可以降低类生效中间的资源锁的时长，在确定允许更新的时候，自定义类加载器120从缓存协调器110的类加载缓冲区读取类文件进行加载的速度快，可有效缩短版本发布及故障解决的响应时间。

场景二：生产系统上仅发现有部分配置文件(如XML\PROPERTIES\TXT等)需要调整生效时，如配置地市信息的XML文件里面需要增加一个地市、日志的级别配置LOG4J.PROPERTIES的级别调整等。在此情况下由上述架构实现配置文件的更新。首先是将新的配置文件上传ZOOKEEPER集群30中，系统启动后，若ZOOKEEPER集群30上传有新的配置文件或有需要更改的配置文件，将ZOOKEEPER集群30的加载标识更改为Y，文件目录监听器130会监听到ZOOKEEPER集群30的配置文件目录发生了变动，或者ZOOKEEPER集群30的检测代理向文件目录监听器130上报配置文件目录变动通知，此时文件目录监听器130向应用加载总线100提交配置文件更新请求。应用加载总线100通过文件目录监听器130接收配置文件更新请求，之后应用加载总线100向缓存协调器110发送针对该配置文件更新请求的允许更新响应消息，文件目录监听器130指示配置对象管理器140将新的配置文件转化成配置对象新版本，并将配置对象旧版本替换为配置对象新版本，使得配置对象新版本在应用加载总线100上生效。同时配置对象管理器140通过文件目录监听器130通知ZOOKEEPER集群将ZOOKEEPER集群的加载标识更新为N。本场景中，增加配置对象管理器140，由配置对象管理器140建立配置文件和配置对象的映射，需要进行配置文件更新时，将配置文件转化成JAVA对象，得到配置对象新版本。通过在配置对象管理器140中设计配置对象新旧版本，当允许进行配置文件更新时，将旧的配置对象版本替换成新的配置对象版本，利用版本替换的方式实现配置对象的更新，使得新配置文件生效的效率极大提高，配置对象新旧版本的替换过程瞬间完成，进而大大缩短了配置文件更新的响应时间。

为了能够了确保类文件和配置文件的加载和生效不会与系统的正常运行产生矛盾，防止系统业务对象的运行过程中进行文件更新导致的代码逻辑或数据不一致的现象，缓存协调器110或文件目录监听器130向应用加载总线100上报针对某个服务的文件更新请求之后，应用加载总线100并不是立即发送针对文件更新请求的允许更新响应消息，而是先调用服务监控，监控接收到文件更新请求时应用加载总线100已加载的针对该服务的调用请求，并缓存接收到文件更新请求后针对该服务的调用请求；其次，调用最末参与者算法150，判断已加载的针对该服务的调用请求是否全部调用结束，当已加载的针对该服务的调用请求全部调用结束时，才向缓存协调器110或文件目录监听器130发送针对文件更新请求的允许更新响应消息。上述架构的最末参与者算法150，具体用于判断已加载的针对该服务的调用请求是否全部调用结束，若判断全部调用结束，则向应用加载总线100反馈允许更新的通知消息，若判断还未全部调用结束，则向应用加载总线100反馈暂时不允许更新的通知消息。应用加载总线100根据最末参与者算法150反馈的允许更新的通知消息，向缓存协调器110或文件目录监听器130发送针对文件更新请求的允许更新响应消息。缓存协调器110接收到允许更新响应消息后，会指示自定义类加载器120进行类文件的更新，或文件目录监听器130接收到允许更新响应消息后，会指示配置对象管理器140进行配置文件的配置对象新旧版本的替换，按照上述流程对服务的类文件或配置文件进行更新之后，基于更新后的服务对缓存的调用请求进行调用。

下面以配置文件的更新为例对最末参与者算法150进行详细说明。

为保证更新前后的系统状态的一致性,配置文件服务在动态更新前必须进入配置文件服务请求静止状态，否则极易出现代码逻辑或数据不一致的现象。这就要求当最后一个配置文件请求服务实例完成调用以后才可以替换该配置文件服务用到的配置文件，否则会出现一个配置文件服务的多个版本配置数据在同时运行的异常现象。

其中，服务请求静止状态需要满足如下条件:

1、服务当前没有参与自行启动的事务，即自行启动的事务已经执行完成。

2、服务将来不会自行启动新的事务。

3、服务当前没有参与由其他服务启动的事务。

4、服务将来不会参与由其他服务启动的事务。

本发明实施例采用最末参与者算法150确定系统是否处于服务请求静止状态，该算法的基本思路是配置文件服务Sn在等待时间上限时长t之内被调用的次数P(Sn)为0时，用新的配置文件服务Sn'进行替换。公式：

O[P(Sn)]t＝0？Sn'→Sn：Sn→Sn，其中t≥0；

上述公式的含义说明：表达式“O[P(Sn)]t＝0？”是条件表达式，“Sn'→Sn”为表达式1，“Sn→Sn”为表达式2，上述公式的逻辑为：由判断条件表达式中的O[P(Sn)]t是否等于0，若等于0则执行表达式1，若不等于0，执行表达式2。“Sn'→Sn”的含义表示将Sn替换为Sn'。

其中，Sn表示第n个被更新的配置文件服务，Sn'表示用来替换Sn的配置文件服务；t表示更新等待时间上限；P()表示配置文件服务被调用的次数；O[]表示选择一定时间段进行重新尝试，看调用是否达到次数的要求。

算法执行模块执行最末参与者算法的流程包括：

第一步，接收到配置文件服务Sn'替换Sn的请求后，应用加载总线100监视当前已加载的针对配置文件服务Sn的调用次数N；

第二步，应用加载总线100启动更新的同时设定更新等待时间t，启动倒计时；

第三步，获取当前已加载的针对配置文件服务Sn的调用请求，并将调用请求的次数输入P(Sn)t进行缓存；

第四步，如果t≥0的情况下P(Sn)t＝0，表示在超时之前，最末一个配置文件服务调用完成，配置文件服务Sn进入到了静止状态，此时可使用配置文件服务Sn′替换配置文件服务Sn，向应用加载总线100返回允许替换的响应；

第五步，如果t≥0的情况下P(Sn)t>0，表示在超时之前，最末一个配置文件服务还未执行完成，配置文件服务Sn无法进入静止状态，此时向应用加载总线100返回暂时不允许替换的响应；应用加载总线100记录该异常，并在其他时间点O[]之后选择重试。

第六步，若替换成功，需要重新开放配置文件服务Sn'对外提供服务；若替换失败或产生异常则启动恢复机制，回滚到原始的配置文件服务Sn，重新开放配置文件服务Sn对外提供服务。

与现有技术相比，上述架构结合最末参与者算法进行类文件和配置文件的更新，实现了在不重启系统的情况下进行系统版本在线发布及故障的修复、生效，并基于生效后的服务调用恢复暂停运行的业务对象，可以大大缩短系统版本在线发布及故障的修复的响应时间；对于客户来说，其反映的问题可极速得到响应，使得客户的感知得到提升；对于运营系统来说，系统不会因为频繁的修复而出现间歇性停机的状况发生，全天候无中断的提供服务的方式确保了业务的连续性，使得系统的稳定性大为提升。

基于上述应用架构和最末参与者算法，本发明实施例提供了一种文件更新方法和装置，用于实现在支撑该服务调用的系统正常运行的情况下进行文件的更新和生效。

如图2所示的一种文件更新方法，包括：

步骤201，接收针对一个服务的文件更新请求，文件更新请求中包括请求更新的待生效文件；

步骤202，监控在接收到文件更新请求时已加载的针对该服务的调用请求，并缓存在接收到文件更新请求后针对该服务的调用请求；

步骤203，判断已加载的针对该服务的调用请求是否全部调用结束；

步骤204，若判断已加载的针对该服务的调用请求全部调用结束，则根据待生效文件，对该服务进行更新处理；

步骤205，加载缓存的调用请求，调用更新后的该服务。

上述实施例中，文件更新请求中的待生效文件可以是类文件，也可以是配置文件。

若文件更新请求中的待生效文件可以是类文件，在步骤201之前，还包括：检测类加载缓冲区中是否上传有新的类文件，若是，则将新的类文件确定为待生效文件，并上报文件更新请求。

若文件更新请求中的待生效文件可以是配置文件，在步骤201之前，还包括：检测ZOOKEEPER集群中是否上传有新的配置文件，若是，则将新的配置文件确定为待生效文件，并上报文件更新请求。

步骤203具体包括：设定更新等待时间上限t，若t≥0的情况下，P(Sn)t＝0，则确定在超时之前已加载的针对该服务的调用请求已经全部调用结束；若t≥0的情况下，P(Sn)t>0，则确定在超时之前已加载的针对该服务的调用请求未全部调用结束；其中，Sn表示在待生效文件生效前该服务的服务实例；t表示设置的更新等待时间上限；P()表示接收到文件变更请求时已加载的针对该服务的调用请求的个数。

若所述待生效文件为上传至所述类加载缓冲区中的类文件，步骤204具体包括：从所述类加载缓冲区读取所述待生效文件，对所述待生效文件进行预编译，并判断所述待生效文件是否为新增加的类对象；若是新增加的类对象，则在自定义加载器中加载所述待生效文件，使所述待生效文件生效；并在所述类加载缓冲区中为所述新增加的类对象建立索引；若是对已有类对象的修改，则将所述自定义加载器中的所述已有类对象删除，并加载所述待生效文件，使所述待生效文件生效。在自定义类加载器加载新的类文件之前，将类文件放在加载缓冲区可以降低类生效中间的资源锁的时长，在确定允许更新的时候，自定义类加载器从缓存协调器的类加载缓冲区读取类文件进行加载的速度快，可有效缩短版本发布及故障解决的响应时间。

若所述待生效文件为上传至ZOOKEEPER集群中的配置文件，则步骤204具体包括：根据配置文件与配置对象的映射关系，将所述待生效文件转化为配置对象新版本，即将配置文件转化成JAVA对象，得到配置对象新版本，并将所述服务的配置对象旧版本替换为所述配置对象新版本，使新的配置文件生效。利用版本替换的方式实现配置对象的更新，使得新配置文件生效的效率极大提高，配置对象新旧版本的替换过程瞬间完成，进而大大缩短了配置文件更新的响应时间。

上述实施例中，在接收到针对一个服务的文件更新请求时，为了确保服务类文件和配置文件的更新不对系统的正常运行产生矛盾，防止系统业务对象的运行过程中进行文件更新导致的代码逻辑或数据不一致的现象，本发明实施例通过确定合适时机进行文件更新，即判断已加载的针对该服务的调用请求全部调用结束时，来进行该服务的类文件和/或配置文件的更新。为了实现在支撑该服务调用的系统正常运行的情况下进行文件的更新和生效，本发明实施例制定了业务调用请求与文件更新请求的处理逻辑，在接收到针对一个服务的文件更新请求时，首先监控接收到所述文件更新请求时已加载的针对该服务的调用请求，并缓存接收到所述文件更新请求后针对该服务的调用请求；其次，判断所述已加载的针对该服务的调用请求是否全部调用结束，当已加载的针对该服务的调用请求全部调用结束时，来进行该服务的类文件和/或配置文件的更新；再次，基于更新后的所述服务的类文件和/或配置文件对所述服务进行调用；这样实现在支撑该服务调用的系统正常运行的情况下进行文件的更新和生效，与现有技术相比，并基于生效后的服务调用恢复暂停运行的业务对象，可以大大缩短系统版本在线发布及故障的修复的响应时间；对于客户来说，其反映的问题可极速得到响应，使得客户的感知得到提升；对于运营系统来说，系统不会因为频繁的修复而出现间歇性停机的状况发生，全天候无中断的提供服务的方式确保了业务的连续性，使得系统的稳定性大为提升。

基于上述方法流程，本发明实施例提供了一种类文件更新的流程，如图3所示，可利用自定义类加载器对正在运行的类代码动态更新，由自定义类加载器从缓存协调器的类加载缓冲区读取并加载新的类文件，具有速度快，可有效缩短版本发布及故障解决的响应时间的优点。具体过程包括：

步骤301，将新的类文件打包发布到类加载缓冲区，新的类文件按照包路径存放，同时将类加载缓冲区的类加载标识更新为Y。

步骤302，检测类加载缓冲区中是否上传有新的类文件，若是，则将新的类文件确定为待生效类文件，并上报文件更新请求；

具体的，设置定时器，令JAVA类扫描线程定时扫描类加载缓冲区，当扫描到类加载标识为Y时转入步骤303，否则线程进入休眠状态，等待下一次扫描时间到来唤醒线程。

步骤303，接收到针对步骤302的文件更新请求的允许更新的响应消息，根据接收到的允许更新的响应消息，从所述类加载缓冲区读取所述待生效类文件，对所述待生效类文件进行预编译，并判断预编译验证通过的待生效类文件是否为新增加的类对象；

步骤304，自定义类加载器对预编译验证通过的待生效类文件进行类加载；

具体的，若待生效类文件是新增加的类对象，则在自定义加载器中加载所述待生效类文件，使所述待生效类文件生效，并在所述类加载缓冲区中为所述新增加的类对象建立索引；若是对已有类对象的修改，则将所述自定义加载器中的所述已有类对象删除，并加载所述待生效类文件，使所述待生效类文件生效。

步骤305，所述待生效类文件生效以后，对类加载缓冲区进行状态修改，将类加载缓冲区的类加载标识更新为N。

基于上述方法流程，本发明实施例提供了一种配置文件更新的方法流程，如图4所示，具体包括：

步骤401，将配置文件从配置文件中心上传到ZOOKEEPER集群中，待文件完全上传完成后，将ZOOKEEPER中的加载标识更新为Y。

步骤402，检测ZOOKEEPER集群中是否上传有新的配置文件，若是，则将新的配置文件确定为待生效文件，并上报文件更新请求；

具体的，由文件目录监听器检测ZOOKEEPER集群中配置文件目录文件的变化，若检测到ZOOKEEPER集群中的类加载标识为Y时转入步骤403，否则继续检测。

步骤403，接收到针对步骤402的文件更新请求的允许更新的响应消息，并根据接收到的允许更新的响应消息，以及配置文件与配置对象的映射关系，将配置文件转化成JAVA对象，得到配置对象新版本；

具体的，通过配置对象生成工厂类，将配置文件转化成JAVA对象，得到配置对象新版本。

步骤404，将所述服务的配置对象旧版本替换为所述配置对象新版本，使新的配置文件生效；

利用版本替换的方式实现配置对象的更新，使得新配置文件生效的效率极大提高，配置对象新旧版本的替换过程瞬间完成，进而大大缩短了配置文件更新的响应时间。

步骤405，新的配置文件生效后，对ZOOKEEPER集群进行状态修改，将ZOOKEEPER集群中的加载标识更新为N。

基于上述方法流程，本发明实施例还支持另一场景的文件更新：前端发起针对一个服务的业务调用请求，此时刚好JAVA文件和配置文件都发生变动，比如，如需要对数据库密码配置文件修改，同时需要对数据库加密算法对应的类文件也进行修改等，在这种情况下考虑到类文件的更新对新服务的影响比重较大，可优先进行JAVA代码的预生效，然后进行配置文件的生效，共同完成后将服务状态置为可用状态。本发明实施例提供了一种针对上述场景的整体处理流程，如图5所示，包括：

第1步，Class文件扫描器通过扫描类加载缓冲区中的Class文件，并对比该Class文件的上次加载时间，如果发现类变更，将发送一个类变动通知给热加载管理器；同时，如果配置文件信息发生变动，ZOOKEEPER集群也将发送一个配置文件变动通知给热加载管理器；其中，热加载管理器相当于本发明上述加载架构中的缓存协调器和应用目录监听器；

第2步，热加载管理器针对收到的变更通知返回变动通知接收成功消息；

如图5所示，针对收到的类变动通知反馈一个接收成功消息，针对收到的配置文件变动通知，反馈一个接收成功消息；第3步，热加载管理器首先针对类变动通知向服务管理器发送文件变更请求；

其中，服务管理器相当于本发明实施例的应用加载总线；热加载管理器调用服务加载器对同时接收的类文件变更通知和配置文件的变更通知进行选择，因类文件的更新对新服务的影响比重较大，优选的，根据变更通知的文件类型，首先对Class文件变更通知进行响应，向服务管理器发送文件变更请求，该文件变更请求为类文件变更请求；而将配置文件的变更通知放入更新请求队列中排队等待，待类文件更新生效后，再针对配置文件变更通知进行响应，向服务管理器发送文件变更请求，使得该文件变更请求为配置文件变更请求；

第4步，服务管理器缓存在接收到文件更新请求后针对该服务的业务调用请求；

第5步，服务管理器通过服务监控模块监控在接收到文件更新请求时已加载的针对该服务的调用请求的个数，并调用最末参与者算法，判断已加载的针对该服务的调用请求是否全部调用结束，当判断已加载的针对该服务的调用请求全部调用结束，向热加载管理器发送针对该文件变更请求的允许更新的响应消息；

第6步，若该服务为有状态服务，则将当前服务实例的状态进行修改，并保存到新的服务实例中；

第7步，热加载管理器接收允许更新的响应消息，并根据允许更新的响应消息，对需要变更的文件进行更新，得到最新版本的服务实例；

具体的若文件更新请求为类文件更新请求，则指示自定义类加载器加载类加载缓冲区中新类文件或进行已有类文件的替换，得到最新版本的服务实例；若文件更新请求为配置文件更新请求，则指示配置文件管理器将新的配置文件转化成对应的配置对象新版本，并将配置对象旧版本替换为配置对象新版本，使新配置文件生效或者完成已有配置文件的替换，得到最新版本的服务实例；

第8步，服务管理器加载第4步缓存的业务调用请求；

第9步，调用最新版本的服务实例，对第8步加载的调用请求进行处理；

第10步(图中未显示)，热加载管理器判断更新请求队列中是否存在其他变更通知；若存在，重复第3步至第9步；若不存在结束任务。

上述实施例中，在接收到针对一个服务的文件更新请求时，为了确保服务类文件和配置文件的更新不对系统的正常运行产生矛盾，防止系统业务对象的运行过程中进行文件更新导致的代码逻辑或数据不一致的现象，本发明实施例通过确定合适时机进行文件更新，即判断已加载的针对该服务的调用请求全部调用结束时，来进行该服务的类文件和/或配置文件的更新。为了实现在支撑该服务调用的系统正常运行的情况下进行文件的更新和生效，本发明实施例制定了业务调用请求与文件更新请求的处理逻辑，在接收到针对一个服务的文件更新请求时，首先监控接收到所述文件更新请求时已加载的针对该服务的调用请求，并缓存接收到所述文件更新请求后针对该服务的调用请求；其次，判断所述已加载的针对该服务的调用请求是否全部调用结束，当已加载的针对该服务的调用请求全部调用结束时，来进行该服务的类文件和/或配置文件的更新；再次，基于更新后的所述服务的类文件和/或配置文件对所述服务进行调用；这样实现在支撑该服务调用的系统正常运行的情况下进行文件的更新和生效，与现有技术相比，并基于生效后的服务调用恢复暂停运行的业务对象，可以大大缩短系统版本在线发布及故障的修复的响应时间；对于客户来说，其反映的问题可极速得到响应，使得客户的感知得到提升；对于运营系统来说，系统不会因为频繁的修复而出现间歇性停机的状况发生，全天候无中断的提供服务的方式确保了业务的连续性，使得系统的稳定性大为提升。

基于上述方法流程，本发明实施例还提供一种文件更新装置，文件更新装置的具体内容参见上述方法流程，此处不再累述。

本发明实施例提供了一种如图6所示的文件更新装置，具体包括：

接收单元601，用于接收针对一个服务的文件更新请求，文件更新请求中包括请求更新的待生效文件；

监控单元602，用于监控在接收到文件更新请求时已加载的针对该服务的调用请求；

缓存单元603，用于缓存在接收到文件更新请求后针对该服务的调用请求；

判断单元604，用于判断已加载的针对该服务的调用请求是否全部调用结束；

更新单元605，用于若所述判断单元判断所述已加载的针对该服务的调用请求全部调用结束，则根据所述待生效文件，对所述服务进行更新处理；

执行单元606，用于加载缓存的所述调用请求，调用更新后的所述服务。

进一步地，还包括第一检测单元和第二检测单元；

第一检测单元，用于在接收针对一个服务的文件更新请求之前，检测类加载缓冲区中是否上传有新的类文件，若是，则将新的类文件确定为待生效文件，并上报文件更新请求；和/或，

第二检测单元，用于在接收针对一个服务的文件更新请求之前，检测ZOOKEEPER集群中是否上传有新的配置文件，若是，则将新的配置文件确定为待生效文件，并上报文件更新请求。

进一步地，若所述待生效文件为上传至所述类加载缓冲区中的类文件；则所述更新单元605，具体用于：

从所述类加载缓冲区读取所述待生效文件，对所述待生效文件进行预编译，并判断所述待生效文件是否为新增加的类对象；

若是新增加的类对象，则在自定义加载器中加载所述待生效文件，使所述待生效文件生效；并在所述类加载缓冲区中为所述新增加的类对象建立索引；

若是对已有类对象的修改，则将所述自定义加载器中的所述已有类对象删除，并加载所述待生效文件，使所述待生效文件生效。

进一步地，若所述待生效文件为上传至ZOOKEEPER集群中的配置文件，则所述更新单元605用于：

根据配置文件与配置对象的映射关系，将所述待生效文件转化为配置对象新版本，并将所述服务的配置对象旧版本替换为所述配置对象新版本，使所述待生效文件生效。

进一步地，判断单元604具体用于：

设定更新等待时间上限t，

若t≥0的情况下，P(Sn)t＝0，则确定在超时之前已加载的针对该服务的调用请求已经全部调用结束；

若t≥0的情况下，P(Sn)t>0，则确定在超时之前已加载的针对该服务的调用请求未全部调用结束；

其中，Sn表示在待生效文件生效前该服务的服务实例；t表示设置的更新等待时间上限；P()表示接收到文件变更请求时已加载的针对该服务的调用请求的个数。

上述实施例中，在接收到针对一个服务的文件更新请求时，为了确保服务类文件和配置文件的更新不对系统的正常运行产生矛盾，防止系统业务对象的运行过程中进行文件更新导致的代码逻辑或数据不一致的现象，本发明实施例通过确定合适时机进行文件更新，即判断已加载的针对该服务的调用请求全部调用结束时，来进行该服务的类文件和/或配置文件的更新。为了实现在支撑该服务调用的系统正常运行的情况下进行文件的更新和生效，本发明实施例制定了业务调用请求与文件更新请求的处理逻辑，在接收到针对一个服务的文件更新请求时，首先监控接收到所述文件更新请求时已加载的针对该服务的调用请求，并缓存接收到所述文件更新请求后针对该服务的调用请求；其次，判断所述已加载的针对该服务的调用请求是否全部调用结束，当已加载的针对该服务的调用请求全部调用结束时，来进行该服务的类文件和/或配置文件的更新；再次，基于更新后的所述服务的类文件和/或配置文件对所述服务进行调用；这样实现在支撑该服务调用的系统正常运行的情况下进行文件的更新和生效，与现有技术相比，并基于生效后的服务调用恢复暂停运行的业务对象，可以大大缩短系统版本在线发布及故障的修复的响应时间；对于客户来说，其反映的问题可极速得到响应，使得客户的感知得到提升；对于运营系统来说，系统不会因为频繁的修复而出现间歇性停机的状况发生，全天候无中断的提供服务的方式确保了业务的连续性，使得系统的稳定性大为提升。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种文件更新方法，其特征在于，包括：

接收针对一个服务的文件更新请求，所述文件更新请求中包括请求更新的待生效文件；

监控在接收到所述文件更新请求时已加载的针对该服务的调用请求，并缓存在接收到所述文件更新请求后针对该服务的调用请求；

判断所述已加载的针对该服务的调用请求是否全部调用结束；

若判断所述已加载的针对该服务的调用请求全部调用结束，则根据所述待生效文件，对所述服务进行更新处理；

加载所述在接收到所述文件更新请求后针对该服务的调用请求，调用更新后的所述服务。

2.如权利要求1所述的方法，其特征在于，在接收针对一个服务的文件更新请求之前，还包括：

检测类加载缓冲区中是否上传有新的类文件，若是，则将所述新的类文件确定为所述待生效文件，并上报所述文件更新请求；和/或，

检测ZOOKEEPER集群中是否上传有新的配置文件，若是，则将所述新的配置文件确定为所述待生效文件，并上报所述文件更新请求。

3.如权利要求2所述的方法，其特征在于，若所述待生效文件为上传至所述类加载缓冲区中的类文件；

所述根据所述待生效文件，对所述服务进行更新处理，包括：

从所述类加载缓冲区读取所述待生效文件，对所述待生效文件进行预编译，并判断所述待生效文件是否为新增加的类对象；

若是新增加的类对象，则在自定义加载器中加载所述待生效文件，使所述待生效文件生效；并在所述类加载缓冲区中为所述新增加的类对象建立索引；

若是对已有类对象的修改，则将所述自定义加载器中的所述已有类对象删除，并加载所述待生效文件，使所述待生效文件生效。

4.如权利要求2所述的方法，其特征在于，若所述待生效文件为上传至ZOOKEEPER集群中的配置文件；则

所述根据所述待生效文件，对所述服务进行更新处理，包括：

根据配置文件与配置对象的映射关系，将所述待生效文件转化为配置对象新版本，并将所述服务的配置对象旧版本替换为所述配置对象新版本，使所述待生效文件生效。

5.如权利要求1至4中任一项中所述的方法，其特征在于，

所述判断所述已加载的针对该服务的调用请求是否全部调用结束，包括：设定更新等待时间上限t，

若t≥0的情况下，P(Sn)t＝0，则确定在时间超过t之前所述已加载的针对该服务的调用请求已经全部调用结束；

若t≥0的情况下，P(Sn)t>0，则确定在时间超过t之前所述已加载的针对该服务的调用请求未全部调用结束；

其中，Sn表示在所述待生效文件生效前所述服务的服务实例；t表示设置的更新等待时间上限；P()表示接收到所述文件变更请求时已加载的针对该服务的调用请求的个数。

6.一种文件更新装置，其特征在于，包括：

接收单元，用于接收针对一个服务的文件更新请求，所述文件更新请求中包括请求更新的待生效文件；

监控单元，用于监控接收到所述文件更新请求时已加载的针对该服务的调用请求；

缓存单元，用于缓存在接收到所述文件更新请求后针对该服务的调用请求；

判断单元，用于判断所述已加载的针对该服务的调用请求是否全部调用结束；

更新单元，用于若所述判断单元判断所述已加载的针对该服务的调用请求全部调用结束，则根据所述待生效文件，对所述服务进行更新处理；

执行单元，用于加载所述在接收到所述文件更新请求后针对该服务的调用请求，调用更新后的所述服务。

7.如权利要求6所述的装置，其特征在于，还包括第一检测单元和第二检测单元；

所述第一检测单元，用于在接收针对一个服务的文件更新请求之前，检测类加载缓冲区中是否上传有新的类文件，若是，则将所述新的类文件确定为所述待生效文件，并上报所述文件更新请求；和/或，

所述第二检测单元，用于在接收针对一个服务的文件更新请求之前，检测ZOOKEEPER集群中是否上传有新的配置文件，若是，则将所述新的配置文件确定为所述待生效文件，并上报所述文件更新请求。

8.如权利要求7所述的装置，其特征在于，

若所述待生效文件为上传至所述类加载缓冲区中的类文件；则所述更新单元，具体用于：

从所述类加载缓冲区读取所述待生效文件，对所述待生效文件进行预编译，并判断所述待生效文件是否为新增加的类对象；

若是新增加的类对象，则在自定义加载器中加载所述待生效文件，使所述待生效文件生效；并在所述类加载缓冲区中为所述新增加的类对象建立索引；

若是对已有类对象的修改，则将所述自定义加载器中的所述已有类对象删除，并加载所述待生效文件，使所述待生效文件生效。

9.如权利要求7所述的装置，其特征在于，

若所述待生效文件为上传至ZOOKEEPER集群中的配置文件，则所述更新单元用于：

根据配置文件与配置对象的映射关系，将所述待生效文件转化为配置对象新版本，并将所述服务的配置对象旧版本替换为所述配置对象新版本，使所述待生效文件生效。

10.如权利要求6至9中任一项中所述的装置，其特征在于，所述判断单元具体用于：

设定更新等待时间上限t，

若t≥0的情况下，P(Sn)t＝0，则确定在时间超过t之前所述已加载的针对该服务的调用请求已经全部调用结束；

若t≥0的情况下，P(Sn)t>0，则确定在时间超过t之前所述已加载的针对该服务的调用请求未全部调用结束；

其中，Sn表示在所述待生效文件生效前所述服务的服务实例；t表示设置的更新等待时间上限；P()表示接收到所述文件变更请求时已加载的针对该服务的调用请求的个数。

Images