Dynamic updating method and device and storage medium

Abstract

The invention discloses a dynamic updating method and device and a storage medium. The method comprises the steps that a dynamic updating configuration instruction is received through a graphical user interface; generating a standardized dynamic update file based on the dynamic update configuration instruction; analyzing the standardized dynamic update file, and determining a target server and a target process to be updated according to an analysis result; establishing a communication connection with the target server, obtaining an update state of the target process through the communication connection, and judging whether the target process can execute an update operation or not based on the update state; and if the target process can execute the update operation, sending the update instruction content to the target process through the communication connection to execute a dynamic update operation. According to the method, the standardized file is generated through graphical configuration, the instruction is automatically sent based on update state judgment after analysis, update automation and accurate control are achieved, human errors are reduced, and update efficiency and reliability are improved.

Description

Technical Field

[0001] This application relates to the field of online game update technology, and in particular to a dynamic update method, device and storage medium. Background Technology

[0002] With the continuous expansion of online games, the number of server clusters and game processes has increased dramatically, and the rapid iteration of gameplay has led to increasingly frequent maintenance and update needs. Against this backdrop, non-stop dynamic updates to distributed servers have become a routine but crucial operational task. Traditional update methods heavily rely on manual operation by maintenance personnel. Typically, operators need to identify target servers and processes one by one, manually write update command files, upload the update files to the respective server directories via file transfer tools, and finally manually trigger the update execution. This series of operations is not only tedious and time-consuming, but also carries the risk of human error at multiple stages, such as syntax or coding errors in the update file, omissions or duplicates of execution servers or processes, etc. These errors can range from minor issues like update failures requiring retrying to serious problems like service anomalies affecting the stable operation of the game.

[0003] Therefore, how to transform the traditional dynamic update process, which relies heavily on personal experience and manual operation, into a standardized, automated, and efficient method that can effectively avoid human error has become a pressing technical problem.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a dynamic update method, device and storage medium, which aims to solve the technical problems of error-prone and inefficient manual dynamic updates of existing server clusters.

[0006] To achieve the above objectives, this application proposes a dynamic update method, which includes: The system receives dynamic update configuration instructions via a graphical user interface, the dynamic update configuration instructions including the target scope and execution control. A standardized dynamic update file is generated based on the dynamic update configuration instructions. The standardized dynamic update file includes a unique identifier and update instruction content. The standardized dynamic update file is parsed, and the target server and target process to be updated are determined based on the parsing results. Establish a communication connection with the target server, obtain the update status of the target process through the communication connection, and determine whether the target process can perform an update operation based on the update status; If the target process is capable of performing an update operation, the update instruction content is sent to the target process through the communication connection to control the target process to perform a dynamic update operation.

[0007] In one embodiment, the step of parsing the standardized dynamic update file and determining the target server and target process to be updated based on the parsing result includes: The parsing results are used to extract matching features, and the corresponding matching strategy is determined according to the type of the matching features. The matching strategy includes the setting of matching accuracy and matching range. According to the matching strategy, the target server and target process corresponding to the matching feature are determined, wherein the corresponding target server is determined according to the matching strategy, a matching range is defined among the target servers, and the target process is determined within the defined matching range.

[0008] In one embodiment, after parsing the standardized dynamic update file and determining the target server and target process to be updated based on the parsing result, the method further includes: Extract the update instruction content from the parsing results and determine the expected update version carried by the update instruction content; Obtain the current version information and resource usage status of the target process, perform a compatibility analysis between the expected update version and the current version information, and determine whether there is a compatibility risk based on the analysis results; If there is a compatibility risk, a version alert will be generated and the update process will be paused; If there is no compatibility risk, the target process is determined to meet the update execution conditions based on the resource occupancy status. If the target process meets the update execution conditions, the step of establishing a communication connection with the target server is executed.

[0009] In one embodiment, after the step of determining whether the target process meets the update execution conditions based on the resource occupancy status if there is no compatibility risk, the method further includes: When it is determined that the target process does not meet the update execution conditions, a resource scheduling instruction is generated based on the data volume of the update instruction content; The resource scheduling instruction is sent to the target server so that the target server pre-allocates the required resources for the target process. After receiving the resource readiness confirmation information from the target server, the step of establishing a communication connection with the target server is executed.

[0010] In one embodiment, before the step of sending the update instruction content to the target process via the communication connection to control the target process to perform a dynamic update operation, the method further includes: Count the number of target processes involved in the update instruction; If there are multiple target processes, determine the update status of each target process; When it is determined that all target processes can perform update operations based on their update status, the step of sending the update instruction content to the target processes through the communication connection is executed to control the target processes to perform dynamic update operations.

[0011] In one embodiment, after the step of sending the update instruction content to the target process via the communication connection to control the target process to perform a dynamic update operation, the method further includes: In response to feedback that the target process has completed the update, predefined smoke test cases are sent to the target process to verify the core functions of the target process; Obtain the execution results based on the smoke test cases, and determine the updated performance metrics and log information of the target process from the execution results; The performance metrics and log information are compared and analyzed with the baseline data before the update, and the update effect of the target process is confirmed based on the analysis results. If the update result is confirmed to be correct, a convergence confirmation command is sent to the target process so that the target process can switch to the new version to provide services.

[0012] In one embodiment, the step of sending the update instruction content to the target process via the communication connection to control the target process to perform a dynamic update operation includes: The historical update records of the target process are obtained through the communication connection, and the update failure rate of the historical update records is calculated. If the update failure rate is greater than a preset failure rate threshold, a heartbeat detection mechanism and a status confirmation mechanism are added to the update instruction content and sent to the target process.

[0013] In one embodiment, if the update failure rate is greater than a preset failure rate threshold, after the step of adding a heartbeat detection mechanism and a status confirmation mechanism to the update instruction content and sending them to the target process, the method further includes: During the execution of the update instruction, the health indicators and update progress of each target process are obtained at preset intervals through the heartbeat detection mechanism; If any target process is detected to have an abnormal health indicator or a stalled update progress, a partial rollback operation is automatically triggered to restore the target process to its pre-update state, while sending a continue execution instruction to other target processes besides the target process. Record information about the abnormal target process and the rollback results, generate an anomaly report containing repair suggestions, and feed it back to the graphical user interface.

