A CDN edge node plugin management method and device based on WASM

Abstract

This invention discloses a CDN edge node plugin management method and apparatus based on WASM, effectively solving various defects in the application of existing CDN edge node pluginization technologies. The method provided by this invention includes: receiving a plugin release task issued by the central control layer through a collaborative adaptation layer, and matching the WASM plugin package corresponding to the target edge node; controlling the collaborative adaptation layer to generate a distribution task based on the WASM plugin package, so that the collaborative adaptation layer distributes the WASM plugin package to the target edge node of the edge node execution layer; the target edge node receives the WASM plugin package distributed by the collaborative adaptation layer, verifies the WASM plugin package, and generates a verification result; based on the verification result, the target edge node loads and runs the WASM plugin in the WASM plugin package in a hot-swappable manner in the locally running CDN main process, thereby realizing the management of edge node plugins.

Description

Technical Field

[0001] This invention relates to the field of plug-in management technology, and in particular to a CDN edge node plug-in management method and apparatus based on WASM. Background Technology

[0002] As a core infrastructure of content delivery networks, the functional scalability of CDN edge nodes directly determines service adaptability and business iteration efficiency. Modularization has become the mainstream technology for achieving flexible functional expansion of CDN edge nodes. Traditional CDN edge node plugin deployment and update solutions employ static integration or script interpretation execution modes, which have significant technical shortcomings in terms of business continuity, development flexibility, large-scale operation and maintenance, and delivery efficiency, and can no longer meet the core requirements of high availability and rapid iteration for internet services.

[0003] Traditional static plugin solutions tightly couple plugins with the CDN main process. Deploying, updating, or uninstalling plugins requires restarting the node service, inevitably causing business interruptions and impairing user experience. For high-concurrency business scenarios such as e-commerce and live streaming, service interruptions directly lead to economic losses and user churn. Furthermore, plugin development is strongly tied to the main program's development language, often using compiled languages ​​like C / C++. Developers need to deeply adapt to the CDN underlying architecture, resulting in high development barriers, long development cycles, and difficulty in quickly responding to personalized business needs.

[0004] Some CDN service providers use script-based plugins such as Lua to alleviate coupling issues. However, script interpretation and execution efficiency is low, which cannot match the high concurrency and low latency processing requirements of CDN edge nodes. Furthermore, they lack a sound resource isolation mechanism. Abnormal plugin operation can easily cause the main process to crash. At the same time, the script security boundaries are vague, posing security risks such as malicious code execution and unauthorized access to resources.

[0005] At the scale of operations and maintenance, traditional solutions lack a unified plugin management system. When dealing with massive edge node clusters, plugin deployment requires manual operation on a node-by-node basis, resulting in chaotic version control, no canary release capability, and plugin updates are prone to causing system-wide failures, leading to high operation and maintenance costs and low efficiency. In addition, plugin distribution adopts a full transmission mode, resulting in large data transmission volumes. In cross-regional and low-bandwidth scenarios, distribution is time-consuming, and the cycle from new feature development to full cluster deployment is long, making it impossible to quickly deliver business requirements.

[0006] While existing technologies have attempted to apply WASM technology to edge programmable computing and achieve plug-in sandbox operation, they only focus on the single operation of the WASM module and lack the ability to manage the entire lifecycle of plug-in development, deployment, updates, and decommissioning. Furthermore, there is no unified standard for plug-in interfaces in the industry, requiring developers to adapt to different CDN platforms, which further increases development and access costs and makes it difficult to achieve large-scale promotion and application. Summary of the Invention

[0007] To address the shortcomings of existing technologies, the present invention aims to provide a CDN edge node plug-in management method and apparatus based on WASM, which effectively solves the various defects in the application of CDN edge node plug-in in existing technologies.

[0008] The technical solution provided in this application is: a CDN edge node plugin management method based on WASM, applicable to a management system, the management system including a central control layer, a collaborative adaptation layer, and an edge node execution layer, the method including:

[0009] The collaborative adaptation layer receives the plugin release task for edge nodes issued by the central control layer, and matches the WASM plugin package corresponding to the target edge node based on the pre-stored real-time load data and hardware architecture information of each edge node.

[0010] The collaborative adaptation layer is controlled to generate a distribution task based on the WASM plugin package, so that the collaborative adaptation layer distributes the WASM plugin package to the target edge node of the edge node execution layer;

[0011] The target edge node receives the WASM plugin package distributed by the collaborative adaptation layer, verifies the WASM plugin package, and generates a verification result.

[0012] Based on the verification results, the target edge node loads and runs the WASM plugin in the WASM plugin package in a hot-swappable manner in the CDN main process running locally, so as to realize the management of the edge node plugin.

[0013] Furthermore, the target edge node, in its locally running CDN main process, hot-swap loads and runs the WASM plugin from the WASM plugin package, including:

[0014] A loading strategy is pre-configured on the target edge node, and the target edge node is controlled to execute the loading strategy to load instances in the WASM plugin package;

[0015] After loading is complete, an independent running sandbox is allocated to the WASM plugin package, initialization operations are performed, and the plugin is marked as available.

[0016] In response to a plugin uninstallation command or a version update command, the plugin loader clears the memory cache occupied by the plugin and releases the corresponding independent running sandbox resources.

[0017] Furthermore, in response to a plugin uninstallation command or a version update command, the plugin loader clears the memory cache occupied by the plugin and releases the corresponding independent running sandbox resources, including:

[0018] Based on the version update command, an independent sandbox is created for the WASM plugin package, and preloading and initialization are performed to form a new version plugin instance;

[0019] After the independent sandbox preloading is successful and the new version plugin instance is ready, the resource release process of the old version plugin instance is triggered.

[0020] Furthermore, in response to a plugin uninstallation command or a version update command, the plugin loader clears the memory cache occupied by the plugin and releases the corresponding independent running sandbox resources, including:

[0021] Collect resource parameters during the runtime of the WASM plugin instance and determine whether the resource parameters meet the corresponding plugin exception conditions;

