A version upgrade method and device

Abstract

The present invention relates to the field of financial technology (Fintech), and discloses a version upgrade method and device. When the first version is marked as an upgraded state, the first node stops the first service instance; updates the first functional parameter of the system database to the first local memory; starts the first service instance, and runs the first service instance through the first functional parameter of the first local memory. This solution only performs version upgrades on the first service instance of the first node, rather than performing version upgrades on all service instances on the first node or all service instances of all nodes in the distributed system. The method is flexible and can minimize the risk of version upgrade failure. Each business function is realized by means of functional parameters, rather than relying on running code to realize business functions in the prior art. Therefore, this solution can realize version upgrade by updating functional parameters through the first configuration file, avoiding the complexity of completing upgrades by changing code in the prior art.

Description

Technical Field

[0001] The present invention relates to the field of financial technology (Fintech), and more particularly to a version upgrade method and device. Background Art

[0002] With the development of computer technology, more and more technologies (such as big data, cloud computing, and blockchain) are being applied in the financial sector. Traditional finance is gradually shifting towards FinTech, and big data technology is no exception. However, the security and real-time requirements of the financial and payment industries have also placed higher demands on big data technology.

[0003] Grayscale release, also known as canary release, is a method that allows for a smooth transition between black and white releases. For example, during a software system upgrade, a smooth transition between old features and new features can be achieved.

[0004] Suppose the current version of a software system is version A. After a successful upgrade, the new version is version B. To upgrade version A to version B, a phased release can be used: when upgrading a feature in version A, the system user or the system itself controls some users to continue using version A while others start using version B. After a period of time, if users using version B experience no issues, all users are gradually upgraded to version B.

[0005] Traditional core banking deposit systems are all based on a single-node model using IOE (IBM, Oracle, EMC). Common solutions include:

[0006] Grayscale releases are achieved by preparing a grayscale release environment. This environment is created based on the current online production environment for each release. Each release requires a grayscale release environment to be created in advance based on the production server version number, number of servers running, and each server's request processing capacity (such as request response time and number of requests processed). Production releases must be fully tested in the grayscale release environment before proceeding.

[0007] It can be seen that the above implementation scheme is for a single node, and it is often necessary to first create a grayscale release environment, and then release it to production after the test is passed, which makes the release process complicated. Summary of the Invention

[0008] The present invention provides a version upgrade method and device to solve the problem that the existing technology cannot perform grayscale release during the version upgrade process for a software system with a distributed architecture.

[0009] In a first aspect, an embodiment of the present invention provides a version upgrade method, the method comprising: when the first version is marked as an upgraded state, the first node stops the first service instance on the first node; the first version mark is used to indicate whether the first service instance needs to be upgraded; the first node updates the first functional parameter recorded in the system database to the first local memory of the first service instance; the first functional parameter is the functional parameter after the system database is changed through the first configuration file; the first configuration file is used to upgrade the functional parameters that have a dependent relationship with the service instance; the first node starts the first service instance, and runs the first service instance through the first functional parameter in the first local memory.

[0010] Based on this solution, when it is confirmed that the first service instance is in a state that requires a version upgrade, the first node will stop all services provided by the first service instance to the outside, and update the first functional parameters in the system database to the first local memory of the first service instance. When the first node starts the first service instance, the first service instance can resume providing services to the outside based on the first functional parameters in the first local memory. This solution, by setting up local memory in the service instance, can ensure that only the first service instance on the first node is upgraded first, rather than upgrading all service instances on the first node and all service instances of all nodes in the distributed system. This version upgrade method is more flexible and can minimize the risk of version upgrade failure. In addition, this solution implements various business functions through functional parameters, rather than relying on running code to implement business functions as in the prior art. Therefore, this solution can achieve version upgrades by updating functional parameters through the first configuration file, avoiding the complexity of completing upgrades by changing code in the prior art.

[0011] In a possible implementation method, the first node updates the first function parameter recorded in the system database to the first local memory of the first service instance, including: the first node determines the function parameter tables that need to be updated to the first local memory through the cache definition table; the cache definition table records the attribute information of each function parameter table; the function parameter table records the function parameters of the set function; the first node obtains the function parameter tables from the system database and loads them to the first local memory.

[0012] Based on this solution, the function parameter table that needs to be updated to the local memory is determined by the cache definition table, which can quickly refresh the system database to the local memory, so that the first service instance can provide services externally with the updated function parameter table after restarting.

[0013] In one possible implementation method, running the first service instance through the first function parameter in the first local memory includes: the first service instance determines the first function parameter table corresponding to the service request to be processed in the cache definition table; the first service instance determines to execute the service request through the first function parameter table in the first local memory based on the attribute information of the first function parameter table in the cache definition table.

[0014] Based on this solution, after the first service instance is started, a service request sent by the front end is received, and the cache definition table is determined to have the first function parameter table corresponding to the service request, so that the service request can be responded to through the first function parameter table in the first local memory of the first service instance, which reasonably distinguishes the business of the system database and the local memory, reduces the pressure on the system database, and speeds up the processing of service requests.

[0015] In one possible implementation method, before the first service instance determines the first function parameter table corresponding to the service request to be processed in the cache definition table, it also includes: the interception thread in the first node determines that the service request needs to call the first function parameter table.

[0016] Based on this solution, by setting up an interception thread, a judgment can be made by the interception thread as to whether the pending service request is processed through the local memory of the service instance or through the system database; in addition, the set interception thread can determine the function parameter table used to respond to the pending service request.

[0017] In a possible implementation method, before the first node updates the first function parameter recorded in the system database to the first local memory of the first service instance, it also includes: the polling thread of the first node determines that the function parameter table in the system database has changed.

[0018] Based on this solution, by setting up a polling thread, it is possible to periodically check whether the function parameter table in the first local memory of the first service instance is consistent with the function parameter table in the system database. When it is determined that the two are inconsistent, the polling thread will update the function parameter table in the system database to the first local memory of the first service instance.

[0019] In one possible implementation method, when the second version is marked as non-upgraded, the first node obtains the second functional parameters from the second local memory of the second service instance to run the second service instance; the second version mark is used to indicate whether the second service instance needs to be upgraded; the second functional parameters are the records in the system database before being changed by the first configuration file.

[0020] Based on this solution, when it is confirmed that the second service instance is in a state that does not require version upgrade, the first node only needs to obtain the second function parameter from the second local memory of the second service instance, so that the second service instance can still provide services to the outside normally with the old version of the program. This method ensures that during the version upgrade of the first service instance, since the first node will temporarily stop the first service instance's external service behavior, the scheduling system can transfer the preset user traffic to the first service instance to the second service instance that is still operating normally, allowing the second service instance to provide services to users, thereby ensuring that during the upgrade of the first service instance, the distributed system can still have a normally operating second service instance to provide services to the outside, minimizing the transaction scope and number of users affected by the database change script.

[0021] In a possible implementation method, after running the first service instance, it also includes: after the first service instance fails to run, the first node suspends the first service instance and updates the second functional parameter in the system database to the first local memory; the second functional parameter is a record of restoring the system database to the state before the first functional parameter according to the first rollback configuration file.

[0022] Based on this solution, during the version upgrade of the first service instance, due to certain factors, the first service instance on the first node will not be able to upgrade from the old version of the program to the new version of the program as scheduled and normally, that is, the first service instance will fail to run after the version upgrade. In this regard, the present application only needs to use the data rollback operation to restore the program from the new version to the old version, thereby ensuring that the first service instance whose version cannot be successfully upgraded can still use the old version of the program to provide services to the outside world.

[0023] In a possible implementation method, the first local memory stores the function parameter table in the system database according to a set table structure.

[0024] Based on this solution, by storing the function parameter table in the system database in the first local memory of the first service instance, services can be provided to the outside world based on the local data content of the first service instance; on the other hand, during the version upgrade of the service instance, since the function parameter table in the system database can be stored in the local memory of the service instance, for some service instances that need version upgrades (first service instances), it / they can use the latest function parameter table in the system database to provide services to the outside world; and for some service instances that do not need version upgrades (second service instances), it / they can continue to use the unupdated function parameter table in its own local memory to provide services to the outside world, thereby achieving the purpose of batch upgrading of all service instances on the first node.

