Plug-in service processing method and Spring Boot service dynamic aggregation integration system

Abstract

The invention provides a plug-in service processing method and a Spring Boot service dynamic aggregation integration system, and relates to the technical field of computer software, and the plug-in service processing method comprises the following steps: receiving a plug-in service directory, and executing initialization operation; traversing the plug-in service directory by using the plug-in management framework, and generating a plug-in service package and a plug-in resource list corresponding to the plug-in service; the plug-in service package is loaded through the plug-in management framework, so that a key component of the plug-in service package is registered to Servlet Context of a Servlet container of a main service; and instantiating the service starting class of the plug-in service through the plug-in management framework, and executing starting operation for the registered plug-in service by utilizing the instantiated service starting class, so that a key component of the plug-in service monitors and responds to an external HTTP request. According to the method, flexible scheduling and efficient utilization of resources are realized, the micro-service deployment and operation and maintenance cost can be reduced, and the resource use efficiency can be effectively improved.

Description

Technical Field

[0001] The present invention relates to the field of computer software technology, and in particular to a plug-in service processing method and a SpringBoot service dynamic aggregation integration system. Background Art

[0002] At a time when microservice architecture is all the rage, the Spring Boot framework in the Java service field has become the preferred solution for implementing microservice architecture with its powerful capabilities. As a lightweight Java development framework, Spring Boot follows the Java Servlet specification and enables developers to easily split applications into multiple small, independent, and highly cohesive microservice units through built-in efficient Servlet containers (such as Tomcat, Jetty, etc.). This "divide and conquer" architectural strategy significantly improves the scalability, maintainability, and flexibility of the system, and is particularly suitable for scenarios that process large-scale data and complex business processes.

[0003] However, if this microservice architecture is deployed in a resource-constrained environment, such as edge computing devices, small data centers, or single-server deployments, it will face a series of challenges. The traditional microservice deployment model relies on a large number of server instances to support the operation of each service, which not only increases hardware costs, but also makes resource allocation and management complex and difficult to optimize. Each microservice consumes certain system resources during operation, such as CPU (Central Processing Unit), memory, and network bandwidth. If there is a lack of effective resource management and scheduling mechanisms, uneven resource allocation may occur, with some services having excess resources while others having insufficient resources, which in turn affects overall performance and causes resource waste.

[0004] In addition, the operation and maintenance complexity of the microservice architecture has also increased dramatically with the increase in the number of services. Tasks such as monitoring, log collection, and troubleshooting have become increasingly arduous, which is undoubtedly a huge challenge for an environment with limited resources and insufficient staffing. Summary of the invention

[0005] In view of this, the purpose of the present invention is to provide a plug-in service processing method and a Spring Boot service dynamic aggregation integration system to achieve flexible scheduling and efficient utilization of resources, which can not only reduce the cost of microservice deployment and operation and maintenance, but also effectively improve resource utilization efficiency.

[0006] In a first aspect, an embodiment of the present invention provides a plug-in service processing method, which is applied to a Spring Boot service dynamic aggregation integration system, and the method includes:

[0007] If the plug-in service directory is received, the initialization operation is performed, which includes the main service environment initialization operation, the Servlet container configuration operation, and the plug-in management framework configuration operation. The plug-in management framework uses a custom ClassLoader mechanism to enable each plug-in service to have an independent class space;

[0008] Use the plug-in management framework to traverse the plug-in service directory and generate a plug-in service package and a plug-in resource list corresponding to the plug-in service in the plug-in service directory. The plug-in service package includes the files required to implement the plug-in service, and the plug-in resource list is used to record the attribute information of each plug-in service;

[0009] Load the plug-in service package through the plug-in management framework to register the key components of the plug-in service package to the ServletContext of the Servlet container of the main service. The key components include Servlet components, Filter components, and Listener components.

[0010] The plug-in management framework instantiates the service startup class of the plug-in service based on the attribute information recorded in the plug-in resource list, and uses the instantiated service startup class to perform startup operations on the registered plug-in service, so that the key components of the plug-in service that enters the running state listen to and respond to external HTTP requests.

[0011] In one embodiment, if the plug-in service directory is received, an initialization operation is performed, including:

[0012] If the plug-in service directory is received, the main service environment initialization operation is performed to initialize the system environment of the main service itself based on the plug-in service directory;

[0013] After initializing the system environment of the main service itself, the Servlet container configuration operation and the plug-in management framework configuration operation are executed. The Servlet container configuration operation is used to configure the Servlet container of the main service and initialize the ServletContext of the Servlet container. The plug-in management framework configuration operation is used to load and initialize the plug-in management framework.

[0014] In one implementation, the plug-in management framework is used to traverse the plug-in service directory to generate a plug-in service package and a plug-in resource list corresponding to the plug-in service in the plug-in service directory, including:

[0015] Activate the plugin management framework;

[0016] Use the plugin management framework to traverse the plugin service directory to find plugin folders that meet the preset plugin specifications. Each plugin service is designed to be stored in a separate plugin folder.

[0017] Using the plug-in management framework to check the specified file in the plug-in folder, so as to identify a valid plug-in folder from the plug-in folder based on the checking result of the specified file;

[0018] The valid plug-in folder is used as the plug-in service package, and the plug-in resource list is obtained by scanning the plug-in service package.

[0019] In one embodiment, the plug-in service package is loaded through the plug-in management framework to register the key components of the plug-in service package to the ServletContext of the Servlet container of the main service, including:

[0020] Generate a dynamic service class loader instance corresponding to each plug-in service based on the plug-in resource list through the custom ClassLoader mechanism of the plug-in management framework;

[0021] For each plug-in service, use the dynamic service class loader instance corresponding to the plug-in service to load the plug-in service package corresponding to the plug-in service;

[0022] After loading the plug-in service package corresponding to each plug-in service, the key components of the plug-in service package are rewritten using the ServletContextWrapper class to register the key components of the plug-in service package with the ServletContext of the Servlet container of the main service.

[0023] In one embodiment, the identifier of each plug-in service is unique; the method further includes:

[0024] During the registration process, the preset conflict resolution strategy is used to make the names and paths of key components of each plug-in service package unique;

[0025] The conflict resolution strategy includes: generating a name of a key component based on the identifier of the plug-in service corresponding to the plug-in service package; configuring a content-path for the plug-in service corresponding to the plug-in service package to specify a URL root path of the key component of the plug-in service package.

[0026] In one implementation, the plug-in management framework instantiates the service startup class of the plug-in service based on the attribute information recorded in the plug-in resource list, and uses the instantiated service startup class to perform a startup operation on the registered plug-in service, including:

[0027] Based on the plug-in resource list, the plug-in management framework locates the service startup class of the plug-in service package, and uses Java's reflection mechanism to dynamically load and instantiate the service startup class;

