Micro-service merging system and micro-service merging method

Abstract

The invention provides a micro-service merging system and a micro-service merging method. The micro-service merging system comprises a storage device and a processor. The storage device is used for storing a request preprocessing module, a module loading module and a service calling module. The processor is coupled to the storage device and is used for executing the request preprocessing module, the module loading module and the service calling module. The request preprocessing module carries out request preprocessing on the service request to obtain request data corresponding to the service request. The module loading module analyzes the request data to obtain module information corresponding to the request data, and the module loading module judges whether the module information is loaded to the storage device or not; and in response to the fact that the module information is not loaded to the storage device, the module loading module loads the module and the service information according to the module information. And the service calling module calls the corresponding micro-service according to the service information.

Description

Technical Field

[0001] The present invention relates to a microservice deployment and processing technology, and in particular to a microservice merging system and a microservice merging method. Background Art

[0002] Generally speaking, when enterprises or system users have high requirements for data security, they will consider storing data and performing application operations locally. However, when microservice architecture is to be privately deployed, it will lead to high hardware costs and high costs for organization and operation and maintenance, and will also face high complexity during deployment and adjustment. In addition, enterprise users have high requirements for data consistency, which will also increase the difficulty of microservice setup and privatization. Summary of the invention

[0003] The present invention is directed to a microservice merging system and a microservice merging method, which can merge microservices into a main project to ensure data consistency.

[0004] 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 calling 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 calling module. The request preprocessing module performs request preprocessing on the service request to obtain 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 calling module calls the corresponding microservice according to the service information.

[0005] According to an embodiment of the present invention, the microservice merging method of the present invention includes the following steps: executing a request preprocessing module through a processor to perform request preprocessing on a service request, so that the request preprocessing module obtains request data corresponding to the service request; executing a module loading module through a processor to parse the request data, so that the module loading module obtains module information corresponding to the request data, and the module loading module determines whether the module information has been loaded into a 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 executing a service calling module through a processor to call the corresponding microservice according to the service information.

[0006] Based on the above, the microservice merging system and microservice merging 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.

[0007] In order to make the above features and advantages of the present invention more clearly understood, embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0011] Figure 4 is a merging module flow chart of a microservice merging method according to an embodiment of the present invention;

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

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

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

[0015] Description of Reference Numerals

[0016] 100: Microservices merge system;

[0017] 110: processor;

[0018] 120: storage device;

[0019] 121: request preprocessing module;

[0020] 122: module loading module;

[0021] 123: service call module;

[0022] 124: system startup module;

[0023] 125: Merge module;

[0024] 126: Third-party module analysis module;

[0025] 510: Merge previous modules;

[0026] 511: Project A;

[0027] 512: Project B;

[0028] 513: Project N;

[0029] 520: Merged module;

[0030] 521: Main Project X;

[0031] 522: application level configuration;

[0032] 523: Third-party modules;

[0033] 524: Module A;

[0034] 525: Module B;

[0035] 526: module N;

[0036] 600: Microservices merging system;

[0037] 610: Caller;

[0038] 613: Cache service instance list;

[0039] 620: Service provider;

[0040] 630: service name;

[0041] 700: System architecture of microservices merging system;

[0042] 710: case level;

[0043] 720: Industry level;

[0044] 730: application layer;

[0045] 731: Module A;

[0046] 732: module configuration file;

[0047] 733: message file;

[0048] 734: interface file;

[0049] 735: Module B;

[0050] 736: module configuration file;

[0051] 737: message file;

[0052] 738: interface file;

[0053] 740: Third-party modules;

[0054] 741: Application configuration file;

[0055] 742: application message file;

[0056] 750: platform layer;

[0057] 751: Platform configuration file;

[0058] 752: message file;

[0059] 753: Platform jar package;

[0060] S210~S250, S410~S450, S611~S613, S621~S623: steps. DETAILED DESCRIPTION

[0061] Reference will now be made in detail to exemplary embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Whenever possible, the same reference numerals are used in the drawings and the description to refer to the same or like parts.

