Distributed runtime management method and system based on base plug-in mechanism

Through the base plug-in mechanism and eBPF communication protocol, the problems of high operation and maintenance costs and low resource utilization in distributed application architecture are solved, efficient plug-in management and elastic resource allocation are achieved, and the stability and scalability of the system are improved.

CN120447988APending Publication Date: 2025-08-08CHINA CITIC BANK CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510554983.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-04-29
Publication Date
2025-08-08

AI Technical Summary

Technical Problem

In the existing distributed application architecture, the number of Sidecar instances increases linearly with the number of business instances, resulting in high operation and maintenance costs, low resource utilization, serious version fragmentation, and poor resource redundancy and fault isolation.

Method used

The base plug-in mechanism is adopted to isolate the base process from business applications, combine the control center's resource scheduling and plug-in warehouse management to realize dynamic loading, upgrade and state collection of plug-in, use the eBPF communication protocol for efficient data interaction, and ensure the healthy status of the plug-in process through the lease mechanism.

Benefits of technology

It reduces operation and maintenance costs, improves resource utilization and system stability, ensures the consistency of plug-in versions and data transmission efficiency, and enhances the flexibility and scalability of the system.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120447988A_ABST
    Figure CN120447988A_ABST
Patent Text Reader

Abstract

The invention relates to a distributed runtime management method based on a base plug-in mechanism, which comprises the following steps of: independently running a base process and isolating the base process from a service application process, executing dynamic loading, starting, stopping and upgrading operations on a plurality of plug-in processes through a local inter-process communication interface, and simultaneously collecting running state data of each plug-in; the control center periodically receives the plug-in running state reported by each base, generates a resource scheduling instruction in combination with a service load prediction model, and dynamically adjusts the start-stop state of the plug-in in the cluster to realize elastic allocation of computing resources; the plug-in warehouse stores a multi-version plug-in package and responds to a downloading request of the base, and version verification and downloading acceleration services are provided based on a content addressing mechanism; two-way communication is established between each plug-in process and the base through a standard control interface, and data interaction is carried out between each plug-in process and a service application through an eBPF enhanced communication protocol, so that high-efficiency plug-in management, flexible allocation of resources and safety and high efficiency of plug-in version management are realized.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a distributed runtime management method and system based on a base plug-in mechanism. Background Art

[0002] In distributed application architectures, runtime management is the core infrastructure for enabling capabilities such as service governance, traffic control, and security isolation. Current mainstream distributed runtime solutions (such as Microsoft Dapr and Ant Layotto) use a multi-sidecar instance model, where each business application or service module deploys an independent sidecar process, using the sidecar proxy to implement inter-service communication and state management. While this model decouples business logic from infrastructure to a certain extent, it has significant drawbacks in actual implementation:

[0003] Each business instance needs to deploy an independent sidecar, which causes the number of sidecar instances in the cluster to grow linearly with the number of business instances. The operation and maintenance costs (deployment, upgrade, and monitoring) increase exponentially, resulting in high operation and maintenance complexity.

[0004] Sidecar versions are severely fragmented, making it difficult to ensure global consistency (for example, different business modules rely on different Sidecar versions). Each Sidecar instance requires its own computing resources (CPU and memory), resulting in insufficient resource utilization in low-load scenarios (for example, idle Sidecars still occupy memory). Multiple instances cannot share common components, and repeated initialization leads to resource redundancy and severe resource waste.

[0005] A single sidecar instance must handle multiple functions. A failure in a single functional module can cause the entire sidecar to crash, leading to cascading business interruptions. The lack of fine-grained runtime isolation means that high-load plug-ins may preempt other plug-in resources (e.g., CPU scheduling delays), resulting in poor fault isolation. Summary of the Invention

[0006] In order to address the shortcomings of the existing technology, the present invention provides a process isolation management method in which the base and plug-ins cooperate with each other, and combines the resource scheduling of the control center, the version management and distribution of the plug-in warehouse, and the communication between the plug-in and the business application to achieve efficient plug-in management, flexible allocation of resources, and security and efficiency of plug-in version management.

[0007] In a first aspect, the present invention provides a distributed runtime management method based on a base plug-in mechanism, characterized in that it includes the following steps:

[0008] The base process runs independently and is isolated from the business application process. It dynamically loads, starts, stops, and upgrades multiple plug-in processes through the local inter-process communication interface, and collects the running status data of each plug-in at the same time.