[0022] If so, a plugin exception event is confirmed, and the execution of the WASM plugin package instance is immediately suspended while preserving its runtime context.

[0023] Furthermore, the collaborative adaptation layer distributes the WASM plugin package to the target edge node of the edge node execution layer, including:

[0024] Based on the target node filtering conditions in the received release instruction, the target edge node list that meets the conditions is matched from the node profile library maintained by the collaborative adaptation layer.

[0025] The collaborative adaptation layer executes the publishing task so that the target edge nodes in the target edge node list receive the WASM plugin package.

[0026] Further, executing the release task to ensure that the target edge nodes in the target edge node list receive the WASM plugin package includes:

[0027] After receiving the publishing task, the distribution module in the coordination and adaptation layer calls the node profiling module to obtain the real-time load data of each target edge node.

[0028] Based on the real-time load data, a distribution rhythm rule is generated, and the target edge nodes are dynamically sorted and batched according to the distribution rhythm rule to generate an ordered update queue.

[0029] The update interface of each target edge node is called sequentially according to the update queue to execute the push or notification pull of the WASM plugin package.

[0030] Further, the update interfaces of each target edge node are called sequentially according to the update queue to execute the push or notification pull of the WASM plugin package, including:

[0031] For target edge nodes that require version updates, the collaboration adaptation layer obtains the old version plugin package currently installed on the target edge node; the WASM plugin package is the new version.

[0032] By comparing the bytecode differences between the WASM plugin package and the old version plugin package, an incremental patch package is generated and transmitted to the target edge node.

[0033] This application provides another solution: a WASM-based CDN edge node plugin management device, suitable for management systems, the management system including a central control layer, a collaborative adaptation layer, and an edge node execution layer, the device comprising:

[0034] The receiving module is used to receive the plugin release task for edge nodes issued by the central management and control layer through the collaborative adaptation layer, and match the WASM plugin package corresponding to the target edge node based on the pre-stored real-time load data and hardware architecture information of each edge node.

[0035] The control module is used to control the collaborative adaptation layer to generate a distribution task based on the WASM plugin package, so that the collaborative adaptation layer distributes the WASM plugin package to the target edge node of the edge node execution layer;

[0036] The verification module is used to receive the WASM plugin package distributed by the collaborative adaptation layer through the target edge node, verify the WASM plugin package, and generate a verification result.

[0037] The management module is used to load and run the WASM plugin in the WASM plugin package in a hot-swappable manner in the CDN main process running locally on the target edge node based on the verification result, so as to realize the management of the edge node plugin.

[0038] This application also provides a solution: an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps of any of the WASM-based CDN edge node plug-in management methods described above are performed.

[0039] This application also provides another solution: a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of any of the WASM-based CDN edge node plugin management methods described above.

[0040] This application provides a CDN edge node plugin management method based on WASM, applicable to a management system. The management system includes a central control layer, a collaborative adaptation layer, and an edge node execution layer. The method first receives a plugin release task for edge nodes from the central control layer through the collaborative adaptation layer, and matches the WASM plugin package corresponding to the target edge node based on pre-stored real-time load data and hardware architecture information of each edge node. Next, it controls the collaborative adaptation layer to generate a distribution task based on the WASM plugin package, enabling the collaborative adaptation layer to distribute the WASM plugin package to the target edge node of the edge node execution layer. Then, the target edge node receives the WASM plugin package distributed by the collaborative adaptation layer, verifies the WASM plugin package, and generates a verification result. Finally, based on the verification result, the target edge node loads and runs the WASM plugin in the WASM plugin package in a hot-swappable manner in its locally running CDN main process, thereby achieving management of edge node plugins. Based on the above methods, this application not only achieves plugin deployment, updates, and uninstallation without restarts, completely avoiding service interruptions and ensuring CDN business continuity, adapting to the stable operation requirements of high-concurrency business scenarios; it also breaks the strong binding restrictions of development languages, supporting the compilation of multiple languages ​​into standardized WASM bytecode, coupled with standardized interfaces and template libraries, significantly reducing the threshold for plugin development and access, and improving development flexibility. It also constructs a three-tier management and control architecture and a remote visual management center, supporting batch distribution of plugins, canary releases, and version traceability. Combined with an incremental transmission mechanism to reduce data loss, it achieves refined operation and maintenance of large-scale clusters, significantly reducing labor costs. Furthermore, it implements a WASM sandboxed runtime environment with triple isolation mechanisms for memory, CPU, and interfaces, avoiding the performance and security drawbacks of script plugins, ensuring node operational security. Simultaneously, plugins take effect within seconds, significantly shortening the development cycle from new feature to full cluster deployment, significantly improving business delivery efficiency, and laying a solid technical foundation for the rapid iteration and diversified upgrades of CDN services. Attached Figure Description

[0041] Figure 1 This is a flowchart illustrating a CDN edge node plugin management method based on WASM, provided in an embodiment of this application.

[0042] Figure 2 This is a schematic diagram of the operation flow of the plug-in loader provided in the embodiments of this application.

[0043] Figure 3 This is a schematic diagram illustrating the operation flow of the resource monitoring module provided in an embodiment of this application.

[0044] Figure 4 This is a structural block diagram of a CDN edge node plug-in management device based on WASM, provided for an embodiment of this application.

[0045] Figure 5 A structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0046] For the purposes of this invention, the foregoing and other technical contents, features and effects are described in conjunction with the appendix below. Figure 1-5 The detailed description of the embodiments will make this clear. All structural details mentioned in the following embodiments are based on the accompanying drawings.

[0047] Modularization of CDN edge nodes is the mainstream direction for functional expansion. Traditional solutions have many drawbacks: static plugins require node restarts, causing service interruptions; Lua script plugins have low execution efficiency and poor isolation; and plugins are strongly bound to the main programming language, resulting in high development barriers. Furthermore, the lack of a unified management system makes large-scale operation and maintenance difficult. Existing WASM edge computing solutions also lack full lifecycle management capabilities for plugins, and their interfaces are inconsistent.

