Structured JSON configuration based serialization dynamic module on-demand loading method

Abstract

The application provides an ordered dynamic module on-demand loading method based on structured JSON configuration, relates to the technical field of software engineering, and constructs a structured JSON configuration file of a business node, performs security verification on the structured JSON configuration file, obtains module configuration information, extracts function attributes and running parameters of all modules from the module configuration information, and generates a module feature identifier; an ordered queue during module loading is determined according to a dependency relationship and an execution priority list, homologous configuration matching is performed based on the module feature identifier in a multi-level cache cluster, and a cache matching result is obtained; the module is selected and loaded through the ordered queue, and pre-loading verification and independent running of the loaded module are performed based on the dependency relationship and the cache matching result, the application can realize ordered on-demand loading and independent running of the module by combining multi-level cache matching and pre-loading verification of the module feature identifier, so that the starting response efficiency of the modular system is improved.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and more specifically, to an ordered dynamic module on-demand loading method based on structured JSON configuration. Background Technology

[0002] Software engineering is a systematic discipline within computer science that studies the development, operation, and maintenance of software. Its core objective is to construct highly reliable and maintainable software systems through standardized and engineered methods. In software engineering practice, modular development is a key technical means to reduce system complexity, improve code reusability, and enhance team collaboration efficiency.

[0003] With the rapid popularization of enterprise-level applications and microservice architectures, the functional scale and business complexity of software systems continue to grow. How to achieve efficient organization, flexible scheduling, and on-demand loading of functional modules has become a core factor affecting system startup performance, resource utilization efficiency, and operational flexibility. On-demand module loading refers to defining the loading strategy, execution order, and dependencies of each functional module in the system through an external structured JSON configuration file. This allows the main program to dynamically and selectively load the required modules during runtime based on the configuration file. However, existing module loading methods cannot transform heterogeneous module configuration information into unified and comparable feature identifiers. This results in a large number of modules with the same or similar configuration features being repeatedly parsed and loaded in multiple loading cycles and multiple business nodes. Furthermore, there is a lack of cross-node module instance sharing and reuse mechanisms, insufficient consideration of inter-module dependencies, and a lack of mechanisms for detecting and handling circular dependencies. It is also impossible to pre-check the readiness status of dependent modules, the version compatibility of cached instances, and parameter adaptability before module instantiation. Therefore, how to combine multi-level cache matching based on module feature identifiers with pre-loading verification to achieve orderly on-demand loading and independent operation of modules, so as to improve the startup response efficiency of modular systems, is a challenge faced by the industry. Summary of the Invention

[0004] This application provides an ordered dynamic module on-demand loading method based on structured JSON configuration. It can combine multi-level cache matching of module feature identifiers and pre-loading verification to realize ordered on-demand loading and independent operation of modules, thereby improving the startup response efficiency of modular systems.

[0005] Firstly, this application provides a method for loading ordered dynamic modules on demand based on structured JSON configuration, the loading method comprising the following steps: Construct a structured JSON configuration file for the business nodes. The structured JSON configuration file includes a module queue, the dependencies of all modules, and a list of execution priorities. The structured JSON configuration file is subjected to security verification to obtain module configuration information. The functional attributes and running parameters of all modules are extracted from the module configuration information to generate module feature identifiers. Based on the dependencies and the execution priority list, an ordered queue is determined when the module is loaded. In a multi-level cache cluster, same-origin configuration matching is performed based on the module feature identifier to obtain cache matching results. The loading module is selected through the ordered queue, and the loading module is pre-loaded and run independently based on the dependency relationship and the cache matching result.

[0006] In this embodiment, constructing the structured JSON configuration file for the business node specifically includes: Obtain the business breakdown result of the business node, and divide the business function into multiple independent functional modules according to the business breakdown result to obtain the module queue; Assign a unique module identifier to all modules in the module queue, and configure the execution priority value and start / stop permission identifier for each functional module; The dependencies between functional modules are determined based on the business call chain. The module's unique identifier, the execution priority value, the start / stop permission identifier, and the dependency relationship are assembled in a structured JSON format to generate a structured JSON configuration file.

[0007] In this embodiment, the security verification of the structured JSON configuration file to obtain module configuration information specifically includes: The structured JSON configuration file is then subjected to format validity checks and field integrity checks in sequence. After successful validation, the validated structured JSON configuration file is converted into a standardized file stream. The standardized file stream is parsed in layers to extract the configuration parameters and dependent resources of each module, thereby obtaining the module configuration information.

