Application updating method and device and electronic device

Abstract

This application provides an application update method, apparatus, and electronic device. The method is applied to a primary-backup active-active disaster recovery center, which includes a production center and a disaster recovery center. The production center carries business traffic, and the disaster recovery center takes over business traffic when the primary center fails. The method includes: when the target application in the production center is updated, if the disaster recovery center is not in a business takeover state, copying the application file and configuration file template of the target application from the production center to the disaster recovery center; based on an environment variable file predefined for the disaster recovery center environment, replacing variable placeholders in the configuration file template with specific values ​​defined in the environment variable file to obtain the final configuration file for the disaster recovery center; and updating the version of the target application in the disaster recovery center according to the final configuration file. This method improves the automation, synchronization accuracy, and operational stability of application updates under an active-active architecture.

Description

Technical Field

[0001] This application relates to the field of disaster recovery and backup, and in particular to an application update method, apparatus and electronic device. Background Technology

[0002] In modern enterprise information systems, active-active architecture is a core solution for ensuring business continuity and high availability. In-city active-active architecture achieves real-time load balancing and automatic failover of business traffic by deploying the same applications in two geographically proximate data centers (production center and disaster recovery center).

[0003] Existing technologies typically employ manual operation and maintenance or basic scripts to complete application version releases and synchronization between production centers and disaster recovery centers. However, this approach disperses file copying, configuration modification, and service processing, resulting in insufficient process coordination and susceptibility to omissions or sequential deviations due to manual intervention. Furthermore, the lack of effective means to perceive the operational status of the disaster recovery center leads to inaccurate control over update timing, making it difficult to balance the accuracy, stability, and business continuity of version synchronization.

[0004] Therefore, how to improve the automation, security, and verification reliability of version synchronization under a dual-active architecture to ensure continuous business operation has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides an application update method, apparatus, and electronic device to improve the automation, synchronization accuracy, and operational stability of application updates under a dual-active architecture.

[0006] In a first aspect, embodiments of this application provide an application update method. The method is applied to a primary-backup active-active disaster recovery center, which includes a production center and a disaster recovery center. The production center carries business traffic, and the disaster recovery center takes over business traffic when the primary center fails. The method includes:

[0007] When the target application in the production center is updated, if the disaster recovery center is not in a business takeover state, copy the application files and configuration file templates of the target application in the production center to the disaster recovery center.

[0008] Based on the environment variable file predefined for the disaster recovery center environment, the variable placeholders in the configuration file template are replaced with the specific values ​​defined in the environment variable file to obtain the final configuration file of the disaster recovery center.

[0009] Update the target application in the disaster recovery center according to the final configuration file.

[0010] In one possible embodiment, updating the target application in the disaster recovery center according to the final configuration file includes:

[0011] Deploy the target application's application files to the specified directory of the disaster recovery center, and write the final configuration file to the corresponding configuration loading path of the disaster recovery center;

[0012] After deployment, a version identification file is generated, which is used to identify that the disaster recovery center has completed the version update.

[0013] In one possible embodiment, after updating the target application in the disaster recovery center according to the final configuration file, the method further includes:

[0014] After detecting the version identification file, the target application in the disaster recovery center is automatically restarted, and preset health check commands are executed repeatedly.

[0015] If the health check command's exit code indicates the target application is healthy, the update is considered successful; otherwise, if the health check fails after the preset maximum restart time, the update is considered to have failed.

[0016] In one possible embodiment, after updating the target application in the disaster recovery center according to the final configuration file, the method further includes:

[0017] If the update is confirmed to be successful, an update success log will be generated; if the update is confirmed to be unsuccessful, an update failure log will be generated and an alarm will be triggered.

[0018] In one possible embodiment, when a preset health check command is used, the method further includes:

[0019] Perform consistency checks on the application files of the target applications in the disaster recovery center and the production center.

[0020] If the file consistency check passes, the update is confirmed to be successful.

[0021] In one possible embodiment, before copying the application files and configuration file templates of the target application from the production center to the disaster recovery center, the method further includes:

[0022] Read the status information of the disaster recovery center from the status information storage unit;

[0023] Based on the status information, determine whether the disaster recovery center is in a state of business takeover.

[0024] In one possible embodiment, reading the status information of the disaster recovery center from the status information storage unit includes:

[0025] Obtain the version identification file of the target application in the production center and the version identification file of the target application in the disaster recovery center;

[0026] Compare the version identification files of the production center and the disaster recovery center;

[0027] If the comparison results indicate that the version identification files of the production center and the disaster recovery center are inconsistent, the execution step reads the status information of the disaster recovery center from the status information storage unit.