[0048] Based on this, this application provides a CDN edge node plugin management method and apparatus based on WASM, which will be described below with reference to embodiments and accompanying drawings.

[0049] Example 1

[0050] To facilitate understanding of this embodiment, a detailed description of a WASM-based CDN edge node plugin management method disclosed in this application embodiment will be provided first. For example... Figure 1 The diagram illustrates a WASM-based CDN edge node plugin management method. This application provides a WASM-based CDN edge node plugin management method applicable to management systems. The management system includes a central control layer, a collaborative adaptation layer, and an edge node execution layer. The method includes:

[0051] S101. Receive the plugin release task for edge nodes issued by the central control layer through the collaborative adaptation layer, and match the WASM plugin package corresponding to the target edge node based on the pre-stored real-time load data and hardware architecture information of each edge node.

[0052] S102. Control the collaborative adaptation layer to generate a distribution task based on the WASM plugin package, so that the collaborative adaptation layer distributes the WASM plugin package to the target edge node of the edge node execution layer;

[0053] S103. Receive the WASM plugin package distributed by the collaborative adaptation layer through the target edge node, verify the WASM plugin package, and generate a verification result;

[0054] S104. Based on the verification result, the target edge node loads and runs the WASM plugin in the WASM plugin package in a hot-swappable manner in the CDN main process running locally, so as to realize the management of the edge node plugin.

[0055] In step S101, the collaborative adaptation layer of this application, acting as the core bridge between the CDN central management layer and the edge node execution layer, is primarily responsible for receiving plugin release tasks for target edge nodes issued by the central management layer. These plugin release tasks include key information such as plugin identifier, target node range, release priority, and version requirements, and are transmitted via the gRPC interface in Protobuf format to ensure efficient and complete data transmission. After receiving the plugin release task, the collaborative adaptation layer, relying on its own node profiling module, calls pre-stored basic data and real-time monitoring data for each edge node. The core data includes real-time load data and hardware architecture information for each edge node: real-time load data is reported by the nodes at a preset frequency (default 60 seconds / time, 10 seconds / time under high load), covering CPU utilization, memory utilization, bandwidth utilization, etc., and is normalized to generate a node load coefficient; the hardware architecture information includes the x86_64, aarch64, or armv7l architecture type of the node, serving as the core basis for plugin package matching. Based on the above core data, the collaborative adaptation layer first filters out… Among the target edge nodes, those with current load within the updateable range (low-load and medium-load nodes are prioritized, while high-load nodes are paused for matching) are selected. Based on the hardware architecture information of each target node, the WASM plugin package with WASM bytecode that is fully compatible with the node's architecture is accurately matched from the plugin resources synchronized by the central control layer. At the same time, the collaborative adaptation layer will use the incremental / full transmission module to determine whether the WASM plugin package is an updated version of the plugin already installed on the node. If it is an update, an incremental patch package is generated to further optimize transmission efficiency. Finally, the accurate matching between the target edge node and the corresponding WASM plugin package is completed, laying the foundation for subsequent plugin distribution and installation.

[0056] The central control layer also includes a plugin resource management module, which provides full-dimensional CRUD capabilities for plugins, including plugin metadata (ID, function tags, type, dependency list), multi-architecture optimized bytecode packages, MD5 hash values, and signature information. It supports batch uploading and on-demand downloading of plugin packages, and automatically distributes adapted versions based on hardware architecture information in edge node profiles, ensuring the compatibility and integrity of plugin deployment. This module provides compliant plugin package resources and version metadata to the version and release control module through "plugin version query interface" and "plugin package acquisition interface." The node profile module in the collaborative adaptation layer generates node profiles based on data reported by edge nodes to the central control layer at a fixed frequency of 60 seconds per report. If the node load exceeds the threshold (CPU ≥ 80% / Memory ≥ 85% / Bandwidth ≥ 75%), a high-frequency report is triggered every 10 seconds per report. The report uses Protobuf binary format and includes hardware architecture (x86_64 / aarch64 / armv7l), operating system (CentOS7+ / Ubuntu18.04+ / Tongxin UOS Server Edition), and resource load (CPU...). The central control layer generates "node profiles" based on the reported data, which are categorized into five dimensions: memory usage, bandwidth utilization, disk I / O utilization, business attributes, and plugin status. These profiles are used for plugin version matching and controlling the plugin transmission rhythm.

[0057] In step S102, after completing the accurate matching of the target edge node with the corresponding WASM plugin package, the collaborative adaptation layer feeds back the matching result (including the adapted WASM plugin package information, the list of updatable target edge nodes, node load coefficient, transmission method suggestions, etc.) to the central control layer via the gRPC interface. Upon receiving the feedback, the central control layer's version and release control module generates a plugin distribution task based on the matching result. The distribution task explicitly includes core configurations such as the WASM plugin package (full package or incremental patch package), the target edge node list, distribution priority, distribution rhythm limits, failure threshold, and update time window, ensuring that the distribution process is controllable and traceable. After the task is generated, the central control layer distributes it to the collaborative adaptation layer. After receiving the distribution task, the collaborative adaptation layer uses the distribution module to combine the real-time node status provided by the node profiling module and executes the distribution operation in a refined manner according to preset rules: the distribution batches are divided according to the node load coefficient. Low load nodes (load coefficient < 0.5) are distributed in batches of 100 nodes, medium load nodes (0.5-0.7) are distributed in batches of 50 nodes, and high load nodes (≥ 0.7) are suspended from distribution. The distribution rate of core business nodes is 50% of that of non-core nodes, and the batch interval is ≥ 5 minutes. At the same time, the number of nodes distributed in a single batch in a single region / operator is strictly controlled to be ≤ 5% of that region to avoid the impact of centralized distribution on node performance. During the distribution process, the collaborative adaptation layer executes the plugin package transmission through the incremental / full transmission module. The incremental transmission mode is used by default to save bandwidth. If the incremental transmission fails, it automatically switches to full transmission and records the entire distribution chain log in real time. At the same time, it continuously receives distribution feedback from each target edge node and reports it to the central control layer. The central control layer adjusts the distribution rhythm in real time based on the feedback data. If the failure rate of a single batch is ≥10%, the distribution is suspended to ensure that the WASM plugin package is accurately, securely, and efficiently distributed to each target edge node of the edge node execution layer, preparing for subsequent plugin loading and execution.

