Gateway plug-in asynchronous publishing and cluster state synchronization method and system

Abstract

The application discloses a gateway plug-in asynchronous publishing and cluster state synchronizing method and system, and relates to the technical field of distributed systems.The method comprises the following steps: a management end generates node-level task records for each to-be-updated node and stores the node-level task records into a task table, and a unified batch number is allocated for the same batch; an update instruction is issued to each edge node in an asynchronous mode; the edge node writes the instruction into a local task queue for serial execution, and reports the state after performing file operation, database migration, configuration update and service reloading; the management end aggregates the callback information of each node to generate a batch overall completion state; and when retrying, the instruction is reissued only to the failed node.The application ensures the consistency of the cluster version, and improves the reliability and efficiency of large-scale gateway cluster plug-in publishing.

Description

Technical Field

[0001] This invention relates to the field of distributed system technology, specifically to a method and system for asynchronous deployment of gateway plugins and synchronization of cluster status. Background Technology

[0002] In a microservice architecture, the API gateway serves as the unified entry point for traffic and the policy enforcement point, undertaking core functions such as routing, authentication, rate limiting, and circuit breaking. The gateway's functionality is expanded and modified primarily through a plugin mechanism. Plugin releases and updates involve multiple strongly correlated steps, including code file replacement, database schema migration, and service process reloading, constituting heavyweight system-level change operations. As business scale continues to expand, the number of nodes in the gateway cluster increases. How to efficiently and reliably synchronize plugin versions across the entire cluster in a large-scale distributed environment becomes a key challenge in the operations and maintenance system.

[0003] Currently, mainstream gateway plugin distribution and state synchronization solutions can be categorized into two types.

[0004] The first type is the synchronous blocking deployment mode. Operations personnel directly call the interfaces of each node through the management platform to execute file distribution and update commands, and synchronously wait for the execution results from each node before proceeding to the next node. In this mode, there is a strong coupling between the management end and the execution end. The execution time of a single node is significantly affected by network conditions and node load. When the cluster size is large, the entire deployment process is prone to timeouts due to slow responses from some nodes. Furthermore, batch concurrent update operations are also limited by the connection resources and timeout thresholds of the management end.

[0005] The second category is the configuration center pull mode. This type of solution relies on configuration centers such as Nacos and Apollo, with gateway nodes obtaining configuration updates through periodic pulling or long polling. For example, Chinese patent application CN121530945A discloses an asynchronous task message passing method based on the MCP protocol. It establishes a full-duplex communication session between the calling end and the executing end through the MCP protocol layer, utilizes Nacos services for service registration and discovery, and transmits task semantic information through a standardized session to improve the efficiency of asynchronous task message passing. This solution focuses on ensuring the reliability of communication between the calling end and the executing end, solving packet loss and out-of-order delivery problems during message passing through breakpoint resumption and acknowledgment mechanisms.

[0006] However, the above solution still has the following drawbacks in specific scenarios where gateway plugins are released: First, existing asynchronous task message passing solutions only focus on the reliability of task instructions and status events. When an exception occurs at any stage of the update process, the execution end lacks an automated full rollback mechanism, and nodes are prone to falling into a "semi-update" abnormal state where file versions and database structures do not match. Furthermore, the management end cannot accurately detect the failed stage to trigger targeted remedial operations.

[0007] Secondly, existing solutions lack effective management of cluster-level state consistency. In the configuration center pull mode, each node independently maintains its own configuration version, and the management end cannot know the effective status of all nodes in the cluster in real time, posing a risk of "configuration drift." Although the synchronous blocking mode can obtain the return value of a single call, when some nodes lose instructions due to network interruptions or process restarts, the management end cannot distinguish these nodes from the nodes that executed successfully, and the overall task progress aggregation statistics lack accurate support from a list of failed nodes. Furthermore, there is a lack of an atomic aggregation mechanism to determine whether all nodes in the cluster have completed the same version of the plugin update.

[0008] Third, the existing retry granularity is too coarse. The full retry mechanism based on the task dimension will still re-execute the update operation on all nodes when only a few nodes in the cluster fail, causing normal nodes to suffer unnecessary service reload interruptions and expanding the impact of the failure. Furthermore, for retries of failed nodes, there is a lack of idempotency guarantees and continuity maintenance of the execution context. Multiple retries may cause secondary anomalies such as duplicate file overwriting or duplicate execution of database migration scripts. Summary of the Invention

[0009] The present invention aims to overcome the above-mentioned defects of the prior art and provide a method and system for asynchronous deployment of gateway plugins and synchronization of cluster status.

[0010] To achieve the above-mentioned objectives, this invention provides a method for asynchronous deployment of gateway plugins and synchronization of cluster status, comprising the following steps: Step S1, Task Construction and Storage. In response to the plugin release request, the management system generates a node-level release task record for each node to be updated in the target cluster. This node-level release task record is stored in a pre-defined plugin release task table, and a unique batch number is assigned to all node-level release task records within the same release batch. Each node-level release task record includes at least a node identifier, a plugin identifier, a plugin version number, and a task execution status.

[0011] Step S2, Asynchronous Instruction Issuance Step. The management terminal retrieves node-level release task records with a task execution status of "Pending Deployment" from the plugin release task table through timed scanning or event triggering. It then issues an update instruction containing the batch number, the plugin identifier, and the plugin version number to the corresponding edge node. If the issuance is successful, the corresponding task execution status is updated to "Deploying". If the issuance fails, the corresponding task execution status is marked as "Issuance Failed" and the reason for the failure is recorded.

[0012] Step S3, edge node local execution. After receiving the update instruction, the edge node writes the update instruction into its local task queue, which is then executed serially by a single thread in a first-in, first-out order. The execution of each plugin update task includes the following sub-steps: File operation sub-steps: Perform a full backup of the currently running plugin files; download and unzip the target version of the plugin package; perform a first integrity check on each unzipped file, and overwrite the files in the plugin directory if the check passes; perform a second integrity check on each file in the overwritten plugin directory; if either the first or second integrity check fails, terminate the current update process and trigger a file rollback to restore the plugin directory to the backup state.

[0013] Database migration sub-step: In response to the second integrity verification passing, the database migration instruction of the gateway is invoked to execute the database structure change corresponding to the target plugin version; the database migration instruction is executed based on the gateway's native transaction mechanism, and automatically rolls back when a single migration script fails to execute.

[0014] Configuration update sub-step: Verify the enabled status of the target plugin in the gateway configuration file. If it is not enabled, append the corresponding plugin configuration item and record the configuration change flag.

[0015] Service reload sub-step: Invoke the gateway's hot reload command to load the updated plugin code and configuration in a smooth restart manner.

[0016] Result callback sub-step: After all the above sub-steps are successfully executed, a success status is reported to the callback interface of the management end; if any of the above sub-steps fails or the total execution time exceeds the preset timeout threshold, the execution is terminated and a failure status and the corresponding failure reason are reported to the callback interface of the management end.

[0017] Step S4, Status Aggregation and Presentation. The management terminal receives callback information reported by each edge node, locates the corresponding node-level release task record based on the batch number and node identifier in the callback information, and updates the task execution status and failure reason of the record. In response to a progress query request for any release batch, the management terminal counts the task execution status of all node-level release task records under that batch, and generates the overall completion status of the release batch based on the statistical results.

[0018] Step S5, Targeted Retry Step. In response to the retry operation triggered by the operations and maintenance personnel, the management terminal extracts node-level release task records from the plugin release task table whose task execution status is failed, timed out, or failed to be delivered. Steps S2 to S3 are re-executed only for the extracted records. Each update instruction carries the plugin version number. Before execution, the edge node checks whether a historical execution record with the same batch number exists in its local cache. If it does, the current instruction is ignored to avoid duplicate execution.

[0019] To implement the above method, the present invention also provides a gateway plugin asynchronous release and cluster state synchronization system, including a management terminal and an edge proxy module deployed on each gateway node: The management terminal includes: The task creation module is used to respond to plugin release requests, generate node-level release task records for each node to be updated in the target cluster, store the node-level release task records in a preset plugin release task table, and assign a unified batch number to all node-level release task records in the same release batch; the node-level release task record includes at least a node identifier, a plugin identifier, a plugin version number, and a task execution status.

[0020] The instruction delivery module is used to obtain node-level release task records with a task execution status of "to be deployed" from the plugin release task table by means of timed scanning or event triggering, and to send an update instruction containing the batch number, the plugin identifier and the plugin version number to the corresponding edge agent module. If the instruction is successfully sent, the corresponding task execution status is updated to "deploying". If the instruction fails, the corresponding task execution status is marked as "successful" and the reason for failure is recorded.

[0021] The callback receiving module is used to receive callback information reported by each edge agent module, locate the corresponding node-level release task record based on the batch number and node identifier in the callback information, and update the task execution status and failure reason of the record.

