CN112860300A - 分布式sdk热更新处理方法、应用服务器集群 - Google Patents

Abstract

本申请提供的分布式SDK热更新处理方法、应用服务器集群，可用于大数据技术领域，本发明通过SDK版本号来确定当前SDK版本是否是最新版本，当SDK更新时，仅仅需要增量升级包，然后配合类加载器加载的方式，进而基于字节码修改来实现版本热更新，可以做到通过对SDK热升级，可以在很大程度上缓解推动应用客户端配合升级SDK的重重阻碍，可以做到应用无感知的情况下，通过热更新快速迭代版本，解决了SDK升级难的痛点。

Description

分布式SDK热更新处理方法、应用服务器集群

技术领域

本申请涉及应用热更新处理技术领域，具体涉及分布式SDK热更新处理方法、应用服务器集群及应用客户端。

背景技术

目前业界常见的访问分布式服务的方式都是在应用程序端内嵌SDK，通过RPC来调用分布式服务，而一旦SDK需要更新升级时，则需要应用配合更新SDK程序包，并对大量的应用服务器进行程序的重启生效操作。

在持续交付的时代，版本内容的升级和迭代频率都在不断提升，而很多应用重新部署过程会比较复杂，停机停服务是不能接受的，尤其对于某些大型应用来说，每次重启都需要花费大量的时间成本，所以如果能在不重启进程的情况下升级应用进程中的程序逻辑，以达到版本升级，功能上线的效果，在某些业务场景下变得十分重要。

发明内容

针对现有技术中的问题，本申请提供一种分布式SDK热更新处理方法、应用服务器集群及应用客户端，能够在不影响整个系统对外服务的高性能基础上，保证了数据零丢失且不中断对外服务。

为解决上述技术问题，本申请提供以下技术方案：

本发明第一方面实施例提供一种分布式系统的SDK热更新处理方法，所述SDK热更新处理方法由应用客户端执行，包括：

若应用服务器集群上传有可升级SDK版本号的升级包，获取所述应用服务器集群中的所述升级包；所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

在某些实施例中，所述获取所述应用服务器集群中的所述升级包，包括：

定时获取所述应用服务器集群中的所述升级包。

在某些实施例中，所述获取所述应用服务器集群中的所述升级包，包括：

每隔设定时长获取所述应用服务器集群中的所述升级包。

在某些实施例中，所述通过类加载器加载所述升级包，包括：

实例化所述类加载器；

解析所述升级包，获得类路径信息以及字节码信息；

基于字节码信息，通过所述类加载器加载的方式获取所述类路径信息下的类对象；

实例化所述类对象，进而可通过调用所述类对象加载所述升级包。

在某些实施例中，所述实例化所述类对象，包括：

使用反射调用JnosRedisPool.getInstance获取类对象的实例；

通过NosRedisClient接口将所述类对象的实例发送至应用。

本发明第二方面实施例提供一种分布式系统的SDK热更新处理方法，所述SDK热更新处理方法由应用服务器集群执行，包括：

向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

若应用客户端确定获取所述升级包，将所述升级包发送至所述应用客户端，以使所述应用客户端通过类加载的方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

在某些实施例中，所述向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码，包括：

定时接收所述应用客户端发送的当前SDK版本号。

在某些实施例中，所述向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码，包括：

每隔设定时长向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码。

在某些实施例中，所述根据当前SDK版本号确定是否向所述应用客户端发送升级包，包括：

若所述当前SDK版本号为全量版本号，则通过SDK版本号与对应可升级的版本号映射关系确定更新版本号；

比对所述更新版本号和所述当前SDK版本号，若所述更新版本号大于所述当前SDK版本号，则将所述更新版本号确定为可升级版本号；

若所述当前SDK版本号为非全量版本号，则截取所述SDK版本号中的全量格式版本，通过SDK版本号与对应可升级的版本号映射关系，确定可升级版本的SDK版本号；

若存在所述可升级版本号，则从一可升级版本号与二进制升级包的存储表中索引对应的二进制升级包的存储地址，并确定向所述应用客户端发送索引得到的所述二进制升级包。

本发明第三方面实施例提供一种分布式系统的SDK热更新处理方法，包括：

应用客户端获取所述应用服务器集群中的所述升级包；

所述应用服务器集群根据当前SDK版本号确定是否向所述应用客户端发送升级包；所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

应用客户端通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

本发明第四方面实施例提供一种应用客户端，包括：

版本号发送模块，若应用服务器集群上传有可升级SDK版本号的升级包，获取所述应用服务器集群中的所述升级包；所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

升级模块，通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

在某些实施例中，所述版本号发送模块具体用于定时获取所述应用服务器集群中的所述升级包。

在某些实施例中，所述版本号发送模块具体用于每隔设定时长获取所述应用服务器集群中的所述升级包。