[0058] In a specific implementation of step S102, one embodiment is as follows: the collaborative adaptation layer distributes the WASM plugin package to the target edge node of the edge node execution layer, including:

[0059] S1021. Based on the target node filtering conditions in the received release instruction, match the target edge node list that meets the conditions from the node profile library maintained by the collaborative adaptation layer.

[0060] S1022, The collaborative adaptation layer executes the publishing task so that the target edge nodes in the target edge node list receive the WASM plugin package.

[0061] In steps S1021-S1022, after receiving the published task, the collaborative adaptation layer of this application first extracts the target node filtering conditions from the task, and then calls the node profile library maintained by its own node profile module. This node profile library stores the full profile data of all edge nodes in real time, covering basic node information (hardware architecture, region, operator, service tag), real-time operating data (CPU utilization, memory utilization, bandwidth utilization, load factor), and plugin status information. All data is reported and updated in real time by each edge node at a preset frequency (default 60 seconds / time, 10 seconds / time under high load) to ensure the accuracy and timeliness of the profile data. The profile information of each edge node is compared with the target node filtering conditions one by one, and edge nodes that meet all conditions are selected to form an edge node list. During the matching process, if the target node filtering criteria include load-related requirements, nodes with load coefficients within the updateable range (low load, medium load) will be prioritized. High-load nodes (load coefficient ≥ 0.7) will not be included in the target list to avoid impacting node performance during plugin distribution. If the target node filtering criteria specify hardware architecture, only x86_64 or aarch64 architecture nodes compatible with the WASM plugin package will be matched to ensure the plugin can be loaded and executed normally later. The matched edge nodes will be compiled into an edge node list. After obtaining the edge node list, the collaborative adaptation layer will verify the edge node list, removing nodes with abnormal online status or those that do not meet the plugin installation environment requirements. Finally, a target edge node list that meets the requirements will be determined, and the matching process log will be recorded synchronously for subsequent traceability and verification. After the target edge node list matching is completed, the collaborative adaptation layer will officially execute the release task issued by the central control layer and start the plugin package distribution process. Before distribution, the collaborative adaptation layer uses the incremental / full transmission module to determine the type of WASM plugin package to be distributed (full package or incremental patch package) based on the current version of the plugins of each node in the target edge node list. For nodes that have installed the old version of the plugin, an incremental patch package is generated to save bandwidth and improve distribution efficiency; for nodes that have not installed the plugin, a full WASM plugin package is sent, so that the target edge nodes in the target edge node list receive the WASM plugin package.

[0062] In a specific implementation of step S1022, one embodiment is as follows: Executing the publishing task to enable the target edge nodes in the target edge node list to receive the WASM plugin package includes:

[0063] A1. After receiving the publishing task, the distribution module in the coordination and adaptation layer calls the node profiling module to obtain the real-time load data of each target edge node.

[0064] A2. Generate a distribution rhythm rule based on the real-time load data, and dynamically sort and batch the target edge nodes according to the distribution rhythm rule to generate an ordered update queue;

[0065] A3. In accordance with the update queue, call the update interface of each target edge node in sequence to execute the push or notification pull of the WASM plugin package.

[0066] In steps A1-A3, after receiving the plugin release task issued by the central management layer, the primary task of the distribution module of the collaborative adaptation layer is to obtain the real-time load data of each target edge node, including the CPU utilization, memory utilization, bandwidth utilization, and node load coefficient generated after normalization (calculated as (CPU utilization + memory utilization + bandwidth utilization) / 3, normalized to the 0-1 range). Based on the real-time load data and the distribution requirements in the release task, the distribution module generates specific distribution rhythm rules. These rules strictly conform to the high concurrency and low latency operation requirements of CDN edge nodes, taking into account both distribution efficiency and node operation stability. The specific rules are as follows: Distribution priority and batch size are determined based on node load coefficients. Low-load nodes (load coefficient < 0.5) have the highest priority and are distributed in batches of 100 nodes; medium-load nodes (load coefficient 0.5-0.7) have medium priority and are distributed in batches of 50 nodes; high-load nodes (load coefficient ≥ 0.7) have low priority and are suspended from distribution until their load drops to an acceptable level. Meanwhile, differentiated management is implemented for core business nodes and non-core business nodes. The distribution rate for core business nodes is set to 50% of that for non-core nodes, and the batch interval is ≥ 5 minutes. Furthermore, the number of nodes distributed in a single batch by a single region / operator is strictly controlled to be ≤ 5% of that region to avoid concentrated distribution causing a spike in node load and affecting the normal operation of CDN services. After the distribution rhythm rules are generated, the distribution module dynamically sorts and batches all edge nodes in the target edge node list based on these rules, generating an ordered update queue. Batch division strictly follows the batch size requirements in the distribution rhythm rules, dividing the sorted target edge nodes into several distribution batches. Each batch contains nodes of the same load level and from the same region / carrier, avoiding management chaos caused by mixing nodes with different loads or regions. The update queue clearly records the node list, distribution order, and expected distribution time for each batch, ensuring the distribution process is traceable and controllable. After the update queue is generated, the distribution module sequentially calls the update interface of each target edge node according to the queue order, performing WASM plugin package push or notification pull operations to ensure that the plugin package is delivered accurately and efficiently to each target edge node. Specifically, for each distribution batch, the distribution module calls the update interface of all target edge nodes in that batch in batches. First, it sends a plugin distribution notification to the node, clearly informing it of key information such as the plugin package type (full package or incremental patch package), plugin version, and transmission method. If the node's current load is low and the network status is good, the distribution module adopts an active push mode, directly transmitting the WASM plugin package to the target edge node through the gRPC interface. If the node's current load is high or the network status is unstable, the distribution module adopts a notification pull mode, informing the node of the plugin package acquisition address, and the node actively pulls the plugin package when its own load is idle.

