Distributed SDK hot update processing method, application server cluster and application client

Abstract

The distributed SDK hot update processing method and application server cluster provided by the present application can be used in the field of big data technology. The present invention determines whether the current SDK version is the latest version through the SDK version number. When the SDK is updated, only an incremental upgrade package is required, and then the class loader is loaded to achieve version hot update based on bytecode modification. By hot upgrading the SDK, the many obstacles in promoting the application client to cooperate in upgrading the SDK can be alleviated to a large extent. The version can be quickly iterated through hot update without the application being aware of it, thus solving the pain point of difficult SDK upgrades.

Description

Technical Field

[0001] The present application relates to the technical field of application hot update processing, and specifically to a distributed SDK hot update processing method, an application server cluster, and an application client. Background Art

[0002] Currently, the common way to access distributed services in the industry is to embed SDK in the application and call distributed services through RPC. Once the SDK needs to be updated, the application needs to cooperate in updating the SDK package and restart the program on a large number of application servers to take effect.

[0003] In the era of continuous delivery, the frequency of version content upgrades and iterations is constantly increasing, and the redeployment process of many applications is relatively complicated. Downtime and service suspension are unacceptable, especially for some large applications. Each restart takes a lot of time. Therefore, if the program logic in the application process can be upgraded without restarting the process to achieve the effect of version upgrade and function launch, it becomes very important in some business scenarios. Summary of the invention

[0004] In response to the problems in the prior art, the present application provides a distributed SDK hot update processing method, an application server cluster and an application client, which can ensure zero data loss and uninterrupted external services without affecting the high performance of the entire system's external services.

[0005] In order to solve the above technical problems, this application provides the following technical solutions:

[0006] A first aspect of the present invention provides a method for hot updating an SDK of a distributed system. The method is executed by an application client and includes:

[0007] If the application server cluster uploads an upgrade package with an upgradeable SDK version number, obtain the upgrade package in the application server cluster; the upgrade package includes the update source code after updating at least part of the source code of the current full SDK package;

[0008] By class loading, the updated source code is used to replace at least part of the source code in the current full SDK package.

[0009] In some embodiments, obtaining the upgrade package in the application server cluster includes:

[0010] The upgrade package in the application server cluster is obtained periodically.

[0011] In some embodiments, obtaining the upgrade package in the application server cluster includes:

[0012] The upgrade package in the application server cluster is obtained at set intervals.

[0013] In some embodiments, loading the upgrade package through a class loader includes:

[0014] Instantiating the class loader;

[0015] Parsing the upgrade package to obtain class path information and bytecode information;

[0016] Based on the bytecode information, the class object under the class path information is obtained by loading with the class loader;

[0017] The class object is instantiated, and the upgrade package can be loaded by calling the class object.

[0018] In some embodiments, instantiating the class object includes:

[0019] Use reflection to call JnosRedisPool.getInstance to get an instance of the class object;

[0020] The instance of the class object is sent to the application through the NosRedisClient interface.

[0021] A second aspect of the present invention provides a method for hot updating an SDK of a distributed system, wherein the method is executed by an application server cluster and includes:

[0022] Sending an upgradeable SDK version number to the application client, so that the application client determines whether to obtain the upgrade package according to the upgradeable SDK version number and the current SDK version number, wherein the upgrade package includes update source code after updating at least part of the source code of the current full SDK package;

[0023] If the application client determines to obtain the upgrade package, the upgrade package is sent to the application client, so that the application client replaces at least part of the source code in the current full SDK package with the updated source code through class loading.

[0024] In some embodiments, the sending of the upgradeable SDK version number to the application client so that the application client determines whether to obtain the upgrade package according to the upgradeable SDK version number and the current SDK version number, and the upgrade package includes the update source code after updating at least part of the source code of the current full SDK package, including:

[0025] Regularly receive the current SDK version number sent by the application client.

[0026] In some embodiments, the sending of the upgradeable SDK version number to the application client so that the application client determines whether to obtain the upgrade package according to the upgradeable SDK version number and the current SDK version number, and the upgrade package includes the update source code after updating at least part of the source code of the current full SDK package, including:

[0027] The upgradeable SDK version number is sent to the application client at set intervals, so that the application client determines whether to obtain the upgrade package based on the upgradeable SDK version number and the current SDK version number, and the upgrade package includes the updated source code after updating at least part of the source code of the current full SDK package.

[0028] In some embodiments, determining whether to send an upgrade package to the application client according to the current SDK version number includes:

[0029] If the current SDK version number is a full version number, the updated version number is determined by the mapping relationship between the SDK version number and the corresponding upgradeable version number;

[0030] Comparing the update version number with the current SDK version number, if the update version number is greater than the current SDK version number, determining the update version number as an upgradeable version number;

[0031] If the current SDK version number is a non-full version number, intercept the full format version in the SDK version number, and determine the SDK version number of the upgradeable version through the mapping relationship between the SDK version number and the corresponding upgradeable version number;

[0032] If the upgradeable version number exists, the storage address of the corresponding binary upgrade package is indexed from a storage table of upgradeable version numbers and binary upgrade packages, and the binary upgrade package obtained by the index is sent to the application client.

[0033] A third aspect of the present invention provides a method for hot updating an SDK of a distributed system, including:

[0034] The application client obtains the upgrade package in the application server cluster;

[0035] The application server cluster determines whether to send an upgrade package to the application client according to the current SDK version number; the upgrade package includes an update source code after updating at least part of the source code of the current full SDK package;

[0036] The application client replaces at least part of the source code in the current full SDK package with the updated source code through class loading.

[0037] A fourth aspect of the present invention provides an application client, including:

[0038] A version number sending module, if an upgrade package with an upgradeable SDK version number is uploaded to the application server cluster, obtains the upgrade package in the application server cluster; the upgrade package includes an update source code after updating at least part of the source code of the current full SDK package;

[0039] The upgrade module replaces at least part of the source code in the current full SDK package with the updated source code by class loading.

[0040] In some embodiments, the version number sending module is specifically used to periodically obtain the upgrade package in the application server cluster.

[0041] In some embodiments, the version number sending module is specifically configured to obtain the upgrade package in the application server cluster at set intervals.

[0042] In some embodiments, the upgrade module includes:

[0043] A loader instantiation unit, instantiating the class loader;

[0044] A parsing unit, parsing the upgrade package to obtain class path information and bytecode information;

[0045] A loading unit, based on the bytecode information, obtains the class object under the class path information by loading through the class loader;

[0046] The object instantiation unit instantiates the class object, and then can load the upgrade package by calling the class object.