在某些实施例中，所述升级模块包括：

加载器实例化单元，实例化所述类加载器；

解析单元，解析所述升级包，获得类路径信息以及字节码信息；

加载单元，基于字节码信息，通过所述类加载器加载的方式获取所述类路径信息下的类对象；

对象实例化单元，实例化所述类对象，进而可通过调用所述类对象加载所述升级包。

在某些实施例中，所述对象实例化单元，包括：

反射调用单元，使用反射调用JnosRedisPool.getInstance获取类对象的实例；

实例发送单元，通过NosRedisClient接口将所述类对象的实例发送至应用。

本发明第五方面实施例提供一种应用服务器集群，包括：

版本号接收模块，向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

升级包发送模块，若应用客户端确定获取所述升级包，将所述升级包发送至所述应用客户端，以使所述应用客户端通过类加载的方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

在某些实施例中，所述版本号接收模块具体用于定时接收所述应用客户端发送的当前SDK版本号。

在某些实施例中，所述版本号接收模块具体用于每隔设定时长向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码。

在某些实施例中，所述升级包发送模块，包括：

更新版本号确定单元，若所述当前SDK版本号为全量版本号，则通过SDK版本号与对应可升级的版本号映射关系确定更新版本号；

比对单元，比对所述更新版本号和所述当前SDK版本号，若所述更新版本号大于所述当前SDK版本号，则将所述更新版本号确定为可升级版本号；

可升级版本确定单元，若所述当前SDK版本号为非全量版本号，则截取所述SDK版本号中的全量格式版本，通过SDK版本号与对应可升级的版本号映射关系，确定可升级版本的SDK版本号；

索引单元，若存在所述可升级版本号，则从一可升级版本号与二进制升级包的存储表中索引对应的二进制升级包的存储地址，并确定向所述应用客户端发送索引得到的所述二进制升级包。

本发明第六方面实施例提供一种分布式系统的SDK热更新处理系统，包括：应用客户端和应用服务器集群；其中，

应用客户端获取所述应用服务器集群中的所述升级包；

所述应用服务器集群根据当前SDK版本号确定是否向所述应用客户端发送升级包；所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

应用客户端通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

第七方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的分布式SDK热更新处理方法。

第八方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述的分布式SDK热更新处理方法。

由上述技术方案可知，本申请提供的分布式SDK热更新处理方法、应用服务器集群及应用客户端，本发明通过SDK版本号来确定当前SDK版本是否是最新版本，当SDK更新时，仅仅需要增量升级包，然后配合类加载器加载的方式，进而基于字节码修改来实现版本热更新，可以做到通过对SDK热升级，可以在很大程度上缓解推动应用客户端配合升级SDK的重重阻碍，可以做到应用无感知的情况下，通过热更新快速迭代版本，解决了SDK升级难的痛点。

附图说明

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

图1为本发明的交互流程示意图。

图2为本申请分布式SDK热更新处理方法的流程示意图之一。

图3为本申请分布式SDK热更新处理方法的流程示意图之二。

图4为本申请实施例中应用客户端的结构示意图。

图5为本申请实施例中应用服务器集群结构示意图。

图6为本申请实施例中的电子设备的结构示意图。

具体实施方式

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

在现有技术中，目前业界常见的访问分布式服务的方式都是在应用程序端内嵌SDK，通过RPC来调用分布式服务，而一旦SDK需要更新升级时，则需要应用配合更新SDK程序包，并对大量的应用服务器进行程序的重启生效操作。

在持续交付的时代，版本内容的升级和迭代频率都在不断提升，而很多应用重新部署过程会比较复杂，停机停服务是不能接受的，尤其对于某些大型应用来说，每次重启都需要花费大量的时间成本，所以如果能在不重启进程的情况下升级应用进程中的程序逻辑，以达到版本升级，功能上线的效果，在某些业务场景下变得十分重要。

举例而言，采用具有代理模式的分布式系统，具备支持JAVA语言的sdk，在使用分布式系统时需要在应用程序中引入SDK包，当SDK更新时，需要应用在程序中重新引入更新后的SDK包，并在应用服务器上重新部署相关介质，重新启动应用程序方可生效，对应用影响较大。

本发明鉴于此，通过借助于字节码技术，配合增量升级，通过替换字节码文件来修改源码中需要更新的程序逻辑，进而可以保证业务服务的连续性和应用无感知，对应用端的SDK实现热更新，可以根据需要定制化开发SDK的功能需求，有效降低推动应用升级SDK带来的影响范围。

下面结合附图对本发明的上述构思进行详细说明。

在本申请的一个或多个实施例中，如图1所示，包括应用客户端1以及应用服务器集群2。

