A distributed dynamic configuration updating method and a distributed server system

Abstract

The application discloses a kind of distributed dynamic configuration updating method and distributed server system, it is related to distributed system configuration management technical field.Therein, method is applied in the server in distributed server system, distributed server system includes controller and at least one server, method includes: receiving configuration change information from controller, wherein, configuration change information includes identification key and attribute configuration value;Obtain the preset hosting object register, determine the configuration binding information corresponding to identification key in hosting object register, and based on configuration binding information, target hosting object is called in process running memory;Based on the attribute configuration value, the attribute value of the hosting object member field corresponding to target hosting object is modified, to complete the configuration update of business service process.The above scheme can improve the efficiency of hot updating of the configuration data of server.

Description

Technical Field

[0001] This invention relates to the field of distributed system configuration management technology, and in particular to a distributed dynamic configuration update method and a distributed server system. Background Technology

[0002] Hot configuration updates in a distributed service architecture refer to the dynamic real-time updating and application of business configuration parameters without requiring the server's service processes to be restarted or shut down. It is a core technology for ensuring the stable operation of distributed server systems and improving the efficiency of business iteration.

[0003] Currently, traditional configuration update solutions can only modify cached parameters during the configuration push process. When performing configuration updates, they rely on the server framework to perform a full scan of all configuration fields on the server, lacking a precise configuration binding relationship indexing and positioning mechanism. This makes it impossible to accurately and purposefully update the member fields of managed objects within the service process. Especially in a modular loading environment with domestic middleware, configuration annotation scanning is prone to failure, making it difficult to quickly and accurately match the target configuration fields that need updating, significantly reducing the overall efficiency of hot updates to server configuration data. Summary of the Invention

[0004] In view of this, this application provides a distributed dynamic configuration update method and a distributed server system, the main purpose of which is to solve the technical problem of low efficiency in hot updating server configuration data.

[0005] According to a first aspect of the present invention, a distributed dynamic configuration update method is provided, the method being applied to a server in a distributed server system, the distributed server system including a controller and at least one server, the method comprising: Receive configuration change information from the controller, wherein the configuration change information includes an identification key and an attribute configuration value; Obtain a preset managed object registry, determine the configuration binding information corresponding to the identifier key in the managed object registry, and retrieve the target managed object in the process runtime memory based on the configuration binding information; Based on the attribute configuration value, the attribute values ​​of the managed object member fields corresponding to the target managed object are modified to complete the configuration update of the business service process.

[0006] In an optional embodiment, the configuration change information further includes a version number; the server has a version lookup table, which records multiple identifier keys and a corresponding version number for each identifier key; before determining the configuration binding information corresponding to the identifier key in the managed object registry, the method further includes: determining the corresponding version number of the identifier key in the version lookup table, and determining whether the version number in the configuration change information is less than or equal to the corresponding version number; if the version number is less than or equal to the corresponding version number, the configuration change information is discarded; if the version number is greater than the corresponding version number, the step of determining the configuration binding information corresponding to the identifier key in the managed object registry is performed, and the value of the corresponding version number of the identifier key is incremented by one in the version lookup table.

[0007] In an optional embodiment, modifying the attribute values ​​of the managed object member fields corresponding to the target managed object based on the attribute configuration value to complete the configuration update of the business service process includes: determining whether the attribute configuration value is encrypted information encrypted using an encryption algorithm; if the attribute configuration value is encrypted information, decrypting the encrypted information using a white-box cryptographic decryption algorithm to obtain decrypted information; and modifying the attribute values ​​of the managed object member fields corresponding to the target managed object based on the decrypted information to complete the configuration update of the business service process.

[0008] According to a second aspect of the present invention, a distributed server system is provided, the distributed server system including a controller and at least one server, wherein the server is configured to perform the distributed dynamic configuration update method as described above; The controller is used to receive configuration change information from a remote host computer, wherein the configuration change information includes operator identification, timestamp information, identification key and attribute configuration value; The controller is also used to perform permission verification based on the operator identifier. When the operator identifier passes the permission verification, it generates operation log information based on the operator identifier, the timestamp information, the identifier key, and the attribute configuration value, and sends the operation log information to the host computer, and sends the configuration change information to each of the servers.

[0009] In an optional embodiment, the controller broadcasts the configuration change information to each of the servers; after receiving the configuration change information, each server sets its own source node identifier in the configuration change information and sends the configuration change information to each other server in the distributed server system.