[0047] In some embodiments, the object instantiation unit includes:

[0048] The reflection call unit uses reflection to call JnosRedisPool.getInstance to obtain an instance of the class object;

[0049] The instance sending unit sends the instance of the class object to the application through the NosRedisClient interface.

[0050] A fifth aspect of the present invention provides an application server cluster, including:

[0051] A version number receiving module, which sends an upgradeable SDK version number to an application client, so that the application client determines whether to obtain the upgrade package according to the upgradeable SDK version number and the current SDK version number, wherein the upgrade package includes an update source code after updating at least part of the source code of the current full SDK package;

[0052] The upgrade package sending module sends the upgrade package to the application client if the application client determines to obtain the upgrade package, so that the application client replaces at least part of the source code in the current full SDK package with the updated source code through class loading.

[0053] In some embodiments, the version number receiving module is specifically configured to periodically receive the current SDK version number sent by the application client.

[0054] In some embodiments, the version number receiving module is specifically used to send an upgradeable SDK version number to an application client at set intervals, so that the application client determines whether to obtain the upgrade package based on the upgradeable SDK version number and the current SDK version number, and the upgrade package includes the updated source code after updating at least part of the source code of the current full SDK package.

[0055] In some embodiments, the upgrade package sending module includes:

[0056] An update version number determining unit, if the current SDK version number is a full version number, determines the update version number through a mapping relationship between the SDK version number and a corresponding upgradeable version number;

[0057] A comparison unit, comparing the update version number with the current SDK version number, and if the update version number is greater than the current SDK version number, determining the update version number as an upgradeable version number;

[0058] an upgradeable version determining unit, which, if the current SDK version number is a non-full version number, intercepts the full format version in the SDK version number, and determines the SDK version number of the upgradeable version through a mapping relationship between the SDK version number and the corresponding upgradeable version number;

[0059] The indexing unit, if the upgradeable version number exists, indexes the storage address of the corresponding binary upgrade package from a storage table of upgradeable version numbers and binary upgrade packages, and determines to send the binary upgrade package obtained by the index to the application client.

[0060] The sixth aspect of the present invention provides a distributed system SDK hot update processing system, including: an application client and an application server cluster; wherein:

[0061] The application client obtains the upgrade package in the application server cluster;

[0062] The application server cluster determines whether to send an upgrade package to the application client according to the current SDK version number; the upgrade package includes an update source code after updating at least part of the source code of the current full SDK package;

[0063] The application client replaces at least part of the source code in the current full SDK package with the updated source code through class loading.

[0064] In a seventh aspect, the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the distributed SDK hot update processing method when executing the program.

[0065] In an eighth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the distributed SDK hot update processing method.

[0066] It can be seen from the above technical scheme that the distributed SDK hot update processing method, application server cluster and application client provided by the present application, the present invention determines whether the current SDK version is the latest version through the SDK version number. When the SDK is updated, only an incremental upgrade package is required, and then it is loaded in conjunction with the class loader, and then the version hot update is implemented based on bytecode modification. By hot upgrading the SDK, the many obstacles to promoting the application client to cooperate in upgrading the SDK can be alleviated to a large extent. The version can be quickly iterated through hot updates without the application being aware of it, thus solving the pain point of difficult SDK upgrades. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0068] Figure 1 It is a schematic diagram of the interaction process of the present invention.

[0069] Figure 2 This is one of the flow charts of the distributed SDK hot update processing method of this application.

[0070] Figure 3 This is the second flow chart of the distributed SDK hot update processing method of this application.

[0071] Figure 4 This is a schematic diagram of the structure of the application client in the embodiment of the present application.

[0072] Figure 5 This is a schematic diagram of the application server cluster structure in an embodiment of the present application.

[0073] Figure 6 It is a schematic diagram of the structure of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0074] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0075] In the prior art, the common way to access distributed services in the industry is to embed SDK in the application and call distributed services through RPC. Once the SDK needs to be updated, the application needs to cooperate in updating the SDK package and restart the program for a large number of application servers to take effect.

[0076] In the era of continuous delivery, the frequency of version content upgrades and iterations is constantly increasing, and the redeployment process of many applications is relatively complicated. Downtime and service suspension are unacceptable, especially for some large applications. Each restart takes a lot of time. Therefore, if the program logic in the application process can be upgraded without restarting the process to achieve the effect of version upgrade and function launch, it becomes very important in some business scenarios.

[0077] For example, when using a distributed system with a proxy mode and an SDK that supports the JAVA language, it is necessary to introduce the SDK package into the application when using the distributed system. When the SDK is updated, the application needs to reintroduce the updated SDK package into the program, redeploy related media on the application server, and restart the application for the update to take effect, which has a significant impact on the application.

[0078] In view of this, the present invention, by making use of bytecode technology and cooperating with incremental upgrades, modifies the program logic that needs to be updated in the source code by replacing the bytecode file, thereby ensuring the continuity of business services and the non-awareness of the application, and realizing hot updates of the SDK on the application side. The functional requirements of the development SDK can be customized as needed, effectively reducing the impact of promoting application upgrades to the SDK.

[0079] The above concept of the present invention is described in detail below with reference to the accompanying drawings.

[0080] In one or more embodiments of the present application, Figure 1 As shown, including application client (such as Figure 1 SDK side) and application server cluster (such as Figure 1 Proxy side).

[0081] The application server cluster is a distributed cluster device, which specifically includes multiple distributed servers, which store the SDK upgrade package of the application. When the application uses the distributed system, the SDK package must be introduced in the client program. The SDK contains an interface class that defines all the callable methods of the current SDK. When the SDK needs to add tracking functions, collection functions, logic modifications, etc. to the existing interface, the updated SDK package can be deployed on the server. The SDK periodically detects whether the server has a version to be updated. When the server's SDK version to be updated is uploaded, it automatically triggers the application client to automatically obtain the SDK update package through the network, and implements hot updates of related classes through custom class loaders. After class loading and updating are completed, the client will call the updated class program when using the distributed system.

[0082] It can be understood that the present invention is applicable to the field of big data technology, but of course, the present application is not limited thereto.

[0083] The application client may be an electronic device such as a mobile phone, a mobile computer, or other tablet computer, vehicle-mounted device, etc. equipped with an intelligent system (such as an Android system or an Apple system), but the present invention is not limited thereto.