应用服务器集群是分布式集群装置，具体包括多个分布式的服务器，其存储有应用的SDK升级包，应用在使用分布式系统时需在客户端程序中引入SDK包，SDK包含一个接口类，该接口定义当前SDK所有可调用的方法。当SDK需在已有接口中增加埋点功能、采集功能、逻辑修改等，便可将更新后的SDK包部署在服务端。通过SDK中周期性探测服务端是否有待更新版本，当服务端待更新SDK版本完成上传后，则自动触发应用客户端通过网络自动获取SDK更新包，通过自定义类加载器实现相关类的热更新，完成类加载及更新后，客户端使用分布式系统时将会调用更新后的类程序。

可以理解，本发明适用于大数据技术领域，当然，本申请并不限于此。

应用客户端1可以是手机、移动电脑等电子设备，或者其他搭载智能系统(例如安卓系统或苹果系统)的平板电脑、车载设备等，本发明不限于此。

可以理解的是，各个应用服务器集群之间可以使用任何合适的网络协议进行通信，包括在本申请提交日尚未开发出的网络协议。所述网络协议例如可以包括TCP/IP协议、UDP/IP协议、HTTP协议、HTTPS协议等。当然，所述网络协议例如还可以包括在上述协议之上使用的RPC协议(Remote Procedure Call Protocol，远程过程调用协议)、REST协议(Representational State Transfer，表述性状态转移协议)等。

在本发明的具体实施例中，本发明提供的分布式系统的SDK热更新处理方法，其中的应用客户端具体执行如下步骤，如图2所示：

S101：若应用服务器集群上传有可升级SDK版本号的升级包，获取所述应用服务器集群中的所述升级包；所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码。

具体的，应用客户端可以每隔一段时间向应用服务器发送自身当前SDK版本号，例如在一个具体场景中，应用客户端每隔1小时向应用服务器发送当前SDK版本号，这样可以保证当应用服务器一旦上传了最新版本的SDK包时，即可在第一时间内完成自动热更新。

进一步的，应用客户端也可以定时地向应用服务器发送自身当前SDK版本号，例如在一个具体场景中，应用客户端在每天的凌晨0：00向应用服务器发送自身当前SDK版本号，这样可以使得应用版本的更新在一天之内。

在优选的实施例中，应用客户端可以基于当前的任务繁重程度来动态地向英语服务器发送当前SDK版本号，例如当系统检测当前CPU(或者MCU)使用状况在30％以下，运行内存使用状况在40％以下，则认为此时的应用终端处于具有闲置处理能力状态，则可以通过后台发送，在该应用处于未启动状态下采用字节码修改的技术来进行热更新，实现完全无感更新。

可以理解，本发明中的“向应用服务器集群”发送当前SDK版本号可以是仅仅发送SDK版本号信息，例如将当前SDK版本号编译为二进制字符串，然后向应用服务器集群发送该二进制字符串，应用服务器集群在后台对该二进制字符串进行反编译得到当前SDK版本号。

当然，在优选的实施例中，可以通过设置使得客户端可以自动触发获取SDK更新包(即升级包)，该实施例中，应用客户端可以周期性地访问应用服务器集群，当应用服务器集群上传有更新后的SDK包时，即“告知”应用客户端已经上传更新后的SDK包，例如应用服务器集群向应用客户端发送一个特殊字符，或者特殊二进制字符串，应用客户端基于自定义的识别设置，可以识别出该特殊字符或者特殊二进制字符串，进而“知晓”已存在可更新的SDK包。

进一步的，如图1所示，应用客户端1还可以首先向应用服务器集群发送检查是否有升级包的指令，进而可以查询应用服务器集群中是否上传了升级包，若是，则应用服务器集群返回确认指令以及可升级SDK版本号。

具体而言，应用客户端在工程中引入Sdk全量包，传入appid等租户信息调用JnosRedisPool.initPool初始化实例，通过getClient获取实例并调用提供的接口与redis进行数据交互，有以下关键信息：

1)poolMap：缓存sdk实例，每次交互都从内存获取实例。

2)检查是否升级定时任务：在sdk首次成功创建pool实例时该定时任务被启动，用于定期检查sdk是否可升级并触发升级，频率每小时执行一次。

3)升级标识：默认false，检查有更新则置为true。

4)当前版本号：标识为当前sdk的版本号。

5)升级目标版本号：升级标识为true时，由服务端返回的可升级的目标版本号。

S102：通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

本步骤基于字节码修改技术，通过class字节码文件(类文件)的加载，用更新源码对应的class字节码文件替换被更新的class字节码文件，进而对应用端的SDK实现热更新。

在一些实施例中，考虑到同一个类加载器，不能重复加载同一个类，这里通过逐次自定义类加载器加载升级包中所有自定义类，通过对单例模式中对象的重新创建及赋值实现自定义类的热更新。