[0014] In addition, to achieve the above objectives, this application also proposes a dynamic update device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the dynamic update method as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the dynamic update method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: The technical solution of this application receives dynamic update configuration instructions through a graphical user interface. These instructions include a target scope and execution control. A standardized dynamic update file is generated based on the instructions, comprising a unique identifier and update instruction content. The standardized dynamic update file is parsed to determine the target server and target process to be updated based on the parsing results. A communication connection is established with the target server to obtain the update status of the target process and determine whether the target process can perform the update operation based on the update status. If the target process can perform the update operation, the update instruction content is sent to the target process through the communication connection to control the target process to perform the dynamic update operation. This application achieves automated and precise control of updates by generating standardized files through graphical configuration, parsing them, and automatically sending instructions based on the update status, reducing human error and improving update efficiency and reliability. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the dynamic update method of this application; Figure 2This is a detailed step diagram based on step S30 in the first embodiment; Figure 3 This is a detailed step diagram based on step S50 in the first embodiment; Figure 4 This is a flowchart illustrating the second embodiment of the dynamic update method of this application; Figure 5 This is a flowchart illustrating the third embodiment of the dynamic update method of this application; Figure 6 This is a flowchart illustrating the fourth embodiment of the dynamic update method of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the dynamic update method in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution of this application embodiment is as follows: receiving a dynamic update configuration instruction through a graphical user interface, the dynamic update configuration instruction including a target scope and execution control; generating a standardized dynamic update file based on the dynamic update configuration instruction, the standardized dynamic update file including a unique identifier and update instruction content; parsing the standardized dynamic update file, determining the target server and target process to be updated based on the parsing result; establishing a communication connection with the target server, obtaining the update status of the target process through the communication connection, and determining whether the target process can perform the update operation based on the update status; if the target process can perform the update operation, sending the update instruction content to the target process through the communication connection to control the target process to perform the dynamic update operation.

[0024] In existing technologies, when manually performing dynamic updates to a server, the reliance on manually writing instructions, specifying targets, and uploading files can easily lead to coding errors, missing or duplicate targets, resulting in low efficiency and poor reliability of the update operation.

[0025] This application provides a solution that receives configuration instructions through a graphical interface and generates standardized update files. After parsing, the target server and process are accurately determined. Based on the real-time determination of the process update status, the instructions are automatically sent to the target that can be updated. This achieves standardization and condition-triggered automation of the entire process, significantly reduces human error, improves the accuracy and overall efficiency of update execution, and ensures the reliability of server-side updates.

[0026] Based on this, the embodiments of this application provide a dynamic update method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the dynamic update method of this application. In this embodiment, the dynamic update method includes steps S10 to S50: Step S10: Receive a dynamic update configuration instruction through a graphical user interface. The dynamic update configuration instruction includes a target range and execution control. In this embodiment, the graphical user interface (GUI) serves as the entry point for user interaction with the dynamic update system. It structurally receives and encapsulates the user's update intent, forming dynamic update configuration instructions that can be precisely processed by subsequent processes. The GUI typically manifests as a desktop application or web page containing multiple dedicated input controls. Through the GUI, the user first selects or inputs the target scope, which defines the update's domain. This update scheme includes two levels: server scope and process scope. Specifically, the server scope can be specified through preset server groups, manually entered IP address lists, or fuzzy matching rules based on hostname patterns (such as "GS*"). The process scope is further limited within the selected server scope and can be determined by selecting the process type (such as the game logic process "GameServer" or the database process "DBServer") or directly specifying a list of process identifiers (PIDs).

[0027] In addition to the target scope, users also need to set execution control parameters through the interface. These parameters determine the update execution strategy and constraints. Typical execution control parameters include, but are not limited to: planned execution time window, used to specify the specific time or period at which the update is allowed to be triggered; concurrent execution level, controlling how many target processes are sent update instructions simultaneously; and retry strategy, defining the number of retries and intervals when the update instruction fails to be sent or executed. After completing the filling and selection of all necessary parameters, the user submits by clicking the "Generate" or "Confirm" button on the interface. At this time, the logic layer behind the interface will perform validity checks on all input data, such as checking the IP address format, confirming the logic of the time window, and verifying the existence of the process type. After the verification is successful, the system serializes all the parameters entered by the user and encapsulates them into a structured data object, namely the dynamic update configuration instruction. The dynamic update configuration instruction serves as a bridge connecting user intent and automated execution process; its completeness and accuracy directly affect the reliability of all subsequent steps.

[0028] Step S20: Generate a standardized dynamic update file based on the dynamic update configuration instruction. The standardized dynamic update file includes a unique identifier and update instruction content. Upon receiving the dynamic update configuration command, the system needs to convert the displayed data into a standardized intermediate representation that can be stably parsed and transmitted by different modules, namely the standardized dynamic update file. The first step in generating this file is to generate a globally unique identifier, namely the unique identifier. The algorithm for generating the unique identifier must ensure its uniqueness within the system's lifecycle or a very long period of time. This is typically achieved using an algorithm based on a combination of timestamps, machine identifiers, and random numbers (such as a UUID-like algorithm), or by utilizing a distributed sequence generation service with strictly monotonically increasing characteristics. This unique identifier will serve as the unique identity credential for this update task, persisting throughout the entire process of subsequent parsing, execution, status tracking, and logging.

[0029] Next, based on the dynamically updated configuration instructions, the update instruction content is constructed to provide a technical description of the user's specific update operation. The format and syntax of this technical description need to be predefined according to a set of specifications, typically a structured code block or script paragraph, possibly written in a domain-specific language (DSL) or a standard scripting language (such as Lua or Python code snippets). The system converts the user's intent (such as modifying a configuration parameter or hot-loading a new functional module) into instruction text conforming to the specified specifications. During the generation process, template engine population may be involved, i.e., pre-setting instruction templates containing placeholders and replacing these placeholders according to the specific parameters in the configuration instructions.