[0010] In an optional embodiment, when the server receives configuration change information from other servers, it determines whether its own source node identifier exists in the configuration change information; if its own source node identifier exists in the configuration change information, the configuration change information is discarded.

[0011] In an optional embodiment, the controller is further configured to acquire business engineering code and deploy the business engineering code to the class bytecode storage directory of each server, wherein the managed object member field of the configurable managed object in the business engineering code is pre-configured with declaration annotation information, the declaration annotation information including an identifier key and a default configuration value; the server is further configured to extract the business engineering code in its own class bytecode storage directory, determine the identifier key in the declaration annotation information of the managed object member field of the configurable managed object of the business engineering code, and based on the identifier key, determine whether there is a preset configuration value corresponding to the identifier key in the server's cache, and if there is a preset configuration value corresponding to the identifier key in the cache, assign the preset configuration value to the managed object member field.

[0012] In an optional embodiment, when the server's cache does not contain a preset configuration value corresponding to the identifier key, the server is further configured to determine whether the cache of other servers in the distributed server system contains a preset configuration value corresponding to the identifier key. If the cache of other servers contains a preset configuration value corresponding to the identifier key, the server obtains the preset configuration value and assigns the preset configuration value to the managed object member field.

[0013] In an optional embodiment, if the preset configuration value corresponding to the identifier key does not exist in the cache of other servers, the default configuration value is assigned to the managed object member field.

[0014] In an optional embodiment, each of the servers is equipped with middleware; the server obtains a class loader corresponding to the type of the middleware, and extracts the business code from the class bytecode storage directory based on the class loader.

[0015] This invention provides a distributed dynamic configuration update method and a distributed server system. By pre-setting a registry for stored configuration binding relationships, it avoids the inefficient approach of relying on frameworks for full-scale field scanning and matching, as used in traditional solutions. Based on the identifier key of the configuration change information, it can quickly and accurately locate the target managed object and its corresponding member fields within the process memory. This overcomes the shortcomings of traditional solutions, which lack a precise indexing and positioning mechanism and can only update cached parameters. It can directly update the member fields of the business managed object, eliminating redundant scanning and adaptation operations. This effectively improves the accuracy and execution efficiency of hot configuration updates on the distributed server, and stably ensures the business requirements for real-time iterative updates of distributed system configurations.

[0016] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings: Figure 1 This diagram illustrates the structure of a distributed server system according to an embodiment of the present invention. Figure 2 The diagram illustrates a flowchart of a distributed dynamic configuration update method provided by an embodiment of the present invention. Detailed Implementation

[0018] The present invention will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the present application can be combined with each other.

[0019] Hot configuration updates in a distributed service architecture refer to the dynamic, real-time updating and application of business configuration parameters without requiring server service processes to restart or shut down. This is a core technology for ensuring the stable operation of distributed server systems and improving business iteration efficiency. Currently, traditional configuration update schemes can only modify cached parameters through configuration push. When performing configuration updates, they rely on the server framework to perform a full scan and match of configuration fields within the server, lacking a precise configuration binding relationship indexing and positioning mechanism. This makes it impossible to accurately and purposefully update the member fields of managed objects within the service process. Especially in the modular loading environment of domestic middleware, configuration annotation scanning is prone to failure, making it impossible to quickly and accurately match the target configuration fields that need updating, significantly reducing the overall efficiency of hot server configuration data updates.

[0020] To address the aforementioned issues, in one embodiment, a distributed dynamic configuration update method is provided. This method is illustrated using the example of hot configuration updates on a server within a distributed server system. Figure 1 As shown, the distributed server system includes a controller 100 and at least one server 200. The controller 100 can be a computer terminal used by relevant personnel to publish configuration information to the server 200. Each server 200 is pre-configured with specific types of middleware, such as Baolande or Dongfangtong. The business engineering code required for the server to execute business is pre-packaged and deployed to the server 200. The controller 100 communicates with each server 200. Here, a distributed cache publish-subscribe channel is established between the controller 100 and each server 200. The distributed cache publish-subscribe channel is a message broadcast channel built into the system's distributed cache. After the business service process of each server starts, it pre-subscribes to this channel. When the administrator modifies the configuration and writes the configuration data to the distributed cache, the cache sends the configuration change message outward through this channel. All server business processes that have completed the subscription can receive the notification in real time, so that the controller 100 can broadcast to all servers 200 through this publish-subscribe channel, realizing the unified distribution and synchronous push of configuration change information and other data.

[0021] Furthermore, such as Figure 2 As shown, the distributed dynamic configuration update method includes the following steps: 101. Receive configuration change information from the controller, wherein the configuration change information includes an identification key and an attribute configuration value.