[0008] In this embodiment, extracting the functional attributes and operating parameters of all modules from the module configuration information to generate module feature identifiers specifically includes: Iterate through the module configuration information and extract the functional attribute fields and running parameter fields of each module; The functional attribute fields and running parameter fields of each module are serialized and concatenated to obtain the feature strings of each module; Perform a hash operation on the feature strings of each module to obtain a fixed-length hash value for each module. Then, associate and store the fixed-length hash values ​​of all modules to obtain the module feature identifier.

[0009] In this embodiment, determining the ordered queue for module loading based on the dependencies and the execution priority list specifically includes: A module dependency graph is constructed based on the aforementioned dependency relationships; Loop detection and topology sorting are performed on the module dependency graph to obtain the loading order of each module; The loading order of each module is adjusted a second time based on the execution priority list to obtain an ordered queue for module loading.

[0010] In this embodiment, the process of performing source configuration matching based on the module feature identifier in a multi-level cache cluster to obtain cache matching results specifically includes: The module feature identifier is distributed to the cache nodes of the multi-level cache cluster; In the cache node, query the local cache space to see if there is an existing module instance that matches the module feature identifier; The existing module instances are summarized and marked for hits, generating cached matching results.

[0011] In this embodiment, selecting the loading module through the ordered queue specifically includes: Traverse the ordered queue sequentially and read the dependency list of the module to be loaded. Verify whether all dependent modules in the dependency list of the currently unloaded module have been loaded and registered. If the verification is successful, the currently unloaded module will be loaded.

[0012] In this embodiment, the pre-loading verification and independent operation of the loading module based on the dependency relationship and the cache matching result specifically includes: Based on the cache matching results, a pre-loading check is performed on the loading module to confirm the version compatibility and parameter adaptability of the cache instance; After the verification is successful, the loading module that hits the cache directly mounts the cache instance and performs incremental parameter updates based on the current module configuration; The loaded module that misses the cache performs reflection instantiation and completes the injection of initialization parameters; After the module is loaded, each loaded module is controlled to initialize and run independently according to its own business logic, and the newly generated module instance is synchronously written to the multi-level cache cluster.

[0013] In this embodiment, the multi-level cache cluster is a distributed three-level cache architecture, including a local node cache layer, a regional aggregation cache layer, and a global core cache layer. The local node cache layer stores frequently invoked module instances of the current business node; The regional aggregation cache layer stores module instances shared by multiple nodes within the corresponding geographical region; The global core cache layer stores standardized module instances that are common to the entire system and performs deduplication and scheduling management of the global cache.

[0014] In this embodiment, the module queue refers to a set of functional modules divided according to business function boundaries. Each functional module corresponds to an independent business processing capability and includes a unique module identifier, module name, start / stop status, set of running parameters, and loading class path information.

[0015] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects: The technical solution provided in this application combines multi-level cache matching based on module feature identifiers with pre-loading verification to achieve ordered on-demand loading and independent operation of modules. First, by constructing a structured JSON configuration file containing module queues, dependencies, and execution priority lists, the module loading strategy is completely decoupled from business code, enabling the system to dynamically adjust the module organization structure without modifying the source code. Then, by performing security verification on the structured JSON configuration file and extracting the functional attributes and runtime parameters of all modules to generate module feature identifiers, a computable mapping relationship between module configuration information and cache indexes can be established, providing a lightweight comparison basis for rapid matching and cross-node reuse. Second, based on dependencies and execution priority lists, an ordered queue is determined during module loading, and the module loading is performed simultaneously in a multi-level cache cluster based on module feature identifiers. Source configuration matching deeply couples dependency resolution, priority sorting, and distributed caching mechanisms, enabling modules to quickly reuse existing instances before loading, thus avoiding resource consumption from repeated resolution and loading across nodes. Then, an ordered queue selects loading modules, and pre-loading verification and independent execution are performed on these modules based on dependency relationships and cache matching results. Dependency readiness and cache instance validity checks are moved to before loading execution, ensuring that only modules that pass verification enter the instantiation process. An independent execution mechanism achieves state isolation and parallel initialization between modules. Finally, through the coordinated operation of the above configuration-driven, feature-based, ordered queue and multi-level cache matching, and pre-loading verification technologies, ordered on-demand loading and independent execution of modules are achieved, improving the startup response efficiency, resource reuse rate, and operational reliability of the modular system.