[0062] Figure 1 Schematic diagram of a microservice merging system according to an embodiment of the present invention. 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 the business process system 200. The microservice merging system 100 may also include a communication interface or a data transmission interface having actual circuit elements, so that the processor 110 can communicate or transmit data with an external business system, a user interface, an application programming interface (API) or a database. In this embodiment, the microservice merging system 100 can be implemented, for example, on a cloud server, a private server within an enterprise, or a data center within an enterprise.

[0063] 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 (DSP), application specific integrated circuits (ASIC), programmable logic devices (PLD), other similar processing circuits, or a combination of these devices.

[0064] The storage device 120 may also implement a remote cloud storage service or a local data storage service. The storage device 120 may include a memory and / or a database, wherein the memory may be, for example, a non-volatile memory (NVM). The storage device 120 may store relevant programs, modules, systems or algorithms for implementing various embodiments of the present invention, so that the processor 110 can access and execute them to implement the relevant functions and operations described in various embodiments of the present invention.

[0065] Figure 2 This is a service call flow chart of a microservice merging method according to an embodiment of the present invention. Figure 3 FIG. 1 is a schematic diagram of a microservice merging system and multiple modules according to an embodiment of the present invention. Figure 1 as well as Figure 2 The storage device 120 may store a request preprocessing module 121, a module loading module 122, a service calling module 123, a system startup module 124, a merging module 125, and a third-party module analyzing module 126. The request preprocessing module 121, the module loading module 122, the service calling module 123, the system startup module 124, the merging module 125, and the third-party module analyzing module 126 may be implemented in a programming language such as JSON (JavaScript Object Notation), Extensible Markup Language (XML), or YAML, but the present invention is not limited thereto.

[0066] Refer to Figure 1 to Figure 2 , the microservice merging system 100 executes the following steps S210 to S250. In step S210, the processor 110 may receive a service request, and then execute 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 step includes the request filter filtering external requests (such as service requests) to perform identity authentication and log recording, and then the request controller receives the filtered external request and then performs interface forwarding of the request. Then, 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 can be, for example, based on the service request, recording information related to the service request such as the login user, login time, identity information, permission information, or tenant information to the organized context.

[0067] In step S220, the processor 110 may execute the module loading module 122 to parse the request data and obtain 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 the routing rule 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.

[0068] In step S240, in response to the module information not being loaded into the storage device 120, the 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 through the module loading module 122. In addition, the module loading module 122 caches the service information to the storage device 120, and then loads the corresponding module information into the storage device 120120, and updates the module service list in the storage device 120. Next, in response to the module information being loaded into the storage device 120, the module loading module 122 inputs the service information (e.g., service name) into the service calling module 123. In other words, when the module information has been loaded into the storage device 120, the module loading module 122 inputs the service name corresponding to the request data into the service calling module 123.

[0069] In step S250, the processor 110 may execute the service calling module 123 to call the corresponding microservice according to the service information. In one embodiment, calling the corresponding microservice according to the service information may include the following steps, wherein the service calling module 123 parses the context according to the service name of the service information to obtain the corresponding service interface. In this way, the service calling module 123 matches the corresponding microservice according to the service interface. Next, the service calling module 123 determines whether the microservice includes unresolved module information. When the microservice does not include unresolved module information, the service calling module 123 calls the microservice. When the microservice includes unresolved module information, the module loading module 122 parses the unresolved module information to repeat step S240 to load the relevant service into the storage device 120 based on the unresolved module information.

[0070] Figure 4 1 is a flow chart of the merging module of the 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 may execute the system startup module 124, the merging module 125, and the third-party module analysis module 126, and receive a merging instruction sent by a user to merge the corresponding modules. For example, the user may send a merging instruction to the processor 110 according to a communication interface or a data transmission interface. Next, refer to Figure 3 as well as Figure 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 merge instruction, thereby obtaining multiple sub-project modules. The merge instruction includes an address. In other words, the system startup module 124 pulls the corresponding code from the file server based on the address.