[0022] Specifically, the server maintains a communication connection with the controller and listens in real time for configuration change information broadcast by the controller through a pre-defined distributed cache publish-subscribe channel. The identifier key is a unique configuration identifier corresponding to a member field of the managed object, used to accurately locate the configuration item to be updated. The attribute configuration value is the latest business parameter attribute value that needs to be updated for the corresponding configuration identifier. After listening to the configuration change broadcast message, the server receives and parses the configuration change information in real time, providing valid data for subsequent accurate matching of the target managed object and dynamic configuration updates. As an example, the identifier key in the configuration change information can be "riskSwitch," and its corresponding attribute configuration value can be "0," which can be the attribute value corresponding to the identifier key.

[0023] 102. Obtain a preset managed object registry, determine the configuration binding information corresponding to the identifier key in the managed object registry, and retrieve the target managed object in the process runtime memory based on the configuration binding information.

[0024] The managed object (Bean) registry can be pre-configured and stores multiple identifier keys and corresponding configuration binding information for each identifier key. The configuration binding information includes the process memory index of the managed object associated with the corresponding identifier key. Specifically, after the server obtains the managed object registry, it retrieves the matching configuration binding information based on the received identifier key. Using the process memory index of the managed object recorded in the configuration binding information, it directly and accurately locates and retrieves the corresponding target managed object in the current process's runtime memory and determines the managed object member fields corresponding to that target managed object.

[0025] 103. Based on the attribute configuration value, modify the attribute values ​​of the managed object member fields corresponding to the target managed object to complete the configuration update of the business service process.

[0026] Specifically, after accurately locating and retrieving the target managed object and its corresponding managed object member fields, the server extracts the latest attribute configuration values ​​carried in the configuration change information. Using Java reflection, it directly accesses the corresponding managed object member fields in the process's runtime memory and replaces the original attribute values ​​of these fields with the latest configuration values. This step requires no modification to local configuration files, no rebuilding of the managed object instance, and no restarting of the business service process. It only performs targeted value overwriting and updating of specified member fields of the target managed object in memory, completing real-time refresh of field values ​​and ultimately achieving dynamic updates and immediate effects of the business configuration corresponding to the business service process.

[0027] The distributed dynamic configuration update method provided in this embodiment can store configuration binding relationships in a pre-defined managed object registry, avoiding the inefficient method of relying on frameworks to perform full-scale field scanning and matching in traditional solutions. Based on the identifier key of the configuration change information, it can quickly and accurately locate the target managed object and its corresponding member fields inside the process memory. This method makes up for the shortcomings of traditional solutions, which lack a precise indexing and positioning mechanism and can only update cached parameters. It can directly update the member fields of the business managed object, eliminating redundant scanning and adaptation operations, effectively improving the accuracy and execution efficiency of hot configuration updates on distributed servers, and stably ensuring the business needs of real-time iterative updates of distributed system configurations.

[0028] In an optional embodiment, the configuration change information further includes a version number, used to mark how many times the attribute value corresponding to the identifier key in the configuration change information has changed since the system initialization and deployment were completed; furthermore, the server also has a version lookup table, which records multiple identifier keys and the corresponding version number for each identifier key; here, the version number can be the sequence version value of the iterative update of the attribute value corresponding to the identifier key, and as the number of times the attribute value corresponding to the identifier key has changed and been updated increases, the value of the version number corresponding to the identifier key in the version lookup table increases.

[0029] Furthermore, before determining the configuration binding information corresponding to the identifier key in the managed object registry, the method further includes: First, determine the corresponding version number of the identifier key in the version comparison table, and determine whether the version number in the configuration change information is less than or equal to the corresponding version number; Specifically, when the server receives configuration change information carrying a version number, it first searches the local version lookup table, reads the corresponding version number of the identifier key in the configuration change information that has been saved in the version lookup table, and compares the value between the version number of the identifier key carried in the configuration change information and the local corresponding version number of the identifier key in the version lookup table.

[0030] Then, if the version number is less than or equal to the reference version number, the setting change information is discarded; if the version number is greater than the reference version number, the step of determining the configuration binding information corresponding to the identifier key in the managed object registry is executed, and the value of the reference version number corresponding to the identifier key is incremented by one in the version lookup table.