[0028] The onStartup function in the service startup class is called through the plug-in management framework to initialize the Spring container corresponding to the plug-in service package;

[0029] After the Spring container is initialized, the Controller interface class inside the plug-in service package is identified, the URL path mapped by the annotation of the Controller interface class is packaged as a FrameworkServlet instance, and the FrameworkServlet instance is registered in the ServletContext in the Servlet container of the main service to start the plug-in service package.

[0030] In one embodiment, the key components of the plug-in service that enters the running state monitor and respond to external HTTP requests, including:

[0031] Receive external HTTP requests through the main service, determine the target plug-in service corresponding to the HTTP request based on the specified part in the URL path of the HTTP request, and forward the HTTP request to the key component corresponding to the target plug-in service, so that the key component corresponding to the target plug-in service listens to and responds to the HTTP request, and feeds the generated response data back to the main service.

[0032] In one embodiment, the method further comprises:

[0033] If an update to the plug-in service directory is detected, the plug-in management framework is used to traverse the new plug-in service directory, generate a new plug-in service package corresponding to the plug-in service in the new plug-in service directory, load the new plug-in service package, and register the key components of the new plug-in service package to the ServletContext of the Servlet container of the main service.

[0034] In one embodiment, the method further comprises:

[0035] During the shutdown of the plug-in service, the key components of the plug-in service are traversed through the main service, and the stop interface corresponding to the plug-in service is called;

[0036] When the stop interface is called, the ApplicationContext object instance inside the plug-in service is obtained through the plug-in management framework, and the close function of the ApplicationContext object instance is called through the plug-in management framework to use the close function to close the plug-in service.

[0037] In a second aspect, an embodiment of the present invention further provides a Spring Boot service dynamic aggregation integration system, including:

[0038] The initialization module is used to perform initialization operations if the plug-in service directory is received. The initialization operations include the main service environment initialization operation, the Servlet container configuration operation, and the plug-in management framework configuration operation. The plug-in management framework uses a custom ClassLoader mechanism to enable each plug-in service to have an independent class space;

[0039] The plug-in directory scanning module is used to traverse the plug-in service directory using the plug-in management framework to generate plug-in service packages and plug-in resource lists corresponding to the plug-in services in the plug-in service directory. The plug-in service package includes the files required to implement the plug-in service, and the plug-in resource list is used to record the attribute information of each plug-in service;

[0040] The plug-in registration module is used to load the plug-in service package through the plug-in management framework to register the key components of the plug-in service package into the ServletContext of the Servlet container of the main service. The key components include Servlet components, Filter components, and Listener components.

[0041] The plug-in startup module is used to instantiate the service startup class of the plug-in service based on the attribute information recorded in the plug-in resource list through the plug-in management framework, and use the instantiated service startup class to perform startup operations on the registered plug-in service, so that the key components of the plug-in service that enters the running state listen to and respond to external HTTP requests.

[0042] The plug-in service processing method and the Spring Boot service dynamic aggregation integration system provided by the embodiment of the present invention perform an initialization operation if a plug-in service directory is received, the initialization operation includes a main service environment initialization operation, a Servlet container configuration operation, and a plug-in management framework configuration operation, and the plug-in management framework uses a custom ClassLoader mechanism to enable each plug-in service to have an independent class space; then the plug-in service directory is traversed by the plug-in management framework to generate a plug-in service package and a plug-in resource list corresponding to the plug-in service in the plug-in service directory, the plug-in service package includes files required to implement the plug-in service, and the plug-in resource list is used to record the attribute information of each plug-in service; then the plug-in service package is loaded through the plug-in management framework to register the key components of the plug-in service package to the ServletContext of the Servlet container of the main service, the key components including the Servlet component, the Filter component and the Listener component; finally, the service startup class of the plug-in service is instantiated by the plug-in management framework based on the attribute information recorded in the plug-in resource list, and the startup operation is performed on the registered plug-in service using the instantiated service startup class, so that the key components of the plug-in service that enters the running state listen to and respond to external HTTP requests. The above method realizes dynamic scanning, loading, registration, integration and request processing of plug-in services by cleverly designing the architecture of the main service and the plug-in service and combining it with a custom ClassLoader mechanism. The embodiment of the present invention realizes flexible scheduling and efficient utilization of resources, which can not only reduce the cost of microservice deployment and operation and maintenance, but also effectively improve resource utilization efficiency.

[0043] Other features and advantages of the present invention will be described in the following description, and partly become apparent from the description, or understood by practicing the present invention. The purpose and other advantages of the present invention are realized and obtained by the structures particularly pointed out in the description, claims and drawings.

[0044] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0046] Figure 1 A flowchart of a plug-in service processing method provided by an embodiment of the present invention;

[0047] Figure 2 A schematic diagram of the overall process of a plug-in service processing method provided by an embodiment of the present invention;

[0048] Figure 3 A schematic diagram of the structure of a Spring Boot service dynamic aggregation and integration system provided by an embodiment of the present invention;

[0049] Figure 4 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0050] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution of the present invention will be clearly and completely described in combination with the embodiments below. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0051] At present, the relevant technologies have at least the following defects:

[0052] 1. Low resource utilization: In the traditional microservice architecture, since services are subdivided into multiple small units, each service instance may require independent resource allocation, resulting in some resources being idle or inefficiently utilized in an environment with limited resources, while other services may have limited performance due to insufficient resources.

[0053] 2. High deployment and operation complexity: As the number of services increases, the complexity of deployment and operation also increases. Each service needs to be configured, deployed and maintained separately, which not only increases the workload but also increases the risk of errors. At the same time, tasks such as monitoring, log collection, and troubleshooting also become more complex and time-consuming.

[0054] 3. High overhead of remote communication between services: In a microservice architecture, communication between services is inevitable. However, traditional remote communication between services may introduce large network overhead and latency, especially when there are a large number of services and a long call chain. In addition, data serialization and deserialization between services will also consume certain computing resources.

[0055] 4. Lack of unified resource management and scheduling mechanism: Traditional microservice deployment methods often lack a unified resource management and scheduling mechanism, resulting in unreasonable resource allocation, large fluctuations in service performance, and other problems. In an environment with limited resources, these problems are particularly prominent and may seriously affect the stability and reliability of the system.

[0056] 5. High requirements for hardware resources: Although the microservice architecture has significant advantages in the big data environment, in an environment with limited resources, its requirements for hardware resources are often high, resulting in the deployment and operation and maintenance costs of microservices being too high and unbearable in some resource-constrained scenarios.

[0057] 6. Difficulty in achieving dynamic aggregation and integration: Traditional microservice architectures tend to focus more on the independence and loose coupling of services during design and implementation, while ignoring the dynamic aggregation and integration capabilities of services, resulting in difficulty in flexibly combining and adjusting services when there is a need to quickly respond to market changes or business needs.

