Method and device for loading context by service family multi-class loader based on JVM (Java Virtual Machine)
Through the JVM-based service family multi-class loader loading context method, a multi-process multi-class loader multi-context framework is designed, which solves the problem of testing and release difficulty and maintenance workload caused by the complexity of dependence between services in the microservice architecture, realizes service family classification management, collaboration and isolation, and improves operation and maintenance efficiency.
Patent Information
- Application Number
- CN202411773098.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-04
- Publication Date
- 2025-04-08
- Estimated Expiration
- 2044-12-04
AI Technical Summary
Due to the complexity of the dependencies between services, the existing microservice architecture has greatly increased the difficulty of testing and release, increased maintenance workload, and low management and operation and maintenance efficiency.
The multi-class loader loading context method based on JVM is adopted. Through initial loading, service scanning, child process startup, service registration, gateway push and process supervision, a multi-process multi-class loader multi-context framework is designed to realize service family classification management, collaboration and isolation.
By aggregating closely related services into the service family, the service family classification management of microservices is realized, the cooperation and isolation between services is ensured, service monitoring and operation and maintenance efficiency is improved, and development and operation and maintenance costs are reduced.
Smart Images

Figure CN119781737A_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 architecture is gradually unable to meet the needs of modern business for rapid iteration and expansion. Applications under monolithic architecture are often too bloated, which makes it difficult to expand horizontally, thereby increasing the cost of R&D and maintenance. In this context, the introduction of microservice architecture has become a solution. Microservices split large applications into multiple independent small services, each of which can be deployed independently, enhancing the flexibility and responsiveness of the business while reducing the risk and cost of technology upgrades. This enables enterprises to respond to rapidly changing market demands more efficiently.
[0003] Although the existing microservice architecture decouples the functions between components, the resulting complexity of inter-service dependencies has become a new problem. As services are split into smaller and smaller parts, the difficulty of testing and releasing increases significantly. Application testing often requires starting multiple related services, and the complex dependencies require that each service adjustment be carefully evaluated for its impact on other services. In addition, the dramatic increase in the number of services brought about by the microservice architecture has also made maintenance more difficult, especially when the interactions between services become increasingly close, the workload of system management and maintenance continues to increase.
[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 the prior art known to ordinary technicians in the field. Summary of the invention
[0006] The present application shows a method and device for context loading of multiple class loaders of a service family based on JVM.
[0007] In a first aspect, the present application shows 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 service scanner startup information is generated by initializing and loading the system environment of the service family;
[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-processes of the service family, and sub-process supervision information is generated by supervising the sub-process handles;
[0012] Based on the service scanner startup information, sub-process startup information, sub-process service registration information, gateway push information, and sub-process supervision information, the main process verifies the startup service of the sub-process 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 registrar startup information is generated by initializing and loading the configuration file of the service registration;
[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 the service definition file by starting the service scanner includes:
[0018] Based on the service scanner start 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 subprocess context framework is isolatedly loaded through a loading mechanism library, including:
[0022] Based on the framework architecture requirements, the loading mechanism of the hierarchical class loader is constructed to generate a loading mechanism library;
[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 subprocess 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 subprocess 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, based on the sub-process service registration information, the health status of the sub-process is monitored to generate status monitoring 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 sub-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 shows a device for loading context of a service family multi-class loader based on JVM, the device comprising:
[0038] Initialization loading module, used to initialize and load the system environment of the service family;
[0039] A subprocess startup module, used for scanning the service definition file through the service scanner;
[0040] The service registration module is used to load the subprocess context framework in isolation through the loading mechanism library;
[0041] The gateway push and process monitoring module is used to integrate the services of the gateway sub-processes of the service family and monitor 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 illustrates a non-temporary computer-readable storage medium, which, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to execute a method as 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 described in any of the above aspects.
[0046] The technical solution provided by this application may have the following beneficial effects:
[0047] Based on the embodiment of the present disclosure, first, in the JVM software program, by initializing and loading the system environment of the service family, the service scanner startup information is generated. Afterwards, based on the project structure, the service definition file is scanned to generate the sub-process startup information. Then, the sub-process context framework is isolated and loaded through the loading mechanism library to generate the sub-process service registration information. And, by integrating the services of the gateway sub-process of the service family, the gateway push information is generated, and the sub-process handle is supervised to generate the sub-process supervision information. Finally, based on the above information, the startup service of the sub-process is verified to complete the design of the multi-process multi-class loader multi-context framework. Therefore, the implementation of the present disclosure can aggregate closely related services into a service family by providing a multi-process multi-class loader multi-context framework design scheme, realize the service family classification management of microservices, ensure the collaboration and isolation between microservices, and improve the service monitoring and operation efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0048] Figure 1 This is a flowchart of the steps of a method for loading contexts of a service family multi-class loader based on JVM in the present application.
[0049] Figure 2 It is a framework flow chart of a method for loading contexts of a service family multi-class loader based on JVM in the present application.
[0050] Figure 3 This is a flowchart of the operation implementation of a method for loading contexts of a service family multi-class loader based on JVM in the present application.
[0051] Figure 4 It is a structural block diagram of a device for loading context of a JVM-based service family multi-class loader of the present application.
[0052] Figure 5 It 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 following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0055] Reference Figure 1, shows a flowchart of a method for loading contexts of a service family multi-class loader based on JVM of the present application, the method can be applied to electronic devices, wherein the method can specifically include the following steps:
[0056] Step S101 : Based on the JVM software program, the system environment of the service family is initialized and loaded to generate service scanner start information.
[0057] Step S102: Based on the project structure, the service definition file is scanned by the service scanner startup information to generate sub-process startup information.
[0058] Step S103: Based on the sub-process startup information, the sub-process context framework is isolated and loaded through a loading mechanism library to generate sub-process service registration information.
[0059] Step S104, based on the sub-process service registration information, by integrating the services of the gateway sub-processes of the service family, generating gateway push information, and by supervising the sub-process handles, generating sub-process supervision information.
[0060] Step S105, based on the service scanner startup information, sub-process startup information, sub-process service registration information, gateway push information, and sub-process supervision information, the main process verifies the startup service of the sub-process to complete the design of the multi-process multi-class loader multi-context framework.
[0061] This method of loading contexts of multiple class loaders of service families based on JVM improves the high cohesion within the service family by classifying and managing microservices in service families while ensuring isolation and autonomy between services. In this way, the complexity of service management is significantly reduced, and the overall cost of development and operation and maintenance is effectively reduced.
[0062] Below, as Figure 2 As shown, a method for loading contexts of a service family multi-class loader based on JVM in an embodiment of the present disclosure will be further described.
[0063] In step S101, service scanner start information may be generated by initializing and loading the system environment of the service family based on the JVM software program.
[0064] In some optional embodiments of this example, in order to implement a flexible microservice splitting mechanism and provide a core framework and governance capabilities between service families, JVM (Java Virtual Machine, a virtual machine that can execute Java bytecode, is part of the Java platform and can run software programs written in Java) is used as a software program writing platform to initialize the framework of the entire system. While ensuring highly cohesive microservice governance within the service family, the independence and scalability between service families are also guaranteed.
[0065] Among them, the microservices in which service families interact with each other through REST and RPC (Representational State Transfer and Remote Procedure Call are two common communication protocols and architectural styles used for communication between different components in a distributed system) still use existing technologies and will not be described in detail. The following is a detailed description of the service implementation mechanism of a single service family as an example.
[0066] The main process is started on the JVM platform, and the system environment is initialized along with the start of the main process. First, the system loads the configuration file, sets the runtime environment, and initializes the log system so that the necessary logging and debugging information can be provided in subsequent operations. After that, the main process checks whether the external resources and external services that the subprocess services depend on are ready to ensure that the system environment meets the requirements of all services. At the same time, the main process performs corresponding service configuration based on the service family startup parameters contained in the configuration file to send the main process startup information to the components in the system.
[0067] On the one hand, after the main process loads the configuration file for service registration, the service registrar (ProcessBuilder) completes the startup based on the service registrar startup information. At startup, the main process loads the service registrar and initializes it to listening mode. After that, the service registrar ensures that all services remain available by tracking the health status and service status of each child process. Its main responsibility is to coordinate the registration and deregistration of services between child processes. Each child process will register its own information with the service registrar at startup. The service registrar will regularly check the health status of each child process and trigger an alarm mechanism or perform repair operations when an abnormality occurs.
[0068] On the other hand, after the main process loads the service scanning configuration file, the service scanner is started based on the service scanner startup information. The main function of the service scanner is to scan the service directory, find and parse all configuration files (usually XML files) containing service definitions. These configuration files contain detailed service definitions for each child process, including the required resources, dependent libraries, and environment variables used.
[0069] In step S102, based on the engineering project structure, the service definition file may be scanned by the service scanner start information to generate sub-process start information.
[0070] In some optional embodiments of this example, when scanning the service directory, the service scanner will traverse all folders in the project to find the service configuration files therein. These files are usually in XML format and record the specific configuration information of the sub-process. Each service configuration file describes the service definition such as resources, dependent libraries, configuration parameters and operating environment required by the sub-process. By scanning these configuration files, the main process can understand the resource requirements of each sub-process and make full preparations for the subsequent creation and startup of the sub-process. At the same time, the configuration file may also contain information about the startup order, service priority and dependency relationships to help the main process reasonably arrange the startup process of each sub-process.
[0071] According to the service definition obtained by scanning, the main process will first build a subprocess builder, and use the subprocess builder to build and start each subprocess instance. The subprocess builder is a class in Java that provides a simple way to start a process.
[0072] When building a subprocess, the main process will generate the corresponding startup command according to the specific configuration of each subservice, and set the necessary environment variables, working directory and other parameters through the subprocess builder to ensure that the subprocess can run in a suitable environment. The startup command of each subprocess is dynamically generated according to the specific requirements of its service. These commands contain the necessary execution parameters, classpath settings, etc., to ensure that the subprocess can be successfully started and start executing the scheduled tasks.
[0073] Once all subprocess startup commands and configurations are ready, the main process will start all subprocesses one by one in order, and after waiting for the subprocesses to be started to initialize, it will feedback the subprocess startup information to the main process. During the startup process, the main process will also monitor the status of the subprocesses in real time to ensure that each subprocess can start and work normally as expected. If any problems are found during the startup process, the main process will promptly handle the fault according to the subprocess startup failure information. Each subprocess in the service family will perform its tasks independently, and will regularly report 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 subprocess needs to initialize its own class loader (Classloader, a component of the Java Runtime Environment, 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 subprocess, different hierarchical class loaders are usually configured for each subprocess. The hierarchical class loader of each subprocess will load the required classes and resources according to a predefined hierarchical mechanism, which can effectively avoid class loading conflicts between different subprocesses. The hierarchical class loaders of all subprocesses are combined to form a loading mechanism library (Class Loading Mechanism Libraries, referred to as "lib library" in the system framework) in a group of precompiled code files, which 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 the child process startup information, the child process scans its own directory to find multi-context configurations to complete the context definition. These configuration files define different service environments in the child process, that is, each context represents an independent service module or function module. By scanning these context configurations, the child process can understand which specific business logic it needs to process and configure independent resources and environments for each different 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] Afterwards, the child process will specify an independent hierarchical class loader for each context to load context-independent services based on the scanned multi-context configuration (i.e., context definition). Each context represents an independent service environment, which means that the classes and resources in each context need to be loaded in 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 classpath 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 in each context can run independently without interfering with each other, thereby enhancing the stability and scalability of the entire system.
[0080] Finally, each sub-process will start the corresponding service according to its own configuration (the service can be a background task, computing task, database operation, or Web service, etc.). After the startup is completed, the sub-process will register its own context-independent service information with the main process through the service register to generate the sub-process service registration information. The main process will monitor the running status of the sub-process based on these sub-process service registration information to ensure that the service can provide functions normally.
[0081] In step S104, based on the sub-process service registration information, gateway push information may be generated by integrating services of the gateway sub-processes of the service family, and sub-process supervision information may be generated by supervising the sub-process handles.
[0082] In some optional embodiments of this example, once the sub-process is started and starts running the service, the main process will record the service information provided by each sub-process through the service register, and monitor its health status and performance indicators at all times. Through this registration mechanism, the main process can grasp the service capabilities of all sub-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 sub-process can be its process identification, service type, status and performance data, etc.
[0083] In the entire multi-process architecture, the gateway subprocess is relatively special. It serves as the unified entrance for all services and is responsible for handling external requests. When the main process passes the service information of all other subprocesses to the gateway subprocess, the gateway subprocess can ensure that the request is correctly routed and forwarded 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 service call methods such as RPC (remote procedure call) and REST (representational state transfer), the gateway sub-process can route the request to the corresponding sub-process service based on the service push information pushed to itself by the main process, and feedback the main process gateway push information.
[0085] Preferably, the gateway subprocess can also undertake tasks such as load balancing, request forwarding, and fault recovery to ensure that external requests can be processed efficiently and stably.
[0086] In some optional embodiments of this example, after all sub-processes, including the configuration and startup of the gateway sub-process, are completed, the main process will continue to monitor the status of all sub-processes and their services.
[0087] When no failure occurs, the main process will regularly collect the health status, log information and performance data of the child process, and determine whether there are potential problems based on the detection results, and generate status monitoring information. If a child process is found to have a failure or performance degradation (such as a crash or deadlock), the main process will trigger the automatic alarm mechanism, generate a plan startup information, automatically issue an alarm to notify relevant personnel or systems, and take appropriate recovery measures.
[0088] The above-mentioned plan startup information and status monitoring information together constitute the sub-process supervision information of the sub-process. This can enable the system to maintain high availability during operation and avoid service interruptions or performance bottlenecks.
[0089] Preferably, the main process can also set up a management console, which can provide an intuitive interface to simplify the management and maintenance of the system. Through the console, the administrator can view the health status and performance indicators of the service in real time, perform operations such as starting, stopping, and restarting the service, and view logs and troubleshoot problems.
[0090] In step S105, based on the service scanner startup information, sub-process startup information, sub-process service registration information, gateway push information, and sub-process supervision information, the main process can verify the startup service of the sub-process to complete the design of the multi-process, multi-class loader, and multi-context framework.
[0091] In some optional embodiments of this example, once all subprocesses and contexts are successfully started and all services have been registered with the gateway, the startup process of the entire service family is complete. At this point, the system will perform a comprehensive health check to ensure that all services have been correctly started and are running normally. The service registrar, gateway subprocess, and all subprocesses will undergo a round of verification to ensure that the service can provide a stable and reliable interface to the outside world.
[0092] At this point, the main process will perform verification operations, generate verification service information, and confirm that the services provided by each sub-process can work as expected. These verifications include service response time, data consistency checks, performance load tests, etc. The main process will simulate different types of requests to verify whether the sub-process can respond quickly and return correct data. At the same time, the system will perform high-concurrency tests to check the performance of the service under high load conditions to ensure that performance bottlenecks do not occur in the production environment. In addition, data consistency verification is also an important step. The main process will ensure data synchronization and consistency between sub-processes to avoid errors caused by data inconsistencies.
[0093] If a sub-process fails to pass the verification, a repair correction information will be generated. Based on this information, the main process will take remedial measures to repair the sub-process, such as restarting the sub-process or providing necessary support. After the sub-process is repaired, it will be verified again. Through this series of checks, it is ensured that the system can achieve the expected stability and availability before officially providing external services.
[0094] After all services have passed verification, the design of the multi-process, multi-class loader, and multi-context framework is completed, and the system officially provides complete service capabilities to the outside world. At this time, the gateway subprocess will take over all external requests and distribute the requests to each subprocess through load balancing. Each subprocess will perform corresponding services according to the type of request and business needs to ensure that the system can provide processing capabilities on demand. At the same time, the management console will continue to monitor the status of the system to ensure that any potential problems can be discovered in time during the service operation and take corresponding solutions. The entire service framework enters a stable operation stage and can provide efficient and stable services to external users.
[0095] It should be noted that, for the method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present 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 the specification are all optional embodiments, and the actions involved are not necessarily required by the present application.
[0096] Reference Figure 4 , shows a structural block diagram of a device 400 for loading contexts of a service family multi-class loader based on JVM of the present application, the device comprising:
[0097] Initialization loading module 401, used for initializing and loading the system environment of the service family;
[0098] A subprocess starting module 402, 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, and complete the design of the multi-process multi-class loader loading context framework.
[0102] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.
[0103] Optionally, an embodiment of the present application further provides an electronic device, comprising: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, the various processes of the above-mentioned method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be described here.
[0104] The embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, each process of the above method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it is not repeated here. The computer-readable storage medium is, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.
[0105] Figure 5 800 is a block diagram of an electronic device 800 shown in the present application. For example, the electronic device 800 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.
[0106] Reference Figure 5 , the electronic device 800 may include one or more of the following components: a processing component 802 , a memory 804 , a power 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 generally controls the overall operation of the electronic device 800, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 802 may 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 may include one or more modules to facilitate the interaction between the processing component 802 and other components. For example, the processing component 802 may include a multimedia module to facilitate the 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 operations on the device 800. Examples of such data include instructions for any application or method operating on the electronic device 800, contact data, phone book data, messages, images, videos, etc. The memory 804 can be implemented by any type of volatile or non-volatile storage device 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, magnetic disk or optical disk.
[0109] The power supply component 806 provides power to the various components of the electronic device 800. The power supply component 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device 800.
[0110] The multimedia component 808 includes a screen that provides an output interface between the electronic device 800 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 808 includes a front camera and / or a rear camera. When the device 800 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and the rear camera may 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 audio signals. For example, the audio component 810 includes a microphone (MIC), and when the electronic device 800 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 804 or sent via the communication component 816. In some embodiments, the audio component 810 also includes a speaker for outputting audio signals.
[0112] I / O interface 812 provides an interface between processing component 802 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: home button, volume button, start button, and lock button.
[0113] The sensor assembly 814 includes one or more sensors for providing various aspects of status assessment for the electronic device 800. For example, the sensor assembly 814 can detect the open / closed state of the device 800, the relative positioning of components, such as the display and keypad of the electronic device 800, and the sensor assembly 814 can also detect the position change of the electronic device 800 or a component of the electronic device 800, the presence or absence of contact between the user and the electronic device 800, the orientation or acceleration / deceleration of the electronic device 800, and the temperature change of the electronic device 800. The sensor assembly 814 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 814 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 814 may also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.
[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 carrier network (such as 2G, 3G, 4G or 5G), or a combination thereof. In an exemplary embodiment, the communication component 816 receives a broadcast signal or broadcast operation information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 816 also includes 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 technologies.
[0115] In an exemplary embodiment, the electronic device 800 may be implemented by 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, microcontrollers, microprocessors, or other electronic components to perform the above methods.
[0116] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 804 including instructions, and the instructions can be executed by a processor 820 of an electronic device 800 to perform the above method. 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 disk, an optical data storage device, etc.
[0117] Figure 619 is a block diagram of a computer-readable storage medium 1900 shown in the present application. For example, the computer-readable storage medium 1900 may be provided as a server.
[0118] Reference 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, such as an application, that can be executed by the processing component 1922. The application stored in the memory 1932 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute instructions to perform the above method.
[0119] The computer readable storage medium 1900 may 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 may operate based on an operating system stored in the memory 1932, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™ or the like.
[0120] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.
[0121] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment 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 the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.
[0123] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in the present 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 can 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 the present 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 only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, 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 separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[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 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 application, 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, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard drives, ROM, RAM, magnetic disks, or optical disks.
[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 who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on 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 initially 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-processes of the service family, and sub-process supervision information is generated by supervising the sub-process handles; Based on the service scanner startup information, sub-process startup information, sub-process service registration information, gateway push information, and sub-process supervision information, the main process verifies the startup service of the sub-process, and completes the design of the multi-process and multi-class loader loading context framework.
2. The method according to claim 1, characterized in that 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 registrar startup information is generated by initializing and loading the configuration file of the service registration; 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, characterized in that Scanning the service definition file through the service scanner opening information includes: Based on the service scanner start 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 the 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, characterized in that The subprocess context framework is isolated and loaded through the loading mechanism library, including: Based on the framework architecture requirements, the loading mechanism of the hierarchical class loader is constructed to generate a loading mechanism library; 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 subprocess 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 integrating the services of the gateway subprocess 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, based on the sub-process service registration information, the health status of the sub-process is monitored to generate status monitoring 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 succeeds, 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 a service family multi-class loader based on JVM, characterized in that: include: Initialization loading module, used to initialize and load the system environment of the service family; A subprocess startup module, used for scanning the service definition file through the service scanner; The service registration module is used to load the subprocess context framework in isolation through the loading mechanism library; The gateway push and process monitoring module is used to integrate the services of the gateway sub-processes of the service family and monitor 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, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.
Citation Information
Patent Citations
Resource management method and device for nodes in Kubernetes and medium
CN111367659A
Method, equipment and device for dynamically deploying modularization and computer program product
CN114064215A
Micro-service development management system
CN115242644A
Business processing method and device based on micro-front-end single-bin architecture and architecture
CN118170426A
Software application management method based on micro-service architecture
CN118672638A