此外，考虑到升级包较小(几百K)，sdk在有更新时才去下载升级包，在每台proxy存放升级包并提供下载命令可有效分摊下载流量，sdk传入版本号发起下载升级包指令，proxy根据版本号判断是否需要更新SDK，需要则将升级包遵循现有格式通过tcp传给应用服务器，应用服务器中的SDK将升级包加载到内存并判断通过自定义类加载器将自定义类加载至内存，加载其他依赖类时首先判断是否存在框架自定义类加载器，然后再判断是否存在线程上下文自定义类加载器，依次按优先级使用类加载器将依赖类加载至内存中。

进一步的考虑到应用侧目录权限问题，升级包不落地磁盘，而是每次实例化是通过网络传输加载到内存。

在一些具体实施例中，热更新的触发方式具体如下：有两种方式可触发sdk热升级：在应用初始化pool时、定时任务检测到有更新时。

(1)在应用初始化pool时和定时任务检测到有更新时，sdk向proxy发起命令"*2\r\n$12\r\ncheckupgrade\r\n$版本号长度\r\n版本号\r\n"。

(2)proxy的checkupgrade方法解析sdk版本号，有升级则返回升级目标版本号和升级标识true，否则返回升级标识false。

(3)sdk解析返回值，如果升级标识为false且poolMap不存在实例则加载本地包并创建实例，更新到缓存并返回。

(4)如果升级标识为true，则向proxy发起命令"*2\r\n$11\r\ndownloadjar\r\n$版本号长度\r\n版本号\r\n"。proxy的downloadjar方法解析sdk版本号并返回升级包(二进制)。

(5)sdk解析返回值，如果为false或超时则使用本地sdk进行加载，更新升级标识为false；如果下载升级包成功则使用升级包进行加载，加载成功后将pool实例更新到poolMap中，当前版本号替换为目标版本号(只要升级包获取失败或加载失败都必须使用本地sdk，保证应用正常使用)，升级标识置为false。

进一步的，所述通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码，包括：

实例化所述类加载器；

解析所述升级包，获得类路径信息以及字节码信息；

基于字节码信息，通过所述类加载器加载的方式获取所述类路径信息下的类对象；

实例化所述类对象，进而可通过调用所述类对象加载所述升级包中的更新源码，进而替换当前全量SDK包中的所述至少部分源码。

具体的，所述实例化所述类对象，包括：

使用反射调用JnosRedisPool.getInstance获取类对象的实例；

通过NosRedisClient接口将所述类对象的实例发送至应用。

在具体实施例，3.加载升级包过程：

(1)下载了升级包后，首先实例化自定义类加载器(每次都实例化)，将升级包解析出类路径及class字节码信息加载到ClasspathResources(包含map)。

(2)通过该自定义加载器加载“com.icbc.threealive.jnos.jredis.JnosRedisPool”class对象，首先判断该加载器是否已加载过，已加载则从内存获取；否则先从ClasspathResources获取，有则按字节码生成class对象，否则从父类加载器获取直到生成class对象，依赖的类按类似步骤生成class对象。

(3)使用反射调用JnosRedisPool.getInstance获取实例并通过NosRedisClient接口形式返给应用，应用可以调用该接口曝露的所有方法。

由上述技术方案可知，本申请提供的分布式SDK热更新处理方法，本发明通过SDK版本号来确定当前SDK版本是否是最新版本，当SDK更新时，仅仅需要增量升级包，然后配合类加载器加载的方式，进而基于字节码修改来实现版本热更新，可以做到通过对SDK热升级，可以在很大程度上缓解推动应用客户端配合升级SDK的重重阻碍，可以做到应用无感知的情况下，通过热更新快速迭代版本，解决了SDK升级难的痛点。

本发明第二方面提供一种分布式系统的SDK热更新处理方法，所述SDK热更新处理方法由应用服务器集群执行，如图3，包括：

S201：向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码。

具体的，首先应用客户端可以每隔一段时间向应用服务器发送自身当前SDK版本号，应用客户端可以每隔一段时间向应用服务器发送自身当前SDK版本号，例如在一个具体场景中，应用客户端每隔1小时向应用服务器发送当前SDK版本号，这样可以保证当应用服务器一旦上传了最新版本的SDK包时，即可在第一时间内完成自动热更新。

进一步的，应用客户端也可以定时地向应用服务器发送自身当前SDK版本号，例如在一个具体场景中，应用客户端在每天的凌晨0：00向应用服务器发送自身当前SDK版本号，这样可以使得应用版本的更新在一天之内。

在优选的实施例中，应用客户端可以基于当前的任务繁重程度来动态地向英语服务器发送当前SDK版本号，例如当系统检测当前CPU(或者MCU)使用状况在30％以下，运行内存使用状况在40％以下，则认为此时的应用终端处于具有闲置处理能力状态，则可以通过后台发送，在该应用处于未启动状态下采用字节码修改的技术来进行热更新，实现完全无感更新。