[0030] Finally, the unique identifier, the update instruction content, and metadata extracted from the configuration instructions (such as author, creation time, target scope summary, execution control parameters, etc.) are organized according to a predefined encapsulation format. Common encapsulation formats include JSON, XML, or a custom binary format. The encapsulation process ensures the self-descriptive nature of the data, enabling any parser capable of understanding the encapsulation format to accurately extract the various parts. The generated standardized dynamic update file will be persistently stored in a file system or database, with the storage path or index key typically associated with the unique identifier for retrieval and reading in subsequent steps.

[0031] Step S30: Parse the standardized dynamic update file and determine the target server and target process to be updated based on the parsing results; In this embodiment, the purpose of parsing the standardized dynamic update file is to accurately extract the information necessary to drive the update execution and thereby locate the specific physical or logical execution entity. The parsing process begins by reading the file's storage medium and decoding it according to the encapsulation format specification. For example, if the file is in JSON format, a JSON parser is used to load the entire file content and convert it into a structured object in memory. The parser first extracts the unique identifier to establish the context of this parsing task.

[0032] The key data processing logic focuses on extracting and understanding the target of the update instruction from the file content, i.e., determining the target server and target process to be updated. The parsing module needs to process the definition of the target scope, locating the fields describing the server and process scope from the structured data. For server scopes, if an IP list is specified, the IP list is directly parsed; if a group name or fuzzy matching rule is specified, the parsing module needs to call or query a configuration management database (CMDB) that maintains server topology information, expanding the logical name or rule into a specific list of server network addresses. This process may involve network calls and caching mechanisms to improve efficiency.

[0033] Based on the obtained list of specific servers, the process scope is further parsed. The parsing module performs matching calculations based on the process type specified in the instruction (such as "All" or "GameServer") or the specific list of process identifiers, combined with the process list information obtained from the target servers in real time or near real time. For example, a lightweight process information query request can be sent to each target server, or a centralized process status management service can be queried to obtain the list of currently running processes on the server and their attributes (such as type and PID). Subsequently, the parsed process scope rules are applied for filtering, ultimately identifying one or more specific processes on each target server as the target processes. The output of this step is a clear mapping relationship: the update task corresponding to the unique identifier needs to be sent to which specific processes (PID or unique handle) on which specific servers (IP:Port). The accuracy and robustness of the parsing directly determine the precision of the update action, avoiding erroneous or missed updates. Step S40: Establish a communication connection with the target server, obtain the update status of the target process through the communication connection, and determine whether the target process can perform an update operation based on the update status; In this embodiment, after identifying the target server and target process, an update command is not sent immediately. Instead, a communication connection is first established and the real-time state of the target process is assessed, which serves as the basis for a security decision on whether to perform the update. Based on the target server's network address, a network communication connection is initialized, typically using TCP or a reliable connection based on an application layer protocol (such as HTTP / HTTPS, or a custom RPC protocol). After the connection is established, the system sends a status query request to the proxy service on the target server or directly to the target process through the channel of the established connection.

[0034] When acquiring the update status, the update status is a multi-dimensional health snapshot, which includes at least: the process's runtime state (e.g., running, sleeping, zombie), resource utilization (e.g., CPU usage, memory usage, disk I / O), and specific contextual states related to this update task (e.g., whether a critical transaction is being processed, whether an update with the same unique identifier has already been applied). The server or the process itself collects this information and returns it to the control end through the communication connection.

[0035] Subsequently, the system executes decision logic based on the update status. This decision logic is typically implemented as a set of configurable rules or strategies. For example, a typical decision rule might be: "Only when the process status is 'running,' CPU utilization is below 70%, memory availability is above 20%, and the update has not been applied before, is it determined that an update operation can be performed." The decision engine compares the received status data with these preset rules and calculates a Boolean decision result for each target process. This process may involve complex logical operations, such as requiring all conditions to be met simultaneously (AND) or some conditions to be met (OR). The decision logic is designed to avoid prematurely executing updates when processes are under high load, unstable, or during critical business periods, thereby reducing the risk of service interruptions or failures.

[0036] Step S50: If the target process is capable of performing an update operation, the update instruction content is sent to the target process through the communication connection to control the target process to perform a dynamic update operation.

[0037] In this embodiment, after the determination logic confirms that the target process can perform the update operation, it executes the final instruction issuance and triggering action. The control terminal sends an execution command to the target process through the established communication connection. The payload of the execution command is the update instruction content parsed from the standardized file. To ensure the reliability of transmission, this transmission process usually includes an application-layer confirmation mechanism, such as a request-response model, waiting for the target process to return a "command received successfully" confirmation response.

[0038] Upon receiving the update instruction, the target process initiates its internal dynamic update executor, which is responsible for safely applying the update without restarting the process. This specific implementation varies depending on the technology stack and may include: interpreting and executing an embedded script; loading a new dynamic link library (DLL / SO) and replacing the old function pointers; or modifying critical configuration data structures in memory. During execution, the process must ensure the atomicity of the operations and the possibility of rollback, for example, by backing up the old state before applying the new code or by making configuration changes within transaction boundaries.

[0039] After sending the command, the control end does not completely abandon the process. It typically starts a monitoring coroutine or sets a callback to listen for the execution result returned by the target process. The result may include "execution successful," "execution failed," and specific error codes. In some implementations, the control end may also require the target process to report a brief verification result after the update is complete, such as the new version number or verification output for a specific feature.

[0040] The above completes the final closed loop from decision-making to action, ensuring that precise update instructions are delivered and triggered only when the environmental conditions meet safety requirements. This improves the level of automation while ensuring the overall stability and reliability of the update operation.

