Microservice aggregation system and microservice aggregation method

Abstract

A microservice aggregation system and a microservice aggregation method. The microservice aggregation system comprises a storage apparatus and a processor. The storage apparatus is used for storing a request preprocessing module, a module loading module and a service calling module. The processor is coupled to the storage apparatus, and is used for executing the request preprocessing module, the module loading module and the service calling module. The request preprocessing module performs request preprocessing on a service request, so as to obtain request data corresponding to the service request. The module loading module parses the request data, so as to obtain module information corresponding to the request data, and the module loading module determines whether the module information has been loaded into the storage apparatus. In response to the module information not having been loaded into the storage apparatus, the module loading module loads a module and service information on the basis of the module information. The service calling module calls a corresponding microservice on the basis of the service information.

Description

Microservice merging system and microservice merging methods

[0001] This application claims priority to Chinese Patent Application No. 202411449489.0, filed on October 16, 2024, entitled “Microservice Merging System and Microservice Merging Method”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This invention relates to a microservice deployment and processing technology, and in particular to a microservice merging system and a microservice merging method. Background Technology

[0003] Generally, when enterprises or system users have high requirements for data security, they will consider storing data and performing application operations locally. However, deploying a microservice architecture privately leads to high hardware and maintenance costs, as well as high complexity during deployment and adjustments. Furthermore, enterprise users have high requirements for data consistency, which also increases the difficulty of setting up and privatizing microservices. Summary of the Invention

[0004] This invention relates to a microservice merging system and method, which can merge microservices into a main project, thereby ensuring data consistency.

[0005] According to an embodiment of the present invention, the microservice merging system of the present invention includes a storage device and a processor. The storage device is used to store a request preprocessing module, a module loading module, and a service invocation module. The processor is coupled to the storage device and is used to execute the request preprocessing module, the module loading module, and the service invocation module. The request preprocessing module performs request preprocessing on service requests to obtain request data for the corresponding service requests. The module loading module parses the request data to obtain module information corresponding to the request data, and the module loading module determines whether the module information has been loaded into the storage device. In response to the module information not being loaded into the storage device, the module loading module loads the module and service information according to the module information. The service invocation module invokes the corresponding microservice according to the service information.

[0006] According to an embodiment of the present invention, the microservice merging method of the present invention includes the following steps: performing request preprocessing on service requests through a processor-executed request preprocessing module, so that the request preprocessing module obtains the request data corresponding to the service request; parsing the request data through a processor-executed module loading module, so that the module loading module obtains the module information corresponding to the request data, and the module loading module determines whether the module information has been loaded into the storage device; when the module information has not been loaded into the storage device, loading the module and service information according to the module information through the module loading module; and invoking the corresponding microservice according to the service information through a processor-executed service invocation module.

[0007] Based on the above, the microservice merging system and method of the present invention effectively provide a lightweight deployment method through differential configuration and the setting of third-party modules, thereby reducing the complexity and cost of microservices.

[0008] To make the above features and advantages of the present invention more apparent and understandable, specific embodiments are described below in conjunction with the accompanying drawings. Attached Figure Description

[0009] Figure 1 is a schematic diagram of a microservice merging system according to an embodiment of the present invention;

[0010] Figure 2 is a service call flowchart of a microservice merging method according to an embodiment of the present invention;

[0011] Figure 3 is a schematic diagram of a microservice merging system and multiple modules according to an embodiment of the present invention;

[0012] Figure 4 is a flowchart of the merging module of a microservice merging method according to an embodiment of the present invention;

[0013] Figure 5 is a schematic diagram of module merging in a microservice merging method according to an embodiment of the present invention;

[0014] Figure 6 is a schematic diagram of service invocation in a microservice merging method according to an embodiment of the present invention;

[0015] Figure 7 is a schematic diagram of the system architecture of a microservice merging system according to an exemplary embodiment of the present invention.