[0022] The status aggregation module is used to respond to progress query requests for any release batch, count the task execution status of all node-level release task records under that batch, and generate the overall completion status of the release batch based on the statistical results.

[0023] The retry trigger module is used to respond to retry operations triggered by maintenance personnel. It extracts node-level release task records with task execution status of failure, timeout, or delivery failure from the plugin release task table and resubmits the extracted records to the instruction delivery module.

[0024] The edge proxy module includes: The task queue unit is used to receive the update instruction, write the update instruction into the local task queue, and execute it serially by a single thread in a first-in-first-out order.

[0025] The file operation unit is used to perform a full backup of the currently running plugin files; download and decompress the target version of the plugin package; perform a first integrity check on each decompressed file, and overwrite the files in the plugin directory if the check passes; perform a second integrity check on each file in the overwritten plugin directory; if either the first integrity check or the second integrity check fails, the current update process is terminated and a file rollback is triggered to restore the plugin directory to the backup state.

[0026] The database migration unit is used to invoke the gateway's database migration instruction to execute database structure changes corresponding to the target plugin version in response to the second integrity verification passing; the database migration instruction is executed based on the gateway's native transaction mechanism, and automatically rolls back when a single migration script fails to execute.

[0027] The configuration management unit is used to verify the enabling status of target plugins in the gateway configuration file. If the plugin is not enabled, the corresponding plugin configuration item is appended and the configuration change flag is recorded.

[0028] The service reload unit is used to call the gateway's hot reload command to load the updated plugin code and configuration in a smooth restart manner.

[0029] The execution control unit is used to monitor the total execution time of the current plugin update task and terminate the execution when the total execution time exceeds a preset timeout threshold; and after successful execution or execution termination, it reports the success status or failure status and the corresponding failure reason to the callback receiving module of the management terminal.

[0030] The deduplication caching unit is used to record the batch number corresponding to the update instruction after the task queue unit receives the update instruction; to clear the corresponding cache record after the execution control unit completes the reporting; and to ignore the instruction when the task queue unit receives an update instruction containing a cached batch number.

[0031] Compared with the prior art, this application has the following specific advantages: 1. Asynchronous task delivery and node-level state tracking mechanism based on task table This invention constructs a plugin release task table on the management side, storing the task execution status independently for each node to be updated, and using batch numbers to associate records of all nodes under the same release task. This task table serves as the single source of fact for the management side, supporting thread decoupling between the management and execution sides during asynchronous deployments, allowing the management side to release connection resources immediately after command transmission. It also provides a structured data foundation for subsequent progress aggregation queries and precise filtering of failed nodes. Compared to existing solutions, this invention elevates state management from the transport layer to the task orchestration layer, achieving traceability and auditability throughout the entire lifecycle of release tasks.

[0032] 2. Serial queues and transactional execution loops at edge nodes This invention introduces a concurrency control strategy combining a local FIFO task queue and deduplication caching on the edge agent side, ensuring that only one plugin update task is executed at a time, avoiding file conflicts and directory corruption caused by multiple tasks concurrently modifying the plugin directory. More importantly, this invention decomposes the plugin update process into a closed-loop operation chain of "file backup → integrity verification → overwrite → re-inspection → database migration → configuration change → service reload," and sets up a full rollback mechanism at the file and configuration levels. When file verification fails or any step fails, the plugin files and configurations are automatically restored to their pre-update state. Single-node plugin updates possess the atomic characteristic of "all or nothing," eliminating the intermediate "dirty" state where some files are updated and others are not. Database migration commands rely on the gateway's native transaction mechanism; if a single migration script fails, it automatically rolls back. The migration script itself is idempotent, further ensuring the security of the retry process.

[0033] 3. Collaborative architecture of precise node-level callbacks and cluster-level aggregated confirmations This invention constructs a two-layer confirmation architecture of "node-level reporting + management-end aggregation". After each edge agent completes its execution (success, failure, or timeout), it proactively reports the execution result and failure reason of its own node to the callback interface of the management end. The management end updates the status of the corresponding single record in the task table accordingly. When the operation and maintenance personnel query the task progress, the management end statistically analyzes the status distribution of all nodes in the batch in real time. Only when all nodes are successful is the overall status of the batch determined to be successful; if any node fails, times out, or fails to report, the overall status of the batch is partially failed or in progress. This mechanism ensures that the determination of cluster version consistency is based solely on the success of all nodes, fundamentally eliminating the state split problem of "some nodes with new versions and some nodes with old versions" in the cluster.

[0034] 4. Minimum failure set-oriented retry and idempotency guarantee This invention proposes a targeted retry strategy based on a minimum failure set. The management system automatically extracts node records with statuses of failure, timeout, or delivery failure from the task table. Operations personnel can then reissue update commands only for the aforementioned set of failed nodes; successfully executed nodes are not retried. Simultaneously, each update command carries a specific plugin version number, and the edge agent uses batch numbering for deduplication and caching, ensuring that nodes that have successfully executed the command are automatically ignored when receiving duplicate commands. The retry operation has complete idempotency guarantees.

[0035] The aforementioned technical features are not isolated additions, but rather work collaboratively around a complete closed loop of "asynchronous decoupled release, atomic execution, precise state aggregation, and targeted self-healing recovery," forming an overall technical effect that transcends the simple addition of individual features.

[0036] The task table acts as the central hub, receiving asynchronous dispatch and retry scheduling from the management end and status callbacks from each edge node, forming a state-driven engine for the entire process. The serial queue and transactional execution loop of the edge agents ensure atomicity of updates locally, while the aggregation confirmation mechanism of the management end ensures eventual consistency of the cluster globally. These two are coupled through asynchronous HTTP callbacks, preventing the management end from being blocked by slow nodes and achieving accurate collection of node-level status. The minimum failure set retry strategy, based on the aforementioned status data, transforms the accurate identification of failed nodes into precise repair actions, realizing a self-healing chain from "anomaly detection" to "failure set localization" and then to "targeted repair."

[0037] The data flow between each stage forms a unified context transmission link, supporting an end-to-end observable, controllable, and recoverable operation and maintenance closed loop from task issuance, local execution, status reporting, progress aggregation to targeted retries. Attached Figure Description

[0038] Figure 1 This is the overall flowchart of the method in this embodiment; Figure 2 Flowchart of steps for local execution at edge nodes; Figure 3 This is a system architecture diagram for this embodiment. Detailed Implementation

[0039] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the following embodiments are for illustrative purposes only and should not be considered as limiting the scope of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0040] To facilitate understanding of the technical solution of this invention, the following definitions and explanations are provided for several terms used in this application: Edge proxy module: A resident service process deployed on each gateway server, responsible for receiving management instructions from the management terminal and performing specific operations such as file operations, configuration modifications, database migrations, and service control locally.

[0041] Plugin Release Task Table: A metadata table stored in the management database, used to record the intent of plugin release and the execution progress status of each node. It is the core data carrier for achieving asynchronous decoupling.

[0042] Batch Number: A globally unique identifier used to associate all subtasks under the same release task, supporting aggregated queries of overall progress by batch.

[0043] Local task queue: A first-in-first-out queue maintained locally by the edge agent module to serialize the processing of multiple received plugin update requests and avoid plugin directory file conflicts caused by concurrent execution.

[0044] Aggregate state confirmation: A distributed coordination mechanism that recognizes the parent task as successful only when all participants' subtasks in the distributed system have succeeded.

[0045] Minimal failure set retry: A strategy that performs precise retries on a subset of failures, unlike full retries, and can effectively reduce interference with normal nodes.

[0046] Hot reloading: A technique that reloads configuration files or plugin code without restarting the gateway's main process, ensuring uninterrupted business traffic.

[0047] Integrity verification: The process of verifying whether a file has been damaged or tampered with during transmission or decompression by comparing the actual MD5 checksum of the file with the expected MD5 checksum.

[0048] Example 1 like Figure 1 As shown in the figure, this embodiment provides a method for asynchronous deployment of gateway plugins and synchronization of cluster status.

[0049] Step S1: Task construction and storage steps.

[0050] The management console responds to plugin release requests initiated by operations and maintenance personnel. This request includes the storage location information of the plugin package to be released, the target plugin identifier, the target plugin version number, and the target cluster information. Based on the target cluster information, the management console retrieves a list of all gateway nodes within that cluster.

[0051] For example, operations personnel upload the authentication plugin package version 2.2.0 to the management interface, specifying the plugin identifier as auth-plugin, the version number as 2.2.0, and selecting the production gateway cluster as the target cluster. Based on the registration information of the production gateway cluster, the management interface queries and finds that the cluster contains fifty gateway nodes, with node identifiers ranging from node-001 to node-050. The management interface then generates node-level deployment task records for each of these fifty nodes.