[0025] In one possible implementation method, the first node is any one of multiple nodes in a distributed system; the distributed system performs a system upgrade according to set rules, including: each service instance on the first node is upgraded in batches according to a first rule; the first rule is for the upgrade order of the service instances; after the first node is upgraded, the second node is upgraded according to a second rule; the second node is any node in the distributed system except the first node; the second rule is for the upgrade order of the nodes.

[0026] Based on this solution, since a distributed system contains multiple nodes, a test node in the distributed system is first upgraded. If the upgrade of the test node is successful, all other nodes in the distributed system, excluding the test node, can be upgraded. Furthermore, during the upgrade of the test node, the first service instance on it can be upgraded first. This entire process of upgrading a distributed system can minimize the risk of version upgrades and minimize the scope of impact.

[0027] In one possible implementation method, after all service instances are successfully upgraded according to the first configuration file, the first node updates the third functional parameter in the system database to the local memory of each of all service instances; the third functional parameter is set through the second configuration file, and the second configuration file is used to upgrade the functional parameters that have no dependency on the service instance.

[0028] Based on this solution, after all service instances on the first node have achieved version upgrades, the third function parameters in the system database are refreshed to the local memory of all services on the first node again. Then, all service instances on the first node can cooperate better with each other to provide services to the outside world.

[0029] In one possible implementation method, after all service instances of all nodes are successfully upgraded according to the first configuration file and the second configuration file, the first node updates the fourth functional parameter in the system database to the local memory of all service instances; the fourth functional parameter is set through a third configuration file, and the third configuration file is used to upgrade functional parameters that have dependencies on upstream and downstream service instances.

[0030] Based on this solution, after all service instances on each of all nodes in the distributed system are successfully upgraded according to the first configuration file and the second configuration file, the fourth function parameter in the system database is refreshed again to all service instances on each of all nodes, so that all nodes in the distributed system can cooperate with each other better to provide services to the outside world.

[0031] In a second aspect, an embodiment of the present invention provides a version upgrade method, which includes: the publishing end changes the functional parameters in the system database through a first configuration file to obtain the first functional parameters; the publishing end sets the first version mark of the first node to an upgraded state according to a first rule; the first version mark is used to indicate whether the first service instance needs to be upgraded; when the publishing end determines that the upgrade of the first service instance has failed, the publishing end restores the second functional parameters before the first configuration file updates the system database through a first rollback configuration file.

[0032] Based on this solution, the publishing end changes the functional parameters in the system database according to the first configuration file to obtain the first functional parameters; after confirming that the version upgrade of the first service instance has failed, the publishing end modifies the functional parameters in the system database to the functional parameters before the version upgrade according to the first rollback configuration file, and refreshes the first functional parameters in the first local memory of the first service instance to the functional parameters before the version upgrade, thereby ensuring that after the upgrade of the first service instance on the first node fails, the data of the failed version upgrade can be rolled back as soon as possible, so that the first service instance can continue to provide services to the outside world with the old version of the program.

[0033] In one possible implementation method, after determining that all service instances of the first node have been successfully upgraded, the publishing end changes the functional parameters in the system database through a second configuration file to obtain third functional parameters; when determining that the upgrade has failed, the publishing end restores the first functional parameters before the second configuration file updated the system database through a second rollback configuration file.

[0034] Based on this solution, the publishing end modifies the functional parameters in the system database according to the second configuration file to obtain the third functional parameters; when it is confirmed that the degree of cooperation between all service instances on the first node does not meet the preset effect of the second configuration file, the data of all service instances on the first node can be rolled back according to the second rollback configuration file within the first time, so that each service instance on the first node can provide services to the outside world with the first functional parameters.

[0035] In a possible implementation method, after obtaining the third functional parameter, the method further includes: after the publishing end determines that all service instances of all nodes have been successfully upgraded, the publishing end changes the functional parameters in the system database through a third configuration file to obtain a fourth functional parameter; when the publishing end determines that the upgrade has failed, the publishing end restores the third functional parameter to the third configuration file before the system database was updated by the third configuration file through a third rollback configuration file.

[0036] Based on this solution, the publishing end modifies the functional parameters in the system database according to the third configuration file to obtain the fourth functional parameters; when it is confirmed that the degree of cooperation between all service instances on all nodes does not meet the preset effect of the third configuration file, the data of all service instances on all nodes can be rolled back according to the third rollback configuration file within the first time, so that each service instance on all nodes can provide services to the outside world with the second functional parameters.

[0037] In a third aspect, an embodiment of the present invention provides a version upgrade device, which includes: a stop unit, used to stop the first service instance when the first version is marked as an upgraded state; the first version mark is used to indicate whether the first service instance needs to be upgraded; an update unit, used to update the first functional parameter recorded in the system database to the first local memory of the first service instance; the first functional parameter is the functional parameter after the system database is changed through the first configuration file; the first configuration file is used to upgrade the functional parameters that have a dependent relationship with the service instance; a running unit, used to start the first service instance, and run the first service instance through the first functional parameter in the first local memory.

[0038] Based on this solution, when it is confirmed that the first service instance is in a state that requires a version upgrade, the first node will stop all services provided by the first service instance to the outside, and refresh the first functional parameters in the system database to the first local memory of the first service instance. When the first node starts the first service instance, the first service instance can resume providing services to the outside based on the first functional parameters in the first local memory. This solution, by setting up local memory in the service instance, can ensure that only the first service instance on the first node is upgraded first, rather than upgrading all service instances on the first node and all service instances of all nodes in the distributed system. This version upgrade method is more flexible and can minimize the risk of version upgrade failure. In addition, this solution implements various business functions through functional parameters, rather than relying on running code to implement business functions as in the prior art. Therefore, this solution can achieve version upgrades by updating functional parameters through the first configuration file, avoiding the complexity of completing upgrades by changing code in the prior art.

[0039] In a possible implementation method, the update unit is specifically used to: determine the function parameter tables that need to be updated to the first local memory through a cache definition table; the cache definition table records the attribute information of each function parameter table; the function parameter table records the function parameters of the set function; obtain the function parameter tables from the system database and load them into the first local memory.

[0040] Based on this solution, the function parameter table that needs to be updated to the local memory is determined by the cache definition table, which can quickly refresh the system database to the local memory, so that the first service instance can provide services externally with the updated function parameter table after restarting.

[0041] In one possible implementation method, the running unit is specifically used to: the first service instance determines the first function parameter table corresponding to the service request to be processed in the cache definition table; the first service instance determines to execute the service request through the first function parameter table in the first local memory based on the attribute information of the first function parameter table in the cache definition table.

[0042] Based on this solution, after the first service instance is started, a service request sent by the front end is received, and the cache definition table is determined to have the first function parameter table corresponding to the service request, so that the service request can be responded to through the first function parameter table in the first local memory of the first service instance, which reasonably distinguishes the business of the system database and the local memory, reduces the pressure on the system database, and speeds up the processing of service requests.

[0043] In a possible implementation method, the running unit is specifically configured to: determine, by intercepting a thread, that the service request needs to call the first function parameter table.

[0044] Based on this solution, by setting up an interception thread, a judgment can be made by the interception thread as to whether the pending service request is processed through the local memory of the service instance or through the system database; in addition, the set interception thread can determine the function parameter table used to respond to the pending service request.

[0045] In a possible implementation method, the updating unit is further configured to: determine, through a polling thread, whether a function parameter table in the system database has been changed.

[0046] Based on this solution, by setting up a polling thread, it is possible to periodically check whether the function parameter table in the first local memory of the first service instance is consistent with the function parameter table in the system database. When it is determined that the two are inconsistent, the polling thread will update the function parameter table in the system database to the first local memory of the first service instance.

[0047] In a possible implementation method, the running unit is also used to: when the second version is marked as non-upgraded, obtain the second function parameter from the second local memory of the second service instance to run the second service instance; the second version mark is used to indicate whether the second service instance needs to be upgraded; the second function parameter is the record in the system database before it is changed by the first configuration file.

[0048] Based on this solution, when it is confirmed that the second service instance is in a state that does not require version upgrade, the first node only needs to obtain the second function parameter from the second local memory of the second service instance, so that the second service instance can still provide services to the outside normally with the old version of the program. This method ensures that during the version upgrade of the first service instance, since the first node will temporarily stop the first service instance's external service behavior, the scheduling system can transfer the preset user traffic to the first service instance to the second service instance that is still operating normally, allowing the second service instance to provide services to users, thereby ensuring that during the upgrade of the first service instance, the distributed system can still have a normally operating second service instance to provide services to the outside, minimizing the transaction scope and number of users affected by the database change script.