[0016] In summary, the technical solution adopted in this application can combine multi-level cache matching of module feature identifiers and pre-loading verification to realize the orderly on-demand loading and independent operation of modules, thereby improving the startup response efficiency of modular systems. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of the ordered dynamic module on-demand loading method based on structured JSON configuration provided in this application; Figure 2 This is an exemplary flowchart for determining module feature identifiers according to the present application; Figure 3 This is a schematic diagram of the architecture of a multi-level cache cluster provided in this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] Example 1: To better understand the technical solution of this application, the above technical solution will be described in detail below with reference to the accompanying drawings and specific embodiments. Figure 1 As shown in the figure, this is a flowchart of an ordered dynamic module on-demand loading method based on structured JSON configuration according to this embodiment of the present application. The loading method includes the following steps: In step S1, a structured JSON configuration file for the business node is constructed. The structured JSON configuration file includes a module queue, the dependencies of all modules, and an execution priority list.

[0021] In this embodiment, the structured JSON configuration file for the business node can be constructed in the following way: Obtain the business breakdown result of the business node, and divide the business function into multiple independent functional modules according to the business breakdown result to obtain the module queue; Assign a unique module identifier to all modules in the module queue, and configure the execution priority value and start / stop permission identifier for each functional module; The dependencies between functional modules are determined based on the business call chain. The module's unique identifier, the execution priority value, the start / stop permission identifier, and the dependency relationship are assembled in a structured JSON format to generate a structured JSON configuration file.

[0022] It should be noted that the structured JSON configuration file in this application refers to an external data file organized using a key-value pair hierarchical structure to define the module loading strategy. The structured JSON configuration file includes a module queue, the dependencies of all modules, and an execution priority list; it is used to drive the main program to load target modules sequentially and on demand during startup or runtime; the business decomposition result refers to the functional decomposition structure formed after dividing and defining the boundaries of all business functions of the business nodes. This functional decomposition structure records the hierarchical division relationship and boundary definition of business functions in tree or list form, and is used to guide the division of independent functional modules; the business call chain refers to the path description of the execution order and call flow between functional links when a business function processes a complete business request. This path description records the sequence of functional links that the request passes through from receipt to completion and the connection relationship between each link, and is used to determine the dependency direction between functional modules.

[0023] In practice, the process begins by retrieving the business breakdown results from the project planning document of each business node. This breakdown is a functional decomposition structure formed by dividing all business functions undertaken by the business node into domains. This structure records the hierarchical division and boundary definitions of business functions. Based on the breakdown results, the business functions are divided into multiple independent functional modules using the object-oriented single responsibility principle. Each independent functional module corresponds to a business processing capability that can be deployed and run independently, resulting in a module queue. Next, each functional module in the module queue is assigned a unique module identifier. This identifier uniquely identifies the module globally. Additionally, each module is configured with an execution priority value and a start / stop permission identifier. The execution priority value indicates the module's priority when multiple modules are waiting to be loaded simultaneously; a higher value indicates a higher priority. The start / stop permission identifier indicates whether the module is allowed to be loaded and run in the current business node's configuration. Finally, the dependencies between functional modules are determined based on the business call chain. The business call chain records the execution order and call flow of business functions when processing a complete business request. When the execution of the first functional module depends on the loading of the second functional module, a dependency relationship is established between the first and second functional modules. The direction of the dependency relationship is from the dependent party to the dependent party. The module unique identifier, execution priority value, start / stop permission identifier of each functional module, and the dependency relationship between each functional module are assembled according to the key-value hierarchical structure of the structured configuration file to generate a structured JSON configuration file.

[0024] It should be noted that the module queue refers to a collection of functional modules divided according to business function boundaries. Each functional module corresponds to an independent business processing capability. This collection of functional modules records all functional modules to be loaded by the current business node in list form, and is arranged in order according to the importance of the business function or the frequency of call. Each functional module in the module queue contains a unique module identifier, module name, start / stop status, set of running parameters, and loading classpath information. Among them, the unique module identifier is used to uniquely identify the identity of the functional module globally in the system. The module name is used to show the business meaning of the functional module to the operation and maintenance personnel. The start / stop status is used to indicate whether the functional module is allowed to be loaded and run in the current business node configuration. The set of running parameters is used to record the various configuration parameters required by the functional module during initialization. The loading classpath information is used to point to the binary storage location of the functional module in the program package, so that the loader can locate and load the binary bytecode of the module through the classpath at runtime. Through the above data structure definition of the module queue, the main program can traverse all modules to be loaded based on the queue when it starts.

[0025] In step S2, the structured JSON configuration file is security verified to obtain module configuration information. The functional attributes and running parameters of all modules are extracted from the module configuration information to generate module feature identifiers.