[0071] In one embodiment, the file server may be, for example, a Git server for storing code archives. The merge instruction includes main project information and sub-project information. In this way, the step of obtaining the corresponding code from the file server according to the merge instruction may include the following steps: obtaining the sub-project code, sub-project configuration and sub-project tripartite dependency from the file server according to the sub-project information through the system startup module 124. And, obtaining the main project code, configuration information and tripartite dependency information of the sub-project module respectively according to the sub-project code, sub-project configuration and sub-project tripartite dependency through the system startup module 124. In this way, the system startup module 124 extracts the sub-project code, sub-project configuration and tripartite dependency into the main project, and then obtains the main project module including multiple sub-project modules. In addition, the system startup module 124 compiles and packages the main project code, configuration information and tripartite dependency information including the sub-project into the storage device 120.

[0072] 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 plurality of sub-project modules. Specifically, the merging module 125 adjusts the POM file of the sub-project module (i.e., the module to be merged) to the POM file of the parent (i.e., the main project), thereby recording these sub-project modules 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 may be a Jar package. In one embodiment, the step of merging the sub-project modules to generate a compressed file may include: determining, by the merging module 125, whether the plurality of sub-project modules already exist in the storage device 120. When the plurality of sub-project modules are already stored / exist in the storage device 120, the merging module 125 compresses the plurality of sub-project modules into a compressed file. On the other hand, when the plurality of sub-project modules do not exist in the storage device 120, the merging module 125 merges the configuration information and multilingual information of the plurality of 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 multi-lingual information of the sub-project modules (i.e., the multi-lingual files) respectively to obtain the sub-module configuration items (i.e., the configuration files of the sub-project modules) and the sub-module multi-lingual information (i.e., the multi-lingual information of the sub-project modules), and merges and compresses the sub-module configuration items and the sub-module multi-lingual information into a compressed file, thereby completing the merging of the multiple modules.

[0073] Figure 5 This is a schematic diagram of module merging of a microservice merging method according to an embodiment of the present invention. Figures 3 to 5 , the module 510 before merging 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 the user instructions can be merged into the merged module 520, and the merged module 520 includes a main project module (such as main project X 521). Figure 5As shown, the main project X521 may include application-level configuration 522, third-party module 523, module A 524, module B 525 and module N 526, wherein module A 524 is project A 511 after merging, compiling and packaging, module B 525 is project B 512 after merging, compiling and packaging, and module N 526 is project N 513 after merging, compiling and packaging. It is worth noting that the 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). The third-party module 523 stores open source components that are commonly used by multiple sub-project modules, such as database link components, encryption components, email components or publishing components. With such a configuration, the microservice merging system 100 can enable multiple sub-projects to be executed and developed independently of each other at the module layer through the configuration of the application-level configuration 522. Therefore, when merging or adjusting a single sub-project module, the developer's work time can be reduced, and the difficulty and complexity of adjustment and merging can be reduced.

[0074] In step S440, the third-party module analysis module 126 merges the third-party dependency lists in the 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 takes the latest version of the third-party dependency list from the third-party dependency lists of the multiple sub-project modules.

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

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

[0077] Figure 7 is a schematic diagram of the system architecture of a microservice merging system according to an exemplary embodiment of the present invention. 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 call framework based on the enterprise application integration (EAI) architecture, so that the microservice merging system can perform internal service calls based on the enterprise application integration 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 can be a platform compressed file. The industry layer 720 includes a plurality of industry characteristic information, and the plurality of industry characteristic information includes a differential configuration file and an industry characteristic code. The industry characteristic information can be, for example, the industry terminology of the plastic products industry, for example, the plastic products industry collectively refers to the product number and product name as the brand. The industry characteristic code is, for example, a code corresponding to the industry characteristic information. The case layer 710 includes case attribute information. With such a setting, the user can write the case configuration file and the case characteristic code into the case attribute information according to the difference of each case. The application layer 730 stores a third-party module 740, an application configuration file 741, and an application message file 742. In this embodiment, the compressed file includes module information, and the module information includes a main project module. Multiple sub-project modules in the main project module are stored in the application layer 730 in the system architecture, and the application layer 730 stores multiple independent main project modules. The main project module includes a storage block, and the storage block is used to store configuration files of multiple sub-project modules (such as module configuration files 732 and 736), message files (733 and 737), and interface files (734 and 738). The message file includes multilingual information.