[0058] Therefore, in order to solve the problems of unreasonable resource allocation, low service loading efficiency, poor system scalability, etc. encountered during the deployment and operation of Java applications, the present invention provides a plug-in service processing method and system. This system aims to achieve flexible scheduling and efficient utilization of resources by dynamically loading and unloading plug-in services, which can not only reduce the cost of microservice deployment and operation and maintenance, but also effectively improve resource utilization efficiency. Specifically, the main purposes of the plug-in service processing method and the Spring Boot service dynamic aggregation integration system provided by the embodiment of the present invention include:

[0059] 1. Resource optimization: Through the customized ClassLoader mechanism, the refined management and optimization of Java service (also known as plug-in service) resources are realized. This includes dynamically loading and unloading services according to the actual needs of the service and the current state of the system to avoid unnecessary resource occupation and waste. At the same time, the resource utilization of the entire system can be improved through the effective integration and allocation of service resources.

[0060] 2. Dynamic service aggregation: The system can realize dynamic aggregation of Java services, that is, without modifying the original service code, multiple independent service components can be combined into an integrated service system according to business needs. This dynamic aggregation capability allows the system to respond to business changes more flexibly, while also reducing the complexity of system development and maintenance.

[0061] 3. Unified service integration and management: Through unified interfaces and protocols, the system can integrate Java services from different sources and formats to form a unified service platform. This helps break down barriers between services and achieve interconnection and interoperability between services, thereby improving the integration and maintainability of the entire system.

[0062] 4. Avoid remote communication: After the services are aggregated, all HTTP (Hypertext Transfer Protocol) remote calls become local calls, which not only avoids the transmission of data packets in the network and reduces communication delays, but also reduces the risk of communication failures caused by network instability or failures, thereby enhancing the stability and reliability of the system. In addition, local calls eliminate the process of data serialization and deserialization, which consume a lot of computing resources in a high-concurrency environment. By sharing data directly through memory, local calls greatly reduce the consumption of computing resources and reduce network IO (Input / Output) operations, allowing the CPU to focus more on processing business logic, thereby improving the overall performance of the system. This transformation is particularly important in a microservice architecture, which helps optimize resource utilization, improve system responsiveness, and reduce operation and maintenance costs.

[0063] 5. Enhanced system scalability: The system supports dynamic loading and unloading of services, making it easy to expand new services or remove services that are no longer needed. The ability to dynamically expand allows the system to respond to business changes more flexibly, while also reducing the cost of system upgrades and maintenance.

[0064] 6. Improve system stability and security: Through the custom ClassLoader mechanism and strict class loading control mechanism, the system can effectively prevent the loading and execution of malicious code, thereby improving the security and stability of the system. At the same time, services can be isolated and permissions controlled to ensure that different services do not interfere with each other and data is transmitted securely.

[0065] To facilitate understanding of this embodiment, a plug-in service processing method disclosed in an embodiment of the present invention is first described in detail. The method is applied to the Spring Boot service dynamic aggregation integration system. Figure 1 The flowchart of a plug-in service processing method shown in FIG. 1 mainly includes the following steps S102 to S108:

[0066] Step S102: If the plug-in service directory is received, an initialization operation is performed.

[0067] Among them, the initialization operation includes the main service environment initialization operation, the Servlet container configuration operation, and the plug-in management framework configuration operation. The main service environment initialization operation is used to initialize the system environment of the main service itself; the Servlet container configuration operation is used to configure the Servlet container of the main service, set the listening port, thread pool size and concurrency strategy of the Servlet container, and initialize the ServletContext for storing Servlet instances; the plug-in management framework configuration operation is used to load and initialize the plug-in management framework of the main service. The plug-in management framework uses a custom ClassLoader mechanism to enable each plug-in service to have an independent class space. The custom ClassLoader mechanism is also a custom class loader (DynamicServiceClassLoader), which is used to load and manage the external plug-in service directory, so that each plug-in service in the plug-in service directory has an independent class space, thereby avoiding class conflicts and dependency issues.

[0068] Step S104: traverse the plug-in service directory using the plug-in management framework to generate a plug-in service package and a plug-in resource list corresponding to the plug-in service in the plug-in service directory.