[0028] In one possible embodiment, the method further includes:

[0029] When the status information indicates that the disaster recovery center is in a business takeover state, the status information of the disaster recovery center is monitored until it is detected that the disaster recovery center is not in a business takeover state, and then the target application of the disaster recovery center is updated.

[0030] Secondly, embodiments of this application provide an application update apparatus, which is applied to a primary-backup active-active disaster recovery center. The primary-backup active-active disaster recovery center includes a production center and a disaster recovery center. The production center is used to carry service traffic, and the disaster recovery center is used to take over the service traffic when the primary center fails. The apparatus includes:

[0031] The copy module is used to copy the application files and configuration file templates of the target application in the production center to the disaster recovery center when the target application in the production center is updated, if the disaster recovery center is not in a business takeover state.

[0032] The configuration module is used to replace the variable placeholders in the configuration file template with the specific values ​​defined in the environment variable file, based on the environment variable file predefined for the disaster recovery center environment, to obtain the final configuration file of the disaster recovery center.

[0033] The update module is used to update the target application in the disaster recovery center according to the final configuration file.

[0034] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0035] The memory stores computer-executed instructions;

[0036] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0037] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0038] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0039] The application update method, apparatus, and electronic device provided in this application embodiment, when updating the target application in the production center, incorporates the associative design of application file synchronization, configuration template environmentization, and version deployment switching between the production center and the disaster recovery center. This enables the target application in the disaster recovery center to synchronize with the corresponding version in the production center without affecting the current business security, and makes the generated final configuration file adaptable to the disaster recovery center's own environment. This improves the automation level, configuration accuracy, and disaster recovery takeover reliability of the application update process under the primary-backup active-active disaster recovery center architecture. Attached Figure Description

[0040] 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.

[0041] Figure 1 An application scenario diagram provided for an embodiment of this application;

[0042] Figure 2 A flowchart illustrating an application update method provided in this application embodiment. Figure 1 ;

[0043] Figure 3 A flowchart illustrating an application update method provided in this application embodiment. Figure 2 ;

[0044] Figure 4 A flowchart illustrating an application update method provided in this application embodiment. Figure 3 ;

[0045] Figure 5 This is a schematic diagram of the structure of an application update device provided in an embodiment of this application;

[0046] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0047] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0048] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0049] Active-active architecture and application version update control belong to the field of enterprise-level information system operation and maintenance and high availability assurance technology, and are widely used in financial transactions, communication service support, medical information platforms and large-scale Internet core business systems.

[0050] Figure 1 An application scenario diagram provided for an embodiment of this application, such as Figure 1 As shown, business systems are typically deployed in geographically proximate production centers and disaster recovery centers interconnected via communication networks. Under normal circumstances, the production center handles the majority of business traffic, while the disaster recovery center remains in a takeover state to quickly take over business requests should the production center fail. Therefore, each time the application version is updated, the disaster recovery center must promptly and accurately synchronize with the corresponding version in the production center to ensure consistency in business logic, application versions, and configuration rules between the two centers.

[0051] In existing technologies, enterprises typically rely on manual operation and maintenance processes or basic script tools to complete application deployment and version synchronization between production centers and disaster recovery centers. When the target application in the production center is updated, the operation and maintenance personnel manually copy the new program package, binary file, script file, or configuration file to the disaster recovery center. Then, they modify the configuration items such as database address, port number, middleware connection information, and node identifier according to the environment differences. Finally, they restart or reload the target application in the disaster recovery center to complete the version update.

[0052] Based on the above scenarios, it can be seen that the existing application update mechanism is characterized by fragmented steps, reliance on experience, and lack of overall constraints. It has a low degree of automation and is significantly inadequate in terms of update security, configuration accuracy, and business continuity assurance.

[0053] To address the aforementioned issues, this application provides an application update method applicable to active-active disaster recovery centers, including production centers and disaster recovery centers. When a target application in the production center is updated, it first determines whether the disaster recovery center is in a business takeover state. Only if the disaster recovery center is not in a business takeover state will the application files and configuration file templates of the target application in the production center be copied to the disaster recovery center. Subsequently, based on an environment variable file predefined for the disaster recovery center environment, the variable placeholders in the configuration file template are replaced with the specific values ​​defined in the environment variable file to form a final configuration file adapted to the disaster recovery center's operating environment. Finally, the target application in the disaster recovery center is updated according to this final configuration file. By logically associating file copying, environment adaptation, and version update association, the method ensures that the disaster recovery center can balance environmental differences and business security during version synchronization, thereby reducing configuration deviations and update risks caused by manual processing.