可以理解，本发明中的“向应用服务器集群”发送当前SDK版本号可以是仅仅发送SDK版本号信息，例如将当前SDK版本号编译为二进制字符串，然后向应用服务器集群发送该二进制字符串，应用服务器集群在后台对该二进制字符串进行反编译得到当前SDK版本号。

当然，在优选的实施例中，可以通过设置使得客户端可以自动触发获取SDK更新包(即升级包)，该实施例中，应用客户端可以周期性地访问应用服务器集群，当应用服务器集群上传有更新后的SDK包时，即“告知”应用客户端已经上传更新后的SDK包，例如应用服务器集群向应用客户端发送一个特殊字符，或者特殊二进制字符串，应用客户端基于自定义的识别设置，可以识别出该特殊字符或者特殊二进制字符串，进而“知晓”已存在可更新的SDK包。

这样，在应用客户端“检查”完成之后，如果已上传升级包，步骤S201执行。

S202：若应用客户端确定获取所述升级包，将所述升级包发送至所述应用客户端，以使所述应用客户端通过类加载的方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

本申请提供的分布式SDK热更新处理方法，本发明通过SDK版本号来确定当前SDK版本是否是最新版本，当SDK更新时，仅仅需要增量升级包，然后配合类加载器加载的方式，进而基于字节码修改来实现版本热更新，可以做到通过对SDK热升级，可以在很大程度上缓解推动应用客户端配合升级SDK的重重阻碍，可以做到应用无感知的情况下，通过热更新快速迭代版本，解决了SDK升级难的痛点。

在优选的实施例中，所述向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码，包括：

定时接收所述应用客户端发送的当前SDK版本号。

在优选的实施例中，所述向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码，包括：

每隔设定时长向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码。

在优选的实施例中，所述根据当前SDK版本号确定是否向所述应用客户端发送升级包，包括：

若所述当前SDK版本号为全量版本号，则通过SDK版本号与对应可升级的版本号映射关系确定更新版本号；

比对所述更新版本号和所述当前SDK版本号，若所述更新版本号大于所述当前SDK版本号，则将所述更新版本号确定为可升级版本号；

若所述当前SDK版本号为非全量版本号，则截取所述SDK版本号中的全量格式版本，通过SDK版本号与对应可升级的版本号映射关系，确定可升级版本的SDK版本号；

若存在所述可升级版本号，则从一可升级版本号与二进制升级包的存储表中索引对应的二进制升级包的存储地址，并确定向所述应用客户端发送索引得到的所述二进制升级包。

在具体实施例中，应用服务器集群存放sdk各版本的升级包目录：

/data/nos/piza/current/sdk。

服务启动时遍历升级包目录，将版本号及升级包由下面两个变量保存：

1)sdkUpgradeVersMap：sdk版本号与对应可升级的版本号映射关系。

2)sdkVersJarMap：可升级的版本号与二进制升级包的存储表。

示例：

升级包目录结构

3.3

--3.3.3.jar

3.4

--3.4.1.jar

sdkUpgradeVersMap数据

3.3--3.3.3

3.4--3.4.1

sdkVersJarMap数据

3.3.3--对应升级包

3.4.1--对应升级包

sdk

3.3直接升级3.3.3

3.3.1先截取3.3并找到可升级的版本本为3.3.3，发现3.3.1＜3.3.3，需升级到3.3.3

3.3.2同上

3.3.3先截取3.3并找到可升级的版本为3.3.3，发现3.3.3＜＝3.3.3，不升级

3.3.4同上

3.4直接升级3.4.1

3.4.1先截取3.4并找到可升级的版本为3.4.1，发现3.4.1＜＝3.4.1，需升级到3.4.1

之后，checkupgrade方法提供解析sdk版本号并判断是否升级标识给sdk，

处理过程：

1)解析sdk传过来的版本号v_sdk，如果v_sdk为全量版本号，则通过v_sdk在sdkUpgradeVersMap找到可更新版本号v_sdk_upgrade并返回sdk；否则截取为全量格式版本v_sdk_base。

2)用v_sdk_base在sdkUpgradeVersMap找到可升级版本v_sdk_upgrade，并比较v_sdk、v_sdk_upgrade，如果v_sdk小于v_sdk_upgrade则将v_sdk_upgrade返回给sdk。

1.downloadjar方法提供下载sdk升级包接口：

1)解析sdk传过来的版本号v_sdk，如果v_sdk为全量版本则通过v_sdk在sdkUpgradeVersMap找到可更新版本号v_sdk_upgrade，并通过v_sdk_upgrade在sdkVersJarMap找到升级包；否则为增量版本号，直接从sdkVersJarMap中查找升级包。

基于相同的发明构思，本发明又一方面提供一种分布式系统的SDK热更新处理方法，该方法由应用服务器集群和应用客户端共同组成的包括：