[0069] The plug-in service package includes the files required to implement the plug-in service, such as code, resources, configuration files, etc. The plug-in resource list is used to record the attribute information of each plug-in service, such as the name of the plug-in service, ID (Identity document, unique code), version, plug-in startup class (that is, Spring Boot's service startup class) and plug-in location. In one embodiment, when the main service is started, the system immediately enters the plug-in scanning phase. In this stage, the main service enables the dynamic loading feature of the plug-in, scans the plug-in service directory based on a custom plug-in management framework, and identifies and lists all available plug-in service packages. Each plug-in service is encapsulated in a separate folder, and a folder is a plug-in service package. By scanning all available plug-in service packages, a plug-in resource list can be generated to provide data support for subsequent operations.

[0070] Step S106, loading the plug-in service package through the plug-in management framework to register key components of the plug-in service package into the ServletContext of the Servlet container of the main service.

[0071] Among them, the key components include Servlet components, Filter components and Listener components. In one embodiment, the plug-in management framework dynamically creates an independent DynamicServiceClassLoader instance (i.e., a dynamic service class loader instance), uses the DynamicServiceClassLoader instance to load the plug-in service, and uses the ServletContextWrapper class to rewrite the Servlet components, Filter components and Listener components of the plug-in service, thereby registering the above key components in the ServletContext of the Servlet container of the main service.

[0072] Step S108, instantiate the service startup class of the plug-in service based on the attribute information recorded in the plug-in resource list through the plug-in management framework, and use the instantiated service startup class to perform a startup operation on the registered plug-in service, so that the key components of the plug-in service that enters the running state listen to and respond to external HTTP requests.

[0073] In one implementation, the plug-in management framework locates the service startup class of the plug-in service according to the attribute information recorded in the plug-in resource list, and uses the reflection mechanism to dynamically load and instantiate the service startup class, so that the plug-in service completes the initialization of the Spring container through the onStartup function in the service startup class. After the Spring container is initialized, it will identify and package all classes that implement the controller interface inside it, and package them as part of the FrameworkServlet. The packaged FrameworkServlet is registered with the ServletContext of the Servlet container of the main service, so that the plug-in service can be started and the plug-in service can enter the running state. The key components of the plug-in service listen for and respond to external HTTP requests.

[0074] The plug-in service processing method provided in the embodiment of the present invention realizes dynamic scanning, loading, registration, integration and request processing of plug-in services through clever architecture design of main services and plug-in services and combined with a custom ClassLoader mechanism. The embodiment of the present invention realizes flexible scheduling and efficient utilization of resources, which can not only reduce the cost of microservice deployment and operation and maintenance, but also effectively improve resource utilization efficiency.

[0075] For ease of understanding, the embodiment of the present invention provides an implementation of a plug-in service processing method. By cleverly designing the architecture of the main service and the plug-in service and combining the custom ClassLoader mechanism, dynamic scanning, loading, registration, integration and request processing of the service are realized, which greatly improves the flexibility and scalability of the system. The main steps of the method include:

[0076] First, initialize the main service and Servlet container, which is the basic step to build the system. The main service is responsible for the overall life cycle management, while the Servlet container is used to provide HTTP services.

[0077] Then, load the plug-in management framework, identify and index all plug-in service resources in the plug-in service directory. Each plug-in service is encapsulated in a separate folder, which contains the necessary code, resources and configuration files. This folder is the plug-in service package. Read the metadata information of the plug-in service to obtain key information such as the plug-in name, version and mainClass (that is, the Spring Boot startup class), and record it in the plug-in resource list.

[0078] Furthermore, the plug-in service package is loaded through DynamicServiceClassLoader, and then the reflection mechanism is used to instantiate these Spring Boot service startup classes, and the onStartup function is called to complete the initialization of the plug-in service Servlet component.

[0079] Finally, register the key components of the plug-in service with the Servlet container of the main service, and assign an independent content-path to each plug-in service as the root URL (Uniform Resource Locator) path. In this way, when an external HTTP request arrives, the Servlet container can distribute the request to the corresponding plug-in service for processing based on the requested URL path and the previously established mapping relationship. If the requested URL matches the content-path of a plug-in, the Servlet of the plug-in service will be called, execute the corresponding business logic, and generate a response back to the requester.

[0080] Through this process, the system realizes dynamic scanning, loading, registration, integration and request processing of plug-in services, greatly improving the scalability and flexibility of the system.

[0081] Furthermore, the present invention provides a specific implementation of a plug-in service processing method, see Figure 2 The overall flow diagram of a plug-in service processing method shown in the figure includes main service startup, plug-in directory scanning, plug-in service registration, plug-in service startup, plug-in service monitoring, and plug-in service shutdown. When implemented specifically:

[0082] (I) Main service startup:

[0083] During the system initialization phase, the main service plays a vital role. It is responsible for coordinating and starting the core components and processes of the entire system. The following is a detailed description of the main service startup and initialization of the plug-in management framework:

[0084] (1.1) If the plug-in service directory is received, the main service environment initialization operation is performed to initialize the system environment of the main service itself based on the plug-in service directory.

[0085] Specifically, the main service first performs system initialization operations, including loading configuration files, setting system properties, setting plug-in service directories, etc., laying the foundation for the subsequent startup process.

[0086] (1.2) After initializing the system environment of the main service itself, the Servlet container configuration operation and the plug-in management framework configuration operation are executed. The Servlet container configuration operation is used to configure the Servlet container of the main service and initialize the ServletContext of the Servlet container. The plug-in management framework configuration operation is used to load and initialize the plug-in management framework.

[0087] In one example, the Servlet container is configured and started: the main service configures the Servlet container (such as Tomcat, Jetty) to handle HTTP requests, sets the listening port of the Servlet container, defines the context path, thread pool size and concurrency strategy, and initializes the ServletContext to store the Servlet instance. Then, the Servlet container is started to prepare to receive and process the client's HTTP request.

[0088] In one example, the plugin management framework is loaded and initialized: To support dynamic loading and management of plugins, the main service then loads and initializes a dedicated plugin management framework. This framework is the basis of system extensibility. It uses a custom class loader (DynamicServiceClassLoader) to ensure that each plugin service has an independent class space, thus avoiding class conflicts and dependency issues. In addition, the plugin management framework is also responsible for the identification, loading, registration, startup, and possible uninstallation of plugin services, providing a flexible function expansion mechanism for the system.

[0089] (II) Plugin directory scanning:

[0090] When the main service is started, the system immediately enters the plug-in scanning phase. In this phase, the main service enables the dynamic loading feature of plug-ins, scans the plug-in service directory based on the custom plug-in management framework, and identifies and lists all available plug-in service packages. Each plug-in service is encapsulated in a separate folder, which contains the necessary code, resources, and configuration files. Through scanning, the system generates a plug-in resource list, which records in detail the name, ID, version, plug-in startup class, and plug-in location of the plug-in service, providing data support for subsequent operations.

[0091] In the system startup process, immediately after the main service is successfully started, the system automatically enters the plug-in scanning phase. This key phase makes full use of the dynamic plug-in loading feature provided by the main service to identify and prepare available plug-in services by performing the following steps:

[0092] (2.1) Activate the plugin management framework.

[0093] In one example, the main service activates a custom plugin management framework, which is a tool specifically designed to traverse and identify the contents of the plugin service directory. The scanner works based on the path in the plugin service directory.

[0094] (2.2) The plug-in management framework is used to traverse the plug-in service directory to find the plug-in folder that meets the preset plug-in specifications. Each plug-in service is designed to be stored in a separate plug-in folder.

[0095] In one example, the plugin management framework starts traversing the configured plugin service directory to find all folders that meet the preset plugin specifications. Each plugin service is designed to be stored in a separate folder, which contains all the resources required for the plugin to run, including but not limited to plugin code (such as Java class files), resource files (such as images, templates, etc.) and configuration files (such as configuration information in XML or JSON format).

[0096] (2.3) Using the plug-in management framework to check the specified files in the plug-in folder, and identifying the valid plug-in folder from the plug-in folder based on the check result of the specified files; using the valid plug-in folder as a plug-in service package, and obtaining the plug-in resource list by scanning the plug-in service package.

[0097] In one example, during the scanning process, the plugin management framework identifies which folders are valid plugin service packages by checking specific files in the folders. Once the plugin service packages are successfully identified, the plugin management framework extracts key information from these packages and generates a plugin resource list based on them. This list is a detailed record that contains the name, ID, version number, full path of the plugin startup class (that is, Spring Boot startup class), and location of the plugin in the file system for each plugin. This information is critical for the subsequent plugin loading, registration, and startup process.

[0098] Through this series of steps, the system successfully completed the plug-in scanning phase, laying a solid foundation for the subsequent dynamic loading and integration of plug-ins. This process not only improves the scalability and flexibility of the system, but also ensures the automation and efficiency of plug-in management.

[0099] (III) Plug-in service registration:

[0100] The plug-in registration phase, as a natural continuation of plug-in scanning, is the core link for the system to achieve dynamic integration and management of plug-ins. This phase carefully designs a highly customized process to seamlessly integrate the key components of the plug-in into the ServletContext of the main service while ensuring the flexibility and stability of the system. The following is a detailed re-description of the process:

[0101] (3.1) Generate a dynamic service class loader instance corresponding to each plug-in service based on the plug-in resource list through the custom ClassLoader mechanism of the plug-in management framework; for each plug-in service, use the dynamic service class loader instance corresponding to the plug-in service to load the plug-in service package corresponding to the plug-in service.

[0102] For each plug-in service, the plug-in management framework uses the information in its resource list to dynamically create an independent DynamicServiceClassLoader instance (that is, a dynamic service class loader instance). The dynamic service class loader instance is responsible for loading class files unique to the plug-in service, effectively isolating class path conflicts between plug-in services and potential version incompatibility issues between plug-in services and the main service.

[0103] (3.2) After loading the plug-in service package corresponding to each plug-in service, use the ServletContextWrapper class to rewrite the key components of the plug-in service package to register the key components of the plug-in service package with the ServletContext of the Servlet container of the main service.

[0104] In one example, the encapsulation and extension of ServletContext: Each plug-in service contains its own Servlet component, Filter component, and Listener component. In order to support the registration and management of key components in the main service ServletContext, the system designs and implements a custom ServletContextWrapper class (the implementation class of the ServletContext interface). This class implements the ServletContext interface and accepts the ServletContext instance of the main service as a construction parameter. By encapsulating and extending the functions of ServletContext, ServletContextWrapper provides a special context environment for the registration of key components.

[0105] In one example, the component registration method is rewritten and customized: the ServletContextWrapper class rewrites key methods such as addServlet, addFilter, and addListener, so that after the plug-in is loaded, it can register its internal Servlet components, Filter components, and Listener components by calling these rewritten methods. These rewritten methods implement customized processing of key components, including unique name generation, conflict detection and resolution, etc.

[0106] Furthermore, the embodiment of the present invention uses a series of mechanisms to ensure that there is no path conflict or name conflict between registered key components, including:

[0107] Uniqueness guarantee: a conflict check is performed before registration. If a component with the same name already exists, corresponding processing is performed (such as renaming or refusing registration); the identifier of each plug-in service is unique. On this basis, during the registration process, a preset conflict resolution strategy is used to make the name and path of the key components of each plug-in service package unique to avoid conflicts. The conflict resolution strategy includes: generating the name of the key component based on the identifier of the plug-in service corresponding to the plug-in service package, for example, generating a unique name for the key component by using the ID of the plug-in service as part of the namespace; configuring content-path for the plug-in service corresponding to the plug-in service package to specify the URL root path of the key component of the plug-in service package, that is, allowing the plug-in service to specify the URL root path of the key component by configuring content-path.

[0108] Namespace isolation: By using the plug-in service ID as part of the namespace, not only does it ensure the uniqueness of key component names, but it also achieves a high degree of isolation between plug-in services. This isolation mechanism helps reduce mutual interference between plug-ins and improves system stability and maintainability.

[0109] Furthermore, the embodiment of the present invention manages the plug-in service in a unified manner through the main service, including:

[0110] Unified Registration Center: Through the above process services, all plug-in Servlet components, Filter components, and Listener components are successfully registered in the ServletContext of the main service, but they are encapsulated in their own ServletContextWrapper instances, achieving structured management and isolation. The main service accesses and manages these components through a unified interface, while maintaining the independence and interoperability of each plug-in.

[0111] Flexibility and scalability: If the plugin service directory is updated, the plugin management framework is used to traverse the new plugin service directory, generate a new plugin service package corresponding to the plugin service in the new plugin service directory, load the new plugin service package, and register the key components of the new plugin service package to the ServletContext of the Servlet container of the main service. This plugin registration mechanism provides the system with a high degree of flexibility and scalability. With the addition of new plugins or the update of existing plugins, the system can dynamically load and register new components without modifying the core code of the main service or restarting the service. This greatly reduces the maintenance cost of the system and speeds up the launch of new features.

[0112] (IV) Plug-in service startup: As a key step in the plug-in service deployment process, plug-in startup involves complex internal mechanisms and system integration strategies. This process uses the reflection mechanism and the flexibility of the Spring framework to ensure that the plug-in can be started independently and seamlessly integrated with the main service. The following is a detailed re-description of the process:

[0113] (4.1) Based on the plug-in resource list, the plug-in management framework locates the service startup class of the plug-in service package, and uses the Java reflection mechanism to dynamically load and instantiate the service startup class.

[0114] In one example, the plug-in management framework first locates the startup class of the plug-in (i.e., the service startup class of Spring Boot) based on the information in the plug-in resource list, and then dynamically loads and instantiates the startup class using Java's reflection mechanism.

[0115] (4.2) The onStartup function in the service startup class is called through the plug-in management framework to initialize the Spring container corresponding to the plug-in service package.

[0116] In one example, after instantiation, the plugin management framework calls the onStartup method in the startup class. This method is the entry point for Spring Boot service startup and is responsible for performing service initialization. Inside the onStartup method, the plugin service completes the initialization of the Spring container (ApplicationContext). This includes loading Spring configuration files, scanning and registering bean definitions, etc., to ensure that features such as dependency injection and AOP inside the plugin service can work properly.

[0117] (4.3) After the Spring container is initialized, the Controller interface class inside the plug-in service package is identified, the URL path mapped by the annotation of the Controller interface class is packaged as a FrameworkServlet instance, and the FrameworkServlet instance is registered in the ServletContext in the Servlet container of the main service to start the plug-in service package.

[0118] In one example, after the plug-in service is initialized, it will identify and package all classes that implement the Controller interface, and package the URL path mapped by the @RequestMapping annotation of the Controller interface into a part of the FrameworkServlet. The purpose of this is to encapsulate the Web request processing capabilities of the plug-in service into a Servlet so that it can be integrated with the ServletContext of the main service.

[0119] The plugin management framework then registers these packaged FrameworkServlet instances into the ServletContext of the main service. In this way, when external requests arrive through the main service's Web server, the main service can distribute the requests to the corresponding plugin services for processing according to the URL path.

[0120] Through the above steps, the plug-in service not only completes its own initialization and Spring container construction, but also achieves seamless integration with the main service at the Web level. External users do not need to know which functions are provided by which plug-in service. They can access various services implemented by different plug-ins through a unified URL path. This integration method greatly improves the scalability and maintainability of the system. With the addition of new plug-in services or the update of existing plug-ins, the system can easily expand its functions without modifying the core code of the main service or redeploying the entire application.

[0121] (V) Plug-in service monitoring: Receive external HTTP requests through the main service, determine the target plug-in service corresponding to the HTTP request based on the specified part of the URL path of the HTTP request, and forward the HTTP request to the key component corresponding to the target plug-in service, so that the key component corresponding to the target plug-in service monitors and responds to the HTTP request, and feeds the generated response data back to the main service.

[0122] In the specific implementation, after the plug-in service is started, its service officially enters the running state, and listens and responds to external HTTP requests through pre-registered Web components such as Servlet components, Filter components, and Listener components. These components constitute the portal for the plug-in service to interact with the outside world, responsible for receiving requests, executing corresponding business logic, and finally generating response data and returning it to the requester.

[0123] In order to achieve accurate distribution of requests, each plug-in service is assigned a unique content-Path, which is used as the root URL path of the plug-in service to distinguish requests from different plug-ins. When an external HTTP request reaches the web server of the main service, the system will intelligently forward the request to the corresponding plug-in service for processing based on the content-Path part of the URL path of the request. This path-based routing mechanism ensures accurate distribution of requests and independence of plug-in services.

[0124] (VI) Plugin service shutdown: When the system is shut down or a specific plugin needs to be uninstalled, the plugin shutdown phase is triggered as an important part of the plugin service lifecycle management. This phase is designed to ensure that the plugin service can exit safely and orderly and release the resources it occupies, thereby avoiding resource leakage and other potential problems.

[0125] In one embodiment, during the shutdown process of the plug-in service, the key components of the plug-in service are traversed through the main service, and the stop interface corresponding to the plug-in service is called; when the stop interface is called, the ApplicationContext object instance inside the plug-in service is obtained through the plug-in management framework, and the close function of the ApplicationContext object instance is called through the plug-in management framework to use the close function to shut down the plug-in service.

[0126] Specifically, during the plug-in shutdown process, the main service plays the role of coordinator. It will traverse all loaded plug-ins and call the stop interface provided by each plug-in management framework in turn. This stop interface is a method exposed by the plug-in management framework and is specifically used to perform the destruction operation of the plug-in service.

[0127] When the stop interface is called, the plug-in management framework will first obtain the SpringApplicationContext object instance inside the plug-in service. ApplicationContext is the core interface for managing the bean life cycle and configuration information in the Spring framework. It contains the references and configuration information of all beans in the plug-in service.

[0128] After obtaining the ApplicationContext object, the plug-in management framework calls its close method. The close method is responsible for performing a series of cleanup operations, including destroying all Bean instances, closing the database connection pool, releasing the network port, etc., to ensure that the plug-in service does not leave any unreleased resources when it exits.

[0129] By executing the ApplicationContext shutdown method, the system can ensure that the plug-in service follows the resource management specifications of the Spring framework during the destruction process, thereby achieving elegant release of resources. This mechanism not only helps to avoid resource leakage, but also improves the stability and reliability of the system.

[0130] In addition, the plug-in shutdown phase is also an important part of the plug-in life cycle management. It marks the beginning of the transition of the plug-in service from the running state to the non-running state, and provides the necessary conditions for the system to prepare for the next life cycle stage (such as restart, update or complete uninstall).

[0131] During the plug-in shutdown phase, the stop interface of the plug-in management framework is called and the shutdown method of SpringApplicationContext is executed to ensure that the plug-in service can correctly release the occupied resources when exiting, avoiding problems such as resource leakage. This mechanism is an indispensable part of the plug-in life cycle management and provides a strong guarantee for the stable operation and elegant shutdown of the system.

[0132] In summary, the plug-in service processing method provided by the embodiment of the present invention has at least the following characteristics:

[0133] 1. Flexible class loading mechanism: Custom ClassLoader allows dynamic loading of class files. New classes can be loaded or existing classes can be updated without restarting the application. This greatly improves the flexibility and scalability of the system. By loading different modules or services through different ClassLoaders, isolation between classes can be achieved, reducing class version conflicts and dependency issues.

[0134] 2. Dynamic aggregation and integration of services: The system can dynamically aggregate multiple Spring Boot services to achieve rapid integration and deployment of services. This reduces the coupling between services and improves the modularity and maintainability of the system. Through configuration files or environment variables, the dependencies and call order between services can be flexibly configured to meet different business needs.

[0135] 3. Improve development efficiency: Spring Boot itself provides a wealth of starter dependencies and automatic configuration functions, and the dynamic aggregation integration system based on custom ClassLoader further simplifies the integration and development process between services, allowing developers to focus more on the implementation of business logic. The system supports the rapid construction of a test environment, making it easier for developers to test and verify the integrated services.

[0136] 4. Enhance system stability and reliability: Class loader isolation ensures that resources (such as memory, threads, etc.) between different services are independent of each other, avoiding the stability of the entire system being affected by an exception in a service. When an error occurs in a service, the error can be isolated by restarting the service or its ClassLoader to prevent the error from spreading to other services.

[0137] 5. Support for microservice architecture: Spring Boot naturally supports the development of microservice architecture, and the dynamic aggregation integration system based on custom ClassLoader provides strong support for microservice architecture. It makes the integration and communication between microservices more flexible and efficient.

[0138] 6. Easy maintenance and upgrade: Since services are isolated through custom ClassLoader, a service can be upgraded or updated individually without stopping the entire system. The system provides clear module division and dependency relationships, making maintenance and debugging easier and more efficient.

[0139] The plug-in service processing method based on custom ClassLoader provided in the embodiment of the present invention brings many beneficial effects such as flexible class loading mechanism, dynamic aggregation and integration of services, improved development efficiency, enhanced system stability and reliability, support for microservice architecture, and easy maintenance and upgrading. These effects together improve the overall performance of the system and user experience.

[0140] Based on the above embodiments, the present invention provides a Spring Boot service dynamic aggregation and integration system. Figure 3 The structure diagram of a Spring Boot service dynamic aggregation integration system is shown in the figure. The system mainly includes the following parts:

[0141] Initialization module 302, for performing initialization operations if a plug-in service directory is received, including main service environment initialization operations, Servlet container configuration operations, and plug-in management framework configuration operations. The plug-in management framework uses a custom ClassLoader mechanism to enable each plug-in service to have an independent class space;

[0142] The plug-in directory scanning module 304 is used to traverse the plug-in service directory using the plug-in management framework to generate a plug-in service package and a plug-in resource list corresponding to the plug-in service in the plug-in service directory. The plug-in service package includes files required to implement the plug-in service, and the plug-in resource list is used to record attribute information of each plug-in service;

[0143] The plug-in registration module 306 is used to load the plug-in service package through the plug-in management framework to register the key components of the plug-in service package into the ServletContext of the Servlet container of the main service. The key components include Servlet components, Filter components and Listener components.

[0144] The plug-in startup module 308 is used to instantiate the service startup class of the plug-in service based on the attribute information recorded in the plug-in resource list through the plug-in management framework, and use the instantiated service startup class to perform startup operations on the registered plug-in service, so that the key components of the plug-in service that enters the running state listen to and respond to external HTTP requests.

[0145] The Spring Boot service dynamic aggregation and integration system provided in the embodiment of the present invention realizes dynamic scanning, loading, registration, integration and request processing of plug-in services through clever architectural design of main services and plug-in services combined with a custom ClassLoader mechanism. The embodiment of the present invention realizes flexible scheduling and efficient utilization of resources, which can not only reduce the cost of microservice deployment and operation and maintenance, but also effectively improve resource utilization efficiency.

[0146] In one implementation, the initialization module 302 is specifically configured to:

[0147] If the plug-in service directory is received, the main service environment initialization operation is performed to initialize the system environment of the main service itself based on the plug-in service directory;

[0148] After initializing the system environment of the main service itself, the Servlet container configuration operation and the plug-in management framework configuration operation are executed. The Servlet container configuration operation is used to configure the Servlet container of the main service and initialize the ServletContext of the Servlet container. The plug-in management framework configuration operation is used to load and initialize the plug-in management framework.

[0149] In one implementation, the plug-in directory scanning module 304 is specifically used to:

[0150] Activate the plugin management framework;

[0151] Use the plugin management framework to traverse the plugin service directory to find plugin folders that meet the preset plugin specifications. Each plugin service is designed to be stored in a separate plugin folder.

[0152] Using the plug-in management framework to check the specified file in the plug-in folder, so as to identify a valid plug-in folder from the plug-in folder based on the checking result of the specified file;

[0153] The valid plug-in folder is used as the plug-in service package, and the plug-in resource list is obtained by scanning the plug-in service package.

[0154] In one implementation, the plug-in registration module 306 is specifically used to:

[0155] Generate a dynamic service class loader instance corresponding to each plug-in service based on the plug-in resource list through the custom ClassLoader mechanism of the plug-in management framework;

[0156] For each plug-in service, use the dynamic service class loader instance corresponding to the plug-in service to load the plug-in service package corresponding to the plug-in service;

[0157] After loading the plug-in service package corresponding to each plug-in service, the key components of the plug-in service package are rewritten using the ServletContextWrapper class to register the key components of the plug-in service package with the ServletContext of the Servlet container of the main service.

[0158] In one embodiment, the identifier of each plug-in service is unique; and a conflict resolution module is further included, which is used to:

[0159] During the registration process, the preset conflict resolution strategy is used to make the names and paths of key components of each plug-in service package unique;

[0160] The conflict resolution strategy includes: generating a name of a key component based on the identifier of the plug-in service corresponding to the plug-in service package; configuring a content-path for the plug-in service corresponding to the plug-in service package to specify a URL root path of the key component of the plug-in service package.

[0161] In one implementation, the plug-in startup module 308 is specifically used to:

[0162] Based on the plug-in resource list, the plug-in management framework locates the service startup class of the plug-in service package, and uses Java's reflection mechanism to dynamically load and instantiate the service startup class;

[0163] The onStartup function in the service startup class is called through the plug-in management framework to initialize the Spring container corresponding to the plug-in service package;

[0164] After the Spring container is initialized, the Controller interface class inside the plug-in service package is identified, the URL path mapped by the annotation of the Controller interface class is packaged as a FrameworkServlet instance, and the FrameworkServlet instance is registered in the ServletContext in the Servlet container of the main service to start the plug-in service package.

[0165] In one implementation, the plug-in startup module 308 is specifically used to:

[0166] Receive external HTTP requests through the main service, determine the target plug-in service corresponding to the HTTP request based on the specified part in the URL path of the HTTP request, and forward the HTTP request to the key component corresponding to the target plug-in service, so that the key component corresponding to the target plug-in service listens to and responds to the HTTP request, and feeds the generated response data back to the main service.

[0167] In one embodiment, an expansion module is further included for:

[0168] If an update to the plug-in service directory is detected, the plug-in management framework is used to traverse the new plug-in service directory, generate a new plug-in service package corresponding to the plug-in service in the new plug-in service directory, load the new plug-in service package, and register the key components of the new plug-in service package to the ServletContext of the Servlet container of the main service.

[0169] In one embodiment, a service shutdown module is further included, which is used to:

[0170] During the shutdown of the plug-in service, the key components of the plug-in service are traversed through the main service, and the stop interface corresponding to the plug-in service is called;

[0171] When the stop interface is called, the ApplicationContext object instance inside the plug-in service is obtained through the plug-in management framework, and the close function of the ApplicationContext object instance is called through the plug-in management framework to use the close function to close the plug-in service.

[0172] The device provided in the embodiment of the present invention has the same implementation principle and technical effects as those in the aforementioned method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference may be made to the corresponding contents in the aforementioned method embodiment.

[0173] An embodiment of the present invention provides an electronic device. Specifically, the electronic device includes a processor and a storage device. The storage device stores a computer program, and when the computer program is executed by the processor, it executes the method described in any one of the above-mentioned implementation methods.

[0174] Figure 4 A structural diagram of an electronic device provided in an embodiment of the present invention, the electronic device 100 includes: a processor 40, a memory 41, a bus 42 and a communication interface 43, wherein the processor 40, the communication interface 43 and the memory 41 are connected via the bus 42; the processor 40 is used to execute an executable module stored in the memory 41, such as a computer program.

[0175] The memory 41 may include a high-speed random access memory (RAM), and may also include a non-volatile memory, such as at least one disk memory. The communication connection between the system network element and at least one other network element is realized through at least one communication interface 43 (which may be wired or wireless), and the Internet, wide area network, local area network, metropolitan area network, etc. may be used.

[0176] The bus 42 may be an ISA bus, a PCI bus, or an EISA bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0177] Among them, the memory 41 is used to store programs, and the processor 40 executes the program after receiving the execution instruction. The method executed by the device for flow process definition disclosed in any embodiment of the above-mentioned embodiment of the present invention can be applied to the processor 40 or implemented by the processor 40.