[0052] For each node to be updated in the target cluster, the management system generates a node-level deployment task record. Each node-level deployment task record includes at least the following fields: primary key, batch number, node identifier, plugin identifier, plugin version number, task execution status, failure reason, creation time, and update time. Among them, the task execution status indicates the current deployment stage of the node, including status types such as pending deployment, in deployment, successful, failed, deployment failed, and timeout.

[0053] Simultaneously, the management system generates a globally unique batch number for each currently released plugin. This batch number is used to associate all nodes within the same release batch with their corresponding node-level release task records. The management system then writes the batch number into each of these node-level release task records.

[0054] In this invention, the batch number generated by the management terminal for each plugin release request is a globally unique identifier used to associate node-level release task records of all nodes under the same release batch. The encoding rules for this batch number are as follows.

[0055] Batch numbers use a structured coding method, consisting of five fields concatenated sequentially, separated by underscores. The complete format of the batch number is: Environment Identifier_Release Type_Plug-in Identifier_Date and Time_Serial Number.

[0056] The specific definitions of each field are as follows: First field: Environment identifier This field identifies the runtime environment to which the plugin release belongs, using a two-letter code. Specific values ​​include: PR for production, ST for pre-release, TE for testing, and DE for development. This field helps operations personnel quickly identify the scope of impact of a release operation based on its number.

[0057] Second field: Posting type This field identifies the type of release and uses a two-letter code. Specific values ​​include: RL for regular releases, used for routine feature iterations and bug fixes; HF for hotfix releases, used for emergency online fixes; RF for rollback releases, used to revert plugins to previous versions; and BK for canary releases, used for small-scale pilot testing. This field helps operations personnel quickly identify the urgency and nature of the release operation.

[0058] Third field: Plugin ID This field identifies the released plugin, using an abbreviation of the plugin name consisting of three to six lowercase letters. For example, an authentication plugin might be coded as auth, a rate limiting plugin as rate, a logging plugin as log, and a monitoring plugin as monitor. This field helps operations personnel directly identify the specific plugin involved in this release from its identifier.

[0059] Fourth field: Date and time This field identifies the date and time the release request was initiated, using a 14-digit numeric encoding in the format YYYYMMDDHHMMSS. Here, YYYY represents the four-digit year, MM represents the two-digit month, DD represents the two-digit day, HH represents the two-digit hour (24-hour format), MM represents the two-digit minute, and SS represents the two-digit second. This field ensures that multiple release requests generated within the same second can be distinguished by the subsequent sequence number field, while also providing operations personnel with precise time information for the release operation.

[0060] Fifth field: Serial number This field is used to distinguish between multiple release requests within the same second. It uses a four-digit numeric code, with a value ranging from 0001 to 9999. The sequence number increments from 0001 every second. This field, in conjunction with the date and time field, ensures the uniqueness of the batch number globally.

[0061] A complete batch number example is shown below.

[0062] Example 1: PR_RL_AUTH_20260115143025_0001. This number indicates: production environment, regular release, authentication plugin, initiated at 14:30:25 on January 15, 2026, the first release request within that second.

[0063] Example 2: PR_HF_RATE_20260115221510_0003. This number indicates: production environment, hotfix release, rate limiting plugin, initiated at 22:15:10 on January 15, 2026, the third release request within that second.

[0064] Example 3: ST_RL_LOG_20260116093000_0001. This number indicates: pre-release environment, regular release, log plugin, initiated at 9:30:00 on January 16, 2026, the first release request within that second.

[0065] The batch number is automatically generated by the task creation module on the management side when responding to a plugin release request. The generation process is as follows: The task creation module first obtains the current system time and generates a date and time field in the format YYYYMMDDHHMMSS. Then, it queries the plugin release task table to see if a release record of the same environment and plugin type already exists within the current second. If it exists, it takes the current maximum sequence number and increments it by one; otherwise, it starts from 0001. The task creation module concatenates the fields into a complete batch number and then writes this number into the release task record at each node level.

[0066] The batch numbers generated using the above encoding rules have the following characteristics: First, global uniqueness; the combination of date, time, and sequence number ensures that no duplicate numbers will appear. Second, high readability; operations and maintenance personnel can understand the environment, type, plugins, and time information of the release simply by viewing the number. Third, easy retrieval; both management and operations and maintenance personnel can quickly filter and analyze the release history by environment, plugin identifier, or time period. Fourth, this number is used throughout the entire release process, from task creation, command issuance, node execution to callback reporting and status aggregation, serving as the core keyword for linking data at different stages.

[0067] Subsequently, the management console stores all node-level deployment task records into a pre-defined plugin deployment task table. Initially, the task execution status of each node-level deployment task record is set to "pending deployment".

[0068] The plugin release task table has the following field structure: The primary key field is a string type, used as a unique identifier for a single node-level task record, such as record-001 to record-050. The batch number field is a string type, used to associate all records under the same release batch, such as DEP-20260115-001. The node identifier field is a string type, used to identify the target gateway node, such as node-001. The plugin identifier field is a string type, used to identify the plugin to be released, such as auth-plugin. The plugin version number field is a string type, used to indicate the target version number of the plugin to be released, such as 2.2.0. The task execution status field is an enumeration type, with values ​​of pending deployment, deploying, successful, failed, failed delivery, or timed out. The failure reason field is a string type, recording specific error information when the task execution status is failed, failed delivery, or timed out. The creation time field is a timestamp type, recording the creation time of the node-level task record. The update time field is a timestamp type, recording the time of the most recent status update of the node-level task record.

[0069] Step S2: Asynchronous instruction issuance step.

[0070] The management console uses the scheduled inspection task scanning plugin to publish node-level deployment task records in the task table whose execution status is "pending deployment". These scheduled inspection tasks are executed periodically at preset time intervals, for example, every five seconds.

[0071] For each record to be deployed, the management terminal obtains the network address of the corresponding edge proxy module based on the node identifier in the record, and sends an update command to the edge proxy module through a preset command delivery interface. The update command carries the batch number, plugin identifier, and plugin version number corresponding to the record.

[0072] After sending an update command, the management terminal immediately updates the task execution status of the corresponding node-level published task record to "Deploying," without waiting for the edge agent module to return the execution result. Through this method, thread decoupling is achieved between the management terminal and the execution terminal. Once the command is successfully sent, the management terminal can release its current processing thread and switch to processing other records to be deployed or executing other management tasks.

[0073] Specifically, the management console uses an HTTP client to send requests to each edge proxy module in a non-blocking manner. The sending thread considers the instruction successfully issued upon receiving an HTTP 202 (accepted) response from the edge proxy module, then updates the task table status and processes the next record. The management console does not maintain a persistent connection for each request to wait for subsequent execution results.

[0074] If an update command fails to be sent, the management terminal immediately marks the task execution status of the corresponding node-level publish task record as "failed" and records the specific error information in the failure reason field. The failure scenarios include network connection timeout, unresponsive edge proxy module interface, and the edge proxy module returning an error status code. For example, when the management terminal sends an update command to node-025, if the TCP connection timeout is 30 seconds, and the management terminal catches a connection timeout exception, it marks the node's task execution status as "failed" and records the failure reason as "connection timeout." Similarly, if the edge proxy module of node-033 returns an HTTP 503 "service unavailable" response because its local task queue is full, the management terminal marks the node's task execution status as "failed" and records the failure reason as "edge proxy queue busy."

[0075] Step S3: Execute the steps locally on the edge node.

[0076] like Figure 2 As shown, this step specifically includes: After receiving the update command from the management terminal, the edge proxy module first performs deduplication verification. The edge proxy module maintains a local cache area to store recently received or completed batch numbers. This cache area can be implemented using an in-memory hash table structure, where the key is the batch number string and the value is the corresponding cache timestamp. The cache expiration time can be set to ten minutes, after which it is automatically cleaned up to prevent the cache from growing indefinitely.

[0077] When a new update instruction is received, the edge proxy module extracts the batch number from the instruction and queries it in the local cache. For example, if the edge proxy module receives an update instruction with batch number DEP-20260115-001, it queries the cache for this number. If the batch number already exists in the local cache, it means that the task has already been executed locally or is being executed. The edge proxy module discards the current instruction, does not execute it again, and returns an HTTP 200 success response to the management terminal. If the batch number does not exist in the local cache, the edge proxy module records the batch number in the local cache and writes the current update instruction to the tail of the local task queue.

[0078] The local task queue is a first-in, first-out (FIFO) queue. The edge agent module maintains a single thread that continuously retrieves tasks from the head of the local task queue and executes them sequentially according to the FIFO order. This sequential queue mechanism ensures that only one plugin update task is executed at a time, avoiding conflicts and corruption caused by multiple tasks concurrently modifying plugin directory files.