[0031] Specifically, if the version number carried in the configuration change information is less than or equal to the corresponding version number of the identifier key in the version lookup table (e.g., if the version number carried in the configuration change information is "3" and the corresponding version number of the identifier key in the version lookup table is "4"), it indicates that the currently received configuration change information is old version configuration data. The server directly discards this configuration change information and does not perform subsequent configuration location and update operations. If the version number carried in the configuration change information is greater than the corresponding version number in the version lookup table, it is determined that the current configuration change information is valid and the latest configuration data. The server continues to perform subsequent steps of matching the configuration binding information of the corresponding identifier key in the managed object registry, and at the same time, increments the value of the corresponding version number of the identifier key in the version lookup table to complete the synchronization iteration of the local version record.

[0032] The embodiments provided in this application can filter out delayed and duplicate messages, effectively avoid configuration rollback or duplicate updates caused by network disorder and duplicate pushes, and ensure that the configuration parameters of member fields of internally managed objects on each server are always kept up to date.

[0033] In an optional embodiment, step 103, which modifies the values ​​of the managed object member fields corresponding to the target managed object based on the attribute configuration value to complete the configuration update of the business service process, includes: First, determine whether the attribute configuration value is encrypted information encrypted using encryption algorithms such as SM4. If the attribute configuration value is encrypted information, decrypt the encrypted information using the corresponding white-box cryptographic decryption algorithm to obtain the decrypted information. Here, when the attribute configuration value in the configuration change information is an attribute value that needs to be encrypted, such as password information, it can be encrypted using the SM4 algorithm to obtain the encrypted attribute configuration value. A unique identification marker or fixed prefix is ​​then added to this attribute configuration value. After the server receives the configuration change information, it first checks for this marker when reading the attribute configuration value. If the unique encryption marker is detected, the attribute configuration value is determined to be encrypted information using the SM4 algorithm. After removing the marker, the SM4 white-box cryptographic decryption algorithm is used to perform decryption processing, obtaining the decrypted attribute configuration value. If no corresponding marker is detected, the attribute configuration value is determined to be plaintext, and no decryption step is required.

[0034] Then, based on the decrypted information, the attribute values ​​of the managed object member fields corresponding to the target managed object are modified to complete the configuration update of the business service process. The embodiments provided in this application, through the added encryption verification and white-box decryption steps, can protect sensitive configuration values ​​during transmission, ensure the security of configuration data transmission using national cryptographic algorithms such as SM4, and reduce the risk of key leakage through white-box decryption. This effectively prevents sensitive configurations from being stolen and securely completes the update of configuration parameters for the managed object member fields.

[0035] The distributed dynamic configuration update method provided in this embodiment can store configuration binding relationships through a preset managed object registry. It can quickly and accurately locate the target managed object and its corresponding member fields in the process memory based on the identifier key of the configuration change information. This overcomes the shortcomings of traditional solutions, which lack a precise indexing and location mechanism and can only update cached parameters, thus improving the accuracy and execution efficiency of hot configuration updates on distributed servers. Simultaneously, it verifies message versions based on a version lookup table to filter out delayed and duplicate messages, preventing configuration rollbacks and multiple updates caused by network out-of-order delivery and repeated pushes. Furthermore, it can identify encrypted identifiers and uses the SM4 national cryptographic algorithm combined with white-box decryption to protect sensitive configurations, reducing the risk of key leakage, securely completing field updates, and ensuring the stable operation of distributed system configuration iteration.

[0036] Furthermore, this application also provides a distributed server system, such as... Figure 1 As shown, the distributed server system includes a controller 100 and at least one server 200, wherein the server 200 is used to execute the distributed dynamic configuration update method as described above.

[0037] Furthermore, the controller 100 is used to receive configuration change information from a remote host computer (not shown in the figure). This configuration change information includes an operator identifier, timestamp information, an identifier key, and attribute configuration values. Here, when a hot configuration update is required for each server 200, relevant personnel can configure the configuration change information through the host computer and send it to the controller 100. The operator identifier can be the unique account number, employee ID, or unique identification code of the maintenance personnel who wrote the configuration change information in the host computer, used to distinguish the personnel who initiated this configuration modification task. Furthermore, the timestamp information can be the time when the host computer sent the configuration change information to the controller 100.

[0038] Furthermore, the controller 100 is also used to perform permission verification based on the operator identifier in the configuration change information. When the operator identifier passes the permission verification, the controller generates operation log information based on the operator identifier, the timestamp information, the identifier key, and the attribute configuration value, sends the operation log information to the host computer, and distributes the configuration change information to each of the servers 200.