[0026] In this embodiment, the security verification of the structured JSON configuration file to obtain the module configuration information can be performed in the following manner: The structured JSON configuration file is then subjected to format validity checks and field integrity checks in sequence. After successful validation, the validated structured JSON configuration file is converted into a standardized file stream. The standardized file stream is parsed in layers to extract the configuration parameters and dependent resources of each module, thereby obtaining the module configuration information.

[0027] In practice, firstly, a structured data parser is used to read the structured JSON configuration file. The syntax of the JSON configuration file is validated for format validity. This validation checks whether the key-value pair hierarchy conforms to the syntax of structured data formats and whether the data types of each field match the expected data types. If the syntax is complete and the data types match, the validation passes. Next, after the format validation passes, a field integrity check is performed on the structured JSON configuration file. This check verifies whether the file contains a module queue field, a dependency field for each module, and an execution priority list field, and whether the values ​​of each field are within a reasonable range. If all required fields exist and their values ​​are reasonable, the field integrity check passes. Finally, the validated structured JSON configuration file is decoded into a character sequence according to the character encoding standard. The decoded character sequence is then used as a standardized file stream. A hierarchical parser is used to parse the standardized file stream layer by layer. First, the global configuration fields are extracted from the root level. Then, the module array is traversed to extract the configuration parameters and dependent resources of each functional module. All extracted configuration parameters and dependent resources are categorized and summarized according to the module's unique identifier to obtain the module configuration information.

[0028] It should be noted that a standardized file stream refers to the character sequence formed after decoding a validated structured JSON configuration file according to a character encoding standard. This character sequence removes unnecessary whitespace characters and comments from the original file, existing in a uniformly encoded plain text format, facilitating subsequent layer-by-layer parsing by the parsing engine. Module configuration information refers to the summary data set of configuration parameters and dependent resources of all functional modules extracted from the structured JSON configuration file, including each module's unique identifier, execution priority value, start / stop permission identifier, set of runtime parameters, loaded classpath information, and dependencies between modules.

[0029] Preferred, Reference Figure 2 As shown, this diagram is an exemplary flowchart for determining module feature identifiers according to the present application. In this embodiment, the extraction of functional attributes and operating parameters of all modules from the module configuration information to generate module feature identifiers can be achieved through the following steps: In step S21, the module configuration information is traversed to extract the functional attribute fields and running parameter fields of each module; In step S22, the functional attribute fields and running parameter fields of each module are serialized and concatenated to obtain the feature strings of each module; In step S23, a hash operation is performed on the feature string of each module to obtain the fixed-length hash value of each module. The fixed-length hash values ​​of all modules are associated and stored to obtain the module feature identifier.

[0030] In practice, firstly, a data traverser sequentially reads the records of each functional module in the module configuration information. From each functional module's record, functional attribute fields and runtime parameter fields are extracted. The functional attribute fields include a module type identifier and a business function description. The module type identifier represents the category to which the functional module belongs, and the business function description represents the business responsibilities undertaken by the functional module. The runtime parameter fields include module initialization parameters and resource dependency declarations. The module initialization parameters record the configuration items required when the functional module starts, and the resource dependency declarations record the names and version information of the external resources that the functional module depends on during runtime. Then, for each functional module, all field names and values ​​from the extracted functional attribute fields and runtime parameter fields are alternately concatenated in a fixed order: first, the name of one field is concatenated, then its value; then the name of the next field is concatenated, and so on, until all fields are processed, resulting in a string. This string is used as the feature string for the functional module. A feature string is generated for each functional module in this manner. Finally, a hash operation is performed on the feature string of each functional module to obtain the fixed-length hash value of the functional module. The module unique identifier of each functional module and the fixed-length hash value of the functional module are written into the local cache index table according to the key-value pair correspondence. That is, each record stores a module unique identifier and a fixed-length hash value, and the local cache index table is used as the module feature identifier.

[0031] It should be noted that the functional attribute fields in this application refer to information fields used to describe the basic attributes of functional modules. These fields include module type identifiers and business function descriptions, where the business function descriptions explain the business purpose of the functional module to operations and maintenance personnel. The runtime parameter fields refer to information fields used to describe the configuration information required for the functional module to run. These fields include module initialization parameters and resource dependency declarations, where the module initialization parameters provide configuration values ​​when the functional module starts. The module feature identifier refers to a local cache index table that stores the key-value pair correspondence between the unique identifiers of all functional modules and their fixed-length hash values. This table provides an index basis for performing same-source configuration matching in a multi-level cache cluster. By comparing the fixed-length hash values, it is possible to quickly determine whether the configuration content of two functional modules is completely consistent, without needing to compare the complete configuration information field by field.