[0079] The local task queue has a capacity limit of one hundred. When the local task queue is full, the edge proxy module refuses to accept new update commands and returns a response message to the management terminal indicating that the queue is busy, such as an HTTP 503 status code. The response body includes a message that the queue is busy and to try again later.

[0080] When executing each plugin update task, the edge proxy module performs the following sub-steps in sequence: S3.1 File operation sub-steps.

[0081] The edge proxy module performs a full backup of the currently running plugin files. Specifically, the edge proxy module copies all files and subdirectories in the current plugin directory to a preset backup directory. The backup directory is named with the current timestamp or the batch number of the current task to ensure the traceability of the backup data and tasks.

[0082] For example, the authentication plugin directory for the Kong gateway is / usr / local / kong / plugins / auth, which contains twenty-three files, including init.lua, handler.lua, and schema.lua, as well as subdirectories. When performing a backup, the edge proxy module copies all contents of this directory to the backup directory / backup / plugin_auth_DEP-20260115-001_20260115_100523. After the backup is complete, the edge proxy module records the path to the backup directory for use during subsequent rollbacks.

[0083] After the backup is complete, the edge proxy module downloads the target version of the plugin package from the pre-defined plugin package storage repository based on the plugin identifier and version number in the update command. This plugin package is a compressed file, such as tar.gz. During the download, the edge proxy module retrieves the plugin package from the download address provided in the update command via an HTTP GET request. For example, the edge proxy module sends a download request to https: / / repo.example.com / plugins / auth-plugin-2.2.0.tar.gz and saves the plugin package to the local temporary file / tmp / auth-plugin-2.2.0.tar.gz.

[0084] After downloading, the edge proxy module extracts the plugin package to a local temporary directory. For example, the edge proxy module executes `tar -xzf / tmp / auth-plugin-2.2.0.tar.gz -C / tmp / plugin_auth_2.2.0` to extract the plugin package contents to the temporary directory ` / tmp / plugin_auth_2.2.0`. The extracted temporary directory contains all twenty-three files of the target version plugin.

[0085] After decompression, the edge proxy module performs the first integrity check. The plugin package pre-calculates the MD5 checksum of each file during distribution and stores the list of MD5 checksums as metadata within the plugin package; this metadata is typically included in the plugin package as a manifest file. The edge proxy module iterates through each file in the decompressed temporary directory, calculates the actual MD5 checksum for that file, and compares the actual MD5 checksum with the pre-recorded expected MD5 checksums one by one.

[0086] For example, a file named handler.lua in the temporary directory has an expected MD5 checksum of a1b2c3d4e5f678901234567890123456. The edge proxy module uses the MD5 message digest algorithm to calculate the actual MD5 checksum of handler.lua, obtaining a1b2c3d4e5f678901234567890123456, which matches the expected value. Therefore, the integrity check of this file passes. The edge proxy module performs the above comparison on all twenty-three files in the temporary directory sequentially. If the MD5 checksums of all files match, the first integrity check passes. If the MD5 checksum of any file does not match, the first integrity check fails.

[0087] After the first integrity check passes, the edge proxy module copies all files extracted from the temporary directory to the gateway's plugin directory, replacing the files corresponding to the old version of the plugin. For example, the edge proxy module executes `cp -r / tmp / plugin_auth_2.2.0 / / usr / local / kong / plugins / auth` to copy all twenty-three files to the plugin directory.

[0088] After the overwrite operation is complete, the edge proxy module performs a second integrity check. The second integrity check is performed in the same way as the first: it recalculates the MD5 checksum for each file in the plugin directory that has been overwritten and compares it one by one with the expected MD5 checksum to verify that the overwrite operation was complete and error-free. For example, the edge proxy module recalculates the MD5 checksum of ` / usr / local / kong / plugins / auth / handler.lua` and confirms that it is still `a1b2c3d4e5f678901234567890123456`, consistent with the expected value. It then continues to verify the MD5 checksums of the remaining twenty-two files in this directory.

[0089] If either the first or second integrity check fails, the edge proxy module immediately terminates the current update process and triggers a file rollback. The specific operation of the file rollback is as follows: all files in the backup directory are completely copied back to the gateway's plugin directory, overwriting any existing incomplete or corrupted files, thereby restoring the plugin directory to its complete state before the update. For example, when the second integrity check finds that the actual MD5 checksum of the file handler.lua is inconsistent with the expectation, the edge proxy module executes `cp -r / backup / plugin_auth_DEP-20260115-001_20260115_100523 / / usr / local / kong / plugins / auth / ` to copy all files in the backup directory back to the plugin directory, completing the rollback. After the file rollback is complete, the current update task is marked as failed, and the corresponding failure reason is recorded, such as the second integrity check failing or the MD5 checksum of the file handler.lua not matching. Then, the process jumps to the S3.5 result callback sub-step.

[0090] S3.2 Database migration sub-step.

[0091] In response to the successful completion of the second integrity check, the edge proxy module invokes the gateway's database migration command to execute database structure changes corresponding to the target plugin version.

[0092] Taking Kong Gateway as an example, the database migration commands include the database migration upgrade command `kongmigrationsup` and the database migration completion command `kongmigrationsfinish`. After the plugin directory is updated, the edge proxy module executes these two commands sequentially via command line or API. During execution, Kong Gateway automatically detects the differences between the current database version and the target plugin version, identifying the migration scripts that need to be executed.

[0093] The database migration instructions are executed using the gateway's native transaction mechanism. For a single migration script, if execution is successful, the transaction is committed; if execution fails, all database change operations involved in that script are automatically rolled back, ensuring that the database structure does not remain in an inconsistent state due to migration failure. For example, the authentication plugin in version 2.2.0 contains two database migration scripts: the first script adds the `token_expiry_seconds` field, and the second script creates an index. When the first script executes successfully and commits the transaction, the second script throws an exception due to an index name conflict. The gateway automatically rolls back all operations of the second script, but the field addition operations already committed by the first script remain unaffected. Because the migration scripts are idempotent, when operations personnel re-execute the migration after resolving the index name conflict, the gateway automatically skips the successfully executed first script and executes only the second script.

[0094] In database migration instructions, each migration script is executed within an independent database transaction. If a single migration script executes successfully, the transaction is committed; if it fails, all database change operations related to that script are automatically rolled back. The migration scripts are idempotent; scripts that have already been successfully executed are automatically skipped when executed again.

[0095] If the database migration sub-step fails, the edge agent module records the corresponding failure reason, such as migrationfailed: duplicatecolumnnametoken_expiry_seconds, and jumps to the S3.5 result callback sub-step.

[0096] S3.3 Configuration Update Sub-step.

[0097] The edge proxy module reads the gateway's configuration file and verifies whether the target plugin is enabled in the configuration file. Specifically, the edge proxy module searches the configuration file for a configuration block or item corresponding to the target plugin identifier.

[0098] Taking the Kong gateway as an example, its configuration file is ` / etc / kong / kong.conf`. Plugin configurations exist in the form of `plugins` fields and specific plugin configuration blocks. The edge proxy module reads this configuration file and searches for the configuration items corresponding to the authentication plugin. For example, it looks for the configuration section related to `auth-plugin` in the configuration file.

[0099] If the target plugin is not yet enabled, the edge proxy module appends the target plugin's configuration item to the corresponding location in the gateway configuration file according to the preset configuration template. For example, the authentication plugin in version 2.2.0 introduced a new configuration item `token_expiry_seconds`, and the edge proxy module appends the line `auth-plugin.token_expiry_seconds=3600` to the plugin configuration section of the configuration file. Simultaneously, the edge proxy module records the configuration change as changed in its local memory. This flag indicates whether a configuration append operation was performed in the current update task, allowing the module to determine whether the configuration file needs to be restored if a rollback is required.

[0100] If the target plugin is already enabled, the edge proxy module will not modify the configuration file, and the configuration change flag will remain unchanged.

[0101] S3.4 Service overload sub-step.

[0102] The edge proxy module calls the gateway's hot-reload command to load the updated plugin code and configuration files in a smooth restart manner.

[0103] Taking the Kong gateway as an example, the hot-reload command is `kongreload`. When the edge proxy module executes this command, the Kong gateway first starts new Worker processes. These new Worker processes load the updated plugin code and configuration, and begin accepting new incoming business requests. The existing old Worker processes in the gateway continue to process the existing in-transit traffic that is already being processed, without immediately terminating. After all existing connections have been processed, the old Worker processes automatically exit. For example, when performing hot reload, if the gateway currently has two hundred existing HTTP connections being processed, the old Worker processes continue to process these two hundred connections, while the new Worker processes begin to receive new incoming requests. After about thirty seconds, all existing connections have been processed, and the old Worker processes automatically exit. The entire hot reload process does not interrupt the gateway's business services, achieving seamless plugin updates.