[0067] During the plugin package push or notification retrieval process, the distribution module receives real-time execution status (success, failure, transmitting / retrieval) feedback from each target edge node. For nodes that fail to transmit, automatic retry is performed (no more than 3 retries). If the retry still fails, the node's abnormal information is recorded and reported to the central control layer. At the same time, the node is adjusted to a subsequent distribution batch, and the distribution operation is re-executed after the node's status recovers. For nodes that successfully transmit, logs such as the distribution completion time and plugin package type are recorded synchronously to ensure that the entire distribution process is traceable. Finally, the WASM plugin package is distributed to all target edge nodes, laying a solid foundation for subsequent plugin loading, initialization, and execution.

[0068] In the specific implementation of step A3, one embodiment is as follows: The update interfaces of each target edge node are called sequentially according to the update queue to execute the push or notification retrieval of the WASM plugin package, including:

[0069] A31. For target edge nodes that require version updates, the collaboration adaptation layer obtains the old version plugin package currently installed on the target edge node; the WASM plugin package is the new version.

[0070] A32. Compare the bytecode differences between the WASM plugin package and the old version plugin package, generate an incremental patch package, and transmit it to the target edge node.

[0071] In steps A31-A32, for target edge nodes requiring version updates, the collaborative adaptation layer first obtains information about the old version plugin package currently installed on the target edge node through the node profiling module. This information includes core details such as the bytecode data, version number, and architecture type of the old version plugin, ensuring an accurate comparison with the new version WASM plugin package to be distributed. Since the WASM plugin package to be distributed is a new version, the collaborative adaptation layer calls the incremental / full transmission module to perform a segment-by-segment comparison at the bytecode level between the new version WASM plugin package and the old version plugin package already installed on the target edge node. This accurately identifies the differences between the two (including added, modified, and deleted bytecode), and based on a binary differential algorithm, only the differences are packaged to generate an incremental patch package. Compared to the full plugin package, the incremental patch package is significantly smaller, effectively saving network bandwidth and improving plugin distribution efficiency, especially suitable for plugin version updates in cross-regional, low-bandwidth scenarios. After the incremental patch package is generated, the distribution module combines the real-time load status and network conditions of the target edge node and uses the same transmission method as the full package (active push or notification pull) to transmit the incremental patch package to the target edge node.

[0072] In step S103, the target edge node receives the WASM plugin package distributed by the collaborative adaptation layer, verifies the WASM plugin package, and generates a verification result to ensure the plugin package is legal and complete, preventing abnormal plugin packages from affecting node operation. The verification process strictly follows preset specifications and consists of two core steps: integrity verification and legality verification, executed sequentially and checked at each level. After receiving the incremental patch package, the target edge node immediately performs integrity verification (MD5 verification) and legality verification (ECDSA signature verification) on the patch package. After verification, the verification result (verification success or verification failure) is fed back to the distribution module of the collaborative adaptation layer in real time. After receiving the verification result from the target edge node, the collaborative adaptation layer judges the verification result: if the feedback is that the verification is successful, it is determined that the new version of the WASM plugin package (in the form of an incremental patch package) has been successfully delivered, and the successful delivery log is recorded synchronously, including information such as node identifier, patch package version, and delivery time; if the feedback is that the verification fails, the distribution module will automatically trigger the retry mechanism to retransmit the incremental patch package, with a maximum of 3 retries. If the retry still fails, it will automatically switch to transmitting the full WASM plugin package until the target edge node reports successful verification, ensuring that the new version of the WASM plugin package is finally successfully delivered.

[0073] In step S104, based on the verification result, only when the WASM plugin package (full package or incremental patch package) is successfully verified will the target edge node hot-swap load and run the WASM plugin in the local CDN main process. This process does not require restarting the CDN main process, enabling dynamic management of edge node plugins and ensuring business continuity. First, the plugin loader of the target edge node, such as... Figure 2As shown, upon receiving a successful verification command, if it is an incremental patch package, it is first merged with the locally installed old version plugin package to restore it into a complete new version WASM plugin package, ensuring that the plugin bytecode is complete and executable; if it is a full plugin package, it directly enters the loading process. During the loading process, the plugin loader adopts a segmented loading strategy, prioritizing the loading of the plugin's core logic (accounting for 30%-50% of the total bytecode) to quickly complete plugin initialization. Non-core functions are loaded on demand through a mapping table, reducing memory consumption and adapting to the resource-constrained characteristics of CDN edge nodes. At the same time, the plugin loader calls the local lightweight WASM runtime module (based on wazero and optimized, with a size ≤10MB) to create an independent sandbox for the WASM plugin. Through a triple isolation mechanism of memory, CPU, and interface, it ensures that the plugin runtime is completely isolated from the CDN main process, preventing plugin anomalies from affecting the stability of the main process. After loading, the CDN main process seamlessly interacts with WASM plugins through three pre-defined standardized gRPC interfaces: confirming plugin loading and startup via a lifecycle management interface; triggering custom business logic in critical CDN request processing stages (such as authentication and rate limiting) via a business logic trigger interface; and enabling plugins to access CDN underlying capabilities via plugin-initiated calls to the main process interface. Simultaneously, the node's resource monitoring module, such as... Figure 3 As shown, CPU and memory usage data for the plugin are collected at a frequency of 100ms / time to ensure that the plugin's operation does not exceed the preset threshold. The entire hot-swap loading and running process realizes dynamic management of the plugin's "loading-running-control" process without interrupting the CDN main process service. This not only solves the pain point of traditional plugin updates requiring node restarts, but also ensures operational security through sandbox isolation. At the same time, relying on standardized interfaces and fine-grained monitoring, it achieves efficient and secure management of plugins on edge nodes, providing support for flexible expansion of CDN services.