[0049] In a possible implementation method, the running unit is also used to: after the first service instance fails to run, suspend the first service instance and update the second functional parameter in the system database to the first local memory; the second functional parameter is a record of restoring the system database to the state before the first functional parameter according to the first rollback configuration file.

[0050] Based on this solution, during the version upgrade of the first service instance, due to certain factors, the first service instance on the first node will not be able to upgrade from the old version of the program to the new version of the program as scheduled and normally, that is, the first service instance will fail to run after the version upgrade. In this regard, the present application only needs to use the data rollback operation to restore the program from the new version to the old version, thereby ensuring that the first service instance whose version cannot be successfully upgraded can still use the old version of the program to provide services to the outside world.

[0051] In a possible implementation method, the first local memory stores the function parameter table in the system database according to a set table structure.

[0052] Based on this solution, by storing the function parameter table in the system database in the first local memory of the first service instance, services can be provided to the outside world based on the local data content of the first service instance; on the other hand, during the version upgrade of the service instance, since the function parameter table in the system database can be stored in the local memory of the service instance, for some service instances that need version upgrades (first service instances), it / they can use the latest function parameter table in the system database to provide services to the outside world; and for some service instances that do not need version upgrades (second service instances), it / they can continue to use the unupdated function parameter table in its own local memory to provide services to the outside world, thereby achieving the purpose of batch upgrading of all service instances on the first node.

[0053] In one possible implementation method, the first node is any one of multiple nodes in a distributed system; the running unit is specifically used to: batch upgrade each service instance according to a first rule; the first rule is for the upgrade order of service instances; upgrade the second node according to a second rule; the second node is any node in the distributed system except the first node; the second rule is for the upgrade order of nodes.

[0054] Based on this solution, since a distributed system contains multiple nodes, a test node in the distributed system is first upgraded. If the upgrade of the test node is successful, all other nodes in the distributed system, excluding the test node, can be upgraded. Furthermore, during the upgrade of the test node, the first service instance on it can be upgraded first. This entire process of upgrading a distributed system can minimize the risk of version upgrades and minimize the scope of impact.

[0055] In a possible implementation method, the update unit is also used to: after all service instances are successfully upgraded according to the first configuration file, update the third functional parameters in the system database to the local memory of each of all service instances; the third functional parameters are set through the second configuration file, and the second configuration file is used to upgrade functional parameters that have no dependency on the service instances.

[0056] Based on this solution, after all service instances on the first node have achieved version upgrades, the third function parameters in the system database are refreshed to the local memory of all services on the first node again. Then, all service instances on the first node can cooperate better with each other to provide services to the outside world.

[0057] In one possible implementation method, the update unit is also used to: after all service instances of all nodes are successfully upgraded according to the first configuration file and the second configuration file, update the fourth functional parameter in the system database to the local memory of all service instances; the fourth functional parameter is set through a third configuration file, and the third configuration file is used to upgrade functional parameters that have dependencies on upstream and downstream service instances.

[0058] Based on this solution, after all service instances on each of all nodes in the distributed system are successfully upgraded according to the first configuration file and the second configuration file, the fourth function parameter in the system database is refreshed again to all service instances on each of all nodes, so that all nodes in the distributed system can cooperate with each other better to provide services to the outside world.

[0059] In a fourth aspect, an embodiment of the present invention provides a version upgrade device, which includes: a function parameter generation unit, used to change the function parameters in the system database through a first configuration file to obtain a first function parameter; an upgrade state setting unit, used to set the first version mark of the first node to an upgraded state according to a first rule; the first version mark is used to indicate whether the first service instance needs to be upgraded; a function parameter recovery unit, used to restore the second function parameters before the first configuration file updates the system database through a first rollback configuration file when it is determined that the upgrade of the first service instance has failed.

[0060] Based on this solution, the publishing end changes the functional parameters in the system database according to the first configuration file to obtain the first functional parameters; after confirming that the version upgrade of the first service instance has failed, the publishing end modifies the functional parameters in the system database to the functional parameters before the version upgrade according to the first rollback configuration file, and refreshes the first functional parameters in the first local memory of the first service instance to the functional parameters before the version upgrade, thereby ensuring that after the upgrade of the first service instance on the first node fails, the data of the failed version upgrade can be rolled back as soon as possible, so that the first service instance can continue to provide services to the outside world with the old version of the program.

[0061] In one possible implementation method, the function parameter generation unit is further used to: after determining that all service instances of the first node have been successfully upgraded, change the function parameters in the system database through a second configuration file to obtain third function parameters; the function parameter recovery unit is further used to: when determining that the upgrade has failed, restore the first function parameters before the system database was updated by the second configuration file through a second rollback configuration file.

[0062] Based on this solution, the publishing end modifies the functional parameters in the system database according to the second configuration file to obtain the third functional parameters; when it is confirmed that the degree of cooperation between all service instances on the first node does not meet the preset effect of the second configuration file, the data of all service instances on the first node can be rolled back according to the second rollback configuration file within the first time, so that each service instance on the first node can provide services to the outside world with the first functional parameters.

[0063] In one possible implementation method, the function parameter generation unit is further used to: after determining that all service instances of all nodes have been successfully upgraded, change the function parameters in the system database through a third configuration file to obtain fourth function parameters; the function parameter recovery unit is further used to: when determining that the upgrade has failed, restore the third function parameters before the system database was updated by the third configuration file through a third rollback configuration file.

[0064] Based on this solution, the publishing end modifies the functional parameters in the system database according to the third configuration file to obtain the fourth functional parameters; when it is confirmed that the degree of cooperation between all service instances on all nodes does not meet the preset effect of the third configuration file, the data of all service instances on all nodes can be rolled back according to the third rollback configuration file within the first time, so that each service instance on all nodes can provide services to the outside world with the third functional parameters.

[0065] In a fifth aspect, an embodiment of the present invention provides a computing device, including:

[0066] a memory for storing program instructions;

[0067] The processor is used to call the program instructions stored in the memory and execute the method as described in any one of the first aspect and the second aspect according to the obtained program.

[0068] In a sixth aspect, an embodiment of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the method described in any one of the first and second aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0070] Figure 1 A schematic diagram of the architecture of a distributed system provided by an embodiment of the present invention;

[0071] Figure 2 A version upgrade method provided by an embodiment of the present invention;

[0072] Figure 3 Another version upgrade method provided by an embodiment of the present invention;

[0073] Figure 4 Provided is a bank's back-end distributed architecture for an embodiment of the present invention;

[0074] Figure 5 This is an existing solution for grayscale release of service instances.

[0075] Figure 6 A schematic diagram of the release process of a normal version (with ample time to go online) provided in an embodiment of the present invention;

[0076] Figure 7 A schematic diagram of the release process of an emergency version (urgent release time) provided in an embodiment of the invention;

[0077] Figure 8 A version upgrade device provided by an embodiment of the present invention;

[0078] Figure 9 Another version upgrade device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0079] To make the objectives, technical solutions, and advantages of the present invention more apparent, the present invention will be further described in detail below with reference to the accompanying drawings. It is apparent that the embodiments described are only some, not all, of the present invention. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without creative effort are intended to fall within the scope of protection of the present invention.

[0080] like Figure 1 , which is a schematic diagram of the architecture of a distributed system provided by an embodiment of the present invention. For example, the architecture can be used to deploy a distributed deposit core system.

[0081] Among them, the distributed system includes multiple DCNs (Data Center Nodes), each DCN has its own DB (Database System), and the structures and parameters of the DBs on these DCNs are basically the same. By setting a function parameter table in the DB and then combining it with the general code, the purpose of processing the service request to be processed can be achieved. Compared with the existing technology, when the system version is upgraded, it is not only required to modify the database table in the DB, but also required to synchronize the running code when providing services to the outside world based on the database table. Then, it is necessary to redeploy and restart the system to enable this version upgrade. In the embodiment of the present invention, by using a combination of a function parameter table and a general code, when the system version is upgraded, it is only necessary to modify the function parameter table in the DB. The modification content includes addition, deletion, modification, etc., and there is no need to modify the general code or restart the system.

[0082] For any DCN, it includes multiple service instances.