[0039] Specifically, after receiving configuration change information carrying operator identifier, timestamp information, identifier key and attribute configuration value, the controller 100 first retrieves the pre-stored operator identifiers of each of the multiple personnel with configuration update permissions, determines whether the operator identifier is the same as one of the multiple pre-stored operator identifiers, and determines that the personnel corresponding to the operator identifier have the permission to modify the corresponding configuration item when the operator identifier is the same as one of the multiple pre-stored operator identifiers.

[0040] Furthermore, after the operator's identification is verified, the operator's identification, timestamp, identification key, and attribute configuration value are integrated to assemble the operation log information, which is then sent back to the host computer. Simultaneously, configuration change information is distributed to all servers. The audit log can record the following information: operator identity, operation time, operation type, configuration key, attribute value before change, attribute value after change, and a list of servers operated on. It can also record the results and failure reasons of subsequent hot update operations in the audit log. Furthermore, the audit log uses an asynchronous writing method, writing to the audit log file or audit database through an independent thread pool, without affecting the performance of the main process. It supports querying, statistics, and exporting of audit logs, meeting the regulatory audit requirements of the financial industry.

[0041] The distributed server system provided in this application has the capability of full-link audit tracing for configuration changes. It can fully record key information such as the operator, operation time, parameters before and after the change after anonymization, and affected service nodes for each configuration change, thereby complying with the regulatory audit standards of the financial industry.

[0042] In an optional embodiment, the controller broadcasts the configuration change information to each of the servers. Specifically, after the controller completes the permission verification and generates the corresponding operation log, it sends the prepared configuration change information outward in the form of a broadcast push based on the distributed cache publish-subscribe channel established between the controller and each server. All servers subscribed to the channel can listen to the broadcast message and receive the configuration change information.

[0043] Here, each server has a dedicated notification interface "XDCCConfigNotifyMBean" pre-deployed, which is equivalent to setting up a "notifyConfigChange" notification entry point that can be triggered on each server. When any server obtains an update message through the broadcast channel, it can use the underlying JMX management channel of the backup server to access the other servers in the system's server cluster in turn, call the notification interface to actively push configuration change instructions. When the broadcast channel, which serves as the primary channel, cannot work properly, this backup channel can take over the message push task.

[0044] Furthermore, after receiving the configuration change information from the controller or other servers, the server sets its own source node identifier into the configuration change information and sends the configuration change information to every other server in the distributed server system. Specifically, after receiving the configuration change information via the main channel formed by distributed cache publish-subscribe, the server writes its corresponding source node identifier into the configuration change information, and then builds an auxiliary channel based on the JMX / MBean mechanism built into the application server middleware. It calls the MBean notification interface to push the configuration change information carrying the source node identifier to all remaining servers in the server cluster of the distributed server system. Here, the main channel and the JMX / MBean auxiliary channel form two independent message push paths that are redundant with each other, thereby carrying out the configuration change push work between cluster nodes.

[0045] Furthermore, when the server receives configuration change information from other servers in the distributed server system, it determines whether its own source node identifier exists in the configuration change information. Specifically, after a server in the cluster receives configuration change information transmitted from other servers via the JMX / MBean secondary channel, it reads all the source node identifiers carried in the configuration change information, compares the identifier with its own source node identifier pre-stored on the local machine, and then determines whether the configuration change information contains the source node identifier corresponding to the local machine.

[0046] Furthermore, if the configuration change information contains its own source node identifier, the configuration change information is discarded. Specifically, if the server finds that the configuration change information contains the source node identifier corresponding to the local machine, it means that this configuration change message is a message that was forwarded outward by the local machine and then returned in a loop. In this case, the server directly discards the configuration change information and does not continue to execute the subsequent configuration update process. Conversely, if the server detects that the configuration change information does not contain the local machine's source node identifier, it determines that the message comes from other nodes in the cluster. The server normally receives the configuration change information and performs a series of operations such as subsequent version verification, decryption processing, and updating the member fields of the managed object.

[0047] The embodiments provided in this application use controller broadcast as the main transmission path, and then forward configuration change information through the JMXMBean secondary channel between servers. Through the mutual redundancy backup of the dual channels, the failure of a single path can be prevented, ensuring that each server in the cluster can reliably obtain configuration change information.

[0048] In an optional embodiment, during the process of the configuration hot update framework of the entire distributed server system being loaded with the business service, that is, during the initialization and deployment phase of each server, various preparatory tasks will be run sequentially when the server starts and the Spring container is initialized.