[0078] In summary, the microservice merging system and microservice merging method of the present invention can merge multiple microservices as sub-project modules into a new independent service. In addition, the independent service is used as the main project module, and the multiple merged microservices are set as independent projects of the same level to effectively reduce the difficulty of merging and adjusting and reduce the cost of operation and maintenance. In other words, the microservice merging system 100 effectively provides a lightweight deployment method through differential configuration and the setting of third-party modules, while reducing deployment complexity and reducing costs.

[0079] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements 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 in that: include: A storage device for storing a request preprocessing module, a module loading module, and a service calling module; as well as A processor is coupled to the storage device, executes the request preprocessing module, the module loading module, and the service calling module, and receives a service request, The request preprocessing module performs request preprocessing on the service request to obtain 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 calling module calls the corresponding microservice according to the service information.

2. The microservice merging system according to claim 1, characterized in that: In response to the module information being loaded into the storage device, the module loading module inputs the service information into the service calling module.

3. The microservice merging system according to claim 1, characterized in that: The module loading module loads the module, the module object, and the 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 according to claim 1, characterized in that: The service calling module parses the context according to the service name of the service information to obtain the corresponding service interface. The service calling module matches the service interface to the corresponding microservice. The service calling module determines whether the microservice includes unparsed module information. In response to the microservice not including unparsed module information, the service calling module calls the microservice, In response to the microservice including unparsed module information, the module loading module parses the unparsed module information to load related services into the storage device.

5. The microservice merging system according to claim 1, characterized in that: The system architecture of the microservice merging system includes platform layer, application layer, industry layer and case layer. The platform layer includes a service call framework based on an enterprise application integration framework, wherein the microservice merging system performs internal service calls based on the enterprise application integration framework, The industry layer includes a plurality of industry characteristic information, wherein the plurality of industry characteristic information includes a differential configuration file and an industry characteristic code, The case layer includes case attribute information.

6. The microservice merging system according to claim 1, characterized in that: The storage device further 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 a merging instruction. The system startup module obtains the corresponding code from the file server according to the merge instruction, and then obtains multiple sub-project modules. wherein the merging module adjusts the parent project object models corresponding to the plurality of 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 in the plurality of sub-project modules, and obtains the third-party dependency list of the latest version from among the third-party dependency lists of the plurality of sub-project modules.

7. The microservice merging system according to claim 6, characterized in that: The merge instruction includes main project information and sub-project information. The system startup module obtains the sub-project code, sub-project configuration and sub-project tripartite dependencies from the file server according to the sub-project information. The system startup module obtains the main project code, configuration information and tripartite dependency information of the sub-project module according to the sub-project code, the sub-project configuration and the sub-project tripartite dependency, and then obtains the main project module including the multiple sub-project modules.

8. The microservice merging system according to claim 6, characterized in that: The merging module determines whether the plurality of sub-project modules already exist in the storage device. In response to the plurality of sub-project modules already existing in the storage device, the merging module compresses the plurality of sub-project modules into the compressed file, In response to the plurality of sub-project modules not existing in the storage device, the merging module merges the configuration information and the multi-language information of the plurality of sub-project modules to generate the compressed file.

9. The microservice merging system according to claim 6, characterized in that: 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 third-party dependency list of the latest version among the third-party dependency lists of the plurality of sub-project modules as the third-party dependency version information, In response to the versions being the same, the third-party module analysis module stores a total third-party dependency list, wherein the total third-party dependency list is a list generated by merging the third-party dependency lists in the plurality of sub-project modules.