[0083] For each service instance, it has its own local memory, as illustrated by the Java virtual machine level cache in the embodiment of the present invention. The Java virtual machine level cache of each service instance stores part or all of the function parameter tables in the database DB connected to the DCN where the service instance is located. Therefore, theoretically speaking, based on the premise of the same version, each service instance on the same DCN can provide the same functions to the outside world, that is, under the premise of resources allowing, each service instance can provide all the functions above it to the outside world; but from a practical point of view, what specific functions each service instance provides to the outside world also needs to follow the scheduling of its functions by the scheduling system, that is, when each service instance actually provides services to the outside world, it may often use some of the functions among all the functions.

[0084] based on Figure 1 The architectural diagram shown in Figure 2 As shown, a version upgrade method provided by an embodiment of the present invention includes the following steps:

[0085] Step 201: When a first version mark on a first node indicates an upgraded state, the first service instance on the first node is stopped; the first version mark is used to indicate whether the first service instance needs to be upgraded;

[0086] Step 202: The first node updates the first functional parameter recorded in the system database to the first local memory of the first service instance; the first functional parameter is the functional parameter after the system database is modified using the first configuration file; the first configuration file is used to update the functional parameter that has a dependency on the service instance;

[0087] Step 203: The first node starts the first service instance and runs the first service instance using the first functional parameters in the first local memory.

[0088] Based on this solution, when it is confirmed that the first service instance is in a state that requires a version upgrade, the first node will stop all services provided by the first service instance to the outside, and update the first functional parameters in the system database to the first local memory of the first service instance. When the first node starts the first service instance, the first service instance can resume providing services to the outside based on the first functional parameters in the first local memory. This solution, by setting up local memory in the service instance, can ensure that only the first service instance on the first node is upgraded first, rather than upgrading all service instances on the first node and all service instances of all nodes in the distributed system. This version upgrade method is more flexible and can minimize the risk of version upgrade failure. In addition, this solution implements various business functions through functional parameters, rather than relying on running code to implement business functions as in the prior art. Therefore, this solution can achieve version upgrades by updating functional parameters through the first configuration file, avoiding the complexity of completing upgrades by changing code in the prior art.

[0089] In the above step 201, combined with Figure 1 In the architecture, the first node may be any DCN in the distributed deposit core system. As an example, in the embodiment of the present invention, DCN1 is the first node.

[0090] refer to Figure 1 There are N service instances on DCN1. The value of N can be set according to actual needs. As an example, in the embodiment of the present invention, the value of N is 4, that is, there are 4 service instances on DCN1, and they are numbered 1, 2, 3 and 4 respectively.

[0091] The first service instance in step 201 can be any service instance on DCN1 or some service instances on DCN1, which is not limited in the present invention. As an example, the first service instance in the present invention is described as service instance 1.

[0092] When DCN1 detects that the first version of service instance 1 is marked as upgraded, it means that during this version upgrade process, the service instance 1 running on DCN1 in the distributed deposit core system will be upgraded first. In this case, DCN1 will stop service instance 1 from providing services to the outside world.

[0093] Assume that this version upgrade involves changes to some functional parameters. These changes are recorded in a first configuration file. In an embodiment of the present invention, the first configuration file can be recorded as BeforeSQL. By deploying the BeforeSQL script, in the database DB1 connected to DCN1, the original functional parameters have been iterated with the first functional parameters. The first functional parameters are the functional parameters in DB1 after being modified by the BeforeSQL script.

[0094] Therefore, in the above step 202, DCN1 updates the first functional parameters recorded in DB1 to which it is connected to the Java virtual machine level cache of service instance 1, so that after service instance 1 is reactivated, it can provide services to the outside world with the latest functional parameters, that is, the first functional parameters.

[0095] In the above step 203, DCN1 activates the service instance 1, so that the service instance 1 can provide services externally with the first functional parameters.

[0096] For example, if a new feature is added to the functionality of the previous version during the version upgrade, this new feature will be recorded in the BeforeSQL script. By deploying the BeforeSQL script in DB1 connected to DCN1 and if the script runs normally, the new feature will be added to DB1 connected to DCN1. Specifically, the number of function parameter tables in DB1 will be increased by 1. Next, DCN1 will execute an external service stop operation on service instance 1 and update some or all function parameters in DB1 connected to it to the Java virtual machine-level cache of service instance 1. After service instance 1 is reactivated by DCN1, service instance 1 can not only provide the existing functionality of the old version, but also the new functionality added by the version upgrade. This embodiment uses the JVM (Java Virtual Machine) as an example. The specific implementation method of local memory is set according to the specific application environment.

[0097] Optionally, the first node updates the first function parameter recorded in the system database to the first local memory of the first service instance, including: the first node determines the function parameter tables that need to be updated to the first local memory through the cache definition table; the cache definition table records the attribute information of each function parameter table; the function parameter table records each function parameter of the set function; the first node obtains the function parameter table from the system database and loads it to the first local memory.

[0098] Optionally, the first local memory stores all function parameter tables in the system database according to a set table structure.

[0099] As mentioned above, in the distributed deposit core system composed of multiple DCNs, assume that for DCN1, the DB1 to which it is connected stores 101 tables, 100 of which need to be configured as function parameter tables; and one of which does not need to be configured as a function parameter table.

[0100] For example, a table in DB1 is named "dp_limit_rule," and its Chinese name is "Limit Rule Definition." Its functional parameters can be found in Table 1:

[0101] Table 1

[0102]

[0103] Similarly, for tables in DB1 other than the table named "dp_limit_rule" and tables that do not need to be configured as function parameter tables, their respective function parameters can be set according to actual needs.

[0104] In an embodiment of the present invention, when the service instance is initialized and started, the cache definition table needs to be loaded into the JVM memory, and the function parameter table corresponding to the cache definition table needs to be loaded into the JVM local cache data area, so that subsequent data can be read directly from the JVM local cache data area without reading from the database.

[0105] During implementation, the system first reads a preset cache definition table. This table contains attribute information based on the function parameter tables configured in the database. These attributes may include the name of the function parameter table to be cached, its Chinese description, cache level, pre-execution processing flag, change log registration flag, parameter check flag, and parameter processing flag. The attribute information in the cache definition table can be customized based on actual operational needs.

[0106] Specifically, the structure of the cache definition table ksys_tabctl is shown in Table 2:

[0107] Table 2

[0108] Column Name type Can it be empty? primary key Remark biaoming varchar(30) NO PRI The name of the function parameter table that needs to be cached biaozwmc varchar(500) YES Chinese description of the table huancjib varchar(20) YES Cache Level qianclbz varchar(1) YES Pre-execution processing flag denjbgrz varchar(1) YES Register change log flag jiancshu varchar(1) YES Check parameter flags chulcshu varchar(1) YES Processing parameter flags

[0109] For example, for the aforementioned function parameter table "dp_limit_rule", its configuration in the cache definition table is as follows:

[0110] biaoming: dp_limit_rule

[0111] biaozwmc: Quota rule definition

[0112] huancjib: global

[0113] qianclbz: 1

[0114] denjbgrz: 0

[0115] jiancshu: 1

[0116] chulcshu: 1

[0117] Similarly, for tables in DB1 other than the table named "dp_limit_rule" and tables that do not need to be configured as function parameter tables, when they are configured as Java virtual machine-level cache, the configuration performed can refer to the process of the function parameter table named "dp_limit_rule".

[0118] The following is a specific example to illustrate how to cache the function parameter table in the database in the local cache data area of the service instance JVM.

[0119] First, when service instance 1 is initialized and started, it compiles all corresponding records in ksys_tabctl in DB1 into a linked list. Then, for each record in the linked list, it uses the table name as the key and the ksys_tabctl domain object as the value to construct a cache definition hash table, CacheDefMap, and saves it in the Java virtual machine-level cache of service instance 1. Table 3 shows a cache definition hash table, CacheDefMap, provided by an embodiment of the present invention.

[0120] Table 3

[0121] Key Value Name1 ksys_tabctl1 Name2 ksys_tabctl2 Name3 ksys_tabctl3 …… …… Name100 ksys_tabctl100