[0041] Furthermore, you can also view Figure 2 , Figure 2 This is a detailed step diagram based on step S30 in the first embodiment. Figure 2 The steps of parsing the standardized dynamic update file and determining the target server and target process to be updated based on the parsing results include S31-32: Step S31: Extract matching feature items from the parsing results, and determine the corresponding matching strategy according to the type of the matching feature items. The matching strategy includes matching accuracy and matching range settings. Step S32: According to the matching strategy, determine the target server and target process corresponding to the matching feature item, wherein the corresponding target server is determined according to the matching strategy, a matching range is defined among the target servers, and the target process is determined within the defined matching range.

[0042] After successfully loading and decoding the standardized dynamic update file, the parsing module obtains a structured data object as the parsing result. The core data processing logic of step S31 is to intelligently extract and classify key information for target positioning from this result, namely the matching feature items, and dynamically adapt the corresponding positioning strategy accordingly. The matching feature items are mainly divided into two levels: server matching feature items and process matching feature items. Server matching feature items are key information used to identify the target server. The key information may exist in various forms, such as: a specific list of IP addresses (e.g., ["192.168.1.101", "192.168.1.102"]), a logical server group name (e.g., "East China Zone 1 Cluster"), or a hostname pattern based on wildcards (e.g., "prod-webserver-*"). Process matching feature items are key information used to filter specific processes on the target server. Common forms are process type names (e.g., "GameLogic", "Database") or specific process identifier ranges (e.g., "PID: 1000-2000").

[0043] By using a pre-defined matching strategy decision table, different types of features are mapped to corresponding matching strategies. The matching strategy is defined by two core dimensions: matching precision and matching range setting. Matching precision determines whether the interpretation of a feature is "precise" or "fuzzy." For example, for a list of IP addresses, the system applies an "exact match" strategy; for group names or hostname patterns, it applies a "fuzzy match" strategy. The matching range setting defines the boundaries of the search and filtering. At the server level, the range setting might mean "search only within data center A"; at the process level, the range setting might mean "search only within processes identified by user 'game'."

[0044] Specifically, a target determination process is executed based on the matching strategy determined for each feature. First, the target server is determined according to the server matching features and the matching strategy. If the strategy is exact matching, the IP list in the feature is directly used as the target server address set. If the strategy is fuzzy matching, the system calls an external configuration management database service, using the group name or hostname pattern as the query condition, and requests a list of network addresses of all servers that meet the condition, thereby converting the logical description into physical addresses.

[0045] After obtaining the list of physical target servers, the system performs process matching for each target server. Based on process matching characteristics and the set matching strategy, the matching range is narrowed down on the target servers. For example, if the matching strategy is "exact matching by type," the system obtains a list of all processes and their metadata on the server through the communication connection or by querying the process status service, filtering out processes whose process type attributes are exactly the same as the characteristics to form an initial candidate set. If the matching strategy includes a range setting (such as "match only processes with memory usage greater than 1GB"), a range filter is further applied to this candidate set.

[0046] Finally, within the defined matching range, the final target processes are determined. This may involve using all filtered processes directly, or it may require final selection based on additional rules (such as "selecting the three processes with the lowest load").

[0047] The above content demonstrates the intelligent and strategy-based transformation from user-friendly, potentially ambiguous and logical configuration descriptions to precise, executable physical target addresses and process identifiers. This is the key technological foundation for achieving accurate and targeted updates. Furthermore, you can also view Figure 3 , Figure 3 This is a detailed step diagram based on step S50 in the first embodiment. Figure 3The steps of sending the update instruction content to the target process through the communication connection to control the target process to perform dynamic update operations include S51-52: Step S51: Obtain the historical update records of the target process through the communication connection, and calculate the update failure rate of the historical update records; Step S52: If the update failure rate is greater than a preset failure rate threshold, add a heartbeat detection mechanism and a status confirmation mechanism to the update instruction content and send them to the target process.

[0048] In this embodiment, a risk assessment and dynamic enhancement step based on historical data is introduced before the final issuance of the update instruction. An observable data source for update operations is established and utilized to quantify the update stability of the target process. The system maintains a centralized update execution record database, where each record is associated with a specific update attempt. Key fields include: the unique identifier of the target process (e.g., combining server IP and process PID), the unique identifier of the corresponding standardized dynamic update file, the update initiation timestamp, and the final execution status (success, failure, and failure reason classification). When it is necessary to obtain the historical update records of the target process, the control terminal sends a request through the communication connection, or more commonly, to an independent operation and maintenance data query service, using the unique identifier of the target process as the query key, to retrieve all relevant update records within a certain time window (e.g., the most recent 30 days or the most recent 50 times).

[0049] The core of the data processing logic is to statistically analyze these historical records and calculate the update failure rate. The update failure rate is a specific metric, and its calculation formula needs to be predefined. A typical calculation method is: Failure Rate = (Number of records with a "Failed" status / Total number of records within the query time window) * 100%. During the statistical process, failures can be weighted or differentiated based on the cause, for example, failures due to insufficient resources and failures due to code errors can be treated with different weights. The calculated failure rate is a reliability indicator reflecting the past update success rate of the process.

[0050] Furthermore, instruction sending strategies are differentiated based on risk assessment results. Specifically, one or more preset failure rate thresholds are defined, which can be configured according to process type and business importance (e.g., the threshold for core database processes is set to 5%, and the threshold for ordinary application processes can be set to 15%). The calculated update failure rate is then compared with the applicable thresholds.

[0051] If the update failure rate is not greater than the preset failure rate threshold, the update risk of the target process is considered to be within an acceptable range, and the system will send the update instruction content according to the original procedure. Conversely, if the update failure rate is greater than the threshold, the target process is determined to be a "high-risk update target," and an enhanced monitoring and protection mechanism needs to be activated. In this case, the system will not send the original update instruction content, but will instead encapsulate and enhance the update instruction content.