[0032] In step S3, an ordered queue for module loading is determined based on the dependency relationship and the execution priority list. In the multi-level cache cluster, same-source configuration matching is performed based on the module feature identifier to obtain cache matching results.

[0033] In this embodiment, determining the ordered queue for module loading based on the dependencies and the execution priority list can be done in the following way: A module dependency graph is constructed based on the aforementioned dependency relationships; Loop detection and topology sorting are performed on the module dependency graph to obtain the loading order of each module; The loading order of each module is adjusted a second time based on the execution priority list to obtain an ordered queue for module loading.

[0034] In specific implementation, firstly, each functional module in the module configuration information is treated as a vertex in a directed graph, and dependencies are treated as edges. For any two functional modules, when the first functional module depends on the second functional module, a directed edge is established from the first functional module to the second functional module. This process is repeated to traverse all functional module dependencies and combine all vertices and directed edges to construct a module dependency graph. Then, a depth-first traversal algorithm is used to traverse all vertices in the module dependency graph. During the traversal, each vertex is marked with an access status value, including unvisited, currently being accessed, and access completed. Finally, the execution priority value of each functional module is obtained from the execution priority list. The loading order of each module is grouped according to the execution priority value. All functional modules in the same topological sorting layer belong to the same group. Within each group, the functional modules are rearranged according to their execution priority values ​​from high to low, while maintaining the original topological sorting layer order between different groups. All rearranged functional modules are then chained together according to the group order to obtain an ordered queue for module loading.

[0035] It should be noted that the module dependency graph in this application refers to a directed graph structure constructed with functional modules as vertices and the dependencies between modules as directed edges. This directed graph structure completely records the dependency directions between all functional modules, which is used to support subsequent loop detection and topology sorting operations. The access state value refers to the state value marked for each vertex during the depth-first traversal. The secondary adjustment refers to the operation of reordering functional modules within the same topology sorting layer according to their execution priority values ​​while keeping the order between topology sorting layers unchanged. This operation does not change the dependency constraints between modules, but only adjusts the loading order according to business importance within the same dependency layer. The ordered queue refers to the loading order list formed by arranging functional modules according to the topology sorting layer order and execution priority order. Each functional module in this list is accompanied by its unique module identifier and loading order number, which is used to guide the subsequent selection and loading of modules.

[0036] In this embodiment, the cache matching result obtained by performing same-origin configuration matching based on the module feature identifier in a multi-level cache cluster can be specifically achieved in the following manner: The module feature identifier is distributed to the cache nodes of the multi-level cache cluster; In the cache node, query the local cache space to see if there is an existing module instance that matches the module feature identifier; The existing module instances are summarized and marked for hits, generating cached matching results.

[0037] It should be noted that, in this embodiment, the multi-level cache cluster is a distributed three-level cache architecture, including a local node cache layer, a regional aggregation cache layer, and a global core cache layer. Preferably, refer to... Figure 3As shown in the figure, this is a schematic diagram of the architecture of the multi-level cache cluster provided in this application. When a lower-level cache misses, a query is initiated to the upper-level cache. The local node cache layer is deployed locally on the business node and includes a local cache pool. The local cache pool contains a module instance cache, a feature identifier index table, and an access frequency counter, used to store frequently accessed module instances on the current node. The feature identifier index table is used to quickly locate the target instance, and the access frequency counter is used to support the cache eviction policy. The regional aggregation cache layer is deployed on the regional aggregation node and is shared by multiple business nodes in the same region. It includes a regional cache pool. The regional cache pool contains shared module instances and cross-node access records, used to store shared module instances across multiple nodes within the region, enabling cross-node instance reuse within the region. The global core cache layer is deployed on the central node and is shared by all system nodes. It includes a global cache pool and a global management unit. The global cache pool contains a system-wide common module instance storage area, used to store standardized module instances common to the entire system. The global management unit includes a same-source deduplication engine and a scheduling manager. The same-source deduplication engine is used to identify duplicate module instances and perform global deduplication, while the scheduling manager is used to coordinate the storage, updating, and eviction scheduling of module instances.