[0122] Then, by iterating the records in the linked list, the records with huancjib (cache level) of global and qianclbz (pre-execution processing flag) of 1 are processed, that is, the corresponding function parameter table is obtained from DB1 according to the table name in the record, and the table name of the function parameter table, the primary key PRI in the table, and the domain object of the function parameter table are combined into a cache data hash table GlobalCacheMap. The cache data hash table GlobalCacheMap is a hash table with a two-level hash structure. Its key is the table name of the function parameter table in DB1, and its value is represented by another cache hash table. Among them, the key is the primary key PRI in the table, such as the primary key PRI can be any of the six fields in Table 1, which can be specifically set by the staff, so that the selected field constitutes the key; the value is the domain object of the function parameter table, such as the other parts of the field in Table 1 excluding the primary key PRI constitute the value, and the cache data hash table GlobalCacheMap is saved in the Java virtual machine level cache of service instance 1.

[0123] Therefore, when the same operation as service instance 1 is performed on service instance 2, service instance 3 and service instance 4, the content stored in the Java virtual machine level cache of service instance 2, service instance 3 and service instance 4 is the same as that of service instance 1.

[0124] Optionally, running the first service instance through the first function parameter in the first local memory includes: the first service instance determines the first function parameter table corresponding to the service request to be processed in the cache definition table; the first service instance determines to execute the service request through the first function parameter table in the first local memory based on the attribute information of the first function parameter table in the cache definition table.

[0125] After service instance 1 is restarted and receives a service request from the frontend, it checks the cache definition hash table CacheDefMap in service instance 1's Java virtual machine-level cache based on the parameters in the service request to see if there is a corresponding key. If so, it checks the attribute information in the value object corresponding to the key—the ksys_tabctl domain object. Based on this attribute information, it determines whether the service request needs to be executed through the function parameter table in local memory. Specifically, if the processing parameter flag is 1, it indicates that the service request will be processed through service instance 1's Java virtual machine-level cache. The specific value of the processing parameter flag can be set according to the actual application. At the same time, you can also check the registration change log flag and the check parameter flag. If the registration change log flag is 1, the service request is recorded. If it is null or 0, there is no need to record the service request. If the check parameter flag is 1, the input parameters are checked for correctness. If the check parameter flag is null or 0, there is no need to check the input parameters and the parameter processing phase proceeds directly.

[0126] Specifically, the above process can determine that the service request needs to call the first function parameter table through the interception thread in the first node, specifically: the interception thread determines whether there is a set flag on the method corresponding to the service request, that is, a set flag is added to the code that executes the service request, which is used to indicate that it is necessary to jump to the cache definition table to determine whether it is necessary to obtain the function parameter table for executing the method. When the processing parameter flag is 1, it means that it is processed through the Java virtual machine level cache of service instance 1. Specifically, it checks the cache data hash table GlobalCacheMap according to the table name in the record to determine whether there is a corresponding key. If so, the value corresponding to the key is used to obtain the domain object of the corresponding function parameter table and return it to the position of the set flag, thereby continuing to execute the method corresponding to the service request.

[0127] Optionally, before the first node updates the first function parameter recorded in the system database to the first local memory of the first service instance, the process further includes: the polling thread of the first node determines that a function parameter table in the system database has changed.

[0128] When service instance 1 is started, the polling thread on the service instance is immediately started, and the polling thread reads the value of the cache counter in DB1; when the polling thread finds that the cache counter has changed, the polling thread refreshes the function parameter table in DB1 to the Java virtual machine level cache of service instance 1.

[0129] Optionally, when the second version is marked as non-upgraded, the first node obtains the second functional parameters from the second local memory of the second service instance to run the second service instance; the second version mark is used to indicate whether the second service instance needs to be upgraded; the second functional parameters are the records in the system database before being changed by the first configuration file.

[0130] As in the aforementioned example, after service instance 1 on DCN1 is defined as the first service instance, other service instances on DCN1, excluding service instance 1, can be defined as second service instances. For example, in this embodiment of the present invention, service instances 2, 3, and 4 are all second service instances. When DCN1 confirms that the version of the second service instance is marked as non-upgraded, that is, the version upgrade on DCN1 currently only involves service instance 1, but not service instances 2, 3, and 4, DCN1 will not stop services for service instances 2, 3, and 4. At the same time, the Java virtual machine-level caches of service instances 2, 3, and 4 still store the function parameters corresponding to the old version of the application, that is, the second function parameters. Therefore, DCN1 will obtain the second function parameters from the Java virtual machine-level caches of service instances 2, 3, and 4, allowing these service instances to continue to provide external services.

[0131] Optionally, after the first service instance fails to run, the first node suspends the first service instance and updates the second functional parameter in the system database to the first local memory; the second functional parameter is a record of restoring the system database to the state before the first functional parameter according to the first rollback configuration file.

[0132] During a version upgrade, various factors can easily lead to version upgrade failures. For example, when deploying a BeforeSQL script in the database corresponding to DCN1, an error in the script prevents the generation of a database table corresponding to a new functional parameter, indicating an abnormality in the version upgrade. This issue is addressed in an embodiment of the present invention by using a first rollback configuration file. In this embodiment, the first rollback configuration file can be named BeforeRollbackSQL. By deploying the BeforeRollbackSQL script, the database tables in the database corresponding to DCN1 can be quickly restored to their original state from the previous version.

[0133] Furthermore, it is assumed that the BeforeSQL script can be successfully deployed in the database corresponding to DCN1. After DCN1 refreshes the first function parameter in the database to the local memory of service instance 1 and re-enables service instance 1, it is found that when a user makes a request for a new function, service instance 1 cannot respond to the request, which indicates that the version upgrade of service instance 1 has not been successfully achieved. For this result, the embodiment of the present invention provides a method for solving it through the first rollback configuration file. By deploying the BeforeRollbackSQL script, the database table in the database corresponding to DCN1 can be quickly restored to the database table of the original old version. DCN1 refreshes the database table of the old version in the database to the local memory of service instance 1 again. After service instance 1 is re-enabled, it can continue to provide external services with the old version of the function.

[0134] Optionally, the first node is any one of multiple nodes in a distributed system; the distributed system performs a system upgrade according to set rules, including: each service instance on the first node is upgraded in batches according to a first rule; the first rule is for the upgrade order of service instances; after the first node is upgraded, the second node is upgraded according to a second rule; the second node is any node in the distributed system except the first node; the second rule is for the upgrade order of nodes.

[0135] In the previous example, the version upgrade of service instance 1 on DCN1 in the distributed system has been implemented. That is, service instance 1 is upgraded first, and then the other service instances except service instance 1 can be upgraded in sequence. The specific upgrade process can be referred to as service instance 1. In this embodiment of the present invention, a portion of service instances on DCN1 (such as service instance 1) is upgraded first. After confirming that the upgraded version of these service instances is effective, the remaining service instances (service instance 2, service instance 3, and service instance 4) are upgraded. This belongs to the first rule (for service instances).

[0136] After all service instances on DCN1 are upgraded and the effects of the upgrade of all service instances are confirmed to be good, the version upgrade operation of DCN1 is performed on all other DCNs in the distributed system except DCN1. This belongs to the second rule (for nodes).

[0137] Optionally, after all service instances are successfully upgraded according to the first configuration file, the first node updates the third functional parameters in the system database to the local memory of all service instances; the third functional parameters are set through the second configuration file, and the second configuration file is used to upgrade functional parameters that have no dependency on service instances.

[0138] In the aforementioned example, referring to the method steps for performing a version upgrade on service instance 1, when the same version upgrade operation is performed on other service instances on DCN1 except service instance 1, and it is confirmed that each service instance on DCN1 can provide services externally with the first functional parameters, DCN1 deploys a second configuration file in the database, where the second configuration file is recorded as AfterSQL in the embodiment of the present invention. By deploying the AfterSQL script, some database tables in the database are changed, thereby iterating the first functional parameters in the database table to third functional parameters. Finally, DCN1 refreshes the third functional parameters to the Java virtual machine-level cache of all service instances on DCN1, so that each service instance on DCN1 can provide services externally with the third functional parameters.

[0139] Optionally, after all service instances of all nodes are successfully upgraded according to the first configuration file and the second configuration file, the first node updates the fourth functional parameter in the system database to the local memory of all service instances; the fourth functional parameter is set through the third configuration file, and the third configuration file is used to upgrade functional parameters that have dependencies on upstream and downstream service instances.