[0052] The aforementioned enhancements primarily involve adding heartbeat and status confirmation mechanisms to the instruction payload. Technically, "adding" means that when constructing the final data packet sent to the target process, in addition to containing the original update operation code, a series of control flags and configuration parameters are set in the data packet's metadata header or a specific structure. Specifically, the addition of the heartbeat detection mechanism manifests as an explicit requirement in the update instruction content that the target process, during the execution of the update instruction, must report the indicated "health indicators" and "update progress" to the control terminal or monitoring service at specified time intervals (e.g., every 2 seconds). The addition of the status confirmation mechanism involves breaking down an update operation that might have been completed in one step into several explicitly acknowledgable milestone steps, and requiring the target process to wait for and receive a "continue execution" confirmation instruction from the control terminal after completing each milestone before proceeding to the next step.

[0053] Subsequently, a composite instruction packet integrating enhanced monitoring mechanisms is sent to the target process via the communication connection. The receiving and execution logic on the target process side also needs to synchronously support the interpretation and response to these new mechanisms. Through the above technical content, an evolution from "uniform, indiscriminate sending" to "differentiated, strongly monitored sending based on historical risk profiles" has been achieved, which plays a crucial role in improving the update success rate of processes with high failure propensity and enabling early detection and intervention of problems.

[0054] Furthermore, if the update failure rate is greater than a preset failure rate threshold, after adding a heartbeat detection mechanism and a status confirmation mechanism to the update instruction content and sending them to the target process, the method further includes: During the execution of the update instruction, the health indicators and update progress of each target process are obtained at preset intervals through the heartbeat detection mechanism; If any target process is detected to have an abnormal health indicator or a stalled update progress, a partial rollback operation is automatically triggered to restore the target process to its pre-update state, while sending a continue execution instruction to other target processes besides the target process. Record information about the abnormal target process and the rollback results, generate an anomaly report containing repair suggestions, and feed it back to the graphical user interface.

[0055] In this embodiment, after sending an update command integrating an enhanced monitoring mechanism to a high-risk target process, an active and continuous process monitoring phase is entered. The core of this process monitoring phase is to use the heartbeat detection mechanism to perform fine-grained observation of the command execution process and automatically execute remedial measures when deviations from expectations are detected.

[0056] The monitoring phase begins during the execution of the update command. The control unit or a dedicated monitoring service, based on preset parameters in the command, proactively initiates query requests to each target process at preset intervals (e.g., every 5 seconds), or listens for periodic reports from the processes. The health metrics typically include real-time process-level data such as CPU utilization, memory usage, handle count, and thread status, as well as application-level metrics such as request processing latency and error rate. The update progress is a scalar or vector used to measure the completion of the update operation itself, which may be represented as the percentage of completed tasks, the amount of data migrated, or a list of successfully loaded new modules. The system obtains these metrics and progress data through lightweight remote procedure calls (RPC) or by querying monitoring endpoints embedded in the target processes.

[0057] Furthermore, the acquired real-time data is compared with a set of predefined normal baseline ranges to perform anomaly detection. Anomalies in health indicators are typically defined as any key indicator consistently exceeding a threshold (e.g., CPU utilization >90% for more than three consecutive detection cycles). Stagnant update progress is defined as the progress value failing to show any quantifiable increase within two or more consecutive detection intervals. The detection logic is implemented as a separate rule engine that continuously evaluates the incoming monitoring data stream.

[0058] Once the rules engine detects that any target process meets the conditions of abnormal health indicators or stalled update progress, it will immediately and automatically trigger the partial rollback operation, thereby isolating and restoring the single problematic process without affecting other processes that are performing updates normally. Technically, the rollback trigger signal is sent to the abnormal target process. The process's internal preset rollback logic is activated. This logic relies on a specific state snapshot or backup (such as a memory data snapshot, temporary file backup, or reference to old version code) created before the update instruction was executed. The rollback operation loads this snapshot, restoring the process's code segment or data state to the exact state before the update began, ensuring that the process's service functions can continue. Simultaneously, the control terminal explicitly sends a continue execution instruction or an uninterrupted confirmation signal to all other target processes in normal state, ensuring that they are not affected by a single faulty node and can continue to complete or maintain the update.

[0059] Throughout the monitoring and remediation process, logging and report generation are performed synchronously. All operations, including the time of anomaly detection, affected process information (server IP, process ID), specific anomaly indicators, triggered rollback operations, and the results of the rollback operations (success or failure and the reason), are structured and recorded in the event log database. Based on these records, the report generation module extracts key events, analyzes them in conjunction with a knowledge base (such as common causes and solutions for specific error codes), and automatically generates an anomaly report. This anomaly report not only includes a factual description but also appends system inferences or predefined remediation suggestions (e.g., "Process memory overflow; it is recommended to check for memory leaks in the update script and increase the JVM heap size"). Finally, this report is pushed via API or status update and displayed prominently on the corresponding update task overview page or alarm panel for review and subsequent processing by operations personnel.

[0060] Reference Figure 4 , Figure 4 This is a flowchart illustrating the second embodiment of the dynamic update method of this application. In this embodiment, after parsing the standardized dynamic update file and determining the target server and target process to be updated based on the parsing result, steps S60-90 are further included: Step S60: Extract the update instruction content from the parsing result and determine the expected update version carried by the update instruction content; Step S70: Obtain the current version information and resource usage status of the target process, perform a compatibility analysis between the expected update version and the current version information, and determine whether there is a compatibility risk based on the analysis results; Step S80: If there is a compatibility risk, generate a version alert and pause the update process; Step S90: If there is no compatibility risk, determine whether the target process meets the update execution conditions based on the resource occupancy status. If the target process meets the update execution conditions, execute the step of establishing a communication connection with the target server.

[0061] In this embodiment, after the parsing module completes the decoding of the standardized dynamic update file and extracts the list of target servers and target processes, it does not immediately attempt to establish a communication connection. Instead, it inserts a critical pre-verification stage to preemptively eliminate the risk of update failure from both the perspectives of version consistency and system resource sufficiency.