[0038] In practice, firstly, the fixed-length hash value and unique identifier of each functional module are extracted from the module feature identifier. Using the fixed-length hash value as the query key, query requests are initiated to the multi-level cache cluster in the order of local node cache layer, regional aggregation cache layer, and global core cache layer. Upon receiving the query request, each cache node uses the fixed-length hash value as an index to search its local cache space for an existing module instance with the same fixed-length hash value. Then, during the search process at each cache node, the fixed-length hash value of the existing module instance read from its local cache space is compared bit by bit with the fixed-length hash value carried in the query request. If all bits of the two fixed-length hash values ​​are identical, the existing module instance is considered a successful match for the currently queried functional module, and the cache level and cache node address of the existing module instance are recorded. If any bit differs, the match fails, and the search continues for the next existing module instance in the cache node. Finally, the search results of all cache nodes are summarized. When a functional module has a successfully matched existing module instance in any level of cache node, the matching result of the functional module is marked as a hit. When a functional module does not have a successfully matched existing module instance in any level of cache node, the matching result of the functional module is marked as a miss. All functional modules are traversed and their hit status and the hierarchical position of the hit node are recorded respectively. The set of hit status records of all functional modules is used as the cache matching result.

[0039] It should be noted that the same-source configuration matching in this application refers to the process of determining whether the configuration content of a functional module already exists in a cache node based on the fixed-length hash value of the functional module in a multi-level cache cluster. The cache matching result is a summary data set recording the hit status of each functional module in the multi-level cache cluster. Each record contains at least the module's unique identifier, hit status flag, and cache level identifier of the hit node. The hit status flag is used to indicate whether a module instance with the same configuration already exists in the cache, and the cache level identifier of the hit node is used to indicate whether the functional module is found in the local node cache layer, the regional aggregated cache layer, or the global core cache layer when it hits the cache.

[0040] In step S4, a loading module is selected through the ordered queue, and the loading module is subjected to pre-loading verification and independent operation based on the dependency relationship and the cache matching result.

[0041] In this embodiment, the selection of the loading module through the ordered queue can be carried out in the following manner: Traverse the ordered queue sequentially and read the dependency list of the module to be loaded. Verify whether all dependent modules in the dependency list of the currently unloaded module have been loaded and registered. If the verification is successful, the currently unloaded module will be loaded.

[0042] In practice, firstly, the functional module with the highest order in the ordered queue is obtained as the current module to be loaded. Then, its corresponding dependency list is read from the current module to be loaded. The dependency list records the unique identifiers of all the prerequisite functional modules that must be loaded before the current module to be loaded can be loaded. The dependency list is traversed in order. For each unique identifier of a module, it is checked whether the prerequisite functional module corresponding to the unique identifier is in the current set of loaded modules. If it exists in the set of loaded modules, the traversal continues to the next unique identifier of the module. If it does not exist in the set of loaded modules, the traversal stops and the unique identifier of the missing prerequisite functional module is recorded. Then, when all module unique identifiers in the dependency list exist in the set of loaded modules, it is determined that all dependent modules of the current module to be loaded have been loaded and registered. The current module to be loaded is marked as a loaded module and added to the set of loaded modules. When any module unique identifier in the dependency list does not exist in the set of loaded modules, it is determined that the current module to be loaded has not yet met all dependency conditions. Processing of the current module to be loaded is paused, and the next functional module is processed according to the order of the ordered queue.

[0043] It should be noted that the dependency list in this application refers to a list that records the unique identifiers of all prerequisite functional modules that must be loaded before the functional module can be fully loaded. This list originates from the dependency relationships between functional modules defined in the structured JSON configuration file. Each functional module corresponds to a dependency list, and the order in the dependency list does not affect the loading verification result; it is only used to record the dependency set. Loading registration refers to the process where, after a functional module passes the pre-loading verification, the loader completes the loading of binary bytecode, the creation of class instances, and the injection of initialization parameters, and records the unique identifiers of functional modules that successfully complete the above operations in the set of loaded modules. The process involves several steps. First, after a functional module completes loading and registration, it gains the ability to be called by other functional modules. Dependent modules are those recorded in the dependency list that must be loaded before the current functional module can be loaded. Only after all dependent modules have been loaded and registered can the current functional module be loaded. Second, pre-loading verification checks whether all dependent modules in the dependency list of the module to be loaded have been loaded and registered before the binary bytecode loading and class instance creation of the functional module are executed. Pre-loading verification ensures that the loading order of functional modules conforms to dependency requirements, preventing execution exceptions caused by dependent modules not yet being loaded and registered.