[0084] It is to be understood that any suitable network protocol may be used to communicate between application server clusters, including network protocols that have not yet been developed on the date of filing of this application. The network protocols may include, for example, TCP / IP protocol, UDP / IP protocol, HTTP protocol, HTTPS protocol, etc. Of course, the network protocols may also include, for example, RPC protocol (Remote Procedure Call Protocol) and REST protocol (Representational State Transfer) used on top of the above protocols.

[0085] In a specific embodiment of the present invention, the SDK hot update processing method of the distributed system provided by the present invention, wherein the application client specifically performs the following steps, such as Figure 2 As shown:

[0086] S101: If an upgrade package with an upgradeable SDK version number is uploaded to the application server cluster, the upgrade package in the application server cluster is obtained; the upgrade package includes update source code after updating at least part of the source code of the current full SDK package.

[0087] Specifically, the application client can send its current SDK version number to the application server at regular intervals. For example, in a specific scenario, the application client sends the current SDK version number to the application server every hour. This ensures that once the application server uploads the latest version of the SDK package, it can complete automatic hot updates as soon as possible.

[0088] Furthermore, the application client may also periodically send its current SDK version number to the application server. For example, in a specific scenario, the application client sends its current SDK version number to the application server at 0:00 am every day, so that the application version can be updated within one day.

[0089] In a preferred embodiment, the application client can dynamically send the current SDK version number to the English server based on the current task load. For example, when the system detects that the current CPU (or MCU) usage is below 30% and the running memory usage is below 40%, it is considered that the application terminal is in an idle processing capacity state. It can be sent through the background and the bytecode modification technology can be used to perform hot updates when the application is not started, thereby achieving completely seamless updates.

[0090] It can be understood that "sending the current SDK version number to the application server cluster" in the present invention can be just sending the SDK version number information, for example, compiling the current SDK version number into a binary string, and then sending the binary string to the application server cluster, and the application server cluster decompiles the binary string in the background to obtain the current SDK version number.

[0091] Of course, in a preferred embodiment, the client can be configured to automatically trigger the acquisition of an SDK update package (i.e., an upgrade package). In this embodiment, the application client can periodically access the application server cluster. When the application server cluster uploads an updated SDK package, it "notifies" the application client that the updated SDK package has been uploaded. For example, the application server cluster sends a special character or a special binary string to the application client. Based on the customized recognition settings, the application client can recognize the special character or special binary string, and then "know" that there is an updateable SDK package.

[0092] Further, such as Figure 1 As shown, the application client may first send an instruction to the application server cluster to check whether there is an upgrade package, and then query whether the upgrade package is uploaded to the application server cluster. If so, the application server cluster returns a confirmation instruction and an upgradeable SDK version number.

[0093] Specifically, the application client introduces the full SDK package into the project, passes in tenant information such as appid, calls JnosRedisPool.initPool to initialize the instance, obtains the instance through getClient, and calls the provided interface to interact with redis. The key information is as follows:

[0094] 1) poolMap: caches the SDK instance and retrieves the instance from memory for each interaction.

[0095] 2) Check whether to upgrade the scheduled task: This scheduled task is started when the SDK successfully creates a pool instance for the first time. It is used to regularly check whether the SDK can be upgraded and trigger the upgrade. The frequency is once an hour.

[0096] 3) Upgrade flag: Default is false, set to true if there is an update.

[0097] 4) Current version number: identifies the version number of the current SDK.

[0098] 5) Upgrade target version number: When the upgrade flag is true, the upgradeable target version number returned by the server.

[0099] S102: Using the class loading method, replace at least part of the source code in the current full SDK package with the updated source code.

[0100] This step is based on bytecode modification technology. By loading the class bytecode file (class file), the updated class bytecode file is replaced with the class bytecode file corresponding to the updated source code, thereby realizing hot update of the SDK on the application side.

[0101] In some embodiments, considering that the same class loader cannot repeatedly load the same class, all custom classes in the upgrade package are loaded by custom class loaders one by one, and hot updates of custom classes are achieved by recreating and assigning objects in the singleton mode.

[0102] In addition, considering that the upgrade package is small (several hundred KB), the SDK will download the upgrade package only when there is an update. Storing the upgrade package on each proxy and providing a download command can effectively share the download traffic. The SDK passes in the version number to initiate the download upgrade package instruction. The proxy determines whether the SDK needs to be updated based on the version number. If necessary, the upgrade package is transmitted to the application server via TCP in the existing format. The SDK in the application server loads the upgrade package into the memory and determines whether the custom class is loaded into the memory through the custom class loader. When loading other dependent classes, it first determines whether there is a framework custom class loader, and then determines whether there is a thread context custom class loader. The dependent classes are loaded into the memory using the class loaders in order of priority.

[0103] Taking into account the directory permission issue on the application side, the upgrade package is not stored on the disk, but is loaded into the memory through network transmission each time it is instantiated.

[0104] In some specific embodiments, the hot update is triggered as follows: There are two ways to trigger the SDK hot upgrade: when the application initializes the pool and when the scheduled task detects an update.

[0105] (1) When the application initializes the pool and the scheduled task detects an update, the SDK sends the command "*2\r\n$12\r\ncheckupgrade\r\n$version number length\r\nversion number\r\n" to the proxy.

[0106] (2) The proxy's checkupgrade method parses the SDK version number and returns the upgrade target version number and upgrade flag true if there is an upgrade, otherwise it returns the upgrade flag false.

[0107] (3) SDK parses the return value. If the upgrade flag is false and the poolMap instance does not exist, the local package is loaded and an instance is created, updated to the cache and returned.

[0108] (4) If the upgrade flag is true, the command "*2\r\n$11\r\ndownloadjar\r\n$version number length\r\nversion number\r\n" is sent to the proxy. The proxy's downloadjar method parses the SDK version number and returns the upgrade package (binary).

[0109] (5) SDK parses the return value. If it is false or times out, the local SDK is used to load it, and the upgrade flag is updated to false. If the upgrade package is downloaded successfully, the upgrade package is used to load it. After loading successfully, the pool instance is updated to the poolMap, and the current version number is replaced with the target version number (as long as the upgrade package fails to be obtained or loaded, the local SDK must be used to ensure normal use of the application), and the upgrade flag is set to false.

[0110] Furthermore, replacing at least part of the source code in the current full SDK package with the updated source code by class loading includes:

[0111] Instantiating the class loader;

[0112] Parsing the upgrade package to obtain class path information and bytecode information;

[0113] Based on the bytecode information, the class object under the class path information is obtained by loading with the class loader;

[0114] The class object is instantiated, and then the updated source code in the upgrade package can be loaded by calling the class object, thereby replacing at least part of the source code in the current full SDK package.