[0016] Figure Label Explanation: 100: Microservice merging system; 110: Processor; 120: Storage device; 121: Request preprocessing module; 122: Module loading module; 123: Service invocation module; 124: System startup module; 125: Merging module; 126: Third-party module analysis module; 510: Module before merging; 511: Project A; 512: Project B; 513: Project N; 520: Merged module; 521: Main project X; 522: Application-level configuration; 523: Third-party module; 524: Module A; 525: Module B; 526: Module N; 600: Microservice merging system; 610: Microservice - Caller; 620: Microservice - Service Provider; 630: Service name; 700: System architecture of the microservice merging system; 710: Case layer; 720: Industry Layer; 730: Application Layer; 731: Module A; 732: Module Configuration File; 733: Message File; 734: Interface File; 735: Module B; 736: Module Configuration File; 737: Message File; 738: Interface File; 740: Third-Party Module; 741: Application Configuration File; 742: Application Message File; 750: Platform Layer; 751: Platform Configuration File; 752: Message File; 753: Platform JAR Package; S210~S250, S410~S450, S611~S613, S621~S623: Steps. Detailed Implementation

[0017] Reference will now be made in detail to exemplary embodiments of the invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same element symbols are used in the drawings and description to denote the same or similar parts.

[0018] Figure 1 is a schematic diagram of a microservice merging system according to an embodiment of the present invention. Referring to Figure 1, the microservice merging system 100 includes a processor 110 and a storage device 120. The processor 110 is coupled to the storage device 120 and a business process system. The microservice merging system 100 may also include a communication interface or data transmission interface with actual circuit elements, enabling the processor 110 to communicate or transmit data with external business systems, user interfaces, application programming interfaces (APIs), or databases. In this embodiment, the microservice merging system 100 may be implemented, for example, on a cloud server, a private server within an enterprise, or a data center within an enterprise.

[0019] In this embodiment, the processor 110 of the microservice merging system 100 may include, for example, a central processing unit (CPU), or other programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable logic devices (PLDs), other similar processing circuits, or combinations of these devices.

[0020] Storage device 120 may also implement a remote cloud storage service or a local data storage service. Storage device 120 may include memory and / or a database, wherein the memory may be, for example, non-volatile memory (NVM). Storage device 120 may store related programs, modules, systems, or algorithms for implementing the embodiments of the present invention, for access and execution by processor 110 to implement the related functions and operations described in the embodiments of the present invention.

[0021] Figure 2 is a service call flowchart of a microservice merging method according to an embodiment of the present invention. Figure 3 is a schematic diagram of a microservice merging system and multiple modules according to an embodiment of the present invention. Referring first to Figures 1 and 2, the storage device 120 can store a request preprocessing module 121, a module loading module 122, a service call module 123, a system startup module 124, a merging module 125, and a third-party module analysis module 126. The request preprocessing module 121, the module loading module 122, the service call module 123, the system startup module 124, the merging module 125, and the third-party module analysis module 126 can be implemented, for example, in programming languages ​​such as JSON (JavaScript Object Notation), Extensible Markup Language (XML), or YAML, but the present invention is not limited thereto.

[0022] Referring again to Figures 1 and 2, the microservice merging system 100 executes the following steps S210 to S250. In step S210, the processor 110 receives a service request and then executes the request preprocessing module 121 to preprocess the service request so that the request preprocessing module 121 obtains the request data corresponding to the service request. The request data includes a request header, a request body, and a context. In one embodiment, the request preprocessing module 121 may include a request filter and a request controller, and the request preprocessing steps include filtering external requests (e.g., service requests) through the request filter for authentication and logging, and then the request controller receives the filtered external request and performs interface forwarding of the request. Next, the request preprocessing module 121 organizes the context of the service request and sends the request header, request body, and organized context of the service request to the module loading module 122. The organized context may be based on the service request, recording information related to the service request, such as the logged-in user, login time, identity information, permission information, or tenant information, into the organized context.

[0023] In step S220, the processor 110 may execute the module loading module 122 to parse the request data and obtain the module information corresponding to the request data. In this embodiment, the module loading module 122 may parse the context in the request data according to routing rules to obtain the module information. In step S230, the module loading module 122 determines whether the module information has been loaded into the storage device 120.

[0024] In step S240, in response to the module information not being loaded into storage device 120, module loading module 122 loads the module and service information according to the module information. In one embodiment, the step of loading the module and service information according to the module information may include: loading the module, module object (Bean), and service information (e.g., module-level service) according to the module information by module loading module 122. Furthermore, module loading module 122 caches service information in storage device 120, then loads the corresponding module information into storage device 120, and updates the module service list in storage device 120. Next, in response to the module information being loaded into storage device 120, module loading module 122 inputs service information (e.g., service name) into service invocation module 123. In other words, when module information has been loaded into storage device 120, module loading module 122 inputs the service name corresponding to the requested data into service invocation module 123.