若应用服务器集群上传有可升级SDK版本号的升级包，所述应用客户端获取所述应用服务器集群中的所述升级包；所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

所述应用客户端通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

由上述技术方案可知，本申请提供的分布式SDK热更新处理方法，本发明通过SDK版本号来确定当前SDK版本是否是最新版本，当SDK更新时，仅仅需要增量升级包，然后配合类加载器加载的方式，进而基于字节码修改来实现版本热更新，可以做到通过对SDK热升级，可以在很大程度上缓解推动应用客户端配合升级SDK的重重阻碍，可以做到应用无感知的情况下，通过热更新快速迭代版本，解决了SDK升级难的痛点。

基于相同的发明构思，本发明进一步提供一种应用客户端，如图4包括：

版本号发送模块101，若应用服务器集群上传有可升级SDK版本号的升级包，获取所述应用服务器集群中的所述升级包；所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

升级模块102，通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

在具体实施例中，所述版本号发送模块具体用于定时获取所述应用服务器集群中的所述升级包。

在具体实施例中，所述版本号发送模块具体用于每隔设定时长获取所述应用服务器集群中的所述升级包。

在具体实施例中，所述升级模块包括：

加载器实例化单元，实例化所述类加载器；

解析单元，解析所述升级包，获得类路径信息以及字节码信息；

加载单元，基于字节码信息，通过所述类加载器加载的方式获取所述类路径信息下的类对象；

对象实例化单元，实例化所述类对象，进而可通过调用所述类对象加载所述升级包。

在具体实施例中，所述对象实例化单元，包括：

反射调用单元，使用反射调用JnosRedisPool.getInstance获取类对象的实例；

实例发送单元，通过NosRedisClient接口将所述类对象的实例发送至应用。

由上述技术方案可知，本申请提供的应用客户端，本发明通过SDK版本号来确定当前SDK版本是否是最新版本，当SDK更新时，仅仅需要增量升级包，然后配合类加载器加载的方式，进而基于字节码修改来实现版本热更新，可以做到通过对SDK热升级，可以在很大程度上缓解推动应用客户端配合升级SDK的重重阻碍，可以做到应用无感知的情况下，通过热更新快速迭代版本，解决了SDK升级难的痛点。

基于相同的发明构思，本发明进一步提供一种应用服务器集群，如图5包括：

版本号接收模块201，向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

升级包发送模块202，若应用客户端确定获取所述升级包，将所述升级包发送至所述应用客户端，以使所述应用客户端通过类加载的方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

在具体实施例中，所述版本号接收模块具体用于定时接收所述应用客户端发送的当前SDK版本号。

在具体实施例中，所述版本号接收模块具体用于每隔设定时长向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码。

在具体实施例中，所述升级包发送模块，包括：

更新版本号确定单元，若所述当前SDK版本号为全量版本号，则通过SDK版本号与对应可升级的版本号映射关系确定更新版本号；

比对单元，比对所述更新版本号和所述当前SDK版本号，若所述更新版本号大于所述当前SDK版本号，则将所述更新版本号确定为可升级版本号；

可升级版本确定单元，若所述当前SDK版本号为非全量版本号，则截取所述SDK版本号中的全量格式版本，通过SDK版本号与对应可升级的版本号映射关系，确定可升级版本的SDK版本号；

索引单元，若存在所述可升级版本号，则从一可升级版本号与二进制升级包的存储表中索引对应的二进制升级包的存储地址，并确定向所述应用客户端发送索引得到的所述二进制升级包。

由上述技术方案可知，本申请提供的应用服务器集群，本发明通过SDK版本号来确定当前SDK版本是否是最新版本，当SDK更新时，仅仅需要增量升级包，然后配合类加载器加载的方式，进而基于字节码修改来实现版本热更新，可以做到通过对SDK热升级，可以在很大程度上缓解推动应用客户端配合升级SDK的重重阻碍，可以做到应用无感知的情况下，通过热更新快速迭代版本，解决了SDK升级难的痛点。

基于相同的发明构思，本发明实施例提供一种分布式系统的SDK热更新处理系统，包括：应用客户端和应用服务器集群；其中，

若应用服务器集群上传有可升级SDK版本号的升级包，所述应用客户端获取所述应用服务器集群中的所述升级包；所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

所述应用客户端通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

由上述技术方案可知，本申请提供的分布式系统的SDK热更新处理系统，本发明通过SDK版本号来确定当前SDK版本是否是最新版本，当SDK更新时，仅仅需要增量升级包，然后配合类加载器加载的方式，进而基于字节码修改来实现版本热更新，可以做到通过对SDK热升级，可以在很大程度上缓解推动应用客户端配合升级SDK的重重阻碍，可以做到应用无感知的情况下，通过热更新快速迭代版本，解决了SDK升级难的痛点。