[0104] If the hot reload command fails to execute, the edge agent module records the corresponding failure reason, such as kongreloadfailed:workerprocessstartuperror.

[0105] S3.5 Result Callback Sub-step.

[0106] After all sub-steps S3.1 to S3.4 above have been successfully executed, the edge proxy module reports a success status callback to the preset callback interface on the management side. The callback information is an HTTP POST request, and the request body contains the batch number, node identifier, execution status, and failure reason. When the execution status is "success," the failure reason field is empty.

[0107] If any sub-step from S3.1 to S3.4 fails, the edge proxy module terminates the current update process and reports the failure status callback information to the callback interface on the management side. This callback information carries the specific reason for the failure. For example, the execution status is "failed," and the reason for failure is "databasemigrationfailed: duplicatecolumnname."

[0108] Furthermore, the edge proxy module starts a timer when each plugin update task begins execution, monitoring the total execution time of the current task. When the total execution time exceeds a preset timeout threshold, the edge proxy module proactively terminates the currently executing task and reports the execution timeout status callback information to the management callback interface. The timeout threshold is five minutes, calculated from the start time of the task. For example, if the total execution time of a task reaches five minutes while the database migration sub-step is still in progress, the edge proxy module proactively terminates the sub-step, reporting the execution status as timeout and the failure reason as "taskexecutiontimeoutafter300seconds".

[0109] The callback information includes at least the batch number, node identifier, execution status, and failure reason. The execution status includes success, failure, and timeout.

[0110] After the callback information is reported, the edge proxy module clears the cache record corresponding to the batch number from the local cache to free up cache space and ensure that the cache record will not affect the receiving and judgment of subsequent new tasks.

[0111] Step S4: State aggregation and presentation steps.

[0112] After receiving the callback information reported by each edge agent module, the callback interface on the management side locates the corresponding node-level release task record in the plugin release task table based on the batch number and node identifier in the callback information.

[0113] For example, the management console's callback interface receives a callback message from node-018, where the batch number is DEP-20260115-001, the node identifier is node-018, and the execution status is "success". The management console queries the plugin deployment task table for the record with batch number DEP-20260115-001 and node identifier node-018, updates the task execution status of that record from the deployment to "success", and updates the update time field to the current timestamp.

[0114] After successful location, the management system updates the task execution status of the record to the execution status carried in the callback information. If the callback information includes a failure reason, the management system synchronously writes the failure reason into the failure reason field of the corresponding record. If a node fails to report any callback information after a command is successfully issued, the record corresponding to that node will remain in the deployment state, neither automatically judged as successful nor automatically judged as failed, thus ensuring that disconnected nodes are not mistakenly included in the success statistics.

[0115] When operations and maintenance personnel query the overall progress of a specific release batch through the management interface, for example, when viewing the progress of batch DEP-20260115-001, the management interface responds to the progress query request by statistically analyzing the task execution status distribution of all node-level release task records under that batch. Specifically, the management interface executes a database query to count the number of records in that batch with execution statuses of success, failure, failed release, timeout, and deployment in progress.

[0116] Based on the above statistical results, the management system generates the overall completion status for this batch. The overall completion status is determined according to the following rules: If the task execution status of all node-level task release records in this batch is successful, then the overall completion status is "fully successful". If there is any record in this batch with a task execution status of failure, delivery failure, timeout, or deployment in progress, then the overall completion status is "partially failed" or "in progress" accordingly.

[0117] The management interface presents the above statistical results and overall completion status to operations and maintenance personnel through a visual interface, allowing them to monitor the real-time progress of the entire cluster plugin updates and the list of failed nodes. For example, the management interface displays the status distribution of batch DEP-20260115-001 as follows: 46 successful, 1 failed, 2 failed to be deployed, and 1 in deployment, with an overall completion status of partial failure.

[0118] Step S5: Targeted retry step.

[0119] When a release batch contains nodes with execution status of failure, delivery failure, or timeout, the management interface displays a list of the corresponding failed nodes to operations personnel on the query interface. This list includes at least the node identifier, failure status, and reason for failure of the failed node.

[0120] For example, the operations and maintenance personnel see the list of failed nodes for batch DEP-20260115-001 on the management interface: node-007 is in the status of failure, the reason is migrationfailed: connectiontodatabasetimedout; node-025 is in the status of delivery failure, the reason is connection timeout; node-033 is in the status of delivery failure, the reason is edge agent queue busy; node-042 is in the status of deployment, the reason is not reported.

[0121] After troubleshooting and resolving the root cause of the failure, the operations and maintenance personnel initiate a retry operation for the current batch on the management interface. For example, after resolving the database connection problem, confirming that the network has returned to normal, and that the edge agent module queue has been cleared, the operations and maintenance personnel click the retry failed node button on the interface.

[0122] In response to this retry operation, the management console does not retry all nodes. Instead, it automatically extracts all node-level release task records from the plugin release task table that are in the batch with a failed execution status, failed delivery, or timed out. It then re-executes steps S2 to S3 only for the extracted records. In this example, the management console extracts four records from nodes node-007, node-025, node-033, and node-042, and re-issues update commands to these four nodes.

[0123] Nodes that have already successfully completed the retry are not included in the retry process. Through the above minimum failure set-oriented retry strategy, the management end only reissues update instructions to the abnormal nodes, and nodes that are already on the new version are no longer involved, thereby significantly reducing the business impact of retry operations.

[0124] During the retry process, each update command carries a specific plugin version number. Before execution, the edge proxy module checks its local cache for a historical execution record with the same batch number. If the cache is hit, it means the node has already executed the task for that batch, and the edge proxy module directly ignores the current retry command, avoiding issues such as file overwriting or secondary execution of the database migration script. For example, if node-018 receives an update command for batch DEP-20260115-001 again during the retry process, its edge proxy module checks its local cache and finds that the batch number already exists, directly returns a success response and discards the command, without re-executing file overwriting or service reload. This deduplication mechanism, combined with the idempotency design of the database migration script, together constructs a complete idempotency guarantee for the retry operation.

[0125] Example 2 like Figure 3 As shown, this embodiment provides a gateway plugin asynchronous deployment and cluster state synchronization system, which includes a management terminal and an edge proxy module deployed on each gateway node. In this embodiment, the management terminal is used to execute the methods described in steps S1, S2, S4, and S5 of Embodiment 1, and the edge proxy module is used to execute the methods described in step S3 of Embodiment 1.

[0126] The management terminal includes a task creation module, an instruction issuance module, a callback receiving module, a status aggregation module, and a retry triggering module.

[0127] The task creation module responds to plugin release requests by retrieving a list of all gateway nodes in the target cluster and generating a node-level release task record for each node to be updated in the target cluster. Each node-level release task record includes at least a node identifier, plugin identifier, plugin version number, and task execution status. The task creation module also generates a globally unique batch number for the current release request and writes this batch number into each node-level release task record to associate it with all node subtasks under the same release batch. Furthermore, the task creation module batch-inserts all node-level release task records into a preset plugin release task table, initially setting the task execution status of each record to "pending deployment."

[0128] The instruction delivery module retrieves node-level deployment task records with a pending deployment status from the plugin deployment task table via scheduled scanning or event triggering. For each pending deployment record, the instruction delivery module obtains the network address of the corresponding edge proxy module based on the node identifier in the record and sends an update instruction to the edge proxy module through a preset instruction delivery interface. The update instruction carries at least the batch number, plugin identifier, and plugin version number corresponding to the record. After sending the update instruction, the instruction delivery module does not wait for the execution result of the edge proxy module. If the update instruction is successfully sent, the instruction delivery module updates the task execution status of the corresponding node-level deployment task record to "Deploying". If the update instruction fails to send, the instruction delivery module marks the corresponding task execution status as "Deployment Failed" and records the reason for the failure.

[0129] The callback receiving module provides a preset callback interface to receive callback information reported by each edge proxy module. Upon receiving the callback information, the module locates the corresponding node-level release task record in the plugin release task table based on the batch number and node identifier in the callback information, and updates the task execution status of that record to the execution status carried in the callback information. If the callback information includes a failure reason, the module synchronously writes that failure reason into the failure reason field of the corresponding record.

[0130] The status aggregation module responds to progress query requests for any release batch initiated by operations personnel or the management interface, and statistically analyzes the task execution status distribution of all node-level release task records under that batch. Based on the statistical results, the status aggregation module generates the overall completion status of the batch. The rule for determining the overall completion status is: if the task execution status of all node-level release task records under that batch is successful, then the overall completion status is "all successful". If any record has a status of failure, delivery failure, timeout, or deployment in progress, then the overall completion status is "partially failed" or "in progress" accordingly.