[0025] In step S250, the processor 110 can execute the service invocation module 123 to invoke the corresponding microservice based on the service information. In one embodiment, invoking the corresponding microservice based on the service information may include the following steps: the service invocation module 123 parses the context based on the service name of the service information to obtain the corresponding service interface. Thus, the service invocation module 123 matches the corresponding microservice based on the service interface. Next, the service invocation module 123 determines whether the microservice includes unparsed module information. If the microservice does not include unparsed module information, the service invocation module 123 invokes the microservice. If the microservice includes unparsed module information, the module loading module 122 parses the unparsed module information to repeat step S240, loading the relevant service into the storage device 120 based on the unparsed module information.

[0026] Figure 4 is a flowchart of the merging module of a microservice merging method according to an embodiment of the present invention. In this embodiment, the storage device 120 may further include a system startup module 124, a merging module 125, and a third-party module analysis module 126. The processor 110 can execute the system startup module 124, the merging module 125, and the third-party module analysis module 126, and receive merging instructions sent by the user to merge the corresponding modules. For example, the user can send the merging instruction to the processor 110 according to a communication interface or a data transmission interface. Next, referring to Figures 3 and 4, the microservice merging system 100 executes the following steps S410 to S450. In step S410, the system startup module 124 obtains the corresponding code from the file server according to the merging instruction, thereby obtaining multiple sub-project modules. The merging instruction includes an address. In other words, the system startup module 124 pulls the corresponding code from the file server based on the address.

[0027] In one embodiment, the file server may be, for example, a Git server, used to store code archives. The merge instruction includes main project information and sub-project information. With this configuration, the step of obtaining the corresponding code from the file server according to the merge instruction may include the following steps: The system startup module 124 obtains the sub-project code, sub-project configuration, and sub-project third-party dependencies from the file server based on the sub-project information. The system startup module 124 also obtains the main project code, configuration information, and third-party dependency information containing the sub-project modules based on the sub-project code, sub-project configuration, and sub-project third-party dependencies. Thus, the system startup module 124 extracts the sub-project code, sub-project configuration, and third-party dependencies into the main project, thereby obtaining a main project module including multiple sub-project modules. Furthermore, the system startup module 124 compiles and packages the main project code, configuration information, and third-party dependency information including the sub-projects into the storage device 120.

[0028] In step S420, the merging module 125 adjusts the project object model (POM) of the parent module (i.e., the main module) corresponding to the multiple sub-project modules. Specifically, the merging module 125 adjusts the POM file of the sub-project modules (i.e., the modules to be merged) to the POM file of the parent (i.e., the main project), thereby making these sub-project modules recorded as belonging to the parent module (i.e., the main project module). In step S430, the merging module 125 merges the sub-project modules to generate a compressed file. The compressed file can be a JAR file. In one embodiment, the step of merging sub-project modules to generate a compressed file may include: determining whether the multiple sub-project modules already exist in the storage device 120 by the merging module 125. When the multiple sub-project modules are already stored / exist in the storage device 120, the merging module 125 compresses the multiple sub-project modules into a compressed file. On the other hand, when the multiple sub-project modules do not exist in the storage device 120, the merging module 125 merges the configuration information and multilingual information of the multiple sub-project modules to generate a compressed file. In other words, the merging module 125 merges the configuration files of the sub-project modules and the multilingual information (i.e., multilingual files) of the sub-project modules respectively to obtain the sub-module configuration items (i.e., the configuration files of the sub-project modules) and the sub-module multilingual information (i.e., the multilingual information of the sub-project modules), and then merges and compresses the sub-module configuration items and the sub-module multilingual information into a compressed file, thereby completing the merging of multiple modules.