[0054] Figure 2 A flowchart illustrating an application update method provided in this application embodiment. Figure 1 ,like Figure 2 As shown, the method includes:

[0055] S201: When the target application in the production center is updated, if the disaster recovery center is not in a business takeover state, copy the application files and configuration file templates of the target application in the production center to the disaster recovery center.

[0056] In this embodiment, the application update method runs on a primary-backup active-active disaster recovery center. The primary-backup active-active disaster recovery center consists of a production center and a disaster recovery center. The production center and the disaster recovery center are typically deployed in different data centers within the same city or between different campuses within the same city, and are interconnected via high-speed dedicated lines or low-latency networks.

[0057] The production center serves as the primary operating environment for handling business traffic and providing services to the outside world. The disaster recovery center takes over business traffic in the event of a failure at the production center.

[0058] The target application refers to the software deployed in the primary / backup active-active disaster recovery center that is related to the business system. Target applications can be, for example, transaction services, clearing services, user services, interface gateways, batch processing services, or middleware systems.

[0059] The business takeover status is used to indicate whether the disaster recovery center is currently handling business traffic.

[0060] Application files refer to the files that carry the content of the target application, including but not limited to executable binary files, runtime packages, class library files, script files, startup files, and static resource files.

[0061] Configuration file templates are used for environment configuration. The environment-related content in the configuration file templates is not hardcoded, but is identified by variable placeholders, so that the configuration structure is separated from the specific environment values.

[0062] In this step, after detecting an update to the target application in the production center, the business takeover status of the disaster recovery center is checked. If the disaster recovery center is not in a business takeover state, the application files and configuration file templates of the target application in the production center are copied to the disaster recovery center to update the target application in the disaster recovery center.

[0063] Specifically, this step can be triggered when the target application in the production center enters the version release process. The detection method can be that the release platform issues an update command, the production center reports an update event after completing the target application version upgrade, or it can be triggered after comparing the version tag files of the target application in the production center and the disaster recovery center.

[0064] To avoid impacting business continuity by updating target applications in the disaster recovery center when it takes over business traffic, it is essential to first determine whether the disaster recovery center is in a business takeover state before updating the target applications.

[0065] This judgment can be made independently or in combination from multiple dimensions. For example, it can be done by querying whether the traffic weight of the corresponding business in the disaster recovery center is greater than a preset threshold, checking whether there are external forwarding records in the load balancer at the disaster recovery center's entry point, and reading real-time request volume metrics from the application monitoring system. This application does not impose any restrictions on this.

[0066] If any judgment result indicates that the disaster recovery center is already in a state of takeover, partial takeover, or handling external requests, then this application update event will be suspended, postponed, or placed in a waiting queue.

[0067] When the judgment result indicates that the disaster recovery center is not in a business takeover state, it means that the disaster recovery center can currently be used as an offline synchronization object. Therefore, the application files and configuration file templates of the target application in the production center are copied to the disaster recovery center.

[0068] Specifically, the application files and configuration file templates of the target application in the production center can be copied to the disaster recovery center via network transmission. For example, this can be achieved using secure file transfer protocols, remote replication protocols, object storage distribution methods, or the built-in synchronization mechanism of a primary-backup active-active disaster recovery center.

[0069] Furthermore, to ensure the integrity of the replication, the file list of application files and configuration file templates can be read first, and then a verification operation can be performed after the replication is completed at the disaster recovery center. Only after successful verification can the application update be performed.

[0070] Optionally, a full update can be used, which involves copying the complete application files and configuration file templates to be updated to fully cover the current target application in the disaster recovery center; or an incremental synchronization can be used, which involves copying only the application files and configuration file templates that have been added or changed relative to the previous version, but still ensuring that the disaster recovery center can obtain a complete and deployable set of target version files.

[0071] This step ensures that the disaster recovery center is in a business takeover state before updating the target application in the production center. It guarantees that the disaster recovery center only updates applications when it is not carrying actual business traffic, avoiding service interruptions, connection problems, and even configuration errors that can occur with traditional manual overwrite updates when the disaster recovery center has taken over traffic. Simultaneously, by copying application files and configuration file templates as unified synchronization objects, it reduces deployment discrepancies between the production and disaster recovery centers caused by file version inconsistencies.

[0072] S202: Based on the environment variable file predefined for the disaster recovery center environment, replace the variable placeholders in the configuration file template with the specific values ​​defined in the environment variable file to obtain the final configuration file for the disaster recovery center.