[0009] Specifically, the base is only responsible for plug-in lifecycle management (loading, starting, stopping, and upgrading) and status collection, and does not carry business logic, reducing resource usage to less than 10% of traditional sidecars. Based on operating system-level isolation technology, resource isolation between plug-in processes is achieved.

[0010] The control center periodically receives plug-in operation status reports from each base, generates resource scheduling instructions based on the business load prediction model, and dynamically adjusts the start and stop status of plug-ins in the cluster to achieve flexible allocation of computing resources;

[0011] Specifically, the control center uses AI models to predict business load and dynamically adjust plug-in startup and shutdown states, enabling elastic scaling of computing resources. The control center collects historical load data and uses time series analysis algorithms (such as ARIMA or LSTM) to build a predictive model. Based on the current cluster's resource utilization and business priorities, an optimization algorithm (such as a genetic algorithm) calculates the optimal plug-in startup and shutdown plan.

[0012] The plugin repository stores multiple versions of plugin packages and responds to download requests from the cradle, providing version verification and download acceleration services based on the content addressing mechanism;

[0013] Specifically, the plugin repository provides multi-version management, security verification, and distribution acceleration capabilities to ensure plugin delivery consistency. This includes digitally signing uploaded plugin packages and verifying dependencies, generating a unique content hash for each plugin version, and supporting a grayscale release strategy based on semantic versioning.

[0014] Each plug-in process establishes two-way communication with the base through a standard control interface, and interacts with business applications through the eBPF enhanced communication protocol.

[0015] Specifically, eBPF technology enables zero-copy data transmission between plug-ins and business applications, reducing communication latency to microseconds. A lease mechanism ensures the rapid removal of abnormal plug-ins and the reestablishment of connections.

[0016] Exemplarily, the communication between the base process and the plug-in process is implemented using Unix Domain Socket, and a heartbeat detection mechanism is set in the communication channel to automatically trigger a fault recovery process when abnormal termination of the plug-in process is detected.

[0017] Specifically, it includes establishing a Unix Domain Socket communication channel (using the base as the server and the plug-in as the client), implementing a heartbeat detection mechanism, and fault recovery (which may include abnormal state detection, plug-in restart, and reconnection mechanism).

[0018] Exemplarily, the eBPF enhanced communication protocol implements zero-copy data transmission acceleration between business applications and plug-ins by implanting a programmable filter in the operating system kernel layer, while providing traffic monitoring capabilities.

[0019] Exemplarily, establishing a lease connection mechanism between the plug-in process and the business application includes:

[0020] When the plug-in starts, it registers with the business application and obtains the initial lease certificate;

[0021] Periodically send lease renewal requests to the control center through the base;

[0022] When the lease times out and is not renewed, the business application automatically terminates the connection channel with the plug-in.

[0023] Exemplarily, the control center generates resource scheduling instructions including: analyzing historical load data to establish a time series prediction model; calculating the optimal start-stop plan based on the current cluster resource utilization and business priority; selecting a subset of plug-ins that meet the minimum survival conditions to keep running during business off-peak periods; and giving priority to starting plug-in instances with high throughput characteristics when a sudden increase in traffic is detected.

[0024] In a second aspect, the present application provides a distributed runtime management system based on a base plug-in mechanism, characterized in that the system includes:

[0025] The base module is used to implement dynamic lifecycle management and operation isolation control of plug-ins;

[0026] Plug-in runtime module, used to execute business logic and achieve communication acceleration;

[0027] Control center module, used for cluster-level resource scheduling;

[0028] Plugin repository module, used for plugin version management and secure distribution;

[0029] The base module interacts with the plug-in runtime module via a local inter-process communication channel;

[0030] The control center module sends a resource scheduling instruction to the base module.

[0031] In a third aspect, the present invention further provides a computer-readable storage medium, characterized in that a computer program is stored on the storage medium, and when the computer program is executed by a processor, it implements the method according to any one of claims 1 to 5.

[0032] In a fourth aspect, the present invention further provides an electronic device, characterized in that it includes a processor and a memory;

[0033] The memory is used to store computer programs;

[0034] The processor is configured to execute the method according to any one of claims 1 to 5 by calling a stored computer program.

[0035] In a fifth aspect, the present invention also relates to a computer program product, comprising a computer program and / or instructions, characterized in that the computer program and / or instructions implement the steps of the above method when executed by a processor.