[0029] Figure 5 is a schematic diagram of module merging in a microservice merging method according to an embodiment of the present invention. Referring to Figures 3 to 5, before merging, module 510 has multiple project modules, such as project A 511, project B 512 to project N 513, etc. After the above steps S410 to S430 of the microservice merging method, multiple projects corresponding to user instructions can be merged into the merged module 520, and the merged module 520 includes a main project module (e.g., main project X 521). As shown in Figure 5, main project X 521 may include application-level configuration 522, third-party module 523, module A 524, module B 525, and module N 526, where module A 524 is project A 511 after merging and compilation packaging, module B 525 is project B 512 after merging and compilation packaging, and similarly, module N 526 is project N 513 after merging and compilation packaging. It's worth noting that application-level configuration 522 stores the differential configurations between multiple sub-project modules (e.g., module A 524, module B 525, and module N 526). Third-party module 523 stores open-source components commonly used by multiple sub-project modules, such as database connection components, encryption components, email sending components, or publishing components. With this configuration, the microservice merging system 100, through application-level configuration 522, allows multiple sub-projects to execute and be developed independently at the module layer. Therefore, when merging or adjusting a single sub-project module, it reduces developer workload and the difficulty and complexity of adjustments and merging.

[0030] In step S440, the third-party module analysis module 126 merges the third-party dependency lists from multiple sub-project modules. In other words, the third-party module analysis module 126 merges the third-party Jar package dependencies of multiple projects in the application layer, that is, merges the application-level third-party Jar package dependencies to generate a merged total third-party dependency list. Next, in step S450, the third-party module analysis module 126 retrieves the latest version of the third-party dependency list from the third-party dependency lists of multiple sub-project modules.

[0031] In one embodiment, the step of retrieving the latest version of the third-party dependency list from multiple sub-project modules may include: the third-party module analysis module 126 determining whether the versions of the third-party dependency lists (i.e., the merged total third-party dependency list) in the multiple sub-project modules are the same. When the versions are different, the third-party module analysis module 126 retrieves the latest version of the third-party dependency list from the multiple sub-project modules as the third-party dependency version information to generate the third-party dependency version information after retrieving the latest version. When the versions are the same, the third-party module analysis module 126 stores the total third-party dependency list, which is a list (i.e., a list) generated after merging the third-party dependency lists in multiple sub-project modules.

[0032] Figure 6 is a schematic diagram of a service call in a microservice merging method according to an embodiment of the present invention. Referring to Figure 6, the microservice merging system 600 can perform intra-process calls, i.e., internal calls. As shown in Figure 6, the microservice merging system 600 can execute the following steps S611 to S613 and steps S621 to S623. In step S611, the microservice caller 610 (e.g., module A) initiates a service call request. Next, in step S613, the microservice caller 610 determines whether the service corresponding to the service call request is already stored in the system based on the service instance list. In response to the service instance list including the corresponding service, in step S612, the microservice caller 610 searches for the corresponding local service name 630 based on the service annotation. Then, the microservice caller 610 sends the service name 630 to the microservice service provider 620, which may be, for example, module B. In step S621, the microservice provider 620 scans the local module based on the service name 630, and in step S622, further scans the module's Enterprise Application Integration (EAI) service. In step S623, the microservice provider 620 caches the corresponding service container and then executes the microservice for the corresponding service request. In this way, through the settings of internal service calls, the microservice merging system 600 can make the service name 630 more semantic and ensure consistency, while eliminating the need to register the address of each microservice and its corresponding microservice in external storage or external components.

[0033] Figure 7 is a schematic diagram of the system architecture of a microservice merging system according to an exemplary embodiment of the present invention. Referring to Figure 7, the system architecture 700 of the microservice merging system includes a platform layer 750, an application layer 730, an industry layer 720, and a case layer 710. The platform layer 750 includes a service invocation framework based on an Enterprise Application Integration (EAI) architecture, enabling the microservice merging system to execute internal service calls based on the EAI architecture. The platform layer 750 is provided with a platform configuration file 751, a message file 752, and a platform JAR package 753. The platform JAR package 753 can be a platform compressed file. The industry layer 720 includes multiple industry characteristic information, including differential configuration files and industry characteristic codes. Industry characteristic information may be, for example, industry terminology used in the plastics industry, such as the plastics industry collectively referring to product numbers and names as "brand names." Industry characteristic codes are, for example, codes corresponding to industry characteristic information. The case layer 710 includes case attribute information. With this configuration, users can write case configuration files and case characteristic codes into the case attribute information according to the differences of each case. Application layer 730 stores third-party modules 740, application configuration files 741, and application message files 742. In this embodiment, the compressed file includes module information, which includes a main project module. Multiple sub-project modules within the main project module are stored in application layer 730 of the system architecture, and application layer 730 stores multiple independent main project modules. Each main project module includes a storage block used to store configuration files (e.g., module configuration files 732, 736), message files (733, 737), and interface files (734, 738) for its multiple sub-project modules. The message files include multilingual information.