[0074] In a specific implementation of step S104, one embodiment is as follows: the target edge node loads and runs the WASM plugin in the WASM plugin package in a hot-swappable manner in the CDN main process running locally, including:

[0075] S1041. Pre-configure a loading strategy on the target edge node, and control the target edge node to execute the loading strategy to load the instance in the WASM plugin package;

[0076] S1042. After loading is complete, an independent running sandbox is allocated to the WASM plugin package, initialization operations are performed, and the plugin is marked as available.

[0077] S1043. In response to a plugin uninstallation command or a version update command, the plugin loader clears the memory cache occupied by the plugin and releases the corresponding independent running sandbox resources.

[0078] In steps S1041-S1043, the edge execution layer of this application pre-configures a dedicated loading strategy in the plugin loader of the target edge node. This strategy, combined with the resource-constrained and high-concurrency operation characteristics of CDN edge nodes, clearly defines the plugin loading priority, loading method, and resource allocation standards, providing standardized guidance for the efficient loading of WASM plugins. When the target edge node receives a successfully verified WASM plugin package (full package or incremental patch package), the plugin loader responds immediately, strictly executing the preset loading strategy to control the target edge node to load plugin instances in the WASM plugin package in an orderly manner. The loading process strictly follows the strategy requirements, prioritizing the loading of core business instances of the plugin, while non-core instances are loaded on demand with delayed loading, reducing the initial loading's occupation of node memory and CPU resources, and ensuring that the loading process does not affect the normal operation of the CDN main process. After loading is completed, the plugin loader immediately calls the local lightweight WASM runtime module to allocate an independent running sandbox for the WASM plugin package, and uses memory and CPU resources to load the plugin. The triple isolation mechanism of PU and interface achieves complete isolation between the plugin and the CDN main process and other plugins, preventing plugin anomalies from affecting the overall node service. After the independent sandbox is allocated, the plugin initialization operation is automatically executed. During the initialization process, the plugin is associated with three types of standardized gRPC interfaces of the CDN main process, the configuration parameters required for plugin operation are loaded, the plugin operation dependencies are verified, and it is ensured that the plugin can respond normally to business trigger commands. After successful initialization, the plugin loader marks the WASM plugin as available, synchronously updates the node plugin status information and reports it to the node profile library of the collaboration and adaptation layer, so that the management and control layer can monitor the plugin's running status in real time. When the target edge node receives a plugin uninstallation command or a version update command, the plugin loader immediately initiates a resource release process: first, it stops the plugin from receiving new business requests; after the plugin has processed all existing requests, it clears all memory caches used during the plugin's operation, deletes temporary files and running logs; then, it terminates the plugin's running instance, releases the corresponding WASM independent running sandbox resources, and ensures that the memory and CPU resources occupied by the sandbox are completely reclaimed to avoid resource leaks. The entire process does not require restarting the CDN main process, realizing dynamic uninstallation and updating of plugins and ensuring the efficiency and security of edge node plugin management.

[0079] In a specific implementation of step S1043, one embodiment is as follows: In response to a plugin uninstallation command or a version update command, the plugin loader clears the memory cache occupied by the plugin and releases the corresponding independent running sandbox resources, including:

[0080] B1. Based on the version update instruction, create an independent sandbox for the WASM plugin package, and perform preloading and initialization to form a new version plugin instance;

[0081] B2. After the independent sandbox preloading is successful and the new version plugin instance is ready, the resource release process of the old version plugin instance is triggered.

[0082] In steps B1-B2, when the target edge node receives a plugin uninstallation command or a version update command, the plugin loader immediately initiates the corresponding processing flow. Based on the version update command, the plugin loader prioritizes the preloading and initialization of the new version plugin to ensure uninterrupted service during the update process. Specifically, the plugin loader calls the local lightweight WASM runtime module to create an independent running sandbox for the WASM plugin package to be updated. This independent running sandbox is completely isolated from the sandbox of the old version plugin instance, preventing interference and avoiding impact on the normal operation of the old version plugin during the loading of the new version. After the independent running sandbox is created, the plugin loader strictly follows the preset loading strategy, performing preloading operations on the WASM plugin package, prioritizing the loading of core business instances of the new version plugin, and delaying the loading of non-core instances as needed, reducing the preloading's impact on node resources and ensuring that the CDN main process and the service processing of the old version plugin are not affected. After preloading is complete, initialization operations are automatically performed, establishing the association between the new version plugin and the three standardized gRPC interfaces of the CDN main process. Configuration parameters required for plugin execution are loaded, and runtime dependencies are verified until the new version plugin instance is fully ready to respond to business trigger commands. Only after the independent running sandbox preloading is successful and the new version plugin instance is ready does the plugin loader trigger the resource release process for the old version plugin instance. During the release process, the old version plugin is first stopped from receiving new business requests. After processing all existing requests, the memory cache occupied by the old version plugin is cleared, temporary files and runtime logs are deleted, and then the old version plugin instance is terminated, releasing the corresponding independent running sandbox resources. This ensures complete reclamation of resources such as memory and CPU, preventing resource leaks. The entire process does not require restarting the CDN main process, achieving seamless hot updates of plugin versions, ensuring business continuity while completing plugin instance iteration and reasonable resource management. Specifically, the old version of the plugin instance first stops accepting new business requests, focusing on processing all existing requests before entering a 30-second window. This window is used to wait for any potential long-lived connection requests to complete, preventing interruption of long-lived connection requests due to direct destruction. During this window, new traffic is strictly prohibited from entering the old instance. After the window ends, the plugin loader forcibly reclaims all resources, including memory and CPU, occupied by the old version of the plugin instance, completely destroying the old instance and preventing resource leaks. The entire process does not require restarting the CDN main process, achieving seamless hot updates of the plugin version, ensuring business continuity while also iterating the plugin instance and managing resources effectively.In addition, to ensure the security of version updates, a robust rollback guarantee mechanism is set up: the old version plugin package will be retained for 7 days. If the new version plugin has serious anomalies (such as an execution failure rate ≥10%), it can be quickly rolled back to the old version. Rollback can be triggered in two ways: one is manual triggering (operated by operations and maintenance personnel), and the other is automatic triggering (triggered by the resource monitoring module after detecting that the monitoring indicators exceed the preset threshold). After the rollback operation is executed, the new version plugin instance is immediately deleted, the old version plugin instance is restarted and its operation is restored to ensure that the business quickly returns to normal.