[0115] Specifically, the instantiating the class object includes:

[0116] Use reflection to call JnosRedisPool.getInstance to get an instance of the class object;

[0117] The instance of the class object is sent to the application through the NosRedisClient interface.

[0118] In a specific embodiment, 3. Loading the upgrade package process:

[0119] (1) After downloading the upgrade package, first instantiate the custom class loader (instantiate it every time), parse the upgrade package to obtain the class path and class bytecode information and load it into ClasspathResources (including map).

[0120] (2) Load the "com.icbc.threealive.jnos.jredis.JnosRedisPool" class object through the custom loader. First, determine whether the loader has been loaded. If it has been loaded, obtain it from the memory; otherwise, obtain it from ClasspathResources first. If it has been loaded, generate the class object according to the bytecode; otherwise, obtain it from the parent class loader until the class object is generated. The dependent classes generate class objects according to similar steps.

[0121] (3) Use reflection to call JnosRedisPool.getInstance to obtain the instance and return it to the application in the form of the NosRedisClient interface. The application can call all methods exposed by the interface.

[0122] It can be seen from the above technical scheme that the distributed SDK hot update processing method provided by the present application determines whether the current SDK version is the latest version through the SDK version number. When the SDK is updated, only an incremental upgrade package is required, and then the class loader is loaded to achieve version hot update based on bytecode modification. By hot upgrading the SDK, the many obstacles in promoting the application client to cooperate in upgrading the SDK can be alleviated to a large extent. The version can be quickly iterated through hot update without the application being aware of it, thus solving the pain point of difficult SDK upgrades.

[0123] A second aspect of the present invention provides a method for processing hot updates of SDKs in a distributed system, wherein the method is executed by an application server cluster. Figure 3 ,include:

[0124] S201: Send an upgradeable SDK version number to an application client, so that the application client determines whether to obtain the upgrade package based on the upgradeable SDK version number and the current SDK version number, and the upgrade package includes update source code after updating at least part of the source code of the current full SDK package.

[0125] Specifically, first, the application client can send its current SDK version number to the application server at regular intervals. For example, in a specific scenario, the application client sends the current SDK version number to the application server every hour. This ensures that once the application server uploads the latest version of the SDK package, it can complete automatic hot update as soon as possible.

[0126] Furthermore, the application client may also periodically send its current SDK version number to the application server. For example, in a specific scenario, the application client sends its current SDK version number to the application server at 0:00 am every day, so that the application version can be updated within one day.

[0127] In a preferred embodiment, the application client can dynamically send the current SDK version number to the English server based on the current task load. For example, when the system detects that the current CPU (or MCU) usage is below 30% and the running memory usage is below 40%, it is considered that the application terminal is in an idle processing capacity state. It can be sent through the background and the bytecode modification technology can be used to perform hot updates when the application is not started, thereby achieving completely seamless updates.

[0128] It can be understood that "sending the current SDK version number to the application server cluster" in the present invention can be just sending the SDK version number information, for example, compiling the current SDK version number into a binary string, and then sending the binary string to the application server cluster, and the application server cluster decompiles the binary string in the background to obtain the current SDK version number.

[0129] Of course, in a preferred embodiment, the client can be configured to automatically trigger the acquisition of an SDK update package (i.e., an upgrade package). In this embodiment, the application client can periodically access the application server cluster. When the application server cluster uploads an updated SDK package, it "notifies" the application client that the updated SDK package has been uploaded. For example, the application server cluster sends a special character or a special binary string to the application client. Based on the customized recognition settings, the application client can recognize the special character or special binary string, and then "know" that there is an updateable SDK package.

[0130] In this way, after the application client completes the "check", if the upgrade package has been uploaded, step S201 is executed.

[0131] S202: If the application client determines to obtain the upgrade package, the upgrade package is sent to the application client, so that the application client replaces at least part of the source code in the current full SDK package with the updated source code through class loading.

[0132] The distributed SDK hot update processing method provided by the present application determines whether the current SDK version is the latest version through the SDK version number. When the SDK is updated, only an incremental upgrade package is required, and then the class loader is loaded to achieve version hot update based on bytecode modification. By hot upgrading the SDK, the many obstacles in promoting the application client to cooperate with the SDK upgrade can be alleviated to a great extent. The version can be quickly iterated through hot update without the application being aware of it, thus solving the pain point of difficult SDK upgrades.

[0133] In a preferred embodiment, the upgradable SDK version number is sent to the application client so that the application client determines whether to obtain the upgrade package according to the upgradable SDK version number and the current SDK version number, and the upgrade package includes the updated source code after updating at least part of the source code of the current full SDK package, including:

[0134] Regularly receive the current SDK version number sent by the application client.

[0135] In a preferred embodiment, the upgradable SDK version number is sent to the application client so that the application client determines whether to obtain the upgrade package according to the upgradable SDK version number and the current SDK version number, and the upgrade package includes the updated source code after updating at least part of the source code of the current full SDK package, including:

[0136] The upgradeable SDK version number is sent to the application client at set intervals, so that the application client determines whether to obtain the upgrade package based on the upgradeable SDK version number and the current SDK version number, and the upgrade package includes the updated source code after updating at least part of the source code of the current full SDK package.

[0137] In a preferred embodiment, the determining whether to send an upgrade package to the application client according to the current SDK version number includes:

[0138] If the current SDK version number is a full version number, the updated version number is determined by the mapping relationship between the SDK version number and the corresponding upgradeable version number;

[0139] Comparing the update version number with the current SDK version number, if the update version number is greater than the current SDK version number, determining the update version number as an upgradeable version number;

[0140] If the current SDK version number is a non-full version number, intercept the full format version in the SDK version number, and determine the SDK version number of the upgradeable version through the mapping relationship between the SDK version number and the corresponding upgradeable version number;

[0141] If the upgradeable version number exists, the storage address of the corresponding binary upgrade package is indexed from a storage table of upgradeable version numbers and binary upgrade packages, and the binary upgrade package obtained by the index is sent to the application client.

[0142] In a specific embodiment, the application server cluster stores the upgrade package directory of each version of the SDK:

[0143] / data / nos / piza / current / sdk.

[0144] When the service starts, it traverses the upgrade package directory and saves the version number and upgrade package in the following two variables:

[0145] 1)sdkUpgradeVersMap: The mapping relationship between the sdk version number and the corresponding upgradeable version number.

[0146] 2)sdkVersJarMap: A storage table of upgradeable version numbers and binary upgrade packages.

[0147] Example:

[0148] Upgrade package directory structure 3.3

[0150] --3.3.3.jar 3.4

[0152] --3.4.1.jar

[0153] sdkUpgradeVersMap data 3.33.3.3 3.43.4.1

[0156] sdkVersJarMap data

[0157] 3.3.3 Corresponding upgrade package

[0158] 3.4.1 Corresponding upgrade package

[0159] SDK

[0160] 3.3 Directly upgrade to 3.3.3

[0161] 3.3.1 first intercepts 3.3 and finds that the upgradeable version is 3.3.3. It is found that 3.3.1<3.3.3, and needs to be upgraded to 3.3.3

[0162] 3.3.2 Same as above

[0163] 3.3.3 first intercepts 3.3 and finds that the upgradeable version is 3.3.3. If 3.3.3 <= 3.3.3, do not upgrade

[0164] 3.3.4 Same as above

[0165] 3.4 Directly upgrade to 3.4.1

[0166] 3.4.1 first intercepts 3.4 and finds that the upgradeable version is 3.4.1. It is found that 3.4.1 <= 3.4.1, and needs to be upgraded to 3.4.1

[0167] After that, the checkupgrade method provides parsing of the SDK version number and determines whether to upgrade the SDK. The processing process is as follows:

[0168] 1) Parse the version number v_sdk passed by sdk. If v_sdk is the full version number, find the updateable version number v_sdk_upgrade in sdkUpgradeVersMap through v_sdk and return sdk; otherwise, intercept it to the full format version v_sdk_base.

[0169] 2) Use v_sdk_base to find the upgradeable version v_sdk_upgrade in sdkUpgradeVersMap, and compare v_sdk and v_sdk_upgrade. If v_sdk is less than v_sdk_upgrade, v_sdk_upgrade is returned to sdk.

[0170] 1. The downloadjar method provides an interface for downloading SDK upgrade packages:

[0171] 1) Parse the version number v_sdk passed by sdk. If v_sdk is a full version, find the updateable version number v_sdk_upgrade in sdkUpgradeVersMap through v_sdk, and find the upgrade package in sdkVersJarMap through v_sdk_upgrade; otherwise, it is an incremental version number, and the upgrade package is directly found in sdkVersJarMap.

[0172] Based on the same inventive concept, another aspect of the present invention provides a method for processing hot updates of SDKs in a distributed system, the method being composed of an application server cluster and an application client and comprising:

[0173] If the application server cluster uploads an upgrade package with an upgradeable SDK version number, the application client obtains the upgrade package in the application server cluster; the upgrade package includes the update source code after updating at least part of the source code of the current full SDK package;

[0174] The application client replaces at least part of the source code in the current full SDK package with the updated source code through class loading.

[0175] It can be seen from the above technical scheme that the distributed SDK hot update processing method provided by the present application determines whether the current SDK version is the latest version through the SDK version number. When the SDK is updated, only an incremental upgrade package is required, and then the class loader is loaded to achieve version hot update based on bytecode modification. By hot upgrading the SDK, the many obstacles in promoting the application client to cooperate in upgrading the SDK can be alleviated to a large extent. The version can be quickly iterated through hot update without the application being aware of it, thus solving the pain point of difficult SDK upgrades.

[0176] Based on the same inventive concept, the present invention further provides an application client, such as Figure 4 include:

[0177] The version number sending module 101 obtains the upgrade package in the application server cluster if the application server cluster uploads an upgrade package with an upgradeable SDK version number; the upgrade package includes an update source code after updating at least part of the source code of the current full SDK package;

[0178] The upgrade module 102 replaces at least part of the source code in the current full SDK package with the updated source code by class loading.

[0179] In a specific embodiment, the version number sending module is specifically used to periodically obtain the upgrade package in the application server cluster.

[0180] In a specific embodiment, the version number sending module is specifically used to obtain the upgrade package in the application server cluster at a set time interval.

[0181] In a specific embodiment, the upgrade module includes:

[0182] A loader instantiation unit, instantiating the class loader;

[0183] A parsing unit, parsing the upgrade package to obtain class path information and bytecode information;

[0184] A loading unit, based on the bytecode information, obtains the class object under the class path information by loading through the class loader;

[0185] The object instantiation unit instantiates the class object, and then can load the upgrade package by calling the class object.

[0186] In a specific embodiment, the object instantiation unit includes:

[0187] The reflection call unit uses reflection to call JnosRedisPool.getInstance to obtain an instance of the class object;

[0188] The instance sending unit sends the instance of the class object to the application through the NosRedisClient interface.

[0189] It can be seen from the above technical solution that the application client provided by the present application determines whether the current SDK version is the latest version through the SDK version number. When the SDK is updated, only an incremental upgrade package is required, and then the class loader is loaded to achieve hot version update based on bytecode modification. By hot upgrading the SDK, the many obstacles to promoting the application client to cooperate in upgrading the SDK can be alleviated to a large extent. The version can be quickly iterated through hot updates without the application being aware of it, thus solving the pain point of difficult SDK upgrades.

[0190] Based on the same inventive concept, the present invention further provides an application server cluster, such as Figure 5 include:

[0191] The version number receiving module 201 sends the upgradeable SDK version number to the application client, so that the application client determines whether to obtain the upgrade package according to the upgradeable SDK version number and the current SDK version number, and the upgrade package includes the update source code after updating at least part of the source code of the current full SDK package;

[0192] The upgrade package sending module 202 sends the upgrade package to the application client if the application client determines to obtain the upgrade package, so that the application client replaces at least part of the source code in the current full SDK package with the updated source code through class loading.

[0193] In a specific embodiment, the version number receiving module is specifically used to periodically receive the current SDK version number sent by the application client.

[0194] In a specific embodiment, the version number receiving module is specifically used to send an upgradeable SDK version number to the application client at set intervals, so that the application client determines whether to obtain the upgrade package based on the upgradeable SDK version number and the current SDK version number, and the upgrade package includes the updated source code after updating at least part of the source code of the current full SDK package.

[0195] In a specific embodiment, the upgrade package sending module includes:

[0196] An update version number determining unit, if the current SDK version number is a full version number, determines the update version number through a mapping relationship between the SDK version number and a corresponding upgradeable version number;

[0197] A comparison unit, comparing the update version number with the current SDK version number, and if the update version number is greater than the current SDK version number, determining the update version number as an upgradeable version number;

[0198] an upgradeable version determining unit, which, if the current SDK version number is a non-full version number, intercepts the full format version in the SDK version number, and determines the SDK version number of the upgradeable version through a mapping relationship between the SDK version number and the corresponding upgradeable version number;