[0178] The processor 40 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit or software instructions in the processor 40. The above processor 40 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present invention can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the embodiments of the present invention can be directly embodied as a hardware decoding processor to execute, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 41, and the processor 40 reads the information in the memory 41 and completes the steps of the above method in combination with its hardware.

[0179] The computer program product of the readable storage medium provided in the embodiment of the present invention includes a computer-readable storage medium storing program code, and the instructions included in the program code can be used to execute the methods described in the previous method embodiments. The specific implementation can be referred to the previous method embodiments, which will not be repeated here.

[0180] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc., which can store program codes.

[0181] Finally, it should be noted that the above-described embodiments are only specific implementations of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The protection scope of the present invention is not limited thereto. Although the present invention is described in detail with reference to the above-described embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-described embodiments within the technical scope disclosed by the present invention, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A plug-in service processing method, characterized in that: The method is applied to a Spring Boot service dynamic aggregation integration system, and the method includes: If the plug-in service directory is received, the initialization operation is performed, which includes the main service environment initialization operation, the Servlet container configuration operation, and the plug-in management framework configuration operation. The plug-in management framework uses a custom ClassLoader mechanism to enable each plug-in service to have an independent class space; Using the plug-in management framework to traverse the plug-in service directory, generate a plug-in service package and a plug-in resource list corresponding to the plug-in service in the plug-in service directory, wherein the plug-in service package includes files required to implement the plug-in service, and the plug-in resource list is used to record attribute information of each plug-in service; Loading the plug-in service package through the plug-in management framework to register key components of the plug-in service package into the ServletContext of the Servlet container of the main service, wherein the key components include Servlet components, Filter components, and Listener components; The plug-in management framework instantiates the service startup class of the plug-in service based on the attribute information recorded in the plug-in resource list, and uses the instantiated service startup class to perform startup operations on the registered plug-in service, so that the key components of the plug-in service that enters the running state listen to and respond to external HTTP requests.