从硬件层面来说，为了保障分布式SDK热更新处理的高可用性，避免主备切换时的数据丢失，本申请提供一种用于实现所述分布式SDK热更新处理方法中的全部或部分内容的电子设备的实施例，所述电子设备具体包含有如下内容：

处理器(processor)、存储器(memory)、通信接口(Communications Interface)和总线；其中，所述处理器、存储器、通信接口通过所述总线完成相互间的通信；所述通信接口用于实现应用服务器集群、装置、分布式消息中间件集群装置、各类数据库以及用户终端等相关设备之间的信息传输；该电子设备可以是台式计算机、平板电脑及移动终端等，本实施例不限于此。在本实施例中，该电子设备可以参照实施例中的分布式SDK热更新处理方法的实施例，以及，分布式SDK热更新处理装置的实施例进行实施，其内容被合并于此，重复之处不再赘述。

图6为本申请实施例的电子设备9600的系统构成的示意框图。如图6所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图6是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。

一实施例中，分布式SDK热更新处理功能可以被集成到中央处理器9100中。例如，中央处理器9100可以被配置为进行如下控制：

S101：若应用服务器集群上传有可升级SDK版本号的升级包，获取所述应用服务器集群中的所述升级包；所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码。

S102：通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

从上述描述可知，本申请的实施例提供的电子设备，本发明通过SDK版本号来确定当前SDK版本是否是最新版本，当SDK更新时，仅仅需要增量升级包，然后配合类加载器加载的方式，进而基于字节码修改来实现版本热更新，可以做到通过对SDK热升级，可以在很大程度上缓解推动应用客户端配合升级SDK的重重阻碍，可以做到应用无感知的情况下，通过热更新快速迭代版本，解决了SDK升级难的痛点。

在另一个实施方式中，分布式SDK热更新处理装置可以与中央处理器9100分开配置，例如可以将分布式SDK热更新处理配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现分布式SDK热更新处理功能。

如图6所示，该电子设备9600还可以包括：通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是，电子设备9600也并不是必须要包括图6中所示的所有部件；此外，电子设备9600还可以包括图6中没有示出的部件，可以参考现有技术。

如图6所示，中央处理器9100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。

其中，存储器9140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序，以实现信息存储或处理等。

输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。

该存储器9140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142，该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。

存储器9140还可以包括分布式SDK热更新处理部9143，该分布式SDK热更新处理部9143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。

基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块9110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132，以经由扬声器9131提供音频输出，并接收来自麦克风9132的音频输入，从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器9130还耦合到中央处理器9100，从而使得可以通过麦克风9132能够在本机上录音，且使得可以通过扬声器9131来播放本机上存储的声音。

本申请的实施例还提供能够实现上述实施例中的执行主体可以为应用服务器集群的分布式SDK热更新处理方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的执行主体为应用服务器集群或客户端的分布式SDK热更新处理方法的全部步骤。

从上述描述可知，本申请的实施例提供的计算机可读存储介质，本发明通过SDK版本号来确定当前SDK版本是否是最新版本，当SDK更新时，仅仅需要增量升级包，然后配合类加载器加载的方式，进而基于字节码修改来实现版本热更新，可以做到通过对SDK热升级，可以在很大程度上缓解推动应用客户端配合升级SDK的重重阻碍，可以做到应用无感知的情况下，通过热更新快速迭代版本，解决了SDK升级难的痛点。

本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

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

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

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (22)

1.一种分布式系统的SDK热更新处理方法，所述SDK热更新处理方法由应用客户端执行，其特征在于，包括：

若应用服务器集群上传有可升级SDK版本号的升级包，获取所述应用服务器集群中的所述升级包；所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

2.根据权利要求1所述的SDK热更新处理方法，其特征在于，所述获取所述应用服务器集群中的所述升级包，包括：

定时获取所述应用服务器集群中的所述升级包。

3.根据权利要求1所述的SDK热更新处理方法，其特征在于，所述获取所述应用服务器集群中的所述升级包，包括：

每隔设定时长获取所述应用服务器集群中的所述升级包。

4.根据权利要求1所述的SDK热更新处理方法，其特征在于，所述通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码，包括：

实例化所述类加载器；

解析所述升级包，获得类路径信息以及字节码信息；

基于字节码信息，通过所述类加载器加载的方式获取所述类路径信息下的类对象；

实例化所述类对象，进而可通过调用所述类对象加载所述升级包中的更新源码，进而替换当前全量SDK包中的所述至少部分源码。

5.根据权利要求1所述的SDK热更新处理方法，其特征在于，所述实例化所述类对象，包括：

使用反射调用JnosRedisPool.getInstance获取类对象的实例；

通过NosRedisClient接口将所述类对象的实例发送至应用。

6.一种分布式系统的SDK热更新处理方法，所述SDK热更新处理方法由应用服务器集群执行，其特征在于，包括：