[0131] The retry trigger module is used to respond to the retry operation initiated by the operation and maintenance personnel on the management interface. It extracts the node-level release task records of the batch of tasks whose execution status is failed, failed to be issued, or timed out from the plugin release task table, and resubmits the extracted records to the instruction issuance module to re-execute the issuance and execution process of the update instruction.

[0132] The edge proxy module includes a task queue unit, a deduplication caching unit, a file operation unit, a database migration unit, a configuration management unit, a service reload unit, and an execution control unit.

[0133] The task queue unit receives update instructions from the instruction issuing module and writes these instructions into a local task queue. The local task queue is a first-in, first-out (FIFO) queue. The task queue unit is also used by a single thread to retrieve tasks from the local task queue in FIFO order for serial execution. The local task queue has a capacity limit of one hundred. When the queue is full, the task queue unit refuses to receive new update instructions and returns a queue busy response to the management terminal.

[0134] The deduplication caching unit is used to extract the batch number from the update instruction received by the task queue unit and query it in the local cache. If the query finds a match, the deduplication caching unit instructs the task queue unit to discard the current instruction. If the query fails, the deduplication caching unit records the batch number in the local cache and then submits the instruction to the task queue. The deduplication caching unit also clears the corresponding batch number from the local cache after the execution control unit completes the callback reporting.

[0135] The file operation unit performs a full backup of the currently running plugin files to a preset backup directory. It also downloads the target version of the plugin package from a preset plugin package repository based on the plugin identifier and version number in the update instruction, and decompresses the plugin package to a local temporary directory. Furthermore, the file operation unit performs a first integrity check on each decompressed file. If the first integrity check passes, the files in the temporary directory are overwritten in the plugin directory. After overwriting, a second integrity check is performed on each file in the plugin directory. If either the first or second integrity check fails, the file operation unit terminates the current update process and triggers a file rollback, completely copying the files from the backup directory back to the plugin directory.

[0136] The database migration unit, in response to the successful completion of the second integrity check, invokes the gateway's database migration instructions to execute database structure changes corresponding to the target plugin version. These database migration instructions are executed using the gateway's native transaction mechanism, and automatically rollback occurs if a single migration script fails. The database migration unit also captures exceptions during the migration process and generates corresponding failure reasons.

[0137] The configuration management unit reads the gateway configuration file and verifies the enabling status of the target plugin in the file. If the target plugin is not enabled, the configuration management unit appends the corresponding plugin configuration item according to the preset configuration template and records the configuration change flag. If the target plugin is enabled, the configuration management unit does not modify the configuration file. The configuration management unit is also used to restore the configuration file to its state before the configuration append operation when the file operation unit triggers a file rollback and the configuration change flag indicates that this task has performed a configuration append operation.

[0138] The service reload unit is used to invoke the gateway's hot-reload instruction after the file operation unit, database migration unit, and configuration management unit have all executed successfully, to load the updated plugin code and configuration in a smooth restart manner. When the hot-reload instruction is executed, the gateway first starts a new Worker process to take over new business requests, and the original Worker process automatically exits after completing the processing of existing in-transit traffic.

[0139] The execution control unit starts a timer when each plugin update task begins execution, monitoring the total execution time of the current plugin update task. When the total execution time exceeds a preset timeout threshold, the execution control unit terminates the current task execution and generates an execution timeout status. The timeout threshold is five minutes. The execution control unit also generates corresponding execution status and failure reasons when the file operation unit, database migration unit, configuration management unit, and service reload unit all execute successfully, or when any of the above units fail or time out, and reports these to the callback receiving module of the management end via a callback interface. The execution status includes success, failure, or timeout.

[0140] Example 3 This embodiment uses an open banking API gateway cluster of a fintech company as an application scenario to illustrate the specific implementation process of the technical solution of this invention. This gateway cluster is built on the Kong gateway and consists of fifty gateway nodes distributed across two availability zones. Each node has an edge proxy module pre-deployed. The operations and maintenance personnel need to upgrade a certain authentication plugin from version 2.1.0 to version 2.2.0.

[0141] The operations and maintenance personnel upload the version 2.2.0 plugin package to the management interface, fill in the plugin identifier as auth-plugin, the version number as 2.2.0, select all fifty nodes as the target cluster, and click the publish button. The management interface responds to this publish request, generates a batch number DEP-20260115-001, and inserts fifty node-level publish task records into the plugin publish task table, initializing the task execution status of each record to pending deployment.

[0142] The management terminal's scheduled scanning task executes every five seconds. Upon detecting a record to be deployed, the command delivery module sequentially sends update commands to fifty edge proxy modules. Because the delivery process is asynchronous, the management terminal completes the sending of all fifty commands within approximately two seconds, unaffected by the actual execution time of each edge node. Forty-eight edge proxy modules return an HTTP 202 (accepted) response, indicating the corresponding record is being updated to "deployment in progress." The remaining two nodes, node-025 and node-033, experienced command delivery timeouts due to network jitter, while node-033 returned an HTTP 503 response due to a full local task queue. These two records are marked as delivery failures, with the reasons recorded as connection timeout and edge proxy queue busy, respectively.

[0143] Forty-eight edge agent modules that normally receive instructions enter their local execution processes. Taking node-001 as an example, after receiving the update instruction, the edge agent module on this node first checks its local deduplication cache. Confirming that batch number DEP-20260115-001 is not in the cache, it writes the batch number to the cache and then writes the instruction to the local task queue. Since there are no other tasks waiting to be executed in the queue, a single thread immediately retrieves the task and begins execution.

[0144] During execution, the file operation unit first performs a full backup of the current version 2.1.0 authentication plugin files, backing them up to the directory / backup / plugin_auth_2.1.0_20260115_100523. Then, the file operation unit downloads the version 2.2.0 plugin package from the plugin package repository and decompresses it to the temporary directory / tmp / plugin_auth_2.2.0. In the first integrity check, the MD5 checksums of all twenty-three files in the temporary directory match the expected values. The file operation unit then copies these twenty-three files to the Kong gateway's plugin directory / usr / local / kong / plugins / auth. After the overwrite is complete, the second integrity check again performs an MD5 comparison on the twenty-three files in the plugin directory, and all matches.

[0145] The database migration unit then executed the `kongmigrationsup` and `kongmigrationsfinish` commands sequentially. Upon inspection, version 2.2.0 contained two database migration scripts, both of which executed successfully sequentially under the transaction mechanism.

[0146] The configuration management unit reads Kong's configuration file, ` / etc / kong / kong.conf`, and checks the configuration block of the authentication plugin. Since version 2.2.0 of the authentication plugin introduced a new configuration item, `token_expiry_seconds`, the configuration management unit appends this item to the plugin configuration section of the configuration file and records the configuration change as changed.

[0147] The service reload unit executes the kongreload command. Upon receiving the reload command, the Kong gateway starts a new Worker process to load the plugin code version 2.2.0. The old Worker processes exit within approximately thirty seconds after processing the existing connections. Throughout the entire reload process, the gateway's external services were not interrupted.

[0148] After all the above sub-steps were completed, the execution control unit recorded the total execution time as one minute and forty-seven seconds, which did not exceed the five-minute timeout threshold. Therefore, it reported a success status callback to the management terminal's callback interface, including the batch number DEP-20260115-001, the node identifier node-001, and the status "success". After the callback information was reported, the deduplication caching unit cleared the cache record for that batch number.

[0149] The remaining 47 nodes that normally received the instructions executed a similar process. Of these, 46 nodes eventually reported successfully, while node-007 failed to report due to a database connection error during the database migration process. The reason for the failure was migrationfailed: connectiontodatabasetimedout.

[0150] The callback receiving module on the management end receives the above callback information one by one and updates the status of the corresponding record in the plugin release task table in sequence. When the operation and maintenance personnel query the overall progress of batch DEP-20260115-001 on the management end, the status aggregation module counts the status distribution of the fifty records under this batch: forty-six records are in the status of success, one record is in the status of failure, two records are in the status of delivery failure, and one record is in the status of deployment. The node in the deployment status is node-042, which is a disconnected node that has issued instructions but has never reported callback information.

[0151] Based on the statistical results, the operations and maintenance personnel first investigated the database connection issue. After restoring the database connection, they clicked the "Retry Failed Nodes" button on the management console. The retry trigger module extracted four records from the task table with statuses of "Failed," "Deployment Failed," and "Deploying," namely nodes node-007, node-025, node-033, and node-042. The update command was only reissued to these four nodes. The forty-six nodes that had already succeeded did not participate in the retries. After the retry command was issued, all four nodes successfully completed the update and reported a success status. At this point, all fifty nodes in batch DEP-20260115-001 had successfully upgraded to version 2.2.0, and the status aggregation module displayed an overall completion status of "All Successful."