[0083] Once the new version plugin instance is ready, before starting the traffic switch, it will monitor two core metrics in real time: execution time and exception rate. The real-time metrics will be compared with the benchmark metrics of the old version plugin. If an abnormality is detected (such as the execution time increasing by 50% or more compared to the benchmark value), the traffic switch operation will be paused immediately, and the version rollback process will be triggered to prevent the abnormal new version plugin from affecting the normal operation of the business.

[0084] In the specific implementation of step S1043, another embodiment is as follows: In response to a plugin uninstallation command or a version update command, the plugin loader clears the memory cache occupied by the plugin and releases the corresponding independent running sandbox resources, including:

[0085] C1. Collect the resource parameters of the WASM plugin instance during runtime, and determine whether the resource parameters meet the corresponding plugin exception conditions;

[0086] C2. If so, then a plugin exception event has occurred. Immediately suspend the execution of the instance of the WASM plugin package while preserving its runtime context.

[0087] In steps C1-C2, during the operation of the WASM plugin instance, the resource monitoring module of the target edge node continuously collects runtime resource parameters at a preset frequency of 100ms / time to ensure real-time capture of the plugin's running status. The core resource parameters collected include the plugin instance's CPU usage and memory usage, while auxiliary parameters such as interface call frequency and response latency are also collected synchronously. All collected data is stored locally on the node in real time and retained for 24 hours for fault tracing. After collecting the resource parameters, the resource monitoring module immediately compares them with preset plugin anomaly conditions. Plugin anomaly conditions are divided into global thresholds and plugin-defined thresholds, with the custom threshold having higher priority than the global threshold. The global threshold is set by default to a single plugin's CPU usage ≤20% and memory usage ≤128MB, which can be remotely adjusted by the CDN central management layer. A three-time consecutive limit exceedance judgment mechanism is used during the judgment process to avoid misjudgments caused by instantaneous resource fluctuations and ensure the accuracy of anomaly judgment. If the collected resource parameters are determined to meet the corresponding plugin anomaly conditions (i.e., exceeding the preset threshold three times consecutively; minor exceedances only report an alarm, while severe exceedances exceeding the threshold by 120% are considered an anomaly), then a plugin anomaly event is immediately identified. At this time, the resource monitoring module will send an anomaly signal to the plugin loader, which will immediately suspend the instance of the WASM plugin package and stop it from receiving new business requests. However, it will retain the entire runtime context of the plugin instance, including the current business processing progress, configuration parameters, interface association status, etc., to support subsequent plugin recovery and troubleshooting, prevent the anomaly from escalating, and reduce business losses.

[0088] Example 2

[0089] This application also provides a CDN edge node plugin management device based on WASM, such as... Figure 4 The diagram shows a block diagram of a WASM-based CDN edge node plugin management device. The functions implemented by this WASM-based CDN edge node plugin management device correspond to the steps described above in executing a WASM-based CDN edge node plugin management method on a terminal device. This device can be understood as a server component including a processor. The WASM-based CDN edge node plugin management device and method described in this application are applicable to management systems. The management system includes a central control layer, a collaborative adaptation layer, and an edge node execution layer. The device includes:

[0090] The receiving module 401 is used to receive the plugin release task for edge nodes issued by the central control layer through the collaborative adaptation layer, and match the WASM plugin package corresponding to the target edge node based on the pre-stored real-time load data and hardware architecture information of each edge node.

[0091] Control module 402 is used to control the collaborative adaptation layer to generate a distribution task based on the WASM plugin package, so that the collaborative adaptation layer distributes the WASM plugin package to the target edge node of the edge node execution layer;

[0092] The verification module 403 is used to receive the WASM plugin package distributed by the collaborative adaptation layer through the target edge node, verify the WASM plugin package, and generate a verification result.

[0093] The management module 404 is used to load and run the WASM plugin in the WASM plugin package in a hot-swappable manner in the CDN main process running locally on the target edge node based on the verification result, so as to realize the management of the edge node plugin.

[0094] In one feasible implementation, the management module includes:

[0095] A loading strategy is pre-configured on the target edge node, and the target edge node is controlled to execute the loading strategy to load instances in the WASM plugin package;

[0096] After loading is complete, an independent running sandbox is allocated to the WASM plugin package, initialization operations are performed, and the plugin is marked as available.

[0097] In response to a plugin uninstallation command or a version update command, the plugin loader clears the memory cache occupied by the plugin and releases the corresponding independent running sandbox resources.

[0098] In one feasible implementation, the management module further includes:

[0099] Based on the version update command, an independent sandbox is created for the WASM plugin package, and preloading and initialization are performed to form a new version plugin instance;

[0100] After the independent sandbox preloading is successful and the new version plugin instance is ready, the resource release process of the old version plugin instance is triggered.

[0101] In one feasible implementation, the management module also includes:

[0102] Collect resource parameters during the runtime of the WASM plugin instance and determine whether the resource parameters meet the corresponding plugin exception conditions;

[0103] If so, a plugin exception event is confirmed, and the execution of the WASM plugin package instance is immediately suspended while preserving its runtime context.

[0104] In one feasible implementation, the control module includes:

[0105] Based on the target node filtering conditions in the received release instruction, the target edge node list that meets the conditions is matched from the node profile library maintained by the collaborative adaptation layer.

[0106] The collaborative adaptation layer executes the publishing task so that the target edge nodes in the target edge node list receive the WASM plugin package.

[0107] In one feasible implementation, the control module further includes:

[0108] After receiving the publishing task, the distribution module in the coordination and adaptation layer calls the node profiling module to obtain the real-time load data of each target edge node.