10. The microservice merging system according to claim 6, characterized in that: The compressed file includes the module information, and the module information includes the main project module, The multiple sub-project modules in the main project module are stored in the application layer in the system architecture, and the application layer stores multiple independent main project modules. The main project module includes a storage block, and the storage block is used to store configuration files, message files and interface files of the plurality of sub-project modules. The application layer stores third-party modules, application configuration files, and application message files.

11. A microservice merging method, characterized in that: include: Executing a request preprocessing module through a processor to preprocess the service request, so that the request preprocessing module obtains request data corresponding to the service request; executing a module loading module by the processor to parse the request data, so that the module loading module obtains module information corresponding to the request data, and the module loading module determines whether the module information has been loaded into a 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 a service calling module to call a corresponding microservice according to the service information.

12. The method according to claim 11, characterized in that Also includes: When the module information has been loaded into the storage device, the service information is input into the service calling module through the module loading module.

13. The method according to claim 11, characterized in that The step of loading the module and the service information according to the module information includes: The module loading module loads the module, the module object, and the 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 according to claim 11, characterized in that The steps of calling the corresponding microservice according to the service information include: The service calling module parses the context according to the service name of the service information to obtain the corresponding service interface; Matching the service interface to the corresponding microservice through the service calling module; and Determining whether the microservice includes unparsed module information through the service calling module; When the microservice does not include unparsed module information, the service calling module calls the microservice, When the microservice includes unparsed module information, the module loading module parses the unparsed module information to load related services into the storage device.

15. The method according to claim 11, characterized in that The method is implemented in a system, and the system architecture of the system includes a platform layer, an application layer, an industry layer and a case layer. The platform layer includes a service call framework based on an enterprise application integration framework, wherein the microservice merging system executes internal service calls based on the enterprise application integration framework, The industry layer includes a plurality of industry characteristic information, wherein the plurality of industry characteristic information includes a differential configuration file and an industry characteristic code, The case layer includes case attribute information.

16. The method according to claim 11, characterized in that Also includes: The processor executes the system startup module to obtain corresponding codes from the file server according to the merge instruction, so that the system startup module obtains multiple sub-project modules; Executing a merging module by the processor to adjust the parent project object models corresponding to the plurality of sub-project modules, and merging 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 in the plurality of sub-project modules, and obtains the third-party dependency list of the latest version from among the third-party dependency lists of the plurality of sub-project modules.

17. The method according to claim 16, characterized in that 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: Obtaining the sub-project code, sub-project configuration and sub-project tripartite dependencies from the file server according to the sub-project information by the system startup module; and The system startup module obtains the main project code, configuration information and tripartite dependency information of the subproject module according to the subproject code, the subproject configuration and the subproject tripartite dependency, and then obtains the main project module including the multiple subproject modules.

18. The method according to claim 16, characterized in that The steps of merging the sub-project modules to generate a compressed file include: Determine by the merging module whether the plurality of sub-project modules already exist in the storage device, When the plurality of sub-project modules already exist in the storage device, the merging module compresses the plurality of sub-project modules into the compressed file. When the plurality of sub-project modules do not exist in the storage device, the merging module merges the configuration information and the multi-language information of the plurality of sub-project modules to generate the compressed file.

19. The method according to claim 16, characterized in that The step of obtaining the latest version of the third-party dependency list from the third-party dependency lists of the plurality of sub-project modules comprises: Determine whether the versions of the third-party dependency lists in the multiple sub-project modules are the same by using the third-party module analysis module. When the versions are different, the third-party module analysis module takes the third-party dependency list of the latest version among the third-party dependency lists of the plurality of 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 third-party dependency list, wherein the total third-party dependency list is a list generated by merging the third-party dependency lists in the plurality of sub-project modules.

20. The method according to claim 16, characterized in that The compressed file includes the module information, and the module information includes the main project module, The multiple sub-project modules in the main project module are stored in the application layer in the system architecture, and the application layer stores multiple independent main project modules. The main project module includes a storage block, and the storage block is used to store configuration files, message files and interface files of the plurality of sub-project modules. The application layer stores third-party modules, application configuration files, and application message files.

Images