[0036] The beneficial effects of the present invention are as follows: (1) the base process can dynamically load, start, stop and upgrade plug-ins to adapt to changes in business needs and ensure the flexibility and scalability of the system; (2) the control center optimizes the utilization of computing resources in the cluster through load prediction and resource scheduling, thereby improving the overall performance and resource utilization of the system; (3) the multi-version storage and content addressing mechanism of the plug-in warehouse ensures the fast download and version verification of plug-ins, thereby improving the efficiency and security of plug-in distribution; (4) the eBPF enhanced communication protocol significantly improves the data interaction efficiency between plug-ins and business applications, and reduces data transmission delays and system overhead; (5) the base supports plug-ins in multiple languages, thereby enhancing the scalability and compatibility of the system and allowing developers to use familiar programming languages for plug-in development; (6) through the lease connection mechanism and heartbeat detection mechanism, the health status of the plug-in process and the security of business applications are ensured, thereby improving the stability and reliability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 This is a flow chart of the distributed runtime management method based on the base plug-in mechanism of the present invention.

[0038] Figure 2 This is a structural diagram of the distributed runtime management system based on the base plug-in mechanism of the present invention. DETAILED DESCRIPTION

[0039] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. The components of the embodiments of the present invention generally described and shown in the drawings herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0040] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of the present invention, the terms "first", "second", etc. are used only to distinguish the description and should not be understood as indicating or implying relative importance.

[0041] First, as Figure 1 As shown, the present invention provides a distributed runtime management method based on a base plug-in mechanism, characterized in that it includes the following steps:

[0042] The base process runs independently and is isolated from the business application process. It dynamically loads, starts, stops, and upgrades multiple plug-in processes through the local inter-process communication interface, and collects the running status data of each plug-in at the same time.

[0043] The control center periodically receives plug-in operation status reports from each base, generates resource scheduling instructions based on the business load prediction model, and dynamically adjusts the start and stop status of plug-ins in the cluster to achieve flexible allocation of computing resources;

[0044] The plugin repository stores multiple versions of plugin packages and responds to download requests from the cradle, providing version verification and download acceleration services based on the content addressing mechanism;

[0045] Each plug-in process establishes two-way communication with the base through a standard control interface, and interacts with business applications through the eBPF enhanced communication protocol.

[0046] In a specific embodiment, the following implementation method may be used:

[0047] The pedestal process runs as an independent process, isolated from business applications through Linux Namespaces. The pedestal manages the entire plugin lifecycle through Unix Domain Sockets (UDS). The pedestal receives commands from the control center through UDS and downloads plugin packages (such as filter_plugin_v2.so) from the plugin repository. Plugins are dynamically loaded using dlopen, and a separate plugin process is created through fork(), binding the process to the UDS path (such as / var / run / plugins / filter.sock). Cgroups resource limits are set for the new plugin process (such as a 20% CPU quota and a 512MB memory limit).

[0048] The base downloads the new version of the plug-in to a temporary directory (such as / tmp / filter_plugin_v3.so).

[0049] A new process is started through execve, and the old process continues to handle existing requests. After the old process gracefully exits within 10 seconds, the pedestal reclaims its resources.

[0050] To collect plugin status metrics in real time, the base sends the GET_METRICS command via UDS, and the plugin returns CPU and memory data in Protobuf format. Furthermore, the plugin's survival status is verified by calling kill(pid,0) every 2 seconds, completing periodic health checks on the plugin process. (The heartbeat detection mechanism includes periodic system calls such as kill(pid,0) or application-layer heartbeat packet exchanges.)

[0051] The control center achieves elastic scaling in seconds based on time series prediction and reinforcement learning algorithms.

[0052] The base reports plugin status every 5 seconds via gRPC streaming, and the control center writes this information to a time series database (InfluxDB). Through feature extraction, cluster-level metrics (QPS, average latency, and error rate) are aggregated to construct a load feature vector.

[0053] An AI prediction model was built using an LSTM neural network. The input was load data from the past five minutes, and the output was a one-minute forecast. For online inference, the model was deployed as a TensorFlow Serving microservice with a response time of <50ms. When the predicted QPS exceeded the current processing capacity by 20%, the plugin was triggered to start. During off-peak hours (e.g., 00:00-06:00), at least one plugin instance was maintained, with the remaining instances dormant. A Kafka broadcast command was broadcasted, and the pedestal subscribed to a dedicated topic (e.g., plugin_scale) for real-time responses.