[0140] In the aforementioned example, after each service instance on DCN1 can provide services to the outside with the third functional parameters, referring to the operation of performing a version upgrade on all service instances on DCN1, the version upgrade operation on DCN1 can be performed on other nodes in the distributed deposit core system except DCN1, and after each service instance in each node in the distributed system can provide services to the outside with the third functional parameters, a third configuration file is deployed in the databases connected to all nodes including DCN1, wherein the third configuration file is recorded as GlobalAfterSQL in the embodiment of the present invention. By deploying the GlobalAfterSQL script, some database tables in the database are modified, thereby iterating the third functional parameters in the database tables to fourth functional parameters. Finally, each node refreshes the fourth functional parameters to the Java virtual machine-level cache of all service instances on the respective nodes, so that each service instance on DCN1 can provide services to the outside with the fourth functional parameters.

[0141] It should be noted that when modifying the functional parameters of a database table, it includes modifying the database table structure and modifying the database table data. Specifically,

[0142] For BeforeSQL scripts, there are BeforeScriptSQL configuration files for DDL (Data Definition Language) and BeforeDataSQL configuration files for DML (Data Manipulation Language).

[0143] For AfterSQL scripts, there is the AfterScriptSQL configuration file for DDL and the AfterDataSQL configuration file for DML;

[0144] For GlobalAfterSQL scripts, there is the GlobalAfterScriptSQL profile for DDL and the GlobalAfterDataSQL profile for DML.

[0145] like Figure 3 As shown, another version upgrade method provided by an embodiment of the present invention includes the following steps:

[0146] Step 301: The publishing end modifies the function parameters in the system database through the first configuration file to obtain the first function parameters;

[0147] Step 302: The publisher sets the first version flag of the first node to an upgraded state according to the first rule; the first version flag is used to indicate whether the first service instance needs to be upgraded;

[0148] Step 303: When the publishing end determines that the upgrade of the first service instance fails, the publishing end uses the first rollback configuration file to restore the second functional parameters before the first configuration file updates the system database.

[0149] Based on this solution, the publishing end changes the functional parameters in the system database according to the first configuration file to obtain the first functional parameters; after confirming that the version upgrade of the first service instance has failed, the publishing end modifies the functional parameters in the system database to the functional parameters before the version upgrade according to the first rollback configuration file, and refreshes the first functional parameters in the first local virtual machine memory of the first service instance to the functional parameters before the version upgrade, thereby ensuring that after the upgrade of the first service instance on the first node fails, the data of the failed version upgrade can be rolled back as soon as possible, so that the first service instance can continue to provide services to the outside world with the old version of the program.

[0150] refer to Figure 1 In step 301, the publisher modifies the function parameters in the DCN1 database based on the BeforeSQL script. For example, if the version upgrade involves a new function, the BeforeSQL script will contain detailed information about this new function. The publisher then deploys the BeforeSQL script to the database. After confirming that the BeforeSQL script has successfully taken effect in the database, the table number of the function parameter table in the database will increase by 1.

[0151] In step 302, after the publisher modifies the function parameters in the database corresponding to DCN1 and obtains the first function parameters, it then updates the service instances on DCN1 according to the batch update rules. Before the update, the publisher identifies the first service instance to be updated as the first service instance and sets the version flag of the first service instance to the upgraded state. For example, if the publisher identifies service instance 1 on DCN1 as the first service instance, the publisher sets the version flag of service instance 1 to the upgraded state.

[0152] In step 303, when DCN1 activates the upgraded service instance 1 and intends to enable it to provide external services with the latest version of the application, but when a user issues a request corresponding to the above-mentioned new function, the service instance 1 cannot respond to the request, the publisher can determine that the version upgrade result of the service instance is an upgrade failure. At this time, the publisher deploys the BeforeRollbackSQL script to restore the function parameters in the database corresponding to DCN1 to the function parameters originally existing in the database before the BeforeSQL script was deployed, that is, the second function parameters.

[0153] Optionally, after determining that all service instances of the first node have been successfully upgraded, the publishing end changes the functional parameters in the system database through the second configuration file to obtain third functional parameters; when determining that the upgrade has failed, the publishing end restores the first functional parameters before the second configuration file updated the system database through the second rollback configuration file.

[0154] Assume that all service instances on DCN1 can provide services with the first function parameter after the version upgrade. The publisher then uses the AfterSQL script to modify the first function parameter in the DCN1 database. For example, if this involves deleting an existing old function, the AfterSQL script will contain detailed information on how to delete the old function. The publisher then deploys the AfterSQL script to the database. After the AfterSQL script is confirmed to have successfully taken effect in the database, the number of function parameter tables in the database remains the same as the initial number.

[0155] After the AfterSQL script successfully takes effect in the database, DCN1 refreshes the third function parameter to the local virtual machine memory of each service instance. If any service instance on DCN1 can still provide the deleted old function when providing external services, the publisher can determine that an exception occurred during the deployment of the AfterSQL script. In this case, the publisher deploys the AfterRollbackSQL script to restore the function parameters in the database connected to DCN1 to the original function parameters in the database before the AfterSQL script was deployed, that is, the first function parameters.

[0156] Optionally, after obtaining the third functional parameter, the publishing end changes the functional parameter in the system database through the third configuration file to obtain the fourth functional parameter after determining that all service instances of all nodes have been successfully upgraded; when the publishing end determines that the upgrade has failed, the publishing end restores the third functional parameter before the system database was updated by the third configuration file through the third rollback configuration file.

[0157] Because DCN1 is in a distributed system environment, the same operations as those executed on DCN1, before and after SQL scripts, are performed on other nodes in the distributed system, excluding DCN1. Furthermore, functional coordination between multiple nodes in the distributed system (including different service instances on the same node and different service instances on different nodes) is also required. In this embodiment of the present invention, the GlobalAfterSQL script is deployed to modify the third functional parameter in the database corresponding to each node in the distributed system, obtaining the modified fourth functional parameter. Consequently, when each node refreshes the fourth functional parameter in the database into the local memory of each service instance, the distributed system can better coordinate between different service instances when providing external services.

[0158] When the coordination effect between different service instances fails to achieve the preset coordination effect, there is reason to believe that an exception has occurred in the GlobalAfterSQL script deployed this time. Therefore, the publisher restores the functional parameters in the database to the third functional parameters by deploying the GlobalAfterRollbackSQL script.

[0159] Next, the solution of the present invention will be described in a specific example.

[0160] like Figure 4 The figure shows a distributed backend architecture for a bank, according to an embodiment of the present invention. This architecture is divided into multiple data nodes, such as DCN1, DCN2, ..., DCNn, and a special logical node, ADM, based on different logical areas. Each node, whether DCN or ADM, deploys multiple service instances. These different service instances can share the same database based on actual needs. This allows each node to function as an independent unit and provide external services.

[0161] The core deposit system is divided into six subsystems based on different functional modules: the online transaction subsystem, the batch transaction subsystem, the ADM online transaction subsystem, the ADM batch transaction subsystem, the small general ledger subsystem, and the console subsystem. The ADM online transaction subsystem and the ADM batch transaction subsystem are deployed on the ADM, while the other subsystems are deployed on various DCNs. On the DCN, the online transaction subsystem and the batch transaction subsystem share the same database. On the ADM, the ADM online transaction subsystem and the ADM batch transaction subsystem share the same database, while the small general ledger subsystem and the console subsystem share the same database. All databases share a similar database structure and parameters.

[0162] like Figure 5 As shown in the figure, a conventional solution for grayscale release of service instances can be summarized into the following four steps:

[0163] 1. Stop all service instances on the entire host node, that is, stop providing services to the outside world;

[0164] 2. Modify the table structure or table data of the database associated with the functional modules in this grayscale release;

[0165] 3. Change the version of all service instances on the host node and update the new code module;

[0166] 4. Start all service instances on the host node, that is, provide services to the outside world again.

[0167] The grayscale release solution proposed in this embodiment of the present invention uses one node, DCN1, as an example to describe the grayscale release process in a distributed environment. Specifically, it is divided into the following eight steps according to the timeline:

[0168] 1. Deploy the BeforeSQL script to change the database table structure involved in this version.

[0169] It does the following:

[0170] a) On the one hand, it corresponds to the relevant functions of the service instances to be deployed soon, which rely on the early changes of these databases;

[0171] b) On the other hand, data changes for existing functions can be performed in BeforeSQL first to enable timely detection of anomalies, avoiding large-scale rollbacks caused by anomalies after subsequent application deployment, thus advancing the release time and minimizing the impact of anomalies on transactions.