[0034] In summary, the microservice merging system and method of the present invention can merge multiple microservices as sub-project modules into a new independent service. Furthermore, by treating the independent service as the main project module, the multiple merged microservices are set up as independent projects at the same level, effectively reducing the difficulty of merging and adjustment, and lowering operation and maintenance costs. In other words, the microservice merging system 100, through differential configuration and the setting of third-party modules, effectively provides a lightweight deployment method while reducing deployment complexity and costs.

[0035] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A microservice merging system, characterized by, include: Storage device for storing the request preprocessing module, the module loading module, and the service invocation module; as well as The processor, coupled to the storage device, executes the request preprocessing module, the module loading module, and the service invocation module, and receives service requests. The request preprocessing module performs request preprocessing on the service request to obtain the request data corresponding to the service request. The module loading module parses the request data to obtain module information corresponding to the request data, and the module loading module determines whether the module information has been loaded into the storage device. In response to the module information not being loaded into the storage device, the module loading module loads the module and service information according to the module information. The service invocation module invokes the corresponding microservice based on the service information. 2.The microservice merging system of claim 1, wherein, In response to the module information being loaded into the storage device, the module loading module inputs the service information into the service invocation module. 3.The microservice merging system of claim 1, wherein, The module loading module loads the module, module object, and service information according to the module information, and caches the service information in the storage device, thereby updating the module service list in the storage device.

4. The microservice merging system of claim 1, wherein, The service invocation module parses the context based on the service name in the service information to obtain the corresponding service interface. The service invocation module matches the service interface to the corresponding microservice. The service invocation module determines whether the microservice includes unparsed module information. In response to the microservice not including unresolved module information, the service invocation module invokes the microservice. In response to the microservice including unparsed module information, the module loading module parses the unparsed module information to load the relevant service into the storage device.

5. The microservice merging system of claim 1, wherein, The system architecture of the microservice merging system includes a platform layer, an application layer, an industry layer, and a case layer. The platform layer includes a service invocation framework based on an enterprise application integration architecture, and the microservice merging system executes internal service calls based on the enterprise application integration architecture. The industry layer includes multiple industry characteristic information, which includes differential configuration files and industry characteristic codes. The case layer includes case attribute information.

6. The microservice merging system of claim 1, wherein, The storage device also stores a system startup module, a merging module, and a third-party module analysis module, wherein the processor executes the system startup module, the merging module, and the third-party module analysis module, and receives merging instructions. The system startup module obtains the corresponding code from the file server according to the merge instruction, thereby obtaining multiple sub-project modules. The merging module adjusts the parent project object model corresponding to the multiple sub-project modules and merges the sub-project modules to generate a compressed file. The third-party module analysis module merges the third-party dependency lists from the multiple sub-project modules and takes the latest version of the third-party dependency list from the multiple sub-project modules.

7. The microservice merging system of claim 6, wherein, The merge instruction includes main project information and sub-project information. The system startup module retrieves the sub-project code, sub-project configuration, and sub-project third-party dependencies from the file server based on the sub-project information. The system startup module obtains the main project code, configuration information, and third-party dependency information containing the sub-project modules based on the sub-project code, the sub-project configuration, and the sub-project third-party dependencies, and then obtains the main project module including the multiple sub-project modules.

8. The microservice merging system of claim 6, wherein, The merging module determines whether the multiple sub-project modules already exist in the storage device. In response to the fact that the multiple sub-project modules already exist in the storage device, the merging module compresses the multiple sub-project modules into the compressed file. In response to the fact that the multiple sub-project modules do not exist in the storage device, the merging module merges the configuration information and multilingual information of the multiple sub-project modules to generate the compressed file. 9.The microservice merging system of claim 6, wherein, The third-party module analysis module determines whether the versions of the third-party dependency lists in the multiple sub-project modules are the same. In response to the different versions, the third-party module analysis module takes the latest version of the third-party dependency list from the third-party dependency lists of the multiple sub-project modules as the third-party dependency version information. In response to the same version, the third-party module analysis module stores a total list of third-party dependencies, which is a list generated by merging the third-party dependency lists from the multiple sub-project modules.