[0054] The plug-in repository implements multi-version management, security verification, and hybrid accelerated distribution.

[0055] Plugin versions follow the MAJOR.MINOR.PATCH format (e.g. 2.1.3). A directed acyclic graph (DAG) can be used to verify plugin dependency compatibility (e.g. requiring libc >= 2.28).

[0056] The developer uses the ECDSA private key to sign the plug-in package, and the signature file is uploaded with the plug-in package.

[0057] When downloading from the base, the plugin repository verifies the legitimacy of the signature through the preset public key chain.

[0058] Efficient communication between plug-ins and business applications, as follows:

[0059] Plug-ins interact with business applications through eBPF zero-copy, while ensuring connection reliability based on a lease mechanism. eBPF accelerates communication by loading eBPF programs into the Linux kernel and attaching them to XDP hook points. Business applications and plug-ins share a ring buffer, with data forwarded directly in kernel mode. The monitoring module uses BPF_MAP_TYPE_HASH to collect traffic metrics (e.g., processing 100,000 requests per second).

[0060] The lease mechanism works as follows: After the plug-in starts, it registers with the business application and obtains a lease ID (e.g., lease-01a2b3), which is valid for 30 seconds. The plug-in renews the lease every 15 seconds through the base station. After three timeouts, the business application automatically disconnects.

[0061] In abnormal scenarios, the control center notifies the business application to terminate the invalid lease (such as a plug-in crash).

[0062] Second, as Figure 2 As shown, the present application provides a distributed runtime management system based on a base plug-in mechanism, characterized in that the system includes:

[0063] The base module is used to implement dynamic lifecycle management and operation isolation control of plug-ins;

[0064] Plug-in runtime module, used to execute business logic and achieve communication acceleration;

[0065] Control center module, used for cluster-level resource scheduling;

[0066] Plugin repository module, used for plugin version management and secure distribution;

[0067] The base module interacts with the plug-in runtime module via a local inter-process communication channel;

[0068] The control center module sends a resource scheduling instruction to the base module.

[0069] The module interaction timing relationship in the system architecture, such as Figure 2 As shown:

[0070] Base module Plug-in runtime module, Unix Domain Socket, cgroups resource isolation, dlopen dynamic loading;

[0071] Plugin runtime module Business applications, eBPF XDP hooks, ring buffer zero copy, and lease HTTP renewal;

[0072] Control Center Module Base module, gRPC streaming, Kafka command broadcast, LSTM prediction model;

[0073] Plugin repository module Base module, content addressing (SHA-256), ECDSA signature verification;

[0074] Control Center Module Business applications, WebHook callbacks, and lease status synchronization.

[0075] Exemplarily, the base module may further include:

[0076] Plug-in process control unit, used to perform plug-in loading, starting, stopping and upgrading operations;

[0077] Process isolation unit, used to create an independent running environment for each plug-in;

[0078] The status monitoring unit is used to collect plug-in operation indicators in real time and report them to the control center unit.

[0079] Exemplarily, the plug-in repository module further includes: a version management service unit and a security verification unit.

[0080] By using this system, the above-mentioned processing method can be executed and the corresponding technical effects can be achieved.

[0081] An embodiment of the present invention also provides a computer-readable storage medium capable of implementing all steps of the method in the above embodiment. The computer-readable storage medium stores a computer program that implements all steps of the method in the above embodiment when executed by a processor.

[0082] An embodiment of the present invention also provides an electronic device for executing the above-mentioned method. As an implementation device of the method, the electronic device has at least a processor and a memory, and in particular, the memory stores the data and related computer programs required for executing the method, and the processor calls the data and programs in the memory to execute all the steps of the implementation method and obtains the corresponding technical effect.

[0083] Preferably, the electronic device may include a bus architecture, which may include any number of interconnected buses and bridges, and the bus will include various circuits linked together by one or more processors and memories. The bus may also link together various other circuits such as peripherals, voltage regulators, and power management circuits, which are all well known in the art and, therefore, will not be described further herein. The bus interface provides an interface between the bus and the receiver and transmitter. The receiver and transmitter can be the same component, namely a transceiver, which provides a module for communicating with various other systems over a transmission medium. The processor is responsible for managing the bus and general processing, while the memory can be used to store data used by the processor when performing operations.