[0172] 2. If an exception occurs in the system in the previous step, use BeforeRollbackSQL to quickly roll back the published data changes. This ensures that even if an exception occurs, the application will not be affected.

[0173] 3. Update the versions of service instances on DCN1 in batches.

[0174] 4. If the system fails due to a version change in the previous step, suspend the service of the changed instance, roll back the service instance, and use BeforeRollbackSQL to roll back the published data changes.

[0175] 5. Deploy the AfterSQL script. Its function is the opposite of the BeforeSQL script. It has no dependency on the service instance and changes the relevant functions of the service instance by changing the table structure. This also ensures that there is no impact on the service instance before and after the change, avoiding affecting online transactions.

[0176] 6. If an exception occurs in the system in the previous step, use AfterRollbackSQL to quickly roll back the published data changes. This ensures that even if an exception occurs, the application will not be affected.

[0177] 7. Deploy the GlobalAfterSQL script. In some scenarios, when upstream and downstream system logic depends on certain functions in the deposit core subsystem, changes to the data involved in these functions are processed uniformly in GlobalAfterSQL to avoid affecting other upstream and downstream systems.

[0178] 8. If an exception occurs in the system in the previous step, use GlobalAfterRollbackSQL to quickly roll back the published data changes. This ensures that even if an exception occurs, the application will not be affected.

[0179] Based on the above description, the following differences are found between the phased release solution proposed in the embodiment of the present invention and the existing phased release technical solution:

[0180] First, the grayscale solution proposed in the embodiment of the present invention is aimed at the changes of the entire service cluster under the distributed architecture, which involves multiple DCNs, multiple databases and multiple service instances. The existing grayscale release solution cannot meet the grayscale release requirements under this architecture.

[0181] For example, in the first step of service suspension, existing technical solutions cannot simultaneously suspend all service instances on the DCN. When the DCN is large and involves many service instances, suspending all service instances simultaneously poses unimaginable risks to the user experience and the security of the bank's financial products.

[0182] Secondly, in the technical solution proposed in the embodiment of the present invention, except for step 3 which requires stopping the service instances in batches (similar to step 3 of the prior art, because stopping the service is necessary to make version changes to the service instances), the remaining steps 1, 2, 4, 5, 6, 7, and 8 do not involve stopping the service instances. Comparing step 3 in the solution proposed in the embodiment of the present invention with step 3 in the traditional solution, the number of service instances stopped in the example of the present invention is greatly optimized, and all instances are changed to be processed in batches. That is to say, at the same time, although some service instances have been stopped, other non-stopped service instances on this DCN can provide services to the outside world. The entire solution greatly reduces the time when the cluster's external services are unavailable during the entire grayscale release cycle, and minimizes the scope of user transaction impact during the grayscale release.

[0183] Then, steps 1, 5, and 7 of the present embodiment differ from step 2 of the prior art approach when modifying database data. In contrast, prior art approaches cannot cache data modifications using SQL configuration files. These approaches can only cache query results in DML statements, storing them in memory, but cannot cache insert, update, or delete operations.

[0184] For example, when modifying data in a quota module's related tables, existing technical solutions insert a piece of data, but this data doesn't take effect immediately. Existing solutions define this in code or configure it in an XML file. Therefore, the quota module's code or related XML files must be modified, and the system must be redeployed and restarted for the data to take effect. In the solution proposed in this embodiment of the present invention, a table is designed as a cache using the aforementioned local Java virtual machine-level caching technology. Regardless of any operation performed on this table, including additions, deletions, and modifications, the cache can be manually refreshed to make the operation take effect. In other words, if you want to modify the functionality of a module on a service instance, you can find the table corresponding to this module's functionality and modify the structure and corresponding data of the associated table to enable this functionality, without having to modify the module's code, re-publish the application, or restart the service instance. Technically, this differs from existing technical solutions in that when some tables are designed as cache tables, calls to these tables by the corresponding modules on the service instance are intercepted by interceptors defined by Spring Aspect Oriented Programming (AOP). If the table is a cache table, the module will read the latest data from the cache. A polling thread is also defined, which is automatically triggered at regular intervals to read all the data in the cache definition table. When it finds that the cache has been refreshed, it will re-read the latest data of all cache tables from the database and reload them for use by the module on the service instance.

[0185] Finally, the corresponding handling methods for abnormal failures caused by data changes in steps 2, 5, and 7 of the embodiment of the present invention are also different from those of the existing solutions. After the data change is completed in the embodiment of the present invention, on the one hand, the business party can directly conduct transactions from the front-end channel to observe whether the changed data has achieved the expected results; on the other hand, the operation and maintenance personnel can also observe the impact of the changed data from the back-end system by monitoring some parameters of the interface services involved in the change module, such as the success rate, failure rate, delay, error log, etc. of the interface call. If the results fed back by the business personnel are not ideal or the operation and maintenance personnel find that the parameter performance indicators of the relevant interface services have declined and there are obvious error logs related to the change in the background, unlike the existing technical solutions, in the embodiment of the present invention, there is no need to stop the service of the application instance, and the rollback script corresponding to the SQL configuration file is directly deployed. By refreshing the cache, the data in the rollback script is modified, so that the transaction function of the module can be quickly restored, and the impact of the transaction failure on the customer can be minimized.

[0186] refer to Figure 6, which is a schematic diagram of the release process of a normal version (with ample online time) provided by an embodiment of the present invention.

[0187] On the first day, select one online instance on any DCN, all batch instances, and one online instance on an ADM, all small ledger instances, and all batch instances for deployment. This ensures that the deployment scope is minimized. During the day, a grayscale rollout of new version features is performed for online transactions in the core deposit system, and at the end of the day, a grayscale rollout is performed for batch transactions and small ledger transactions in the system.

[0188] 2. On the second day, the new version is released to the remaining online instances on the DCN released on the first day. The advantage of this is that after the release is completed on the second day, there is a DCN that has performed the grayscale rollout of the new version function, and the transaction status of the new version can be observed on the complete DCN.

[0189] 3. On the third day, based on the DCNs deployed in the previous two days, if there are no abnormalities, deploy other DCNs according to the same steps until all DCNs are completed.

[0190] refer to Figure 7 , which is a schematic diagram of the release process of an emergency version (the online time is relatively urgent) provided by an embodiment of the invention.

[0191] For the release of emergency versions in the production environment (the launch time is relatively urgent), the entire grayscale solution process can be processed in two days. The entire grayscale solution process is as follows Figure 7 As shown, the main difference from the three-day plan mentioned above is that the work of the first two days of the three-day plan was completed on the first day. The advantage of this approach is that it ensures a complete grayscale release of a DCN while keeping the time and deployment scope minimized. During the day, the new version functionality of the online transactions of the core deposit system was grayscaled, and at the end of the day, the system's batch transactions and small general ledger transactions were grayscaled.

[0192] Based on the same concept, the embodiment of the present invention also provides a version upgrade device, such as Figure 8 As shown, the device includes:

[0193] A stopping unit 801 is configured to stop a first service instance when a first version mark indicates an upgraded state; the first version mark is used to indicate whether the first service instance needs to be upgraded;

[0194] An updating unit 802 is configured to update a first functional parameter recorded in a system database to a first local memory of the first service instance; the first functional parameter is a functional parameter modified by the system database using a first configuration file; the first configuration file is used to update a functional parameter that is dependent on a service instance;

[0195] The running unit 803 is configured to start the first service instance and run the first service instance using the first function parameters in the first local memory.

[0196] Furthermore, for the device, the update unit 802 is specifically used to: determine the function parameter tables that need to be updated to the first local memory through the cache definition table; the cache definition table records the attribute information of each function parameter table; the function parameter table records the function parameters of the set function; obtain the function parameter tables from the system database and load them into the first local memory.

[0197] Further, for the device, the running unit 803 is specifically used to: the first service instance determines the first function parameter table corresponding to the service request to be processed in the cache definition table; the first service instance determines to execute the service request through the first function parameter table in the first local memory based on the attribute information of the first function parameter table in the cache definition table.

[0198] Furthermore, for the device, the running unit 803 is specifically configured to: determine, through an interception thread, that the service request needs to call the first function parameter table.