[0044] In this embodiment, the pre-loading verification and independent operation of the loading module based on the dependency relationship and the cache matching result can be carried out in the following way: Based on the cache matching results, a pre-loading check is performed on the loading module to confirm the version compatibility and parameter adaptability of the cache instance; After the verification is successful, the loading module that hits the cache directly mounts the cache instance and performs incremental parameter updates based on the current module configuration; The loaded module that misses the cache performs reflection instantiation and completes the injection of initialization parameters; After the module is loaded, each loaded module is controlled to initialize and run independently according to its own business logic, and the newly generated module instance is synchronously written to the multi-level cache cluster.

[0045] In practice, the process begins by obtaining the unique identifier of the loaded module. Then, the cache matching results are used to query the hit status flag of the loaded module and the cache level identifier of the hit node. If the hit status flag indicates a hit, the stored module instance is read from the corresponding cache level node based on the cache level identifier. The version number of the stored module instance is compared with the version number in the loaded module's configuration information. Simultaneously, the set of registered parameter fields of the stored module instance is compared with the set of running parameter fields in the loaded module's configuration information. If the version numbers match and the set of registered parameter fields contains all field names from the set of running parameter fields, the version compatibility check and parameter adaptation check are considered passed. If the hit status flag indicates a miss, the version compatibility check and parameter adaptation check are skipped. Then, when the hit status is marked as hit and the verification passes, the binary byte data of the existing module instance is retrieved from the cache level where the hit node is located. The binary byte data is loaded into the runtime environment of the current business node to complete the instance mounting. Based on the running parameter fields in the module configuration information of the loaded module, the field name and field value of each running parameter field are extracted. The registered parameter field with the same field name is searched in the set of registered parameter fields of the existing module instance, and the field value is written into the registered parameter field to complete the incremental parameter update. When the hit status is marked as miss, based on the loading classpath information in the module configuration information of the loaded module, the binary bytecode storage location pointed to by the loading classpath information is located through the class loader. The binary bytecode is read from the binary bytecode storage location, the class instantiation method is called to parse the binary bytecode and create a new instance. The running parameter fields in the module configuration information of the loaded module are retrieved, and all field names and field values ​​in the running parameter fields are passed into the new instance through the constructor or property injection to complete the initialization parameter injection. Finally, after the loading module completes instance mounting or reflection instantiation, the loading module's module initialization method is called, allowing the loading module to independently perform initialization operations according to its own business logic. At the same time, the loading module's unique module identifier, fixed-length hash value, and module instance data are assembled into key-value pair records. Using the fixed-length hash value as the key and the module instance data as the value, the key-value pair records are written to the local node cache layer of the multi-level cache cluster.

[0046] It should be noted that the version compatibility check in this application refers to the process of checking the consistency between the version number of the existing module instance and the version number in the module configuration information of the module to be loaded after retrieving the existing module instance from the cache node. This is used to confirm whether the module instance in the cache is consistent with the module version required by the current configuration, avoiding abnormal module operation due to version mismatch. The parameter adaptability check refers to the process of checking the inclusion of the set of registered parameter fields of the existing module instance and the set of running parameter fields in the module configuration information of the module to be loaded after retrieving the existing module instance from the cache node. This is used to confirm whether the version of the existing module instance in the cache is consistent with the version number in the current configuration information of the module, avoiding abnormal module operation due to version mismatch. The parameters registered by the module instance can cover all the running parameters required by the current configuration, avoiding abnormal module operation due to missing parameters; incremental parameter update means that when the cache is hit, instead of recreating the module instance, the values ​​of the running parameter fields in the current configuration are updated to the corresponding parameter fields of the existing module instance, so that the existing module instance obtains the new parameter configuration while maintaining the original instance state; independent initialization operation means that after the module is loaded, each module independently executes its own defined initialization method, and the initialization process of each module does not interfere with each other. An initialization failure of one module will not affect the operation of other loaded modules.

[0047] In summary, the technical solution adopted in this application can combine multi-level cache matching of module feature identifiers and pre-loading verification to realize the orderly on-demand loading and independent operation of modules, thereby improving the startup response efficiency of modular systems.

[0048] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

Claims

1. A method for loading ordered dynamic modules on demand based on structured JSON configuration, characterized in that, The loading method includes the following steps: Construct a structured JSON configuration file for the business nodes. The structured JSON configuration file includes a module queue, the dependencies of all modules, and a list of execution priorities. The structured JSON configuration file is subjected to security verification to obtain module configuration information. The functional attributes and running parameters of all modules are extracted from the module configuration information to generate module feature identifiers. Based on the dependencies and the execution priority list, an ordered queue is determined when the module is loaded. In a multi-level cache cluster, same-origin configuration matching is performed based on the module feature identifier to obtain cache matching results. The loading module is selected through the ordered queue, and the loading module is pre-loaded and run independently based on the dependency relationship and the cache matching result.