[0199] The indexing unit, if the upgradeable version number exists, indexes the storage address of the corresponding binary upgrade package from a storage table of upgradeable version numbers and binary upgrade packages, and determines to send the binary upgrade package obtained by the index to the application client.

[0200] It can be seen from the above technical solution that the application server cluster provided by the present application determines whether the current SDK version is the latest version through the SDK version number. When the SDK is updated, only an incremental upgrade package is required, and then the class loader is loaded to achieve hot version update based on bytecode modification. By hot upgrading the SDK, the many obstacles to promoting the application client to cooperate in upgrading the SDK can be alleviated to a large extent. The version can be quickly iterated through hot updates without the application being aware of it, thus solving the pain point of difficult SDK upgrades.

[0201] Based on the same inventive concept, an embodiment of the present invention provides a distributed system SDK hot update processing system, including: an application client and an application server cluster; wherein,

[0202] If the application server cluster uploads an upgrade package with an upgradeable SDK version number, the application client obtains the upgrade package in the application server cluster; the upgrade package includes the update source code after updating at least part of the source code of the current full SDK package;

[0203] The application client replaces at least part of the source code in the current full SDK package with the updated source code through class loading.

[0204] It can be seen from the above technical scheme that the SDK hot update processing system of the distributed system provided by the present application determines whether the current SDK version is the latest version through the SDK version number. When the SDK is updated, only an incremental upgrade package is required, and then the class loader is loaded to achieve version hot update based on bytecode modification. By hot upgrading the SDK, the many obstacles in promoting the application client to cooperate in upgrading the SDK can be alleviated to a large extent. The version can be quickly iterated through hot update without the application being aware of it, thus solving the pain point of difficult SDK upgrades.

[0205] From the hardware level, in order to ensure the high availability of the distributed SDK hot update processing and avoid data loss during the master-slave switching, the present application provides an embodiment of an electronic device for implementing all or part of the content of the distributed SDK hot update processing method, and the electronic device specifically includes the following content:

[0206] Processor, memory, communication interface and bus; wherein the processor, memory and communication interface communicate with each other through the bus; the communication interface is used to realize information transmission between application server clusters, devices, distributed message middleware cluster devices, various databases and user terminals and other related devices; the electronic device can be a desktop computer, a tablet computer and a mobile terminal, etc., but the present embodiment is not limited thereto. In the present embodiment, the electronic device can be implemented with reference to the embodiment of the distributed SDK hot update processing method and the embodiment of the distributed SDK hot update processing device in the embodiment, and the contents thereof are incorporated herein and the repeated parts are not repeated.

[0207] Figure 6 FIG. 9 is a schematic block diagram of the system structure of the electronic device 9600 according to an embodiment of the present application. Figure 6 As shown, the electronic device 9600 may include a central processor 9100 and a memory 9140; the memory 9140 is coupled to the central processor 9100. It is worth noting that Figure 6 is exemplary; other types of structures may also be used to supplement or replace this structure to implement telecommunication functions or other functions.

[0208] In one embodiment, the distributed SDK hot update processing function can be integrated into the central processing unit 9100.

[0209] For example, the CPU 9100 may be configured to perform the following control:

[0210] S101: If an upgrade package with an upgradeable SDK version number is uploaded to the application server cluster, the upgrade package in the application server cluster is obtained; the upgrade package includes update source code after updating at least part of the source code of the current full SDK package.

[0211] S102: Using the class loading method, replace at least part of the source code in the current full SDK package with the updated source code.

[0212] From the above description, it can be seen that the electronic device provided by the embodiment of the present application determines whether the current SDK version is the latest version through the SDK version number. When the SDK is updated, only an incremental upgrade package is required, and then the class loader is loaded to achieve hot version update based on bytecode modification. By hot upgrading the SDK, the many obstacles to promoting the application client to cooperate in upgrading the SDK can be alleviated to a large extent. The version can be quickly iterated through hot updates without the application being aware of it, thus solving the pain point of difficult SDK upgrades.

[0213] In another embodiment, the distributed SDK hot update processing device can be configured separately from the central processor 9100. For example, the distributed SDK hot update processing can be configured as a chip connected to the central processor 9100, and the distributed SDK hot update processing function can be implemented through the control of the central processor.

[0214] like Figure 6 As shown, the electronic device 9600 may also include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily have to include Figure 6 In addition, the electronic device 9600 may also include Figure 6 For components not shown, reference may be made to the prior art.

[0215] like Figure 6 As shown, the central processing unit 9100 is sometimes also referred to as a controller or an operation control, and may include a microprocessor or other processor device and / or logic device. The central processing unit 9100 receives input and controls the operation of various components of the electronic device 9600.

[0216] The memory 9140 may be, for example, one or more of a cache, a flash memory, a hard drive, a removable medium, a volatile memory, a non-volatile memory or other suitable devices. The above-mentioned information related to the failure may be stored, and a program for executing the relevant information may also be stored. The CPU 9100 may execute the program stored in the memory 9140 to implement information storage or processing, etc.

[0217] The input unit 9120 provides input to the central processing unit 9100. The input unit 9120 is, for example, a key or a touch input device. The power supply 9170 is used to provide power to the electronic device 9600. The display 9160 is used to display display objects such as images and texts. The display may be, for example, an LCD display, but is not limited thereto.

[0218] The memory 9140 may be a solid-state memory, such as a read-only memory (ROM), a random access memory (RAM), a SIM card, etc. It may also be a memory that saves information even when the power is off, can be selectively erased, and is provided with more data, examples of which are sometimes referred to as EPROMs, etc. The memory 9140 may also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142, which is used to store application programs and function programs or processes for executing the operation of the electronic device 9600 through the central processor 9100.

[0219] The memory 9140 may also include a distributed SDK hot update processing unit for storing data 9143, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for communication functions of the electronic device and / or for executing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0220] The communication module 9110 is a transmitter / receiver 9110 that sends and receives signals via an antenna 9111. The communication module (transmitter / receiver) 9110 is coupled to the central processor 9100 to provide input signals and receive output signals, which may be the same as the case of a conventional mobile communication terminal.

[0221] Based on different communication technologies, multiple communication modules 9110 may be provided in the same electronic device, such as a cellular network module, a Bluetooth module and / or a wireless LAN module, etc. The communication module (transmitter / receiver) 9110 is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide an audio output via the speaker 9131 and receive an audio input from the microphone 9132, thereby realizing a common telecommunication function. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. In addition, the audio processor 9130 is also coupled to the central processor 9100, so that recording can be performed on the local machine through the microphone 9132, and the sound stored on the local machine can be played through the speaker 9131.