2. The plug-in service processing method according to claim 1, characterized in that: If the plugin service directory is received, the initialization operation is performed, including: If the plug-in service directory is received, the main service environment initialization operation is performed to initialize the system environment of the main service itself based on the plug-in service directory; After initializing the system environment of the main service itself, the Servlet container configuration operation and the plug-in management framework configuration operation are executed. The Servlet container configuration operation is used to configure the Servlet container of the main service and initialize the ServletContext of the Servlet container. The plug-in management framework configuration operation is used to load and initialize the plug-in management framework.

3. The plug-in service processing method according to claim 1, characterized in that: The plug-in management framework is used to traverse the plug-in service directory to generate a plug-in service package and a plug-in resource list corresponding to the plug-in service in the plug-in service directory, including: Activating the plugin management framework; Using the plug-in management framework to traverse the plug-in service directory to find a plug-in folder that meets the preset plug-in specification, each of the plug-in services is designed to be stored in an independent plug-in folder; Using the plug-in management framework to check the designated file in the plug-in folder, so as to identify the valid plug-in folder from the plug-in folder based on the checking result of the designated file; The valid plug-in folder is used as a plug-in service package, and a plug-in resource list is obtained by scanning the plug-in service package.

4. The plug-in service processing method according to claim 1, characterized in that: Loading the plug-in service package through the plug-in management framework to register key components of the plug-in service package to the ServletContext of the Servlet container of the main service includes: Generate a dynamic service class loader instance corresponding to each plug-in service based on the plug-in resource list through the custom ClassLoader mechanism of the plug-in management framework; For each of the plug-in services, using the dynamic service class loader instance corresponding to the plug-in service, load the plug-in service package corresponding to the plug-in service; After loading the plug-in service package corresponding to each plug-in service, the key components of the plug-in service package are rewritten using the ServletContextWrapper class to register the key components of the plug-in service package with the ServletContext of the Servlet container of the main service.