[0049] Specifically, in this stage, the controller can acquire the business engineering code and deploy it to the class bytecode storage directory of each server. Here, the business engineering code is the program code that carries the business service logic, managed object definition and configuration binding rules. After compilation, it generates class bytecode files that can be recognized by the server virtual machine. Then, through remote deployment and transmission, the compiled class bytecode files are pushed in batches to the preset class bytecode storage directory of each server, thus completing the local storage of the business engineering bytecode files on each server.

[0050] Specifically, in the business engineering code, the managed object member fields of configurable managed objects whose attribute values ​​can be modified have pre-configured declaration annotation information. This declaration annotation information includes an identifier key and a default configuration value. Here, for each managed object defined in the business engineering code, for configurable managed objects whose member field attribute values ​​can be modified online after the program has started running, without restarting the server or modifying the source code, corresponding declaration annotation information is pre-configured in the member fields that carry business configuration parameters. This declaration annotation information is pre-written into the code, and each declaration annotation information corresponds to a unique identifier key and a default configuration value, used to associate and annotate the attribute values ​​of the member fields of the configurable managed object.

[0051] As an example, the declaration of annotation information can be in the form of @XDCCValue(value="riskSwitch:0", encrypted=true), where "riskSwitch" is the identifier key, "0" is the default configuration value, and encrypted is a boolean flag used to mark whether the attribute value of the member field of the configurable managed object corresponding to the identifier key needs to be encrypted. When encrypted=true, it means that the attribute value corresponding to the identifier key needs to be encrypted, and when encrypted=false, it means that the attribute value does not need to be encrypted.

[0052] Furthermore, the server is used to extract the business project code from its own class bytecode storage directory. Here, each server is equipped with middleware, which can be any of the following: BES, TongWeb, or standard Spring Boot, to adapt to different business deployment and runtime environments. Furthermore, before extracting the business engineering code and parsing the identifier key in the declaration annotation information carried by the member fields of the configurable managed object, the server can obtain the class loader corresponding to the type of its own middleware, and extract the business engineering code from the class bytecode storage directory based on the class loader.

[0053] Specifically, the server can determine which type of middleware it is, such as BES, TongWeb, or standard Spring Boot, based on the middleware identification probe pre-configured in its own framework program.

[0054] Specifically, the middleware identification probe is registered to the server via the SPI mechanism and performs environment detection during the Spring container startup phase of the server. The middleware identification probe can include the Baolande BES probe, the Dongfangtong TongWeb probe, and the standard Spring Boot probe. Each probe is only responsible for identifying one type of middleware. In actual operation, the detection order is Baolande BES probe, Dongfangtong TongWeb probe, and standard Spring Boot probe in sequence. The probe can call the ClassLoader.tryLoadClass() interface encapsulated by the framework to tentatively load the middleware-specific feature class and identify the type of application middleware currently running based on the success or failure of class loading.

[0055] Specifically, if the Baolande BES probe can successfully load the exclusive feature class with the fully qualified name com.bes.appserver.xxx, it can be determined that the current server's runtime environment has Baolande BES middleware deployed. Then, the corresponding class loader for that middleware is invoked. Here, the Baolande BES middleware adopts a modular and isolated class loading architecture, with each deployment module equipped with an independent class loader. The server framework calls the BES-specific class loader interface to obtain the exclusive class loader for the business application module of the Baolande BES middleware, and relies on this loader to read the class bytecode storage directory, loading and parsing the bytecode files corresponding to the business project code.

[0056] Furthermore, if the TongWeb probe successfully loads the exclusive feature class with the fully qualified name com.tongweb.xxx, it determines that the current server runtime environment is running the TongWeb middleware, and then obtains the class loader in that middleware environment. Here, because TongWeb has a unique class loading delegation mechanism, the framework calls ModuleClassLoader as the valid class loader and reads the business project bytecode in the class bytecode storage directory, thereby avoiding annotation scanning failures caused by the class loading delegation mechanism.

[0057] Furthermore, if neither "com.bes.appserver.xxx" nor "com.tongweb.xxx" is loaded, the current server runtime environment is determined to be using the general Spring Boot middleware, and the corresponding class loader is randomly obtained. The Spring Boot environment does not have modular isolation class loading restrictions; the framework can directly call the native Spring class loader to read the business project bytecode in the class bytecode storage directory and perform the class loading operation.

[0058] Furthermore, the server determines the identifier key in the declaration annotation information set in the managed object member field of the configurable managed object of the business engineering code, and based on the identifier key, determines whether there is a preset configuration value corresponding to the identifier key in the server's cache. If there is a preset configuration value corresponding to the identifier key in the cache, the server assigns the preset configuration value to the attribute value of the corresponding managed object member field.