[0222] An embodiment of the present application also provides a computer-readable storage medium that can implement all the steps in the distributed SDK hot update processing method in the above embodiment, where the execution subject can be an application server cluster. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements all the steps in the distributed SDK hot update processing method in the above embodiment, where the execution subject can be an application server cluster or a client.

[0223] From the above description, it can be seen that the computer-readable storage medium provided in the embodiment of the present application determines whether the current SDK version is the latest version through the SDK version number. When the SDK is updated, only an incremental upgrade package is required, and then the class loader is loaded to achieve hot version update based on bytecode modification. By hot upgrading the SDK, the many obstacles to promoting the application client to cooperate in upgrading the SDK can be alleviated to a large extent. The version can be quickly iterated through hot updates without the application being aware of it, thus solving the pain point of difficult SDK upgrades.

[0224] It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as methods, devices, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0225] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (apparatus), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0226] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1A function specified in one or more boxes.

[0227] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0228] The present invention uses specific embodiments to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for those skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A method for processing SDK hot updates in a distributed system, wherein the method is executed by an application client, and is characterized in that: include: If the application server cluster has uploaded an upgrade package with an upgradeable SDK version number, obtain the upgrade package in the application server cluster; The upgrade package includes the updated source code after updating at least part of the source code of the current full SDK package, wherein the application client dynamically sends the current SDK version number to the application server based on the current workload, and uses bytecode modification technology to perform hot update when the application is not started, so as to achieve completely seamless update; Through class loading, the updated source code is used to replace at least part of the source code in the current full SDK package, wherein storing the upgrade package in each proxy and providing a download command can effectively share the download traffic, the sdk passes in the version number to initiate the download upgrade package instruction, the proxy determines whether the SDK needs to be updated based on the version number, and if necessary, the upgrade package is transmitted to the application server via TCP in the existing format, the SDK in the application server loads the upgrade package into the memory and determines to load the custom class into the memory through the custom class loader, and when loading other dependent classes, first determines whether there is a framework custom class loader, and then determines whether there is a thread context custom class loader, and uses the class loader to load the dependent classes into the memory in order of priority.

2. The SDK hot update processing method according to claim 1, characterized in that: The obtaining the upgrade package in the application server cluster includes: The upgrade package in the application server cluster is obtained periodically.

3. The SDK hot update processing method according to claim 1, characterized in that: The obtaining the upgrade package in the application server cluster includes: The upgrade package in the application server cluster is obtained at set intervals.

4. The SDK hot update processing method according to claim 1, characterized in that: The replacing at least part of the source code in the current full SDK package with the updated source code by class loading includes: Instantiating the class loader; Parsing the upgrade package to obtain class path information and bytecode information; Based on the bytecode information, the class object under the class path information is obtained by loading with the class loader; The class object is instantiated, and then the updated source code in the upgrade package can be loaded by calling the class object, thereby replacing at least part of the source code in the current full SDK package.

5. The SDK hot update processing method according to claim 4, characterized in that: The instantiating the class object comprises: Use reflection to call JnosRedisPool.getInstance to get an instance of the class object; The instance of the class object is sent to the application through the NosRedisClient interface.

6. A method for processing SDK hot updates in a distributed system, wherein the method is executed by an application server cluster, and is characterized in that: include: Sending an upgradeable SDK version number to an application client, so that the application client determines whether to obtain the upgrade package according to the upgradeable SDK version number and the current SDK version number, wherein the upgrade package includes the update source code after updating at least part of the source code of the current full SDK package, wherein the application client dynamically sends the current SDK version number to the application server based on the current workload, and uses bytecode modification technology to perform hot updates when the application is not started, so as to achieve completely seamless updates; If the application client determines to obtain the upgrade package, the upgrade package is sent to the application client, so that the application client replaces at least part of the source code in the current full SDK package with the updated source code through class loading. Storing the upgrade package in each proxy and providing a download command can effectively share the download traffic. The SDK passes in the version number to initiate the download upgrade package instruction. The proxy determines whether the SDK needs to be updated based on the version number. If necessary, the upgrade package is transmitted to the application server through TCP in the existing format. The SDK in the application server loads the upgrade package into the memory and determines whether the custom class is loaded into the memory through the custom class loader. When loading other dependent classes, it first determines whether there is a framework custom class loader, and then determines whether there is a thread context custom class loader. The dependent classes are loaded into the memory using the class loaders in order of priority.

7. The SDK hot update processing method according to claim 6, characterized in that: The sending of the upgradeable SDK version number to the application client so that the application client determines whether to obtain the upgrade package according to the upgradeable SDK version number and the current SDK version number, wherein the upgrade package includes the update source code after updating at least part of the source code of the current full SDK package, including: Regularly receive the current SDK version number sent by the application client.

8. The SDK hot update processing method according to claim 6, characterized in that: The sending of the upgradeable SDK version number to the application client so that the application client determines whether to obtain the upgrade package according to the upgradeable SDK version number and the current SDK version number, wherein the upgrade package includes the update source code after updating at least part of the source code of the current full SDK package, including: The upgradeable SDK version number is sent to the application client at set intervals, so that the application client determines whether to obtain the upgrade package based on the upgradeable SDK version number and the current SDK version number, and the upgrade package includes the updated source code after updating at least part of the source code of the current full SDK package.

9. The SDK hot update processing method according to claim 6, characterized in that: The determining whether to send an upgrade package to the application client according to the current SDK version number includes: If the current SDK version number is a full version number, the updated version number is determined by the mapping relationship between the SDK version number and the corresponding upgradeable version number; Comparing the update version number with the current SDK version number, if the update version number is greater than the current SDK version number, determining the update version number as an upgradeable version number; If the current SDK version number is a non-full version number, intercept the full format version in the SDK version number, and determine the SDK version number of the upgradeable version through the mapping relationship between the SDK version number and the corresponding upgradeable version number; If the upgradeable version number exists, the storage address of the corresponding binary upgrade package is indexed from a storage table of upgradeable version numbers and binary upgrade packages, and the binary upgrade package obtained by the index is sent to the application client.