[0199] Furthermore, for the device, the updating unit 802 is specifically configured to: determine, through a polling thread, whether a function parameter table in the system database has been changed.

[0200] Furthermore, for the device, the running unit 803 is also used to: when the second version is marked as non-upgraded, obtain the second function parameter from the second local memory of the second service instance to run the second service instance; the second version mark is used to indicate whether the second service instance needs to be upgraded; the second function parameter is the record in the system database before it is changed by the first configuration file.

[0201] Furthermore, for the device, the operating unit 803 is also used to: after the first service instance fails to run, suspend the first service instance and update the second functional parameter in the system database to the first local memory; the second functional parameter is a record of restoring the system database to the state before the first functional parameter according to the first rollback configuration file.

[0202] Furthermore, for the device, the first local memory stores the function parameter table in the system database according to a set table structure.

[0203] Furthermore, for the device, the first node is any one of multiple nodes in the distributed system; the running unit 803 is specifically used to: batch upgrade each service instance according to the first rule; the first rule is the upgrade order for the service instances; upgrade the second node according to the second rule; the second node is any node in the distributed system except the first node; the second rule is the upgrade order for the nodes.

[0204] Furthermore, for the device, the update unit 802 is also used to: after all service instances are successfully upgraded according to the first configuration file, update the third functional parameters in the system database to the local memory of each of all service instances; the third functional parameters are set through the second configuration file, and the second configuration file is used to upgrade functional parameters that have no dependency on the service instances.

[0205] Furthermore, for the device, the update unit 802 is also used to: after all service instances of all nodes are successfully upgraded according to the first configuration file and the second configuration file, update the fourth functional parameter in the system database to the local memory of all service instances; the fourth functional parameter is set through the third configuration file, and the third configuration file is used to upgrade the functional parameters that have dependencies on upstream and downstream service instances.

[0206] like Figure 9 As shown, another version upgrade device provided by an embodiment of the present invention includes:

[0207] A function parameter generating unit 901 is configured to modify the function parameters in the system database using a first configuration file to obtain first function parameters;

[0208] An upgrade state setting unit 902 is configured to set a first version flag of a first node to an upgrade state according to a first rule; the first version flag is used to indicate whether the first service instance needs to be upgraded;

[0209] The function parameter recovery unit 903 is configured to, when determining that the upgrade of the first service instance fails, restore the second function parameter to the value before the first configuration file updates the system database using the first rollback configuration file.

[0210] Furthermore, for the device, the function parameter generation unit 901 is also used to: after determining that all service instances of the first node have been successfully upgraded, change the function parameters in the system database through the second configuration file to obtain third function parameters; the function parameter recovery unit 903 is also used to: when it is determined that the upgrade has failed, restore the first function parameters before the second configuration file updated the system database through the second rollback configuration file.

[0211] Furthermore, for the device, the function parameter generation unit 901 is also used to: after determining that all service instances of all nodes have been successfully upgraded, change the function parameters in the system database through the third configuration file to obtain the fourth function parameters; the function parameter recovery unit 903 is also used to: when it is determined that the upgrade has failed, restore the third function parameters before the system database was updated by the third configuration file through the third rollback configuration file.

[0212] An embodiment of the present invention further provides a computing device, which may specifically be a desktop computer, a portable computer, a smart phone, a tablet computer, a personal digital assistant (PDA), etc. The computing device may include a central processing unit (CPU), a memory, input / output devices, etc. The input device may include a keyboard, a mouse, a touch screen, etc., and the output device may include a display device such as a liquid crystal display (LCD) or a cathode ray tube (CRT).

[0213] The memory may include a read-only memory (ROM) and a random access memory (RAM), and provides the processor with program instructions and data stored in the memory. In an embodiment of the present invention, the memory may be used to execute program instructions of the version upgrade method;

[0214] The processor is used to call the program instructions stored in the memory and execute the version upgrade method according to the obtained program.

[0215] An embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute a method suitable for version upgrading.

[0216] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, 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 magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0217] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, 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 produce 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 flowcharts and / or block diagrams. 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.

[0218] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work 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 1 The function specified in one or more boxes.

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

[0220] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0221] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A version upgrade method, characterized in that: The method comprises: When the first version mark of the first node is in an upgraded state, the first service instance on the first node is stopped; the first version mark is used to indicate whether the first service instance needs to be upgraded; The first node updates the first function parameter recorded in the system database to the first local memory of the first service instance, and the original function parameter in the first local memory is iterated by the first function parameter; the first function parameter is the function parameter after the system database is modified using the first configuration file; the first configuration file includes change information between the first function parameter and the original function parameter; The first node starts the first service instance and runs the first service instance using the first functional parameters in the first local memory.

2. The method according to claim 1, wherein The first node updates the first function parameter recorded in the system database to the first local memory of the first service instance, including: The first node determines, through a cache definition table, each function parameter table that needs to be updated in the first local memory; the cache definition table records attribute information of each function parameter table; the function parameter table records each function parameter of a set function; The first node obtains the function parameter tables from the system database and loads the tables into the first local memory.

3. The method according to claim 2, wherein The running the first service instance by using the first function parameter in the first local memory includes: The first service instance determines a first function parameter table corresponding to the service request to be processed in the cache definition table; The first service instance determines to execute the service request through the first function parameter table in the first local memory according to the attribute information of the first function parameter table in the cache definition table.

4. The method according to claim 3, wherein Before the first service instance determines the first function parameter table corresponding to the service request to be processed in the cache definition table, the method further includes: The interception thread in the first node determines that the service request needs to call the first function parameter table.

5. The method according to claim 1, wherein Before the first node updates the first function parameter recorded in the system database to the first local memory of the first service instance, the method further includes: The polling thread of the first node determines that a function parameter table in the system database has been changed.

6. The method according to claim 1, wherein The method further comprises: When the second version is marked as non-upgraded, the first node obtains the second function parameter from the second local memory of the second service instance to run the second service instance; the second version mark is used to indicate whether the second service instance needs to be upgraded; the second function parameter is the record in the system database before it is changed by the first configuration file.

7. The method according to claim 1, wherein After running the first service instance, the method further includes: After the first service instance fails to run, the first node suspends the first service instance and updates the second functional parameter in the system database to the first local memory; the second functional parameter is a record of restoring the system database to the state before the first functional parameter according to the first rollback configuration file.

8. The method according to claim 1, wherein The first local memory stores the function parameter table in the system database according to a set table structure.

9. The method according to any one of claims 1 to 8, wherein The first node is any one of a plurality of nodes in a distributed system; The distributed system performs system upgrades according to set rules, including: Each service instance on the first node is upgraded in batches according to a first rule; the first rule is for the upgrade order of the service instances; After the first node is upgraded, the second node is upgraded according to a second rule; the second node is any node in the distributed system except the first node; the second rule is for the upgrade order of the nodes.

10. The method according to any one of claims 1 to 8, wherein The method further comprises: After all service instances are successfully upgraded according to the first configuration file, the first node updates the third functional parameters in the system database to the local memory of each of all service instances; the third functional parameters are set through the second configuration file, and the second configuration file is used to upgrade functional parameters that have no dependency on the service instances.

11. The method according to claim 10, wherein The method further comprises: After all service instances of all nodes are successfully upgraded according to the first configuration file and the second configuration file, the first node updates the fourth functional parameter in the system database to the local memory of all service instances; the fourth functional parameter is set through the third configuration file, and the third configuration file is used to upgrade functional parameters that have dependencies on upstream and downstream service instances.

12. A version upgrade device, characterized in that: The device comprises: a stopping unit, configured to stop the first service instance when the first version mark is in an upgraded state; the first version mark is used to indicate whether the first service instance needs to be upgraded; an updating unit, configured to update a first functional parameter recorded in a system database to a first local memory of the first service instance, wherein the original functional parameter in the first local memory is iterated with the first functional parameter; the first functional parameter is the functional parameter after the system database is modified using a first configuration file; the first configuration file includes change information between the first functional parameter and the original functional parameter; An operating unit is configured to start the first service instance and operate the first service instance using the first function parameters in the first local memory.

13. A computing device, characterized in that include: a memory for storing program instructions; A processor is configured to call the program instructions stored in the memory and execute the method according to any one of claims 1 to 11 according to the obtained program.

14. A computer-readable storage medium, characterized in that The storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the method according to any one of claims 1 to 11.

Images