Method and device for loading context of multi-class loader based on JVM service family
By using the service family multi-class loader context loading method on the JVM platform, the problems of service dependency complexity and management difficulty in the microservice architecture are solved, high cohesion and low operation and maintenance costs of the service family are achieved, and service collaboration and isolation effects are improved.
Patent Information
- Application Number
- CN202411773098.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-04
- Publication Date
- 2025-10-14
- Estimated Expiration
- 2044-12-04
AI Technical Summary
The dependencies between services in the microservice architecture are complex, testing and release are difficult, the maintenance workload increases, and the increase in the number of services makes management difficult.
Through the JVM-based service family multi-class loader loading context method, including system environment initialization, service scanning, child process startup, isolated loading, service integration and supervision, a multi-process multi-class loader multi-context framework is generated to achieve classified management, collaboration and isolation of the service family.
It reduces the complexity of service management, improves the cohesion within the service family, reduces development and operation costs, and ensures collaboration and isolation between services.
Smart Images

Figure CN119781737B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of software development technology, and in particular to a method and device for loading contexts of a service family multi-class loader based on a JVM. Background Art
[0002] With the acceleration of digital transformation, traditional monolithic architectures are increasingly unable to meet the rapid iteration and scalability demands of modern businesses. Applications built on monolithic architectures often become overly bloated, making horizontal scalability difficult, which in turn increases R&D and maintenance costs. In this context, the introduction of a microservices architecture has emerged as a solution. Microservices break large applications into multiple independent, smaller services, each of which can be deployed independently. This enhances business flexibility and responsiveness while reducing the risks and costs of technology upgrades. This enables enterprises to more efficiently respond to rapidly changing market demands.
[0003] While the existing microservices architecture decouples functionality between components, the resulting complexity of inter-service dependencies presents a new challenge. As services become increasingly fragmented, testing and release become significantly more difficult. Application testing often requires starting multiple related services, and the complex dependencies between them necessitate careful evaluation of the impact of each service adjustment on other services. Furthermore, the dramatic increase in the number of services brought about by the microservices architecture also complicates maintenance, especially as services interact more closely, increasing the workload of system management and maintenance.
[0004] Therefore, one or more methods are needed to solve the above problems.
[0005] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present disclosure, and therefore may include information that does not constitute prior art known to ordinary technicians in the field. Summary of the Invention
[0006] The present application shows a method and apparatus for loading context of a service family multi-class loader based on JVM.
[0007] In a first aspect, the present application provides a method for loading contexts of a service family multi-class loader based on a JVM, the method comprising:
[0008] Based on the JVM software program, the system environment of the service family is initialized and loaded to generate the service scanner startup information;
[0009] Based on the project structure, the service definition file is scanned by the service scanner startup information to generate sub-process startup information;
[0010] Based on the sub-process startup information, the sub-process context framework is isolated and loaded through the loading mechanism library to generate sub-process service registration information;
[0011] Based on the sub-process service registration information, gateway push information is generated by integrating services of the gateway sub-process of the service family, and sub-process supervision information is generated by supervising the sub-process handle;
[0012] Based on the service scanner startup information, child process startup information, child process service registration information, gateway push information, and child process supervision information, the main process verifies the child process startup service to complete the design of the multi-process, multi-class loader, and multi-context framework.
[0013] In an exemplary embodiment of the present disclosure, initializing and loading the system environment of the service family includes:
[0014] Based on the JVM software program, the system environment is initialized and loaded to generate the main process startup information;
[0015] Based on the main process startup information, the service registration configuration file is initialized and loaded to generate the service registrar startup information;
[0016] Based on the main process startup information, initialization loading is performed through the service scanning configuration file to generate service scanner startup information.
[0017] In an exemplary embodiment of the present disclosure, scanning a service definition file by starting information using the service scanner includes:
[0018] Based on the service scanner startup information, generate a service definition by scanning the sub-service definition files in the project directory;
[0019] Based on the service definition, the sub-process builder is constructed by the main process to generate the sub-process builder;
[0020] Based on the sub-process builder, sub-process startup information is generated by configuring the sub-process startup sequence.
[0021] In an exemplary embodiment of the present disclosure, the sub-process context framework is isolated and loaded through a loading mechanism library, including:
[0022] Based on the framework architecture requirements, a loading mechanism library is generated by constructing a loading mechanism for the hierarchical class loader;
[0023] Based on the sub-process startup information, the sub-process directory is scanned by loading the mechanism library to generate a context definition;
[0024] Based on the context definition, the sub-process context framework is isolated and loaded by initializing the class loader to generate a context independent service;
[0025] Based on the service registrar startup information, the sub-process service registration information is generated by registering information of the sub-process context independent service.
[0026] In an exemplary embodiment of the present disclosure, service integration is performed on the gateway sub-process of the service family, including:
[0027] Based on the sub-process service registration information, the service internal push information is generated by pushing the sub-process service to the internal gateway;
[0028] Based on the service push information, when a request occurs outside the service family, gateway push information is generated by calling the sub-process service.
[0029] In an exemplary embodiment of the present disclosure, supervising the child process handle includes:
[0030] When the sub-process service fails, based on the sub-process service registration information, the main process sends a preset plan mechanism to the sub-process to generate plan startup information;
[0031] When the sub-process service does not fail, generating status monitoring information by monitoring the health status of the sub-process based on the sub-process service registration information;
[0032] Sub-process supervision information is generated by integrating the plan startup information and status monitoring information.
[0033] In an exemplary embodiment of the present disclosure, verifying the startup service of the child process by the main process includes:
[0034] Based on the service scanner start information, sub-process start information, sub-process service registration information, gateway push information, and sub-process supervision information, the main process verifies the sub-process start service and generates verification service information;
[0035] When the verification service information is unsuccessful, the main process performs configuration repair on the sub-process to generate repair correction information, and based on the repair correction information, the main process performs secondary verification on the startup service of the sub-process;
[0036] When the verification service information is successful, the design of the multi-process multi-class loader multi-context framework is completed by connecting the external request link to the gateway of the service family.
[0037] In a second aspect, the present application provides a device for loading contexts of a service family multi-class loader based on a JVM, the device comprising:
[0038] Initialization loading module, used to initialize and load the system environment of the service family;
[0039] A sub-process startup module, configured to scan the service definition file through the service scanner;
[0040] The service registration module is used to load the sub-process context framework in isolation through the loading mechanism library;
[0041] The gateway push and process supervision module is used to integrate the services of the gateway sub-processes of the service family and supervise the sub-process handles;
[0042] The service verification module is used to verify the startup service of the child process through the main process, completing the design of the multi-process, multi-class loader and multi-context framework.
[0043] In a third aspect, the present application shows an electronic device, which includes: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the method described in any of the above aspects.
[0044] In a fourth aspect, the present application shows a non-temporary computer-readable storage medium, which, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to execute the method described in any of the above aspects.
[0045] In a fifth aspect, the present application illustrates a computer program product. When instructions in the computer program product are executed by a processor of an electronic device, the electronic device is enabled to execute the method as described in any one of the above aspects.
[0046] The technical solution provided by this application may have the following beneficial effects:
[0047] Based on the embodiments of the present disclosure, first, in the JVM software program, the service scanner start information is generated by initializing and loading the system environment of the service family. Then, based on the project structure, the sub-process start information is generated by scanning the service definition file. Then, the sub-process context framework is isolated and loaded by the loading mechanism library to generate the sub-process service registration information. And the gateway sub-process of the service family is integrated for service, to generate the gateway push information, and the sub-process handle is supervised to generate the sub-process supervision information. Finally, based on the above information, the start service of the sub-process is verified to complete the design of the multi-process multi-class loader multi-context framework. Therefore, the present disclosure provides a multi-process multi-class loader multi-context framework design scheme, which can aggregate closely related services into a service family, realizes the service family classification management of microservices, ensures the cooperation and isolation between microservices, and improves the service monitoring and operation efficiency. BRIEF DESCRIPTION OF DRAWINGS
[0048] Figure 1 is a step flow chart of a method for loading a context of a multi-class loader of a service family based on JVM of the present application.
[0049] Figure 2 is a framework flow chart of a method for loading a context of a multi-class loader of a service family based on JVM of the present application.
[0050] Figure 3 is an operation implementation flow chart of a method for loading a context of a multi-class loader of a service family based on JVM of the present application.
[0051] Figure 4 is a structure block diagram of an apparatus for loading a context of a multi-class loader of a service family based on JVM of the present application.
[0052] Figure 5 is a block diagram of an electronic device of the present application.
[0053] Figure 6 is a block diagram of a computer readable storage medium of the present application. DETAILED DESCRIPTION
[0054] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.
[0055] Reference Figure 1, a step flow chart of a method of a multi-class loader loading context of a JVM-based service family according to the present application is shown, which can be applied in an electronic device, wherein the method can specifically include the following steps:
[0056] In step S101, based on the JVM software program, the service scanner start information is generated by initializing and loading the system environment of the service family.
[0057] In step S102, based on the engineering project structure, the service definition file is scanned by the service scanner start information to generate the sub-process start information.
[0058] In step S103, based on the sub-process start information, the sub-process context framework is isolated and loaded by the loading mechanism library to generate the sub-process service registration information.
[0059] In step S104, based on the sub-process service registration information, the gateway sub-process of the service family is integrated by the service to generate the gateway push information, and the sub-process handle is supervised to generate the sub-process supervision information.
[0060] In step S105, based on the service scanner start information, the sub-process start information, the sub-process service registration information, the gateway push information, and the sub-process supervision information, the start service of the sub-process is verified by the main process to complete the design of the multi-process multi-class loader multi-context framework.
[0061] The method of the multi-class loader loading context of the JVM-based service family improves the high cohesion within the service family on the basis of ensuring the isolation and autonomy between services by classifying and managing the micro services. In this way, the complexity of service management is significantly reduced, and the overall cost of development and operation is effectively reduced.
[0062] In the following, as Figure 2 shown, the method of the multi-class loader loading context of the JVM-based service family according to the present application will be further described.
[0063] In step S101, based on the JVM software program, the service scanner start information is generated by initializing and loading the system environment of the service family.
[0064] In some optional embodiments of the present example, in order to realize a flexible micro-service splitting mechanism and provide core framework and governance capabilities between service families, a JVM (Java Virtual Machine, a virtual machine capable of executing Java bytecode, part of the Java platform, capable of running software programs written in Java language) is used as a software program writing platform to initialize the framework of the entire system, while ensuring high cohesion micro-service governance within the service family, the independence and scalability between service families are also guaranteed.
[0065] Among them, the micro-service interaction between service families through REST, RPC (Representational State Transfer and Remote Procedure Call are two common communication protocols and architecture styles used for communication between different components in distributed systems) and other forms still uses existing technologies and is not described in detail. The following is a detailed description of the service implementation mechanism of a single service family.
[0066] The main process is started on the JVM platform, and the initialization of the system environment will be performed along with the startup of the main process. First, the system will load the configuration file, set the runtime environment, and initialize the log system to provide necessary recording and debugging information for subsequent operations. After that, the main process will check whether the external resources and external services depended by the child process services are ready, to ensure that the system environment meets the needs of all services. At the same time, the main process will perform corresponding service configuration based on the service family startup parameters contained in the configuration file, to issue the main process startup information to the components in the system.
[0067] On the one hand, after the main process loads the service registration configuration file, the service registrar (ProcessBuilder) completes the startup based on the service registrar startup information. When starting, the main process will load the service registrar and initialize it to a listening mode. After that, the service registrar will track the health status and service state of each child process to ensure that all services can remain available. Its main responsibility is to coordinate the service registration and deregistration between child processes. Each child process will register its own information to the service registrar when starting, and the service registrar will regularly check the health status of each child process and trigger an alarm mechanism or perform repair operations when an exception occurs.
[0068] On the other hand, the main process starts the service scanner based on the service scanner start information after loading the configuration file of the service scan. The main function of the service scanner is to scan the service directory and find and parse all configuration files (usually XML files) containing service definitions. These configuration files contain detailed service definitions for each sub-process, including the required resources, dependent libraries, and used environment variables, etc.
[0069] In step S102, the service definition file can be scanned by the service scanner start information based on the engineering project structure to generate sub-process start information.
[0070] In some optional embodiments of the present example, the service scanner will traverse all folders in the project when scanning the service directory to find service configuration files therein. These files are usually in XML format and record specific configuration information of the sub-process. Each service configuration file describes the service definition of the required resources, dependent libraries, configuration parameters, and running environment of the sub-process. By scanning these configuration files, the main process can understand the resource requirements of each sub-process and make sufficient preparations for subsequent creation and start of the sub-process. Meanwhile, the configuration file can also contain information about the start order, service priority, and dependency relationship to help the main process reasonably arrange the start process of each sub-process.
[0071] According to the service definition obtained by scanning, the main process will first construct a sub-process constructor and use the sub-process constructor to construct and start each sub-process instance. The sub-process constructor is a class in Java that provides a simple way to start a process.
[0072] When constructing the sub-process, the main process will generate the corresponding start command according to the specific configuration of each sub-service and set the necessary environment variables, working directory, etc. through the sub-process constructor to ensure that the sub-process can run in a suitable environment. The start command of each sub-process is dynamically generated according to the specific requirements of its service. These commands contain necessary execution parameters, class path settings, etc. to ensure that the sub-process can be successfully started and begin to execute the scheduled task.
[0073] Once all the sub-process start commands and configurations are ready, the main process will start all the sub-processes in sequence and feed back the sub-process start information to the main process after waiting for the initialization of the started sub-process to complete. During the start process, the main process will also monitor the status of the sub-process in real time to ensure that each sub-process can be started as expected and work normally. If any problem is found during the start process, the main process will handle the fault in time according to the sub-process start failure information. Each sub-process in the service family will independently execute its task and will periodically report the health status and log information to the main process to ensure the continuity and stability of the service.
[0074] In step S103, based on the sub-process startup information, the sub-process context framework may be isolated and loaded through a loading mechanism library to generate sub-process service registration information.
[0075] In some optional embodiments of this example, each sub-process needs to initialize its own class loader (Classloader, a component of the Java Runtime Environment (Java Runtime Environment), is responsible for dynamically loading Java classes into the memory space of the Java virtual machine) after it is started. In a multi-process architecture, in order to ensure the independence of each sub-process, a different hierarchical class loader is usually configured for each sub-process. The hierarchical class loader of each sub-process will load the required classes and resources according to a pre-defined hierarchical mechanism. This mechanism can effectively avoid class loading conflicts between different sub-processes. The hierarchical class loaders of all sub-processes are combined to form a loading mechanism library in the system framework (Class Loading Mechanism Libraries, referred to as "lib library", refers to a set of precompiled code files. These code files usually contain functions, methods, classes and other modules that can be reused in the program. Developers can avoid rewriting the same functional code by introducing these libraries, thereby improving development efficiency).
[0076] After each child process sends its startup message, it scans its own directory for multi-context configuration files to complete the context definition. These configuration files define the different service environments within the child process, with each context representing an independent service module or functional module. By scanning these context configurations, the child process understands the specific business logic it needs to handle and configures independent resources and environments for each context.
[0077] However, since each context may have different dependencies and configuration requirements, it is necessary to extract independent hierarchical class loaders from the loading mechanism library to load the corresponding classes and resources to ensure complete isolation between different modules.
[0078] The child process then assigns a separate hierarchical class loader to each context based on the scanned multi-context configuration (i.e., context definition) to load context-independent services. Each context represents an independent service environment, meaning that classes and resources within each context must be loaded within an isolated hierarchical class loader environment.
[0079] In this way, the system can ensure that classes and resources between different contexts do not interfere with each other, while also avoiding the problem of class path pollution. This isolation mechanism not only improves the maintainability and modularity of the system, but also provides greater flexibility for subsequent expansion and maintenance. Services within each context can run independently without interfering with each other, thereby enhancing the stability and scalability of the entire system.
[0080] Finally, each child process will start the corresponding service (service can be a background task, computing task, database operation, or web service, etc.) according to its own configuration. After starting, the child process will register its context-independent service information to the main process through the service registry, generating child process service registration information. The main process will monitor the running state of the child process based on these child process service registration information, ensuring that the service can provide normal functions.
[0081] In step S104, based on the child process service registration information, the gateway child process of the service family can be integrated to generate gateway push information, and the child process handle can be supervised to generate child process supervision information.
[0082] In some optional embodiments of the present example, once the child process starts and begins to run the service, the main process will record the service information provided by each child process through the service registry, and constantly monitor its health status and performance indicators. Through this registration mechanism, the main process can master the service capabilities of all child processes in the system, and provide necessary data support for subsequent request routing, load balancing and fault recovery. Among them, the service information of each child process can be its process identifier, service type, state and performance data, etc.
[0083] In the entire multi-process architecture, the gateway child process is relatively special, as the unified entrance of all services, it is responsible for handling external requests. When the main process passes the service information of all other child processes to the gateway child process, the gateway child process can ensure correct routing of requests and forwarding to the target service.
[0084] That is, when other service families in the microservice network send service call requests to the current service family through RPC (Remote Procedure Call), REST (Representational State Transfer) and other service call methods, the gateway child process can route the request to the corresponding child process service based on the service internal push information pushed by the main process to itself, and feedback the main process gateway push information.
[0085] Preferably, the gateway child process can also undertake tasks such as load balancing, request forwarding, fault recovery, etc., to ensure that external requests can be efficiently and stably processed.
[0086] In some optional embodiments of the present example, after the configuration and start of all sub-processes, including the gateway sub-process, are completed, the main process continuously monitors the status of all sub-processes and their services.
[0087] When there is no fault, the main process periodically collects health status, log information and performance data of the sub-processes, and determines whether there is a potential problem according to the detection results to generate status monitoring information. If it is found that a sub-process has a fault or performance degradation (such as crash or deadlock), the main process triggers an automatic alarm mechanism, generates a pre-plan start information, automatically sends an alarm notification to the relevant personnel or system, and takes corresponding recovery measures.
[0088] The pre-plan start information and the status monitoring information together constitute the sub-process supervision information of the sub-processes. In this way, the system can maintain high availability during operation and avoid service interruption or performance bottleneck.
[0089] Preferably, the main process can also set up a management console that provides an intuitive interface to simplify system management and maintenance. Through the console, the administrator can view the health status and performance indicators of the services in real time, perform start, stop, restart and other operations on the services, and perform log viewing and problem troubleshooting.
[0090] In step S105, the start service of the sub-process can be verified by the main process based on the service scanner start information, the sub-process start information, the sub-process service registration information, the gateway push information and the sub-process supervision information, and the design of the multi-process, multi-class loader and multi-context framework is completed.
[0091] In some optional embodiments of the present example, once all sub-processes and contexts are successfully started and all services have been registered with the gateway, the entire service family startup process is completed. At this time, the system will perform a comprehensive health check to ensure that all services have been correctly started and are running normally. The service registrar, the gateway sub-process and all sub-processes will undergo a round of verification to ensure that the services can provide stable and reliable interfaces to the outside.
[0092] At this time, the main process will perform verification operations to generate verification service information to confirm that the services provided by each sub-process can work as expected. These verifications include service response time, data consistency check, performance load test, etc. The main process will simulate different types of requests to verify whether the sub-processes can quickly respond and return correct data. At the same time, the system will perform high-concurrency testing to check the performance of the services under high load to ensure that there is no performance bottleneck in the production environment. In addition, data consistency verification is also an important step, and the main process will ensure the data synchronization and consistency between sub-processes to avoid errors caused by inconsistent data.
[0093] If a sub-process fails verification, a repair and correction message is generated. Based on this information, the main process takes remedial measures to repair the sub-process, such as restarting it or providing necessary support. Once the sub-process is repaired, it undergoes a second verification. This series of checks ensures that the system achieves the expected stability and availability before officially launching services.
[0094] After all services have passed verification, the design of the multi-process, multi-class loader, and multi-context framework is complete, and the system officially provides comprehensive service capabilities. At this point, the gateway sub-process will handle all external requests and distribute them to the various sub-processes through load balancing. Each sub-process will perform the corresponding service based on the request type and business needs, ensuring that the system can provide processing power on demand. Simultaneously, the management console will continue to monitor the system status, ensuring that any potential issues are promptly identified and resolved during service operation. The entire service framework enters a stable operation phase, capable of providing efficient and stable services to external users.
[0095] It should be noted that for the method embodiments, for simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all optional embodiments, and the actions involved are not necessarily required by this application.
[0096] Reference Figure 4 , shows a structural block diagram of a device 400 for loading contexts of a JVM-based service family multi-class loader of the present application, the device comprising:
[0097] Initialization loading module 401, used to initialize and load the system environment of the service family;
[0098] A sub-process starting module 402 is used to scan the service definition file through the service scanner;
[0099] The service registration module 403 is used to load the sub-process context framework in isolation through the loading mechanism library;
[0100] The gateway push and process monitoring module 404 is used to integrate the services of the gateway sub-processes of the service family and monitor the sub-process handles;
[0101] The service verification module 405 is used to verify the startup service of the child process through the main process, completing the design of the multi-process and multi-class loader loading context framework.
[0102] For the apparatus embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant part can be referred to the part of the method embodiment.
[0103] Optionally, the embodiment of the present application further provides an electronic device, including: a processor, a memory, a computer program stored in the memory and executable in the processor, when the computer program is executed by the processor, each process of the above method embodiment is realized, and the same technical effects can be achieved, to avoid repetition, which will not be repeated here.
[0104] The embodiment of the present application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program, when the computer program is executed by the processor, each process of the above method embodiment is realized, and the same technical effects can be achieved, to avoid repetition, which will not be repeated here. The computer readable storage medium is, for example, a read-only memory (Read-Only Memory, ROM), a random access memory (Random Access Memory, RAM), a magnetic disk or an optical disk.
[0105] Figure 5 is a block diagram of an electronic device 800 shown in the present application. For example, the electronic device 800 can be a mobile phone, a computer, a digital broadcast terminal, a message transmission device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.
[0106] Referring to Figure 5 , the electronic device 800 can include one or more of the following components: a processing component 802, a memory 804, a power supply component 806, a multimedia component 808, an audio component 810, an input / output (I / O) interface 812, a sensor component 814, and a communication component 816.
[0107] The processing component 802 usually controls the overall operation of the electronic device 800, such as operations associated with displaying, making phone calls, data communications, camera operations and recording operations. The processing component 802 can include one or more processors 820 to execute instructions to complete all or part of the steps of the above method. In addition, the processing component 802 can include one or more modules to facilitate interaction between the processing component 802 and other components. For example, the processing component 802 can include a multimedia module to facilitate interaction between the multimedia component 808 and the processing component 802.
[0108] The memory 804 is configured to store various types of data to support the operation of the electronic device 800. Examples of such data include instructions for any application or method operating on the electronic device 800, contact data, phonebook data, messages, images, videos, and the like. The memory 804 can be implemented by any type of volatile or nonvolatile memory, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, a magnetic disc or a optical disc.
[0109] The power component 806 supplies power for various components of the electronic device 800. The power component 806 can include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the electronic device 800.
[0110] The multimedia component 808 includes a screen providing an output interface between the electronic device 800 and a user. In some embodiments, the screen can include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense a touch, a slide, and a gesture on the touch panel. The touch sensor can not only sense a boundary of a touching or a sliding action, but also detect duration and pressure related to the touching or sliding action. In some embodiments, the multimedia component 808 includes a front camera and / or a back camera. The front camera and / or the back camera can receive external multimedia data when the device 800 is in an operating mode, such as a shooting mode or a video mode. Each of the front and back cameras can be a fixed optical lens system or have a focal length and optical zoom capability.
[0111] The audio component 810 is configured to output and / or input an audio signal. For example, the audio component 810 includes a microphone (MIC) configured to receive an external audio signal when the electronic device 800 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal can be further stored in the memory 804 or transmitted via the communication component 816. In some embodiments, the audio component 810 also includes a speaker for outputting an audio signal.
[0112] The I / O interface 812 provides an interface between the processing component 802 and peripheral interface modules, which can be a keypad, a click wheel, buttons, and the like. The buttons can include, but are not limited to, a home button, a volume button, a start button, and a lock button.
[0113] The sensor component 814 includes one or more sensors for providing status assessments for various aspects of the electronic device 800. For example, the sensor component 814 can detect an open / closed position of the device 800, relative positioning of components, such as a display and a keypad of the electronic device 800, a change in position of the electronic device 800 or a component of the electronic device 800, presence or absence of user contact with the electronic device 800, orientation or acceleration / deceleration / g-force and temperature of the electronic device 800. The sensor component 814 can include an optical sensor for detecting ambient light, a proximity sensor for detecting nearby objects without any physical touch, a CMOS or CCD image sensor for use in imaging applications, or an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor in some embodiments.
[0114] The communication component 816 is configured to facilitate wired or wireless communication between the electronic device 800 and other devices. The electronic device 800 can access a wireless network based on a communication standard, such as WiFi, a cellular network standard (such as 2G, 3G, 4G, or 5G), or a combination thereof. In an example embodiment, the communication component 816 receives broadcast signals or broadcast operation information from an external broadcast management system via a broadcast channel. In an example embodiment, the communication component 816 can further include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technology.
[0115] In an example embodiment, the electronic device 800 can be implemented using one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, micro-controllers, microprocessors, or other electronic elements for performing the above-described methods.
[0116] In an example embodiment, a non-transitory computer-readable storage medium including instructions, such as the memory 804 including instructions, is also provided, which can be executed by the processor 820 of the electronic device 800 to implement the above-described methods. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disc, and an optical data storage device, etc.
[0117] Figure 6is a block diagram of a computer-readable storage medium 1900 shown in the present application. For example, the computer-readable storage medium 1900 can be provided as a server.
[0118] Referring to Figure 6 The computer-readable storage medium 1900 includes a processing component 1922, which further includes one or more processors, and a memory resource represented by a memory 1932, for storing instructions executable by the processing component 1922, such as an application program. The application program stored in the memory 1932 can include one or more than one module each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute the instructions to perform the above-mentioned method.
[0119] The computer-readable storage medium 1900 can also include a power supply component 1926 configured to perform power management of the computer-readable storage medium 1900, a wired or wireless network interface 1950 configured to connect the computer-readable storage medium 1900 to a network, and an input / output (I / O) interface 1958. The computer-readable storage medium 1900 can operate based on an operating system stored in the memory 1932, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM or the like.
[0120] It should be noted that in this paper, the term "include", "contain" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or includes elements inherent to such process, method, article or device. Without more limitations, the element defined by the statement "including a" does not exclude the presence of another identical element in the process, method, article or device including the element.
[0121] From the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment method can be realized by means of software and necessary general hardware platform, of course, it can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes a plurality of instructions for making a terminal (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) execute the methods described in various embodiments of the present application.
[0122] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of this application, ordinary technicians in this field can also make many forms without departing from the purpose of this application and the scope of protection of the claims, all of which are within the protection of this application.
[0123] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in the embodiments of this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.
[0124] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0125] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0126] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.
[0127] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0128] If the functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the parts that contribute to the prior art or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes various media that can store program codes, such as a U disk, a mobile hard disk, a ROM, a RAM, a magnetic disk or an optical disk, etc.
[0129] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.
Claims
1. A method for loading context of a service family multi-class loader based on JVM, characterized in that: The method comprises: Based on the JVM software program, the service scanner is loaded when the system environment of the service family is initialized and loaded, and the service scanner start information is generated; Based on the project structure, the service definition file is scanned by the service scanner startup information to generate sub-process startup information; Based on the sub-process startup information, the sub-process context framework is isolated and loaded through the loading mechanism library to generate sub-process service registration information; Based on the sub-process service registration information, gateway push information is generated by integrating services of the gateway sub-process of the service family, and sub-process supervision information is generated by supervising the sub-process handle; Based on the service scanner startup information, child process startup information, child process service registration information, gateway push information, and child process supervision information, the main process verifies the child process startup service and completes the design of the multi-process and multi-class loader loading context framework.
2. The method according to claim 1, wherein Initialize and load the system environment of the service family, including: Based on the JVM software program, the system environment is initialized and loaded to generate the main process startup information; Based on the main process startup information, the service registration configuration file is initialized and loaded to generate the service registrar startup information; Based on the main process startup information, initialization loading is performed through the service scanning configuration file to generate service scanner startup information.
3. The method according to claim 2, wherein Scanning the service definition file through the service scanner startup information includes: Based on the service scanner startup information, generate a service definition by scanning the sub-service definition files in the project directory; Based on the service definition, the builder of the sub-process is constructed by the main process to generate a sub-process builder; Based on the sub-process builder, sub-process startup information is generated by configuring the sub-process startup sequence.
4. The method according to claim 3, wherein The subprocess context framework is isolated and loaded through the loading mechanism library, including: Based on the framework architecture requirements, a loading mechanism library is generated by constructing a loading mechanism for the hierarchical class loader; Based on the sub-process startup information, the sub-process directory is scanned by loading the mechanism library to generate a context definition; Based on the context definition, the sub-process context framework is isolated and loaded by initializing the class loader to generate a context independent service; Based on the service registrar startup information, the sub-process service registration information is generated by registering information of the sub-process context independent service.
5. The method according to claim 4, characterized in that By performing service integration on the gateway sub-process of the service family, including: Based on the sub-process service registration information, the service internal push information is generated by pushing the sub-process service to the internal gateway; Based on the service push information, when a request occurs outside the service family, gateway push information is generated by calling the sub-process service.
6. The method according to claim 5, characterized in that By supervising the child process handle, including: When the sub-process service fails, based on the sub-process service registration information, the main process sends a preset plan mechanism to the sub-process to generate plan startup information; When the sub-process service does not fail, generating status monitoring information by monitoring the health status of the sub-process based on the sub-process service registration information; Sub-process supervision information is generated by integrating the plan startup information and status monitoring information.
7. The method according to claim 6, characterized in that Verify the startup service of the child process through the main process, including: Based on the service scanner start information, sub-process start information, sub-process service registration information, gateway push information, and sub-process supervision information, the main process verifies the sub-process start service and generates verification service information; When the verification service information is unsuccessful, the main process performs configuration repair on the sub-process to generate repair correction information, and based on the repair correction information, the main process performs secondary verification on the startup service of the sub-process; When the verification service information is successful, the design of the multi-process multi-class loader multi-context framework is completed by connecting the external request link to the gateway of the service family.
8. A device for loading context of multiple class loaders of a service family based on JVM, characterized in that: include: Initialization loading module, used to initialize and load the system environment of the service family; A sub-process startup module, configured to scan the service definition file through the service scanner; The service registration module is used to load the sub-process context framework in isolation through the loading mechanism library; The gateway push and process supervision module is used to integrate the services of the gateway sub-processes of the service family and supervise the sub-process handles; The service verification module is used to verify the startup service of the child process through the main process, completing the design of the multi-process and multi-class loader loading context framework.
9. An electronic device, characterized in that: include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the method according to any one of claims 1 to 7 when executed by the processor.
10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which implements the method according to any one of claims 1 to 7 when executed by a processor.
Citation Information
Patent Citations
Resource management method and device for nodes in Kubernetes and medium
CN111367659A
Dynamic configuration management method and system in microservice framework
WO2020237797A1