10. A method for processing hot update of SDK in a distributed system, characterized in that: include: If the application server cluster uploads an upgrade package with an upgradeable SDK version number, the application client obtains the upgrade package in the application server cluster; The upgrade package includes the updated source code after updating at least part of the source code of the current full SDK package, wherein the application client dynamically sends the current SDK version number to the application server based on the current workload, and uses bytecode modification technology to perform hot update when the application is not started, so as to achieve completely seamless update; The application client replaces at least part of the source code in the current full SDK package with the updated source code through class loading, wherein storing the upgrade package in each proxy and providing a download command can effectively share the download traffic, the sdk passes in the version number to initiate the download upgrade package instruction, the proxy determines whether the SDK needs to be updated based on the version number, and if necessary, transmits the upgrade package to the application server through TCP in the existing format, the SDK in the application server loads the upgrade package into the memory and determines whether to load the custom class into the memory through the custom class loader, and when loading other dependent classes, first determines whether there is a framework custom class loader, and then determines whether there is a thread context custom class loader, and uses the class loader to load the dependent classes into the memory in order of priority.

11. An application client, characterized in that: include: A version number sending module, if the application server cluster uploads an upgrade package with an upgradeable SDK version number, obtains the upgrade package in the application server cluster; The upgrade package includes the updated source code after updating at least part of the source code of the current full SDK package, wherein the application client dynamically sends the current SDK version number to the application server based on the current workload, and uses bytecode modification technology to perform hot update when the application is not started, so as to achieve completely seamless update; The upgrade module replaces at least part of the source code in the current full SDK package with the updated source code through class loading, wherein storing the upgrade package in each proxy and providing a download command can effectively share the download traffic, the sdk passes in the version number to initiate the download upgrade package instruction, the proxy determines whether the SDK needs to be updated based on the version number, and if necessary, transmits the upgrade package to the application server through TCP in the existing format, the SDK in the application server loads the upgrade package into the memory and determines whether the custom class is loaded into the memory through the custom class loader, and when loading other dependent classes, first determines whether there is a framework custom class loader, and then determines whether there is a thread context custom class loader, and uses the class loader to load the dependent classes into the memory in order of priority.

12. The application client according to claim 11, characterized in that: The version number sending module is specifically used to periodically obtain the upgrade package in the application server cluster.

13. The application client according to claim 11, characterized in that: The version number sending module is specifically configured to obtain the upgrade package in the application server cluster at set intervals.

14. The application client according to claim 11, characterized in that: The upgrade module includes: A loader instantiation unit, instantiating the class loader; A parsing unit, parsing the upgrade package to obtain class path information and bytecode information; A loading unit, based on the bytecode information, obtains the class object under the class path information by loading through the class loader; The object instantiation unit instantiates the class object, and then can load the upgrade package by calling the class object.

15. The application client according to claim 14, characterized in that: The object instantiation unit comprises: The reflection call unit uses reflection to call JnosRedisPool.getInstance to obtain an instance of the class object; The instance sending unit sends the instance of the class object to the application through the NosRedisClient interface.

16. An application server cluster, characterized in that: include: A version number receiving module sends an upgradeable SDK version number to an application client, so that the application client determines whether to obtain the upgrade package according to the upgradeable SDK version number and the current SDK version number, wherein the upgrade package includes an update source code after updating at least part of the source code of the current full SDK package, wherein the application client dynamically sends the current SDK version number to the application server based on the current task load, and uses bytecode modification technology to perform hot updates when the application is not started, so as to achieve completely seamless updates; The upgrade package sending module sends the upgrade package to the application client if the application client determines to obtain the upgrade package, so that the application client replaces at least part of the source code in the current full SDK package with the updated source code through class loading. Storing the upgrade package in each proxy and providing a download command can effectively share the download traffic. The SDK passes in the version number to initiate the download upgrade package instruction. The proxy determines whether the SDK needs to be updated based on the version number. If necessary, the upgrade package is sent to the application server through TCP in the existing format. The SDK in the application server loads the upgrade package into the memory and determines whether the custom class is loaded into the memory through the custom class loader. When loading other dependent classes, it first determines whether there is a framework custom class loader, and then determines whether there is a thread context custom class loader. The dependent classes are loaded into the memory using the class loaders in order of priority.

17. The application server cluster according to claim 16, characterized in that: The version number receiving module is specifically used to periodically receive the current SDK version number sent by the application client.

18. The application server cluster according to claim 16, characterized in that: The version number receiving module is specifically used to send an upgradeable SDK version number to the application client at set intervals, so that the application client determines whether to obtain the upgrade package based on the upgradeable SDK version number and the current SDK version number, and the upgrade package includes the updated source code after updating at least part of the source code of the current full SDK package.

19. The application server cluster according to claim 16, characterized in that: The upgrade package sending module includes: An update version number determining unit, if the current SDK version number is a full version number, determines the update version number through a mapping relationship between the SDK version number and a corresponding upgradeable version number; A comparison unit, comparing the update version number with the current SDK version number, and if the update version number is greater than the current SDK version number, determining the update version number as an upgradeable version number; an upgradeable version determining unit, which, if the current SDK version number is a non-full version number, intercepts the full format version in the SDK version number, and determines the SDK version number of the upgradeable version through a mapping relationship between the SDK version number and the corresponding upgradeable version number; The indexing unit, if the upgradeable version number exists, indexes the storage address of the corresponding binary upgrade package from a storage table of upgradeable version numbers and binary upgrade packages, and determines to send the binary upgrade package obtained by the index to the application client.

20. A distributed system SDK hot update processing system, characterized in that: include: Application client and application server cluster; among them, If the application server cluster uploads an upgrade package with an upgradeable SDK version number, the application client obtains the upgrade package in the application server cluster; the upgrade package includes the update source code after updating at least part of the source code of the current full SDK package, wherein the application client dynamically sends the current SDK version number to the application server based on the current workload, and uses bytecode modification technology to perform hot updates when the application is not started, so as to achieve completely seamless updates; The application client replaces at least part of the source code in the current full SDK package with the updated source code through class loading, wherein storing the upgrade package in each proxy and providing a download command can effectively share the download traffic, the sdk passes in the version number to initiate the download upgrade package instruction, the proxy determines whether the SDK needs to be updated based on the version number, and if necessary, transmits the upgrade package to the application server through TCP in the existing format, the SDK in the application server loads the upgrade package into the memory and determines whether to load the custom class into the memory through the custom class loader, and when loading other dependent classes, first determines whether there is a framework custom class loader, and then determines whether there is a thread context custom class loader, and uses the class loader to load the dependent classes into the memory in order of priority.

21. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the distributed SDK hot update processing method according to any one of claims 1 to 10 is implemented.

22. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the distributed SDK hot update processing method described in any one of claims 1 to 10 is implemented.

Images