2. The method for on-demand loading of ordered dynamic modules based on structured JSON configuration as described in claim 1, characterized in that, The specific steps involved in constructing the structured JSON configuration file for the business nodes are as follows: Obtain the business breakdown result of the business node, and divide the business function into multiple independent functional modules according to the business breakdown result to obtain the module queue; Assign a unique module identifier to all modules in the module queue, and configure the execution priority value and start / stop permission identifier for each functional module; The dependencies between functional modules are determined based on the business call chain. The module's unique identifier, the execution priority value, the start / stop permission identifier, and the dependency relationship are assembled in a structured JSON format to generate a structured JSON configuration file.

3. The method for on-demand loading of ordered dynamic modules based on structured JSON configuration as described in claim 1, characterized in that, The security verification of the structured JSON configuration file yields the following module configuration information: The structured JSON configuration file is then subjected to format validity checks and field integrity checks in sequence. After successful validation, the validated structured JSON configuration file is converted into a standardized file stream. The standardized file stream is parsed in layers to extract the configuration parameters and dependent resources of each module, thereby obtaining the module configuration information.

4. The method for on-demand loading of ordered dynamic modules based on structured JSON configuration as described in claim 1, characterized in that, Extracting the functional attributes and operating parameters of all modules from the module configuration information to generate module feature identifiers specifically includes: Iterate through the module configuration information and extract the functional attribute fields and running parameter fields of each module; The functional attribute fields and running parameter fields of each module are serialized and concatenated to obtain the feature strings of each module; Perform a hash operation on the feature strings of each module to obtain a fixed-length hash value for each module. Then, associate and store the fixed-length hash values ​​of all modules to obtain the module feature identifier.

5. The method for on-demand loading of ordered dynamic modules based on structured JSON configuration as described in claim 1, characterized in that, Determining the ordered queue for module loading based on the dependencies and the execution priority list specifically includes: A module dependency graph is constructed based on the aforementioned dependency relationships; Loop detection and topology sorting are performed on the module dependency graph to obtain the loading order of each module; The loading order of each module is adjusted a second time based on the execution priority list to obtain an ordered queue for module loading.

6. The method for on-demand loading of ordered dynamic modules based on structured JSON configuration as described in claim 1, characterized in that, In a multi-level cache cluster, matching based on the module feature identifier to obtain cache matching results specifically includes: The module feature identifier is distributed to the cache nodes of the multi-level cache cluster; In the cache node, query the local cache space to see if there is an existing module instance that matches the module feature identifier; The existing module instances are summarized and marked for hits, generating cached matching results.

7. The method for on-demand loading of ordered dynamic modules based on structured JSON configuration as described in claim 1, characterized in that, Selecting a loading module through the ordered queue specifically includes: Traverse the ordered queue sequentially and read the dependency list of the module to be loaded. Verify whether all dependent modules in the dependency list of the currently unloaded module have been loaded and registered. If the verification is successful, the currently unloaded module will be loaded.

8. The method for on-demand loading of ordered dynamic modules based on structured JSON configuration as described in claim 1, characterized in that, The pre-loading verification and independent operation of the loading module based on the dependency relationship and the cache matching result specifically includes: Based on the cache matching results, a pre-loading check is performed on the loading module to confirm the version compatibility and parameter adaptability of the cache instance; After the verification is successful, the loading module that hits the cache directly mounts the cache instance and performs incremental parameter updates based on the current module configuration; The loaded module that misses the cache performs reflection instantiation and completes the injection of initialization parameters; After the module is loaded, each loaded module is controlled to initialize and run independently according to its own business logic, and the newly generated module instance is synchronously written to the multi-level cache cluster.

9. The method for on-demand loading of ordered dynamic modules based on structured JSON configuration as described in claim 1, characterized in that, The multi-level cache cluster is a distributed three-level cache architecture, including a local node cache layer, a regional aggregation cache layer, and a global core cache layer. The local node cache layer stores frequently invoked module instances of the current business node; The regional aggregation cache layer stores module instances shared by multiple nodes within the corresponding geographical region; The global core cache layer stores standardized module instances that are common to the entire system and performs deduplication and scheduling management of the global cache.

10. The method for on-demand loading of ordered dynamic modules based on structured JSON configuration as described in claim 1, characterized in that, The module queue refers to a collection of functional modules divided according to business function boundaries. Each functional module corresponds to an independent business processing capability and includes a unique module identifier, module name, start / stop status, set of running parameters, and loading classpath information.

Images