5. The plug-in service processing method according to claim 4, characterized in that: The identifier of each plug-in service is unique; the method further comprises: During the registration process, a preset conflict resolution strategy is used to make the name and path of the key component of each plug-in service package unique; Among them, the conflict resolution strategy includes: generating the name of the key component based on the identifier of the plug-in service corresponding to the plug-in service package; configuring content-path for the plug-in service corresponding to the plug-in service package to specify the URL root path of the key component of the plug-in service package.

6. The plug-in service processing method according to claim 1, characterized in that: The plug-in management framework instantiates the service startup class of the plug-in service based on the attribute information recorded in the plug-in resource list, and uses the instantiated service startup class to perform a startup operation on the registered plug-in service, including: The plug-in management framework locates the service startup class of the plug-in service package based on the plug-in resource list, and dynamically loads and instantiates the service startup class using the Java reflection mechanism; The onStartup function in the service startup class is called through the plug-in management framework to initialize the Spring container corresponding to the plug-in service package; After the Spring container is initialized, the Controller interface class inside the plug-in service package is identified, the URL path mapped by the annotation of the Controller interface class is packaged as a FrameworkServlet instance, and the FrameworkServlet instance is registered in the ServletContext in the Servlet container of the main service to start the plug-in service package.

7. The plug-in service processing method according to claim 6, characterized in that: The key component of the plug-in service that enters the running state monitors and responds to external HTTP requests, including: An external HTTP request is received through the main service, and the target plug-in service corresponding to the HTTP request is determined according to the specified part in the URL path of the HTTP request, and the HTTP request is forwarded to the key component corresponding to the target plug-in service, so that the key component corresponding to the target plug-in service listens to and responds to the HTTP request, and feeds the generated response data back to the main service.