[0073] Among them, the environment variable file refers to the file that predefines the configuration for the disaster recovery center environment. It is used to provide a source of parameter replacement for the configuration file template, so that the configuration processing of the disaster recovery center no longer depends on manual modification item by item, and realizes automated updates.

[0074] The environment variable file can record information such as the database address, database port, database instance name, message middleware address, cache service address, service registration node, data center identifier, hostname, container name, log directory, certificate path, thread pool parameters, node number, and access authentication information required for the actual operation of the disaster recovery center.

[0075] Variable placeholders are used to identify the location markers of configuration items to be replaced, so as to specify the specific fields that need to be replaced by specific values ​​defined in the environment variable file.

[0076] The final configuration file is generated after the template rendering is completed. It can be directly loaded and used by the target application in the disaster recovery center. Together with the application file, it constitutes a complete deployment unit for the target application version to be updated in the disaster recovery center.

[0077] In this step, after the file copy is completed, the corresponding specific values ​​are parsed from the predefined environment variable file stored locally in the disaster recovery center. Based on the variable placeholders in the configuration file template, the variable placeholders in the configuration file template are replaced with the specific values ​​defined in the environment variable file to obtain the final configuration file of the disaster recovery center.

[0078] Specifically, after the file copy is complete, the pre-stored environment variable file is read from the disaster recovery center's local machine. This environment variable file can be pre-generated and maintained by the disaster recovery center's operations and maintenance platform, or it can be distributed to the disaster recovery center for storage by the configuration management center. The system scans for variable placeholders in the configuration file template, establishes a mapping relationship between the placeholder names and the variable names in the environment variable file, and performs a replacement process for each placeholder.

[0079] Optionally, if multiple configuration files exist in the template, they can be rendered one by one in a preset order. For example, the basic system configuration can be generated first, followed by the database connection configuration, and then the registration and discovery configuration and the logging configuration. If variables with the same name appear repeatedly in multiple templates, the same environment variable value can be reused to ensure consistency of the internal configuration of the disaster recovery center.

[0080] Optionally, before generating the final configuration file, it can be checked whether all variable placeholders appearing in the configuration file template can be matched with corresponding values ​​in the environment variable file. If there are any unmatched variable placeholders, the version update is aborted and an exception log is generated to avoid generating an incomplete final configuration file, which could cause the target application version update to fail.

[0081] By combining environment variable files and configuration file templates, the configuration structure and environment value retrieval are decoupled, enabling rule-based rendering of configuration generation for the disaster recovery center. This improves the accuracy, maintainability, and reusability of version updates.

[0082] S203: Update the target application in the disaster recovery center according to the final configuration file.

[0083] Version updates are used to ensure that the target application in the disaster recovery center is consistent with the version in the production center. The target application in the disaster recovery center can be deployed on physical servers, virtual machines, container platforms, or application servers.

[0084] Specifically, the application files and final configuration files are assembled into a release version file, and the version is updated according to the release version directory and the preset update strategy.

[0085] Optionally, to reduce the risk of version switching failure, the version files of the target application currently in effect in the disaster recovery center can be stored in a partition. After the update, the new version is verified; if the verification fails, it is automatically rolled back to the effective version before the update.

[0086] By executing version updates of the target application in the disaster recovery center through the final configuration file, a runnable deployment with consistent local environment parameters in the disaster recovery center is achieved.

[0087] This application provides an application update method, comprising: when the target application in the production center is updated, if the disaster recovery center is not in a business takeover state, copying the application file and configuration file template of the target application in the production center to the disaster recovery center; based on the environment variable file predefined for the disaster recovery center environment, replacing the variable placeholders in the configuration file template with the specific values ​​defined in the environment variable file to obtain the final configuration file of the disaster recovery center; and updating the version of the target application in the disaster recovery center according to the final configuration file. By designing the application file synchronization, configuration template environmentization, and version deployment switching between the production center and the disaster recovery center in an associative manner, the target application in the disaster recovery center can complete the synchronization with the corresponding version in the production center without affecting the current business security, and the generated final configuration file is adapted to the disaster recovery center's own environment, thereby improving the automation level, configuration accuracy, and disaster recovery takeover reliability of the application update process under the primary-backup active-active disaster recovery center architecture.

[0088] Figure 3 A flowchart illustrating an application update method provided in this application embodiment. Figure 2 In this embodiment Figure 2 Based on the embodiments, an application update method is described in detail, such as... Figure 3 As shown, the method includes:

[0089] S301. Obtain the version identification file of the target application in the production center and the version identification file of the target application in the disaster recovery center; compare the version identification files of the production center and the disaster recovery center.