[0059] Specifically, after loading and parsing the complete business project code through a dedicated class loader adapted to the current middleware environment, the framework iterates through all managed object member fields within each managed object in the business project code. It identifies managed object member fields bound with declaration annotations as target member fields, and determines managed objects with target member fields as configurable managed objects. Here, for each configurable managed object bound with declaration annotations, it reads the `@XDCCValue` declaration annotation information bound to its target member field and parses out its carried identifier key, default configuration value, and encryption flag. Specifically, after loading and parsing the complete business project Class object through a dedicated class loader adapted to the current middleware environment, the framework iterates through all member fields of each managed object under the business project code, filtering out target member fields marked with `@XDCCValue` declaration annotation information. Subsequently, for each target member field annotated with `@XDCCValue`, it reads the annotation information of that declaration annotation information and parses out the identifier key, default configuration value, and encryption flag. Furthermore, the server framework first queries the server's local memory cache to check whether the local cache data table contains the identifier key corresponding to the annotation identifier key of the target member field and its preset configuration value; if the local cache hits the identifier key and its preset configuration value, it reads the existing configuration parameters in the cache and assigns the attribute value of the target member field, thereby completing the injection of configuration parameters into the managed object member field.

[0060] Furthermore, if the server does not have a preset configuration value corresponding to the identifier key in the declaration annotation information in its cache, the server is also used to determine whether the preset configuration value corresponding to the identifier key exists in the cache of other servers in the distributed server system. If the preset configuration value corresponding to the identifier key exists in the cache of other servers, the server obtains the preset configuration value and assigns the preset configuration value to the corresponding managed object member field.

[0061] Specifically, if the local cache does not find the preset configuration value for the corresponding identifier key, a second lookup is performed on the caches of other servers in the distributed server system, i.e., the system's distributed cache. Once the preset configuration value is identified in the distributed cache, it is written back to the local cache and then assigned to the managed object member field of the configurable managed object.

[0062] Furthermore, if the preset configuration value corresponding to the identifier key does not exist in the caches of other servers, the default configuration value in the declaration annotation information is assigned to the attribute value of the corresponding managed object member field. Specifically, when searching the distributed caches of other servers and not finding the preset configuration value corresponding to the identifier key in the declaration annotation information, it is determined that there are no custom effective configuration parameters in the current runtime environment. At this time, the framework retrieves the predefined default configuration value in the declaration annotation information, uses this default configuration value as the initial effective configuration parameter, and assigns it to the managed object member field of the corresponding configurable managed object, completing the initial injection of business configuration parameters.

[0063] This mechanism effectively avoids issues such as null fields, configuration failures, and business function anomalies caused by scenarios like missing cached data, failure of the configuration center to push custom configurations, or lack of historical configuration data during the first service startup. It ensures that business services can run normally based on the default configuration after startup. Simultaneously, the framework can synchronously cache the newly applied default configuration value to the server's local memory cache and distributed cache, completing the persistence of configuration data. Subsequent responses to configuration change commands can be based on this default configuration, providing a data foundation for subsequent dynamic hot updates of configurations and ensuring the stability and fault tolerance of the entire configuration hot update framework.

[0064] Furthermore, during the initial deployment phase, a managed object registry can be constructed. Specifically, all configurable managed objects with declaration annotations can be scanned, and their process memory indexes and configurable member field data can be read. Further, the identifier key from the declaration annotations of the configurable managed objects is associated with their memory indexes to generate the managed object registry. When a configuration change message is subsequently received from the distributed cache, the corresponding identifier key can be retrieved from the registry to locate the target managed object and the member fields to be updated, thereby enabling dynamic hot updates of member field values.

[0065] The distributed server system provided in this application is compatible with various middleware such as Baolande BES, Dongfangtong TongWeb, and ordinary Spring-Boot. It uses environment probes to identify middleware types and switch the corresponding class loading adaptation strategy, overcoming the defect of annotation scanning failure caused by the modular class loading isolation of domestic middleware. Simultaneously, it can access configuration parameters based on a combination of local and distributed caching, automatically loading default annotation values ​​when configuration is missing, ensuring normal operation during the initialization and deployment phase. Furthermore, it sets up dual-channel message listening to ensure reliable push of configuration change messages, and sensitive configurations are encrypted and stored using the SM4 national cryptographic algorithm. This enables hot updates of managed object fields without restarting the service, meeting the security, real-time, and regulatory audit requirements of financial businesses in the context of information technology innovation.