10. The microservice merging system of claim 6, wherein, The compressed file includes the module information, which includes the main project module. The multiple sub-project modules within the main project module are stored in the application layer of the system architecture, and the application layer stores multiple independent main project modules. The main project module includes a storage block, which stores the configuration files, message files, and interface files of its multiple sub-project modules. The application layer stores third-party modules, application configuration files, and application message files. 11.A micro-service merging method, characterized in that, include: The processor executes a request preprocessing module to preprocess the service request, so that the request preprocessing module obtains the request data corresponding to the service request. The processor executes the module loading module to parse the request data, so that the module loading module obtains the module information corresponding to the request data, and the module loading module determines whether the module information has been loaded into the storage device; When the module information is not loaded into the storage device, the module loading module loads the module and service information according to the module information. as well as The processor executes the service invocation module to invoke the corresponding microservice based on the service information.

12. The method of claim 11, wherein, Also includes: Once the module information has been loaded into the storage device, the service information is input into the service invocation module through the module loading module.

13. The method of claim 11, wherein, The steps of loading the module and the service information based on the module information include: The module loading module loads the module, module object, and service information according to the module information, and caches the service information in the storage device, thereby updating the module service list in the storage device.

14. The method of claim 11, wherein, The steps for invoking the corresponding microservice based on the service information include: The service invocation module parses the context based on the service name in the service information to obtain the corresponding service interface. The service invocation module matches the service interface to the corresponding microservice; and The service call module determines whether the microservice includes unparsed module information. When the microservice does not include unresolved module information, the service invocation module invokes the microservice. When the microservice includes unparsed module information, the module loading module parses the unparsed module information to load the relevant service into the storage device.

15. The method of claim 11, wherein, The method is implemented in the system, and the system architecture includes a platform layer, an application layer, an industry layer, and a case layer. The platform layer includes a service invocation framework based on an enterprise application integration architecture, wherein the microservice merging system executes internal service invocations based on the enterprise application integration architecture. The industry layer includes multiple industry characteristic information, which includes differential configuration files and industry characteristic codes. The case layer includes case attribute information.

16. The method of claim 11, wherein, Also includes: The processor executes the system startup module to obtain the corresponding code from the file server according to the merge instruction, so that the system startup module can obtain multiple sub-project modules; The processor executes the merging module to adjust the parent project object model corresponding to the multiple sub-project modules, and merges the sub-project modules to generate a compressed file; as well as The processor executes a third-party module analysis module to merge the third-party dependency lists from the multiple sub-project modules, and retrieves the latest version of the third-party dependency list from the multiple sub-project modules.

17. The method of claim 16, wherein, The merge instruction includes main project information and sub-project information. The step of obtaining the corresponding code from the file server according to the merge instruction includes: The system startup module retrieves the sub-project code, sub-project configuration, and sub-project third-party dependencies from the file server based on the sub-project information; and The system startup module obtains the main project code, configuration information, and third-party dependency information containing the sub-project modules based on the sub-project code, the sub-project configuration, and the sub-project third-party dependencies, and then obtains the main project module including the multiple sub-project modules.

18. The method of claim 16, wherein, The steps of merging the sub-project modules to generate a compressed file include: The merging module determines whether the multiple sub-project modules already exist in the storage device. When the multiple sub-project modules already exist in the storage device, the merging module compresses the multiple sub-project modules into the compressed file. When the multiple sub-project modules do not exist in the storage device, the merging module merges the configuration information and multilingual information of the multiple sub-project modules to generate the compressed file.

19. The method of claim 16, wherein, The steps for retrieving the latest version of the third-party dependency list from the third-party dependency lists of the multiple sub-project modules include: The third-party module analysis module determines whether the versions of the third-party dependency lists in the multiple sub-project modules are the same. When the versions are different, the third-party module analysis module takes the latest version of the third-party dependency list from the third-party dependency lists of the multiple sub-project modules as the third-party dependency version information. When the versions are the same, the third-party module analysis module stores a total list of third-party dependencies, which is a list generated by merging the third-party dependency lists in the multiple sub-project modules.

20. The method of claim 16, wherein, The compressed file includes the module information, which includes the main project module. The multiple sub-project modules within the main project module are stored in the application layer of the system architecture, and the application layer stores multiple independent main project modules. The main project module includes a storage block, which stores the configuration files, message files, and interface files of its multiple sub-project modules. The application layer stores third-party modules, application configuration files, and application message files.

Images