[0090] The version identification file is generated after the version update and is used to represent the version information of the target application corresponding to the production center and the disaster recovery center. The version identification file can be a version number, build number, release timestamp, file hash value, or a unique identifier formed by a combination of the above information, so as to serve as the basis for judging the version consistency between the two centers.

[0091] The status information storage unit is used to save the current status information of the disaster recovery center, including but not limited to running status, takeover status, and version synchronization status.

[0092] Specifically, version identification files for the production center and disaster recovery center can be retrieved periodically at preset time intervals, or the process can be triggered by the production center adding a new version identification file.

[0093] Specifically, the system reads the version identification files of the target applications in the production center and the disaster recovery center, and writes the results to the cache. The version identification files of the two centers are compared. If the version identification files of the production center and the disaster recovery center are found to be identical, it indicates that the versions of the target applications in the production center and the disaster recovery center are consistent, and the current monitoring status is maintained.

[0094] S302. If the comparison results indicate that the version identification files of the production center and the disaster recovery center are inconsistent, read the status information of the disaster recovery center from the status information storage unit; and determine whether the disaster recovery center is in a business takeover state based on the status information.

[0095] The status information storage unit can be a database, a distributed key-value store, or a configuration center, used to save the current operating status of the disaster recovery center and its change records.

[0096] When a discrepancy is detected between the version identifier files of the production center and the disaster recovery center, it indicates that the production center has undergone a version change, while the disaster recovery center has not yet completed synchronization. Therefore, the status information of the disaster recovery center is retrieved from the status information storage unit, and based on this, it is determined whether the disaster recovery center is in a business takeover state.

[0097] By linking version consistency checks with disaster recovery center status readings, insecure update operations are avoided during the period when the disaster recovery center takes over the business, thus enhancing the ability to ensure business continuity in disaster recovery switchover scenarios.

[0098] S303. When the status information indicates that the disaster recovery center is in the business takeover state, monitor the status information of the disaster recovery center until it is detected that the disaster recovery center is not in the business takeover state, and then update the target application of the disaster recovery center.

[0099] When the disaster recovery center is in a business takeover state, in order to maintain business stability, updates to the target application are not performed immediately. Instead, the status information of the disaster recovery center is monitored to determine whether the current status of the disaster recovery center is still in a business takeover state.

[0100] The system can check the takeover flag, service traffic statistics, or failover flag of the disaster recovery center and remain in a wait state if the test results still indicate that the disaster recovery center is under takeover. The system will only trigger update control logic and complete the version update of the disaster recovery center when the status information shows that the disaster recovery center has been released from service takeover and the target application no longer carries real-time service requests.

[0101] By monitoring the status information of the disaster recovery center, overwrite updates are avoided during business takeover, reducing the risk of business interruption caused by restarts, file replacements, or configuration refreshes. The disaster recovery center only performs version switching during idle or updateable windows, improving the security, accuracy, and continuity of application updates in a dual-active environment.

[0102] S304. If the disaster recovery center is not in a business takeover state, copy the application files and configuration file templates of the target application from the production center to the disaster recovery center.

[0103] Step S304 is similar to step S201, and will not be described again here.

[0104] S305. Based on the environment variable file predefined for the disaster recovery center environment, replace the variable placeholders in the configuration file template with the specific values ​​defined in the environment variable file to obtain the final configuration file of the disaster recovery center.

[0105] Step S305 is similar to step S202, and will not be described again here.

[0106] S306. Deploy the target application's application files to the specified directory of the disaster recovery center, and write the final configuration file to the corresponding configuration loading path of the disaster recovery center. After deployment, generate a version identifier file.

[0107] The version identification file is used to indicate that the disaster recovery center has completed the version update, that is, the target application of the disaster recovery center has been deployed and configured.

[0108] The specified directory is the landing path of the target application in the disaster recovery center, used to store and load the application files.

[0109] The configuration loading path is the interface location where the disaster recovery center reads the final configuration file, which is used to enable the target application to directly obtain the configuration content that matches the disaster recovery environment when it starts or is reloaded.

[0110] Specifically, the application files corresponding to the version to be updated are copied or synchronized to the designated directory of the disaster recovery center, and the final configuration file is written to the corresponding configuration loading path of the disaster recovery center, so that the application files and configuration content are under the same version association. After writing is completed, the system can create a version identifier file in the preset identifier directory to record the current update status.

[0111] By associating application file deployment, configuration writing, and update tag generation, the disaster recovery center can establish an identifiable and traceable update status after version synchronization. Simultaneously, the version identification file provides data for subsequent version consistency verification.

[0112] S307. After detecting the version identification file, automatically restart the target application in the disaster recovery center and repeatedly execute the preset health check commands.