[0062] First, the update instruction content is located and extracted from the parsing results. This update instruction content is a structured data block containing a field specifically designed to identify the application state expected to be achieved by this update—the expected update version. The expected update version follows predefined encoding rules, typically a combination of major version number, minor version number, and revision number (e.g., "v2.1.3"), or a hash value containing a build timestamp. The parsing engine obtains this information by reading specific keys (e.g., "target_version") within the content block or by parsing metadata comments in the instruction code. Simultaneously, the system uses existing management interfaces or agents to query the server where the target process resides to obtain the current version information of the target process. This is typically achieved by calling the version query API provided by the process, reading version resources from the process's binary file, or querying the process's registration information in the configuration management database.

[0063] After obtaining the version information from both parties, the compatibility analysis is performed. This analysis is driven by a compatibility rule engine. The engine loads predefined compatibility policies, which exist in the form of rule tables or decision trees. The core of the analysis is comparing the expected update version with the current version information. Typical rules include: only allowing updates to be applied to processes within a specific major version number range (forward / backward compatibility checks); or requiring the minor version number to be greater than the current version (i.e., only upgrades are allowed, downgrades are prohibited). Furthermore, the analysis may extend to checking implicit dependencies, such as whether the shared library versions depended on by the expected version are compatible with the target server environment. After applying all relevant policies, the rule engine outputs a deterministic analysis result, indicating whether the compatibility risk exists. For example, if an update package marked as only compatible with v2.0+ is applied to a process running version v1.0, the engine determines that a compatibility risk exists.

[0064] If a compatibility risk is identified, a structured version alert will be generated immediately. The alert will contain at least the following information: the target process identifier that triggered the alert, the current version, the expected update version, and a detailed description of the compatibility conflict (e.g., "major version mismatch"). After generating the alert, the system will set the status of this update task to "paused" and prevent any subsequent communication connection establishment and command sending steps. The alert will be pushed to the monitoring dashboard and the graphical user interface via the system's event bus and / or message queue, typically appearing as a highlight or pop-up to remind maintenance personnel or developers to intervene manually.

[0065] If no compatibility risk is determined, a resource threshold verification is performed. First, the real-time resource usage status of the target process is obtained. This is achieved by sending a lightweight resource query command to the target server. The returned data typically includes: the current memory size used by the target process, CPU time slice percentage, number of open file descriptors, and the overall server load average (e.g., Load Average). Subsequently, the system makes a judgment based on a set of preset update execution condition rules. These rules define the minimum resource threshold and stability requirements for executing the update, such as "process memory usage must be less than 80% of the indicated limit," "the 15-minute average load of the server must be less than 5.0," and "disk space remaining must be greater than twice the size of the update package." The system compares the obtained resource usage status data item by item with these conditions.

[0066] The system determines that the target process meets the update execution conditions only when all conditions are met. At this point, the system continues to execute the subsequent step of "establishing a communication connection with the target server". If any condition is not met, the update process will be paused here, and resource waiting or resource scheduling processes may be triggered (as described in the previous embodiments). Through steps S60 to S90, the system implements dual security checks before the update operation, discovering and avoiding runtime failure risks caused by version mismatch and resource contention as early as possible, thereby improving the success rate and predictability of the entire dynamic update process.

[0067] Furthermore, after the step of determining whether the target process meets the update execution conditions based on the resource occupancy status if there is no compatibility risk, the method further includes: When it is determined that the target process does not meet the update execution conditions, a resource scheduling instruction is generated based on the data volume of the update instruction content; The resource scheduling instruction is sent to the target server so that the target server pre-allocates the required resources for the target process. After receiving the resource readiness confirmation information from the target server, the step of establishing a communication connection with the target server is executed.

[0068] When the resource threshold rules mentioned above determine that the current resource occupancy status of the target process does not meet the update execution conditions, the update process will not terminate directly or enter an infinite wait. Instead, an automated resource pre-allocation sub-process will be activated. The resource pre-allocation sub-process aims to dynamically adjust the target server environment to create the necessary resource conditions for the update operation to be executed.

[0069] Specifically, the first step in this update process can generate resource scheduling instructions based on quantified requirements, which requires precise calculation of the amount of system resources that the target process needs to add or reserve to execute this update. To this end, the data volume and operational complexity are extracted or estimated from the update instruction content. Specifically, the type and structure of the update instruction content are analyzed: if the update instruction contains new modules or data files to be loaded, the total size of the new modules or data files is calculated; if the instruction involves data migration or reconstruction in memory, it is calculated based on the estimated memory increment declared in the metadata. The data processing logic typically involves a resource demand prediction model. This model outputs a resource demand prediction value based on the type of update instruction (e.g., "configuration update," "code hot replacement," "data migration"), historical resource consumption records of similar updates, and the specific parameters of the current update instruction content. This prediction value includes the required increase in heap memory size, temporary disk space, network bandwidth quota, etc. Based on this prediction, the system generates a structured resource scheduling instruction that details the resource type, required amount, and expected allocation period in a machine-readable format (such as JSON or YAML). (For example, pre-allocate 2GB of heap memory for process PID 1234 and keep it available for the next 10 minutes.)

[0070] Subsequently, the resource scheduling command is sent to the target server. This communication is not sent to the target process itself, but rather to a resource management daemon or cluster resource coordinator with higher privileges running on the target server (e.g., a custom Agent or a Kubernetes kubelet). The sending process typically uses a secure, authenticated RPC call through a dedicated management channel independent of subsequent update communications. The command explicitly identifies the target process that will benefit (by process PID or container ID) and requests resource reservation at the server level. For example, in a containerized environment, the command might request updating resource limits for the Pod running the target process; on a traditional server, it might request dynamically adjusting resource quotas for process groups through mechanisms such as cgroups.

[0071] Upon receiving the instruction, the resource manager on the target server attempts to perform an allocation operation in the indicated local resource pool. This may involve allocating resources from the shared pool, adjusting the limits of other low-priority processes, or even temporarily expanding virtual resources. Upon successful operation, the resource manager sends a resource readiness confirmation message to the control terminal. This message confirms that the requested resource has been successfully reserved and bound to the target process, and typically includes a session ID or lease credential for this resource allocation. The control terminal continuously listens for this confirmation message; until it receives it, the update task remains in the "waiting for resources" state.