[0084] Additionally, the electronic device may further include components such as a communication module, an input module, an audio processor, a display, and a power supply. The processor (or controller, operating control) employed may include a microprocessor or other processor device and / or logic device, which receives input and controls the operation of various components of the electronic device. The memory may be one or more of a cache, flash memory, a hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices, and may store the aforementioned data and information. It may also store programs for executing the relevant information, and the processor may execute the programs stored in the memory to implement information storage or processing. The input module is used to provide input to the processor, and may, for example, be a keypad or touch input device. The power supply is used to provide power to the electronic device. The display is used to display objects such as images and text, and may, for example, be an LCD display. The communication module is a transmitter / receiver that sends and receives signals via an antenna. The communication module (transmitter / receiver) is coupled to the processor to provide input signals and receive output signals, similar to the case of a conventional mobile communication terminal. Based on different communication technologies, multiple communication modules can be provided in the same electronic device, such as a cellular network module, a Bluetooth module, and / or a wireless local area network module. The communication module (transmitter / receiver) is also coupled to a speaker and a microphone via an audio processor to provide audio output via the speaker and receive audio input from the microphone, thereby implementing common telecommunications functions. The audio processor may include any suitable buffer, decoder, amplifier, etc. In addition, the audio processor is also coupled to a central processing unit, enabling local recording via the microphone and playback of stored audio via the speaker.

[0085] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0086] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A system that specifies the functions of a box or boxes.

[0087] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction system that is implemented in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0088] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 The present invention is described in detail below. ...

[0089] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present invention are intended to be covered by the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A distributed runtime management method based on a base plug-in mechanism, characterized in that: The following steps are involved: The base process runs independently and is isolated from the business application process. It dynamically loads, starts, stops, and upgrades multiple plug-in processes through the local inter-process communication interface, and collects the running status data of each plug-in at the same time. The control center periodically receives plug-in operation status reports from each base, generates resource scheduling instructions based on the business load prediction model, and dynamically adjusts the start and stop status of plug-ins in the cluster to achieve flexible allocation of computing resources; The plugin repository stores multiple versions of plugin packages and responds to download requests from the cradle, providing version verification and download acceleration services based on the content addressing mechanism; Each plug-in process establishes two-way communication with the base through a standard control interface, and interacts with business applications through the eBPF enhanced communication protocol.

2. The method according to claim 1, characterized in that The communication between the base process and the plug-in process is specifically implemented using Unix Domain Socket, and a heartbeat detection mechanism is set in the communication channel to automatically trigger a fault recovery process when it is detected that the plug-in process is abnormally terminated.

3. The method according to claim 2, characterized in that The eBPF enhanced communication protocol implements zero-copy data transmission acceleration between business applications and plug-ins by implanting programmable filters in the operating system kernel layer, while providing traffic monitoring functions.

4. The method according to claim 3, characterized in that The plug-in process establishes a lease connection mechanism with the business application, including: When the plug-in starts, it registers with the business application and obtains the initial lease certificate; Periodically send lease renewal requests to the control center through the base; When the lease times out and is not renewed, the business application automatically terminates the connection channel with the plug-in.

5. The method according to claim 1, characterized in that The resource scheduling instruction generation of the control center includes: Analyze historical load data to establish a time series forecasting model; Calculate the optimal start and stop plan based on the current cluster resource utilization and business priority; During off-peak hours, select a subset of plugins that meet the minimum survival requirements and keep them running. When a traffic surge is detected, plugin instances with high throughput characteristics are launched first.

6. A distributed runtime management system based on a base plug-in mechanism, characterized in that: The system comprises: The base module is used to implement dynamic lifecycle management and operation isolation control of plug-ins; Plug-in runtime module, used to execute business logic and achieve communication acceleration; Control center module, used for cluster-level resource scheduling; Plugin repository module, used for plugin version management and secure distribution; The base module interacts with the plug-in runtime module via a local inter-process communication channel; The control center module sends a resource scheduling instruction to the base module.

7. A computer-readable storage medium, characterized in that The storage medium stores a computer program, which implements any one of the methods described in claims 1 to 5 when executed by a processor.

8. An electronic device, characterized in that: including processor and memory; The memory is used to store computer programs; The processor is configured to execute any one of the methods described in claims 1-5 by calling a stored computer program.

9. A computer program product comprising a computer program and / or instructions, characterized in that When the computer program and / or instruction is executed by a processor, any method described in claims 1-5 is implemented.