[0113] The preset health check commands are used to detect whether the internal state of the target application is healthy. The health check commands can be commands that access the local health endpoint, execute service probe scripts, or call the application self-check interface.

[0114] The result of a health check command is indicated by the returned exit code.

[0115] Once the generation or update of this file is detected, the restart control of the target application can be triggered. The restart control can be initiated by the deployment script or orchestration component and will repeatedly execute preset health check commands to detect whether the internal state of the target application is healthy.

[0116] S308. If the target application is determined to be healthy based on the exit code of the health check command, the update is confirmed to be successful; if the health check fails after the preset maximum restart time, the update is confirmed to have failed.

[0117] The exit code indicates that the application is in a usable state when it is a preset normal value. An abnormal exit code indicates that the application has not completed startup or has encountered a runtime failure.

[0118] The preset maximum restart time can be pre-set based on the startup time of the target application, the initialization time of dependent components, and the computing resource configuration of the disaster recovery center, in order to prevent the application from being stuck in the startup process for a long time and affecting the version update determination.

[0119] The system continuously executes health check commands until it obtains an exit code that meets the health requirements or reaches a time threshold. If the exit code returned by the health check command meets the preset rules, the system records the update as successful and writes the update result to the runtime log or status file. If a normal exit code is not obtained within the maximum restart time, the system records the update as failed and can further perform version rollback or alarm processing.

[0120] The updated target application can continuously undergo health probes after automatic restart and repeatedly execute health check commands to determine the update results. The maximum restart time limit can promptly detect startup anomalies, reducing the risk of prolonged unavailability of the disaster recovery center during version switching and improving business continuity assurance capabilities.

[0121] S309. After the preset health check command passes, perform a consistency check on the application files of the target applications in the disaster recovery center and the production center; if the file consistency check passes, the update is confirmed to be successful.

[0122] Among them, the file consistency check is used to compare the corresponding target application files in the disaster recovery center and the production center to verify the consistency of the target application files on both sides, thereby determining whether the updated content in the disaster recovery center has been synchronized with the production center.

[0123] Specifically, file consistency verification can be achieved by comparing the hash values ​​(e.g., md5sum) or file content differences (e.g., using the diff command) of the corresponding versions of application files between the production center and the disaster recovery center. If the hash values ​​of the application files in the production center and the disaster recovery center are consistent, and there are no missing files, extra files, or content tampering, then the verification is considered successful.

[0124] In practice, once the target application in the disaster recovery center completes its update and passes a preset health check command, it reads the corresponding version of the target application file from the production center and compares it with the corresponding version of the target application file in the disaster recovery center. If the files on both sides are consistent, and there are no missing files, extra files, or files whose content has been tampered with, the file consistency check is considered passed, and the update is confirmed to be successful. If the check result shows that any file is inconsistent, this result can be used as the basis for determining that the update was incomplete or abnormal, thereby maintaining the update failure status or triggering subsequent alarm processing.

[0125] By introducing file consistency verification after the health check command is executed, the application's operational health and file consistency are jointly verified, thereby improving the accuracy of version update result determination.

[0126] S310. If the update is confirmed to be successful, generate an update success log; if the update is confirmed to be unsuccessful, generate an update failure log and trigger an alarm.

[0127] The update success log is used to indicate that the target application version update of the disaster recovery center has been completed. The update success log includes status information, which includes at least the update completion time, target application identifier, version number corresponding to the version identifier file, and health check results, so as to facilitate subsequent operation and maintenance audit, fault tracing and version verification.

[0128] Update failure logs are used to indicate that the target application version update in the disaster recovery center has failed. Update failure logs include exception information, which includes at least the time of failure, the target application identifier, the stage of failure, the exception return code, and a description of the reason for failure, in order to locate configuration errors, deployment anomalies, or restart failures during the update process.

[0129] Alarms are used to output abnormal notifications to preset alarm channels while generating update failure logs. Alarm channels can include operation and maintenance monitoring platforms, SMS notifications, in-site messages, or email notifications, so that relevant personnel can be informed of update abnormalities in the disaster recovery center in a timely manner and take appropriate measures.

[0130] Specifically, the health check results after the version update are completed confirm whether the target application in the disaster recovery center has been successfully updated. When the health check command returns a preset success exit code and the target application continues to run stably, an update success log is generated; when the health check fails within a preset time, an update failure log is generated and an alarm is triggered simultaneously.

[0131] By recording update results in a closed loop through both success and failure logs and issuing immediate alerts in case of failure, the manageability of the operation and maintenance process is enhanced. The alarm mechanism in failure scenarios shortens the time for anomaly detection, improves fault response efficiency, and thus enhances the security and reliability of application updates in a dual-active disaster recovery environment within the same city.