[0072] Upon successfully receiving the resource readiness confirmation information, the resource obstacle is considered cleared, and the conditions for update execution are met. Only then will the control unit continue with the original step of "establishing a communication connection with the target server," thus advancing subsequent status checks and command sending processes. Through this series of processes, intelligent and automated responses to resource shortage scenarios are achieved, transforming a potentially failed update operation into a controlled resource allocation and subsequent execution, improving the adaptability and success rate of the update process in complex and dynamic environments.

[0073] Reference Figure 5 , Figure 5 This is a flowchart illustrating the third embodiment of the dynamic update method of this application. In this embodiment, before the step of sending the update instruction content to the target process through the communication connection to control the target process to perform the dynamic update operation, steps S100-120 are included: Step S100: Count the number of target processes involved in the update instruction content; Step S110: If there are multiple target processes, determine the update status of each target process; Step S120: When it is determined that all target processes can perform update operations based on the update status of each target process, the step of sending the update instruction content to the target process through the communication connection to control the target process to perform dynamic update operations is executed.

[0074] In this embodiment, before executing the final action of sending the update instruction content to the target process via the communication connection, when the update task involves multiple execution entities, the system introduces a coordination and synchronization phase to ensure batch consistency and atomicity of the update operation. This is achieved by counting the number of target processes involved in the update instruction content and, based on the final target mapping list generated during the parsing process, traversing the list to calculate the total number of unique process identifiers.

[0075] If statistical results indicate that there are multiple target processes, the update status of each target process is determined in parallel or rapidly serially. The key difference in this update status is that the purpose is to establish a unified, instantaneous state snapshot for all target processes, rather than making independent decisions for individual processes. Multiple established or temporarily established communication connections are used to concurrently send status query requests to each target process. To improve efficiency and reduce latency, these status query requests are typically sent asynchronously with a unified collection timeout window. Status data returned by each target process is collected, including runtime health, resource usage, and whether it is in an acceptable update quiet period.

[0076] After obtaining the status feedback from all target processes, a comprehensive judgment is made. The judgment engine compares the status data of each process with the preset "executable update" rule set. Only when the independent judgment result of each target process is "able to execute the update operation" is a global positive conclusion of "all can execute". This judgment logic ensures the consistency of update conditions. If the status of any target process does not meet the conditions (such as a process with excessive load), the global judgment is negative, the update process will pause the update step, and may trigger a waiting or alarm mechanism for the specific process. The system will only trigger the subsequent sending step when it is determined that all target processes can execute the update operation based on the update status of each target process. At this time, the control end may use broadcast, multicast, or parallel unicast to send the update instruction content to all target processes almost simultaneously through various communication connections, thereby realizing the synchronous start of multi-process updates and avoiding the problem of inconsistent service status due to differences in execution timing.

[0077] Reference Figure 6 , Figure 6 This is a flowchart illustrating the fourth embodiment of the dynamic update method of this application. In this embodiment, after the step of sending the update instruction content to the target process through the communication connection to control the target process to perform the dynamic update operation, the method further includes steps S130-160: Step S130: In response to the feedback information that the target process has completed the update, a predefined smoke test case is sent to the target process in order to verify the core functions of the target process; Step S140: Obtain the execution result based on the smoke test case, and determine the updated performance indicators and log information of the target process from the execution result; Step S150: Compare and analyze the performance indicators and log information with the baseline data before the update, and confirm the update effect of the target process based on the analysis results. Step S160: If the update result is confirmed to be correct, a convergence confirmation instruction is sent to the target process so that the target process can switch to the new version to provide services.

[0078] In this implementation, after controlling the target process to perform a dynamic update operation, a post-update verification and state convergence phase is entered to objectively evaluate the update effect and safely complete the service switchover. Specifically, the process is initiated after receiving feedback information (usually a message containing an execution result code and an end timestamp) indicating that the target process has completed the update, via monitoring links or proactive reporting by the process.

[0079] Subsequently, predefined smoke test cases are sent to the target process. These test cases are a series of automated test scripts or request sequences pre-designed for the core functional interfaces of the process type. The content of these test cases is stored in a test case library and associated with the process type or update characteristics. The corresponding test instructions are retrieved from the library and assembled, and then sent to the target process or an associated test driver module via a dedicated test channel or multiplexed management communication connection.

[0080] Subsequently, the target process executes the received test cases and returns the execution results (including request / response data, pass / fail status, and internal error logs) as well as real-time performance metrics (such as interface response time and throughput) and system log information generated during the execution process. After obtaining this raw data, the system parses and extracts it, and structurally determines the key performance metrics and log information that characterize the updated state from the result stream.

[0081] Next, a comparative analysis of the effects is conducted. The performance metrics and log information extracted after the update are compared with the corresponding benchmark data collected before the update or retrieved from the benchmark library. The comparative analysis may involve numerical comparison (e.g., whether the response time is within ±10% of the benchmark value), pattern checking (e.g., whether new exception types appear in the error log), and functional correctness verification (e.g., whether the test case pass rate reaches 100%). A rule analysis engine comprehensively evaluates the analysis results based on preset quality standards (e.g., all performance metric fluctuations are within the allowable range and all core test cases pass), thereby confirming whether the update effect of the target process has achieved the expected results.

[0082] If the analysis confirms that the update effect meets expectations (i.e., "error-free"), the system will send a critical convergence confirmation instruction to the target process. This convergence confirmation instruction is a formal authorization signal, instructing the target process to execute the final switchover action. Upon receiving the convergence confirmation instruction, the target process performs operations such as completely switching traffic to the new version code, clearing old version backups, and updating its publicly declared service version number, thereby officially providing services with the new version. This step establishes a controlled gate between "update complete" and "service ready," ensuring that only validated and effective updates are ultimately enabled, completing closed-loop management of the entire dynamic update lifecycle.