8. The plug-in service processing method according to claim 1, characterized in that: The method further comprises: If an update of the plug-in service directory is detected, the plug-in management framework is used to traverse the new plug-in service directory, generate a new plug-in service package corresponding to the plug-in service in the new plug-in service directory, load the new plug-in service package, and register the key components of the new plug-in service package to the ServletContext of the Servlet container of the main service.

9. The plug-in service processing method according to claim 1, characterized in that: The method further comprises: During the plug-in service shutdown process, the key components of the plug-in service are traversed through the main service, and the stop interface corresponding to the plug-in service is called; When the stop interface is called, the ApplicationContext object instance inside the plug-in service is obtained through the plug-in management framework, and the close function of the ApplicationContext object instance is called through the plug-in management framework to close the plug-in service using the close function.

10. A Spring Boot service dynamic aggregation integration system, characterized in that: include: An initialization module is used to perform initialization operations if a plug-in service directory is received. The initialization operations include the main service environment initialization operation, the Servlet container configuration operation, and the plug-in management framework configuration operation. The plug-in management framework uses a custom ClassLoader mechanism to enable each plug-in service to have an independent class space; A plug-in directory scanning module, used to traverse the plug-in service directory using the plug-in management framework, and generate a plug-in service package and a plug-in resource list corresponding to the plug-in service in the plug-in service directory, wherein the plug-in service package includes files required to implement the plug-in service, and the plug-in resource list is used to record attribute information of each plug-in service; A plug-in registration module, used to load the plug-in service package through the plug-in management framework to register key components of the plug-in service package into the ServletContext of the Servlet container of the main service, wherein the key components include Servlet components, Filter components and Listener components; The plug-in startup module is used to instantiate the service startup class of the plug-in service based on the attribute information recorded in the plug-in resource list through the plug-in management framework, and use the instantiated service startup class to perform a startup operation on the registered plug-in service, so that the key components of the plug-in service that enters the running state listen to and respond to external HTTP requests.

Images