[0132] This application provides an application update method that avoids insecure update operations during business takeover by associating version consistency detection with disaster recovery center status reading. By monitoring the disaster recovery center's status information, it prevents overwrite updates during business takeover. It correlates application file deployment, configuration writing, and update tag generation, ensuring the disaster recovery center maintains an identifiable and traceable update status after version synchronization. Simultaneously, the version identification file provides data for subsequent version consistency verification. The updated target application continuously undergoes health probes after automatic restart and cyclically executes health check commands to determine update results. The maximum restart time limit allows for timely detection of startup anomalies, reducing the risk of prolonged unavailability of the disaster recovery center during version switching. The introduction of file consistency verification jointly confirms application operational health and file consistency, improving the accuracy of version update result determination. The update log records update results in a closed loop and provides immediate alerts in case of failure, enhancing manageability and improving fault response efficiency.

[0133] Figure 4 A flowchart illustrating an application update method provided in this application embodiment. Figure 3 ,like Figure 4 As shown, when the target application in the production center is updated, a new version identifier file is added. At this time, the database is queried to determine whether the disaster recovery center is in a business takeover state.

[0134] If the status information indicates that the disaster recovery center is taking over business traffic, the status information will be continuously monitored until the disaster recovery center exits the business takeover state before the application update is executed.

[0135] After confirming that the disaster recovery center is not under business takeover, the application files and configuration file templates corresponding to the target application in the production center are copied to the disaster recovery center. Then, the environment variable file pre-defined for the disaster recovery center environment is read, and each variable placeholder in the configuration file template is replaced one by one. The specific variable values ​​defined in the environment variable file are written into the corresponding placeholder positions to generate the final configuration file suitable for the disaster recovery center's operating environment.

[0136] The application files of the target application are deployed to the specified directory of the disaster recovery center, and the final configuration file is written to the corresponding configuration loading path of the disaster recovery center. After deployment, a version identification file is generated to indicate that the disaster recovery center has completed this version update.

[0137] After detecting the version identification file, the system automatically restarts the target application in the disaster recovery center and repeatedly executes preset health check commands to monitor the application's running status after restarting. The system determines the health of the target application based on the exit code returned by the health check commands.

[0138] After the health check command is executed and passes, the consistency of the application files of the target application in the disaster recovery center and the production center is verified. When both the health check and the file consistency verification pass, the update is confirmed to be successful and an update success log is generated.

[0139] If the health check fails after the preset maximum restart time, the update is considered to have failed, an update failure log is generated, and an alarm is triggered.

[0140] Figure 5 This is a schematic diagram of an application update device provided in an embodiment of this application. The device is applied in a primary-backup active-active disaster recovery center, which includes a production center and a disaster recovery center. The production center is used to carry business traffic, and the disaster recovery center is used to take over business traffic when the primary center fails. Figure 5 As shown, the application update device 50 provided in this embodiment includes: a copy module 501, a configuration module 502, and an update module 503;

[0141] The copy module 501 is used to copy the application files and configuration file templates of the target application in the production center to the disaster recovery center when the target application in the production center is updated, if the disaster recovery center is not in a business takeover state.

[0142] Configuration module 502 is used to replace variable placeholders in the configuration file template with specific values ​​defined in the environment variable file based on the environment variable file predefined for the disaster recovery center environment, so as to obtain the final configuration file of the disaster recovery center.

[0143] Update module 503 is used to update the version of the target application in the disaster recovery center according to the final configuration file.

[0144] In one possible implementation, the update module 503 is also used to deploy the application files of the target application to a specified directory of the disaster recovery center and write the final configuration file to the configuration loading path corresponding to the disaster recovery center; after the deployment is completed, a version identification file is generated, which is used to identify that the disaster recovery center has completed the version update.

[0145] In one possible implementation, the update module 503 is further configured to automatically restart the target application in the disaster recovery center after detecting the version identifier file, and repeatedly execute preset health check commands; if the target application is healthy according to the exit code of the health check command, the update is determined to be successful; if the health check fails after the preset maximum restart time, the update is determined to be unsuccessful.

[0146] In one possible implementation, the update module 503 is also used to generate an update success log if the update is determined to be successful, and to generate an update failure log and trigger an alarm if the update is determined to be unsuccessful.

[0147] In one possible implementation, the update module 503 is also used to perform consistency verification on the application files of the target applications in the disaster recovery center and the production center; if the file consistency verification passes, the update is confirmed to be successful.