[0109] Based on the real-time load data, a distribution rhythm rule is generated, and the target edge nodes are dynamically sorted and batched according to the distribution rhythm rule to generate an ordered update queue.

[0110] The update interface of each target edge node is called sequentially according to the update queue to execute the push or notification pull of the WASM plugin package.

[0111] In one feasible implementation, the control module also includes:

[0112] For target edge nodes that require version updates, the collaboration adaptation layer obtains the old version plugin package currently installed on the target edge node; the WASM plugin package is the new version.

[0113] By comparing the bytecode differences between the WASM plugin package and the old version plugin package, an incremental patch package is generated and transmitted to the target edge node.

[0114] Example 3

[0115] This application also provides an electronic device, such as Figure 5 As shown, it includes: a processor 501, a memory 502, and a bus 503. The memory 502 stores machine-readable instructions that can be executed by the processor 501. When the electronic device is running, the processor 501 and the memory 502 communicate through the bus 503. When the machine-readable instructions are executed by the processor 501, the steps of any of the WASM-based CDN edge node plug-in management methods described above are executed.

[0116] Example 4

[0117] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of any of the WASM-based CDN edge node plugin management methods described in the present application.

Claims

1. A CDN edge node plugin management method based on WASM, characterized in that, Applicable to a management system, the management system including a central control layer, a collaborative adaptation layer, and an edge node execution layer, the method includes: The collaborative adaptation layer receives the plugin release task for edge nodes issued by the central control layer, and matches the WASM plugin package corresponding to the target edge node based on the pre-stored real-time load data and hardware architecture information of each edge node. The collaborative adaptation layer is controlled to generate a distribution task based on the WASM plugin package, so that the collaborative adaptation layer distributes the WASM plugin package to the target edge node of the edge node execution layer; The target edge node receives the WASM plugin package distributed by the collaborative adaptation layer, verifies the WASM plugin package, and generates a verification result. Based on the verification results, the target edge node loads and runs the WASM plugin in the WASM plugin package in a hot-swappable manner in the CDN main process running locally, so as to realize the management of the edge node plugin.

2. The method as described in claim 1, characterized in that, The target edge node, within its locally running CDN main process, hot-swap loads and runs the WASM plugin from the WASM plugin package, including: A loading strategy is pre-configured on the target edge node, and the target edge node is controlled to execute the loading strategy to load instances in the WASM plugin package; After loading is complete, an independent running sandbox is allocated to the WASM plugin package, initialization operations are performed, and the plugin is marked as available. In response to a plugin uninstallation command or a version update command, the plugin loader clears the memory cache occupied by the plugin and releases the corresponding independent running sandbox resources.

3. The method as described in claim 2, characterized in that, In response to a plugin uninstallation command or a version update command, the plugin loader clears the memory cache occupied by the plugin and releases the corresponding independent running sandbox resources, including: Based on the version update command, an independent sandbox is created for the WASM plugin package, and preloading and initialization are performed to form a new version plugin instance; After the independent sandbox preloading is successful and the new version plugin instance is ready, the resource release process of the old version plugin instance is triggered.

4. The method as described in claim 2, characterized in that, In response to a plugin uninstallation command or a version update command, the plugin loader clears the memory cache occupied by the plugin and releases the corresponding independent running sandbox resources, including: Collect resource parameters during the runtime of the WASM plugin instance and determine whether the resource parameters meet the corresponding plugin exception conditions; If so, a plugin exception event is confirmed, and the execution of the WASM plugin package instance is immediately suspended while preserving its runtime context.

5. The method as described in claim 1, characterized in that, The collaborative adaptation layer distributes the WASM plugin package to the target edge node of the edge node execution layer, including: Based on the target node filtering conditions in the received release instruction, the target edge node list that meets the conditions is matched from the node profile library maintained by the collaborative adaptation layer. The collaborative adaptation layer executes the publishing task so that the target edge nodes in the target edge node list receive the WASM plugin package.

6. The method as described in claim 5, characterized in that, Executing the release task to ensure that the target edge nodes in the target edge node list receive the WASM plugin package includes: After receiving the publishing task, the distribution module in the coordination and adaptation layer calls the node profiling module to obtain the real-time load data of each target edge node. Based on the real-time load data, a distribution rhythm rule is generated, and the target edge nodes are dynamically sorted and batched according to the distribution rhythm rule to generate an ordered update queue. The update interface of each target edge node is called sequentially according to the update queue to execute the push or notification pull of the WASM plugin package.

7. The method as described in claim 6, characterized in that, The update interface of each target edge node is called sequentially according to the update queue to execute the push or notification pull of the WASM plugin package, including: For target edge nodes that require version updates, the collaboration adaptation layer obtains the old version plugin package currently installed on the target edge node; the WASM plugin package is the new version. By comparing the bytecode differences between the WASM plugin package and the old version plugin package, an incremental patch package is generated and transmitted to the target edge node.

8. A CDN edge node plug-in management device based on WASM, characterized in that, Suitable for management systems, the management system including a central control layer, a collaborative adaptation layer, and an edge node execution layer, the device includes: The receiving module is used to receive the plugin release task for edge nodes issued by the central management and control layer through the collaborative adaptation layer, and match the WASM plugin package corresponding to the target edge node based on the pre-stored real-time load data and hardware architecture information of each edge node. The control module is used to control the collaborative adaptation layer to generate a distribution task based on the WASM plugin package, so that the collaborative adaptation layer distributes the WASM plugin package to the target edge node of the edge node execution layer; The verification module is used to receive the WASM plugin package distributed by the collaborative adaptation layer through the target edge node, verify the WASM plugin package, and generate a verification result. The management module is used to load and run the WASM plugin in the WASM plugin package in a hot-swappable manner in the CDN main process running locally on the target edge node based on the verification result, so as to realize the management of the edge node plugin.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of a WASM-based CDN edge node plug-in management method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of a WASM-based CDN edge node plugin management method as described in any one of claims 1 to 7.

Images