[0152] Example 4 This embodiment provides a detailed explanation of the concurrency control and deduplication mechanism for the local task queue of the edge proxy module.

[0153] In a real-world production environment, operations and maintenance personnel may initiate multiple plugin version release tasks in a short period of time, or initiate new retry operations before the original instructions have finished executing during the same batch of retry operations. Both of these scenarios can lead to the same edge proxy module receiving multiple update instructions within a short timeframe.

[0154] In this invention, the local task queue of the edge proxy module adopts a first-in-first-out (FIFO) queue structure, coupled with a single-threaded consumption mechanism, to ensure that multiple update instructions are processed serially locally. Taking a certain edge node as an example, suppose that at a certain moment, three update instructions are written sequentially into the local task queue of this node, corresponding to the retry instructions of batches DEP-20260115-001, DEP-20260115-003, and DEP-20260115-001, respectively.

[0155] A single thread retrieves the first instruction from the head of the queue and begins execution; this instruction corresponds to batch DEP-20260115-001. During the execution of this instruction, subsequent instructions wait in the queue, and no plugin directory operations are performed. Only after the first instruction has been fully executed, callback reporting has been completed, and the deduplication cache has been cleared, does the single thread retrieve the second instruction from the queue and begin execution.

[0156] Before the second instruction begins execution, the deduplication cache unit verifies its batch number. Since batch DEP-20260115-003 differs from batch DEP-20260115-001, which is no longer in the cache, the deduplication check fails, and the instruction executes normally. When the third instruction is retrieved for execution, it also corresponds to batch DEP-20260115-001. The deduplication cache unit finds that this batch number already exists in the cache, a record written at the entry point of step S3 during the first execution. Although it was cleared after the first execution, if a retry instruction was written to the queue before the first execution and has not yet been executed, the batch number still exists in the cache, indicating that the task is either not yet complete or is in progress. In this case, the deduplication cache unit instructs the task queue unit to discard the retry instruction to prevent the same node from executing repeatedly in the same batch.

[0157] By combining the above-mentioned serial queue mechanism with the deduplication caching mechanism, this invention effectively avoids the file corruption problem that may be caused by multiple tasks concurrently modifying the plugin directory, and at the same time eliminates the potential threat to node stability caused by repeatedly executing the same task.

[0158] Example 5 This embodiment illustrates the protective effect of the integrity verification and automatic rollback mechanism in this invention under abnormal scenarios.

[0159] Suppose that during a plugin release process, the edge proxy module backed up the old version of the plugin, with the backup directory being / backup / plugin_auth_DEP-20260115-001_20260115_100523. Subsequently, the new version of the plugin package was downloaded and extracted; the first integrity check passed, and the file overwrite operation was completed. However, during the second integrity check, the edge proxy module discovered that the MD5 checksum of a dynamic link library file, libauth.so, in the plugin directory was inconsistent with the expected value. The expected MD5 checksum was e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0, while the actual calculated MD5 checksum was a1b2c3d4e5f678901234567890123456.

[0160] This inconsistency could be caused by a variety of reasons, including disk write errors during the overwrite process resulting in some bytes not being written correctly, other processes modifying the file simultaneously during the overwrite process, or unexpected changes to the file system during the temporary storage of the plugin package after decompression. Regardless of the reason, the failure of the second integrity check means that the current plugin directory is in an incomplete or incorrect state.

[0161] In this abnormal scenario, the file operation unit in this invention immediately terminates the current update process, ceasing subsequent steps such as database migration, configuration updates, and service reload, thereby preventing the erroneous file state from spreading to the database and service processes. Simultaneously, the file operation unit triggers a file rollback mechanism, executing `cp -r / backup / plugin_auth_DEP-20260115-001_20260115_100523 / / usr / local / kong / plugins / auth / ` to completely copy all old version files from the backup directory back to the plugin directory, overwriting the currently problematic `libauth.so` file and other potentially affected files. After the rollback is complete, the plugin directory is restored to its pre-update state.

[0162] Subsequently, the execution control unit reports a failure status to the management terminal, stating that the second integrity check failed due to a mismatch in the MD5 hash of the file libauth.so. Upon receiving this failure information, the management terminal updates the task status of the node to "failed" and records the specific reason. Maintenance personnel can then learn through the management terminal interface that the node failed to complete the update due to the file integrity check failure and, after troubleshooting disk or network issues, can initiate a retry for that node individually.

[0163] Through the above design, the present invention ensures that even if file-level anomalies occur during the update process, the node will not remain in a semi-updated abnormal state where some files have been updated and some files have not been updated. Instead, it will always be in either the complete state before the update or the complete state after the update, possessing the atomicity property of either all or nothing.

[0164] Example 6 This embodiment compares and illustrates the effectiveness of the minimum failure set-oriented retry strategy in a large-scale cluster with the existing full retry scheme.

[0165] Using the 50-node cluster scenario from Example 3, assume that in a single deployment task, 46 nodes successfully complete the update, node-007 fails due to database migration, nodes-025 and-033 fail to issue commands due to network issues, and node-042 becomes unreachable and fails to report due to a process restart. There are a total of four abnormal nodes.

[0166] Under the existing full retry solution, after fixing the problem, operations personnel need to re-initiate update commands on all fifty nodes. At this point, the forty-six nodes that were successfully updated will again undergo the complete process of file download, decompression and overwriting, database migration, and service reload. While Kong gateway's kongreload hot reload operation does not interrupt business operations, the startup of new Worker processes and the exit of old Worker processes still consume system CPU and memory resources. During peak business periods, simultaneous or staggered reload operations on all fifty nodes can cause overall performance fluctuations in the gateway cluster, with a 100% impact on business operations.

[0167] Under the minimum failure set-oriented retry strategy of this invention, the retry triggering module automatically extracts four records with task execution statuses of failure, delivery failure, and deployment in progress, and only re-issues update instructions to the four abnormal nodes: node-007, node-025, node-033, and node-042. The forty-six nodes that have already been successfully updated do not participate in the retries at all, and no additional file downloads, decompression, or service reload operations are generated.

[0168] From a business impact perspective, the proposed solution affects only four nodes, representing an 8% impact. Compared to the 100% impact of a full retry solution, this invention reduces the impact by 92 percentage points. As the cluster size increases, the improvement in effectiveness becomes even more significant if only a small number of nodes fail. For example, in a 500-node cluster, if only five nodes fail, the impact of this solution is 1%, while a full retry solution achieves 100%, reducing the impact by 99 percentage points.

[0169] Furthermore, from a retry security perspective, this invention ensures through a deduplication caching mechanism that even if a retry command is repeatedly sent to a successfully executed node, the edge proxy module of that node will automatically ignore the command due to a cache hit, preventing duplicate execution. Compared to the full retry scheme, which requires maintenance personnel to manually judge and filter failed nodes, this mechanism has significant advantages in both security and ease of use.

[0170] Example 7 This embodiment provides a detailed description of the pseudocode implementation logic in the edge proxy module to further disclose the technical details of the present invention.

[0171] The entry processing logic of the edge proxy module is as follows: The edge proxy module receives update commands from the management terminal via an HTTP interface, the URL of which is ` / agent / plugin / update`. The received request body contains the deployment batch number, cluster identifier, plugin identifier, plugin version number, and a security token issued by the management terminal. Upon receiving the request, the edge proxy module first verifies the validity of the security token in the request to confirm that the request originates from a legitimate management terminal. If token verification fails, an HTTP 401 Unauthorized response is returned.

[0172] After successful token verification, the edge proxy module checks whether the deployment batch number in the current request already exists in the local cache. If the batch number already exists in the cache, it directly returns an HTTP 200 success response to the management end and discards the request. The response body contains the message "repeat task".

[0173] If the batch number does not exist in the cache, the edge proxy module checks the current length of the local task queue. If the queue length has reached the capacity limit of one hundred, it returns an HTTP 503 service unavailable status code to the management terminal, with the response message "Queue busy, please try again later".

[0174] If the queue length has not reached the upper limit, the edge proxy module writes the current update instruction to the tail of the local task queue, records the batch number in the local cache, and records the task status as "deploying" in the local persistent storage. It then returns an HTTP 202 (accepted) response to the management console, indicating that the management console can continue processing other tasks.

[0175] The core execution flow of the edge proxy module is as follows: After retrieving a task from the local task queue, the edge proxy module generates a deployment identifier for that execution. This deployment identifier is a globally unique string, such as deploy-20260115-100523. A timeout timer is then set for five minutes.

[0176] The edge proxy module first calls its internal download function based on the plugin identifier and version number to download the target version of the plugin package from a pre-defined plugin package repository. The download function retrieves the plugin package via an HTTP GET request. If a network error occurs during the download process or a status code other than 200 is returned, the download function returns an empty value. If the download function returns an empty value, it indicates that the download has failed, and a download failure exception is thrown with the message "DownloadFailed".