[0083] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the dynamic update method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0084] This application provides a dynamic update device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the dynamic update method in Embodiment 1 above.

[0085] The following is for reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing the dynamic update device in the embodiments of this application. The dynamic update device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 7 The dynamically updated device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0086] like Figure 7 As shown, the dynamic update device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the dynamic update device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the dynamic update device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows dynamic update devices with various systems, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0087] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0088] The dynamic update device provided in this application, employing the dynamic update method described in the above embodiments, can solve the technical problems of error-prone and inefficient manual dynamic updates of existing server clusters. Compared with the prior art, the beneficial effects of the dynamic update device provided in this application are the same as those of the dynamic update method provided in the above embodiments, and other technical features of the dynamic update device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0089] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0090] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0091] This application provides a storage medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the dynamic update method in the above embodiments.

[0092] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0093] The aforementioned computer-readable storage medium may be included in the dynamically updated device; or it may exist independently and not be assembled into the dynamically updated device.

[0094] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the dynamic update device, enable the dynamic update device to implement the technical content of the dynamic update method embodiment shown above.

[0095] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0096] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0097] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0098] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described dynamic update method. This solves the technical problem that manual dynamic updates of existing server clusters are prone to errors and are inefficient. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the dynamic update method provided in the above embodiments, and will not be repeated here.

Claims

1. A dynamic update method, characterized in that, The dynamic update method includes the following steps: The system receives dynamic update configuration instructions via a graphical user interface, the dynamic update configuration instructions including the target scope and execution control. A standardized dynamic update file is generated based on the dynamic update configuration instructions. The standardized dynamic update file includes a unique identifier and update instruction content. The standardized dynamic update file is parsed, and the target server and target process to be updated are determined based on the parsing results. Establish a communication connection with the target server, obtain the update status of the target process through the communication connection, and determine whether the target process can perform an update operation based on the update status; If the target process is capable of performing an update operation, the update instruction content is sent to the target process through the communication connection to control the target process to perform a dynamic update operation.

2. The dynamic update method as described in claim 1, characterized in that, The steps of parsing the standardized dynamic update file and determining the target server and target process to be updated based on the parsing results include: The parsing results are used to extract matching features, and the corresponding matching strategy is determined according to the type of the matching features. The matching strategy includes the setting of matching accuracy and matching range. According to the matching strategy, the target server and target process corresponding to the matching feature are determined, wherein the corresponding target server is determined according to the matching strategy, a matching range is defined among the target servers, and the target process is determined within the defined matching range.

3. The dynamic update method as described in claim 1, characterized in that, After parsing the standardized dynamic update file and determining the target server and target process to be updated based on the parsing results, the process further includes: Extract the update instruction content from the parsing results and determine the expected update version carried by the update instruction content; Obtain the current version information and resource usage status of the target process, perform a compatibility analysis between the expected update version and the current version information, and determine whether there is a compatibility risk based on the analysis results; If there is a compatibility risk, a version alert will be generated and the update process will be paused; If there is no compatibility risk, the target process is determined to meet the update execution conditions based on the resource occupancy status. If the target process meets the update execution conditions, the step of establishing a communication connection with the target server is executed.

4. The dynamic update method as described in claim 3, characterized in that, After the step of determining whether the target process meets the update execution conditions based on the resource occupancy status if there is no compatibility risk, the method further includes: When it is determined that the target process does not meet the update execution conditions, a resource scheduling instruction is generated based on the data volume of the update instruction content; The resource scheduling instruction is sent to the target server so that the target server pre-allocates the required resources for the target process. After receiving the resource readiness confirmation information from the target server, the step of establishing a communication connection with the target server is executed.

5. The dynamic update method as described in claim 1, characterized in that, Before the step of sending the update instruction content to the target process via the communication connection to control the target process to perform a dynamic update operation, the method further includes: Count the number of target processes involved in the update instruction; If there are multiple target processes, determine the update status of each target process; When it is determined that all target processes can perform update operations based on their update status, the step of sending the update instruction content to the target processes through the communication connection is executed to control the target processes to perform dynamic update operations.

6. The dynamic update method as described in claim 1, characterized in that, After the step of sending the update instruction content to the target process via the communication connection to control the target process to perform a dynamic update operation, the method further includes: In response to feedback that the target process has completed the update, predefined smoke test cases are sent to the target process to verify the core functions of the target process; Obtain the execution results based on the smoke test cases, and determine the updated performance metrics and log information of the target process from the execution results; The performance metrics and log information are compared and analyzed with the baseline data before the update, and the update effect of the target process is confirmed based on the analysis results. If the update result is confirmed to be correct, a convergence confirmation command is sent to the target process so that the target process can switch to the new version to provide services.

7. The dynamic update method as described in claim 1, characterized in that, The steps of sending the update instruction content to the target process through the communication connection to control the target process to perform dynamic update operations include: The historical update records of the target process are obtained through the communication connection, and the update failure rate of the historical update records is calculated. If the update failure rate is greater than a preset failure rate threshold, a heartbeat detection mechanism and a status confirmation mechanism are added to the update instruction content and sent to the target process.

8. The dynamic update method as described in claim 7, characterized in that, If the update failure rate is greater than a preset failure rate threshold, after the step of adding a heartbeat detection mechanism and a status confirmation mechanism to the update instruction content and sending them to the target process, the method further includes: During the execution of the update instruction, the health indicators and update progress of each target process are obtained at preset intervals through the heartbeat detection mechanism; If any target process is detected to have an abnormal health indicator or a stalled update progress, a partial rollback operation is automatically triggered to restore the target process to its pre-update state, while sending a continue execution instruction to other target processes besides the target process. Record information about the abnormal target process and the rollback results, generate an anomaly report containing repair suggestions, and feed it back to the graphical user interface.

9. A dynamically updating device, characterized in that, The dynamic update device stores a computer program, which, when executed by a processor, implements the dynamic update method according to any one of claims 1-8.

10. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the dynamic update method according to any one of claims 1-8.

Images