向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

若应用客户端确定获取所述升级包，将所述升级包发送至所述应用客户端，以使所述应用客户端通过类加载的方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

7.根据权利要求6所述的SDK热更新处理方法，其特征在于，所述向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码，包括：

定时接收所述应用客户端发送的当前SDK版本号。

8.根据权利要求6所述的SDK热更新处理方法，其特征在于，所述向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码，包括：

每隔设定时长向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码。

9.根据权利要求6所述的SDK热更新处理方法，其特征在于，所述根据当前SDK版本号确定是否向所述应用客户端发送升级包，包括：

若所述当前SDK版本号为全量版本号，则通过SDK版本号与对应可升级的版本号映射关系确定更新版本号；

比对所述更新版本号和所述当前SDK版本号，若所述更新版本号大于所述当前SDK版本号，则将所述更新版本号确定为可升级版本号；

若所述当前SDK版本号为非全量版本号，则截取所述SDK版本号中的全量格式版本，通过SDK版本号与对应可升级的版本号映射关系，确定可升级版本的SDK版本号；

若存在所述可升级版本号，则从一可升级版本号与二进制升级包的存储表中索引对应的二进制升级包的存储地址，并确定向所述应用客户端发送索引得到的所述二进制升级包。

10.一种分布式系统的SDK热更新处理方法，其特征在于，包括：

若应用服务器集群上传有可升级SDK版本号的升级包，所述应用客户端获取所述应用服务器集群中的所述升级包；所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

所述应用客户端通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

11.一种应用客户端，其特征在于，包括：

版本号发送模块，若应用服务器集群上传有可升级SDK版本号的升级包，获取所述应用服务器集群中的所述升级包；所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

升级模块，通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

12.根据权利要求11所述的应用客户端，其特征在于，所述版本号发送模块具体用于定时获取所述应用服务器集群中的所述升级包。

13.根据权利要求11所述的应用客户端，其特征在于，所述版本号发送模块具体用于每隔设定时长获取所述应用服务器集群中的所述升级包。

14.根据权利要求11所述的应用客户端，其特征在于，所述升级模块包括：

加载器实例化单元，实例化所述类加载器；

解析单元，解析所述升级包，获得类路径信息以及字节码信息；

加载单元，基于字节码信息，通过所述类加载器加载的方式获取所述类路径信息下的类对象；

对象实例化单元，实例化所述类对象，进而可通过调用所述类对象加载所述升级包。

15.根据权利要求14所述的应用客户端，其特征在于，所述对象实例化单元，包括：

反射调用单元，使用反射调用JnosRedisPool.getInstance获取类对象的实例；

实例发送单元，通过NosRedisClient接口将所述类对象的实例发送至应用。

16.一种应用服务器集群，其特征在于，包括：

版本号接收模块，向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

升级包发送模块，若应用客户端确定获取所述升级包，将所述升级包发送至所述应用客户端，以使所述应用客户端通过类加载的方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

17.根据权利要求16所述的应用服务器集群，其特征在于，所述版本号接收模块具体用于定时接收所述应用客户端发送的当前SDK版本号。

18.根据权利要求16所述的应用服务器集群，其特征在于，所述版本号接收模块具体用于每隔设定时长向应用客户端发送可升级SDK版本号，以使所述应用客户端根据所述可升级SDK版本号以及当前SDK版本号确定是否获取所述升级包，所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码。

19.根据权利要求16所述应用服务器集群，其特征在于，所述升级包发送模块，包括：

更新版本号确定单元，若所述当前SDK版本号为全量版本号，则通过SDK版本号与对应可升级的版本号映射关系确定更新版本号；

比对单元，比对所述更新版本号和所述当前SDK版本号，若所述更新版本号大于所述当前SDK版本号，则将所述更新版本号确定为可升级版本号；

可升级版本确定单元，若所述当前SDK版本号为非全量版本号，则截取所述SDK版本号中的全量格式版本，通过SDK版本号与对应可升级的版本号映射关系，确定可升级版本的SDK版本号；

索引单元，若存在所述可升级版本号，则从一可升级版本号与二进制升级包的存储表中索引对应的二进制升级包的存储地址，并确定向所述应用客户端发送索引得到的所述二进制升级包。

20.一种分布式系统的SDK热更新处理系统，其特征在于，包括：应用客户端和应用服务器集群；其中，

若应用服务器集群上传有可升级SDK版本号的升级包，所述应用客户端获取所述应用服务器集群中的所述升级包；所述升级包包括对当前全量SDK包的至少部分源码进行更新后的更新源码；

所述应用客户端通过类加载方式，用所述更新源码替换当前全量SDK包中的所述至少部分源码。

21.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至10任一项所述的分布式SDK热更新处理方法。

22.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至10任一项所述的分布式SDK热更新处理方法。

Images