[0177] After successful download, the edge proxy module calls the backup function to perform a full backup of the current plugin environment. The backup includes at least all files in the plugin directory and the current configuration state. The backup function returns the path to the backup directory. After the backup is complete, the edge proxy module unzips the downloaded plugin package to a temporary directory.

[0178] After decompression, the edge proxy module iterates through each file in the temporary directory, calculates its MD5 checksum, and compares it with the expected MD5 checksum recorded in the temporary directory. During the comparison, if the MD5 checksum of any file is inconsistent, a verification failure exception is thrown with the message "VerificationFailed".

[0179] After all files pass MD5 verification, the edge proxy module copies the files from the temporary directory to the gateway's plugin directory, replacing the old versions. After the overwrite is complete, the edge proxy module performs another MD5 check on the files in the plugin directory to verify the integrity of the overwrite result. If verification fails, a verification failure exception is thrown.

[0180] After all file operations are successful, the edge proxy module checks whether the gateway configuration file already contains the target plugin's configuration items. This is done by reading the configuration file content and using regular expressions to match the target plugin's configuration blocks. If not found, the target plugin's configuration items are appended to the configuration file, and a flag indicating that the configuration has changed is set to true.

[0181] After configuration confirmation, the edge proxy module executes the database migration and upgrade command and the database migration completion command in sequence, followed by the gateway reload command. Once all three commands are executed successfully, the status of the current task is updated to success in the local persistent storage.

[0182] If an exception is thrown at any of the above stages, the edge proxy module captures the exception and records the exception message. Then, it executes rollback logic: if a backup directory exists, all files in the backup directory are copied back to the gateway's plugin directory, overwriting the current files. If the configuration change flag is true, the configuration file is restored to its state before being appended. After the rollback is complete, the current task's status is updated to failure in local persistent storage, and the corresponding failure reason is recorded.

[0183] In the final step, regardless of whether the task succeeds or fails, the edge proxy module calls the callback reporting function to report the execution result of the current task to the callback interface of the management end. The callback reporting function only reports the execution result of the current node itself and does not report any information about other nodes in the cluster. After reporting is completed, the edge proxy module clears the record of the current batch number from its local cache.

[0184] The key design considerations in the above pseudocode implementation are as follows: At the core architecture level, this invention adopts an asynchronous and decoupled design. The entry interface only performs authentication and task enqueueing operations and immediately returns an accepted response. Time-consuming plugin update operations are all executed in background coroutines, effectively avoiding HTTP request timeouts. The entire process is state-driven, tracking the entire process status through records in the database to achieve eventual consistency. At the security mechanism level, this invention adopts a backup-before-modification strategy, forcibly performing a full backup before overwriting files to ensure rollback under any failure scenario. MD5 verification forms a closed loop, performing comparison after decompression and re-checking after overwriting, doubly ensuring file integrity and preventing file corruption caused by partial overwriting. At the cluster coordination level, a single edge agent module only reports the execution results and failure reasons of its own node and does not hold task data for the entire cluster. Global judgment is completed in real time by the management end when querying task progress. The management end aggregates the status of all nodes in the same batch, and only considers the batch task to be completed when all nodes are successful, ensuring cluster version consistency. The task table of the management end is the only authoritative source of status, and the edge agent module only makes a copy record locally. The final status is based on the data of the management end after the callback update.

[0185] The embodiments described above are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for asynchronous deployment of gateway plugins and synchronization of cluster status, characterized in that, include: Task building and storage steps: In response to the plugin release request, the management end generates node-level release task records for each node to be updated in the target cluster and stores them in the task table. A unified batch number is assigned to the same release batch. Each record contains at least the node identifier, plugin identifier, plugin version number and task execution status. Asynchronous command issuance steps: The management terminal retrieves records with a status of "to be deployed" from the task table, and issues an update command containing batch number, plugin identifier and version number to the corresponding edge node. If the issuance is successful, the update status is "deployment in progress"; if it fails, it is marked as issuance failure. Local execution steps at edge nodes: Edge nodes write received update commands into a local task queue, which is then executed serially by a single thread. Task execution includes file operations, database migration, configuration updates, and service reload. After completion, the execution status is reported to the management terminal. Specifically, the file operation steps include: fully backing up the current plugin files to a backup directory; downloading and decompressing the target version plugin package to a temporary directory; performing a first integrity check on the decompressed files, and overwriting them in the plugin directory if the check passes; performing a second integrity check on the overwritten files; if either check fails, a file rollback is triggered, and the backup directory files are completely copied back to the plugin directory. Database migration involves calling the gateway's database migration command to perform database structure changes corresponding to the target plugin version. The configuration update steps include: reading the gateway configuration file, verifying the target plugin's enabling status, and if not enabled, appending the corresponding plugin configuration items according to the preset configuration template and recording the configuration change flag. During file rollback, if the configuration change flag indicates that configuration appending has been performed, the configuration file is restored to its state before appending. Service reload involves calling the gateway's hot-reload command to load the updated plugin code and configuration file in a smooth restart manner. Status aggregation and presentation steps: The management end updates the task table based on the callback information; in response to the progress query request, it counts the status of each node under the batch and generates the overall completion status; Targeted retry steps: The management side responds to the retry operation by retrieving records with statuses of failure, timeout, or delivery failure from the task table, and only re-executes the instruction delivery and local execution steps for the retrieved records.

2. The method for asynchronous deployment of gateway plugins and synchronization of cluster status according to claim 1, characterized in that, The batch number adopts a structured coding method, which is composed of five fields in sequence: environment identifier, release type, plugin identifier, date and time, and sequence number. The environment identifier is used to identify the runtime environment to which the release belongs, the release type is used to identify the release type, the plugin identifier is used to identify the released plugin, the date and time is used to identify the time when the release was initiated, and the sequence number is used to distinguish multiple release requests within the same second.

3. The method for asynchronous deployment of gateway plugins and synchronization of cluster status according to claim 1, characterized in that, The database migration step calls the gateway's database migration command to perform database structure changes. The migration command relies on the gateway's native transaction mechanism and is idempotent. If a single migration script fails to execute, it will be automatically rolled back. If a migration script that has already been successfully executed is executed again, it will be automatically skipped.

4. The method for asynchronous deployment of gateway plugins and synchronization of cluster status according to claim 1, characterized in that, After receiving an update instruction, the edge node first extracts the batch number and queries it in the local cache. If it already exists, the current instruction is discarded. If it does not exist, the batch number is recorded in the cache and then the instruction is written to the local task queue.

5. The method for asynchronous deployment of gateway plugins and synchronization of cluster status according to claim 1, characterized in that, When a task begins execution, the edge node starts a timer to monitor the total execution time. If the timeout threshold is exceeded, the current task execution is terminated, and the execution timeout status and failure reason are reported to the management terminal.

6. The method for asynchronous deployment of gateway plugins and synchronization of cluster status according to claim 1, characterized in that, The rules for determining the overall completion status are as follows: if all nodes in a batch are in a successful state, the overall status is considered fully successful; if there are records of failure, delivery failure, timeout, or deployment in progress, the overall status is considered partially failed or in progress.

7. The method for asynchronous deployment of gateway plugins and synchronization of cluster status according to claim 1, characterized in that, When the hot-load command is executed, the gateway first starts a new working process to take over the new service request, and the original working process automatically exits after completing the processing of the existing traffic in transit, so as to achieve uninterrupted plugin updates.

8. A gateway plugin asynchronous deployment and cluster state synchronization system, characterized in that, The system is used to implement the method of claim 1, and the system includes a management terminal and an edge proxy module deployed on each gateway node; The management module includes: a task creation module, used to generate node-level deployment task records in response to plugin release requests and store them in the task table, assigning a unified batch number to the same batch; an instruction issuance module, used to retrieve the records to be deployed from the task table and issue update instructions to the edge agent module; a callback receiving module, used to receive callback information and update the status of the corresponding records in the task table; a status aggregation module, used to respond to progress query requests to count the batch status and generate the overall completion status; and a retry triggering module, used to respond to retry operations to extract failed records and resubmit them to the instruction issuance module. The edge proxy module includes: a task queue unit, used to receive update instructions and write them to the local task queue, executed serially by a single thread; a file operation unit, used to back up plugin files, download and verify the target version plugin package, and trigger file rollback when verification fails; a database migration unit, used to call the gateway migration command to perform database structure changes; a configuration management unit, used to verify and update plugin configuration items; a service reload unit, used to call the gateway hot reload command to load the updated code and configuration; and an execution control unit, used to monitor task execution time and terminate execution when timeout, and report the status and failure reason to the callback receiving module after successful execution or termination.

Images