[0148] In one possible implementation, the replication module 501 is also used to read the status information of the disaster recovery center from the status information storage unit; and to determine whether the disaster recovery center is in a business takeover state based on the status information.

[0149] In one possible implementation, the replication module 501 is further configured to obtain the version identification file of the target application in the production center and the version identification file of the target application in the disaster recovery center; compare the version identification files of the production center and the disaster recovery center; and if the comparison result indicates that the version identification files of the production center and the disaster recovery center are inconsistent, execute the step of reading the status information of the disaster recovery center from the status information storage unit.

[0150] In one possible implementation, the replication module 501 is further configured to monitor the status information of the disaster recovery center when the status information indicates that the disaster recovery center is in a business takeover state, and then perform application updates on the target application of the disaster recovery center when it is detected that the disaster recovery center is not in a business takeover state.

[0151] The application update device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0152] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the device 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0153] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0154] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0155] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0156] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0157] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0158] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0159] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0160] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0161] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0162] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0163] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0164] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0165] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0166] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0167] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. An application update method, characterized in that, The method is applied to a primary-backup active-active disaster recovery center, which includes a production center and a disaster recovery center. The production center is used to carry business traffic, and the disaster recovery center is used to take over the business traffic when the primary center fails. The method includes: When the target application in the production center is updated, if the disaster recovery center is not in a business takeover state, the application files and configuration file templates of the target application in the production center are copied to the disaster recovery center. Based on the environment variable file predefined for the disaster recovery center environment, the variable placeholders in the configuration file template are replaced with the specific values ​​defined in the environment variable file to obtain the final configuration file of the disaster recovery center. The target application in the disaster recovery center is updated according to the final configuration file.

2. The method according to claim 1, characterized in that, The step of updating the target application in the disaster recovery center according to the final configuration file includes: The application files of the target application are deployed to the specified directory of the disaster recovery center, and the final configuration file is written to the configuration loading path corresponding to the disaster recovery center. After deployment is complete, a version identification file is generated, which is used to identify that the disaster recovery center has completed the version update.

3. The method according to claim 2, characterized in that, After updating the target application in the disaster recovery center according to the final configuration file, the method further includes: Upon detecting the version identifier file, the target application in the disaster recovery center is automatically restarted, and preset health check commands are executed repeatedly. If the target application is deemed healthy based on the exit code of the health check command, the update is considered successful; if the health check fails after the preset maximum restart time, the update is considered to have failed.

4. The method according to claim 3, characterized in that, After updating the target application in the disaster recovery center according to the final configuration file, the method further includes: If the update is confirmed to be successful, an update success log will be generated; if the update is confirmed to be unsuccessful, an update failure log will be generated and an alarm will be triggered.

5. The method according to claim 3, characterized in that, In the case of a preset health check command, the method further includes: Perform a consistency check on the application files of the target applications in the disaster recovery center and the production center. If the file consistency check passes, the update is confirmed to be successful.

6. The method according to claim 1, characterized in that, Before copying the application files and configuration file templates of the target application from the production center to the disaster recovery center, the method further includes: Read the status information of the disaster recovery center from the status information storage unit; Based on the status information, determine whether the disaster recovery center is in a business takeover state.

7. The method according to claim 6, characterized in that, The step of reading the status information of the disaster recovery center from the status information storage unit includes: Obtain the version identification file of the target application in the production center and the version identification file of the target application in the disaster recovery center; Compare the version identification files of the production center and the disaster recovery center; If the comparison results indicate that the version identification files of the production center and the disaster recovery center are inconsistent, the procedure is to read the status information of the disaster recovery center from the status information storage unit.

8. The method according to claim 6, characterized in that, The method further includes: When the status information indicates that the disaster recovery center is in a business takeover state, the status information of the disaster recovery center is monitored until it is detected that the disaster recovery center is not in a business takeover state, and then the target application of the disaster recovery center is updated.

9. An application update device, characterized in that, The device is applied to a primary / backup active-active disaster recovery center, which includes a production center and a disaster recovery center. The production center is used to carry business traffic, and the disaster recovery center is used to take over the business traffic when the primary center fails. The device includes: The copy module is used to copy the application files and configuration file templates of the target application in the production center to the disaster recovery center when the target application in the production center is updated, if the disaster recovery center is not in a business takeover state. The configuration module is used to replace the variable placeholders in the configuration file template with the specific values ​​defined in the environment variable file, based on the environment variable file predefined for the disaster recovery center environment, to obtain the final configuration file of the disaster recovery center. The update module is used to update the target application in the disaster recovery center according to the final configuration file.

10. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

Images