[0066] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of any particular implementation scenario. The above disclosures are merely a few specific implementation scenarios of this application; however, this application is not limited thereto, and any variations conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A distributed dynamic configuration update method, characterized in that, The method is applied to a server in a distributed server system, the distributed server system including a controller and at least one server, the method comprising: Receive configuration change information from the controller, wherein the configuration change information includes an identification key and an attribute configuration value; Obtain a preset managed object registry, determine the configuration binding information corresponding to the identifier key in the managed object registry, and retrieve the target managed object in the process runtime memory based on the configuration binding information; Based on the attribute configuration value, the attribute values ​​of the managed object member fields corresponding to the target managed object are modified to complete the configuration update of the business service process.

2. The method according to claim 1, characterized in that, The configuration change information also includes a version number; the server has a version lookup table, which records multiple identifier keys and the corresponding version number for each identifier key; Before determining the configuration binding information corresponding to the identifier key in the managed object registry, the method further includes: Determine the corresponding version number of the identifier key in the version comparison table, and determine whether the version number in the configuration change information is less than or equal to the corresponding version number; If the version number is less than or equal to the reference version number, the configuration change information is discarded. If the version number is greater than the reference version number, the step of determining the configuration binding information corresponding to the identifier key in the managed object registry is executed, and the value of the reference version number corresponding to the identifier key is incremented by one in the version reference table.

3. The method according to claim 1, characterized in that, The step of modifying the attribute values ​​of the managed object member fields corresponding to the target managed object based on the attribute configuration value to complete the configuration update of the business service process includes: Determine whether the attribute configuration value is encrypted information encrypted based on an encryption algorithm. If the attribute configuration value is encrypted information, perform a decryption operation on the encrypted information based on a white-box cryptographic decryption algorithm to obtain decrypted information. Based on the decrypted information, the attribute values ​​of the member fields of the managed object corresponding to the target managed object are modified to complete the configuration update of the business service process.

4. A distributed server system, characterized in that, The distributed server system includes a controller and at least one server, wherein the server is used to execute the distributed dynamic configuration update method as described in any one of claims 1 to 3; The controller is used to receive configuration change information from a remote host computer, wherein the configuration change information includes operator identification, timestamp information, identification key and attribute configuration value; The controller is also used to perform permission verification based on the operator identifier. When the operator identifier passes the permission verification, it generates operation log information based on the operator identifier, the timestamp information, the identifier key, and the attribute configuration value, and sends the operation log information to the host computer, and sends the configuration change information to each of the servers.

5. The distributed server system according to claim 4, characterized in that, The controller broadcasts the configuration change information to each of the servers. After receiving the configuration change information, the server sets its own source node identifier into the configuration change information and sends the configuration change information to each other server in the distributed server system.

6. The distributed server system according to claim 5, characterized in that, When the server receives configuration change information from other servers, it determines whether its own source node identifier exists in the configuration change information; If the configuration change information contains its own source node identifier, the configuration change information will be discarded.

7. The distributed server system according to claim 4, characterized in that, The controller is also used to obtain business engineering code and deploy the business engineering code to the class bytecode storage directory of each server. The managed object member fields of the configurable managed objects in the business engineering code are pre-configured with declaration annotation information, which includes an identifier key and a default configuration value. The server is also used to extract the business project code from its own class bytecode storage directory, determine the identifier key in the declaration annotation information of the managed object member field of the configurable managed object of the business project code, and based on the identifier key, determine whether there is a preset configuration value corresponding to the identifier key in the server's cache. If there is a preset configuration value corresponding to the identifier key in the cache, the server assigns the preset configuration value to the managed object member field.

8. The distributed server system according to claim 7, characterized in that, When the server does not have a preset configuration value corresponding to the identifier key in its cache, the server is further configured to determine whether the preset configuration value corresponding to the identifier key exists in the cache of other servers in the distributed server system. If the preset configuration value corresponding to the identifier key exists in the cache of other servers, the server obtains the preset configuration value and assigns the preset configuration value to the corresponding managed object member field.

9. The distributed server system according to claim 8, characterized in that, If the preset configuration value corresponding to the identifier key does not exist in the cache of other servers, the default configuration value is assigned to the corresponding managed object member field.

10. The distributed server system according to claim 7, characterized in that, Each of the servers is equipped with middleware; the server obtains the class loader corresponding to the type of the middleware, and extracts the business project code from the class bytecode storage directory based on the class loader.

Images