Software updating method and device, equipment and storage medium

Abstract

The invention provides a software updating method and device, equipment and a storage medium, and the method comprises the steps: generating a new version contract file based on a new version code, and enabling the new version contract file to be used for providing a standardized description of a new version API; obtaining a comparison result of the new version contract file and the old version contract file, and determining whether the comparison result meets a preset constraint condition; when it is determined that the comparison result meets a preset constraint condition, verifying whether an actual API interface of the new version code during operation is consistent with an API interface contained in the new version contract file or not; routing the traffic to the new-version service according to a preset gray release strategy after confirming that the traffic is consistent, and monitoring whether the running state of the new-version service is abnormal or not during gray release; if not, updating the old-version service into a new-version service, and if yes, triggering an exception handling mechanism; zero-interruption deployment of services is realized, compatibility detection and system reliability are greatly improved, resources are effectively saved, and continuity of key services is guaranteed.

Description

Technical Field

[0001] This application relates to the field of computer software, and more particularly to a software update method, apparatus, device, and storage medium. Background Technology

[0002] Hot update technology for software systems is a core mechanism to ensure high availability of online services, especially in fields with extremely high continuity requirements such as finance and healthcare, where "zero interruption" has become a necessity. However, current mainstream deployment solutions, such as deployment with downtime and blue-green deployment, still have significant limitations. Deployment with downtime will directly cause service interruption, while blue-green deployment, although it can reduce downtime, still relies on traffic switching mechanisms, which will generate an average of more than 30 seconds of service unavailability window. Moreover, during the redundancy deployment of replicas, resource consumption will increase by 40%-60%, driving up operating costs.

[0003] Meanwhile, existing API compatibility management relies heavily on manual verification and regression testing, lacking automation and real-time verification capabilities. Statistics show that approximately 17% of online failures are caused by undetected interface incompatibility changes, significantly increasing the risk to system stability. Summary of the Invention

[0004] This application provides a software update method, apparatus, device, and storage medium for achieving zero-disruption deployment of services through contract pre-verification, sandbox isolation, and atomic switching, significantly improving compatibility testing and system reliability, effectively saving resources, and ensuring the continuity of critical services.

[0005] In a first aspect, this application provides a software update method, comprising:

[0006] A new version contract file is generated based on the new version code. The aforementioned new version contract file is used to provide a standardized description of the new version API.

[0007] Obtain the comparison results between the new version of the contract file and the old version of the contract file, and confirm whether the comparison results meet the preset constraints.

[0008] When the comparison result is determined to meet the preset constraints, verify whether the actual API interface of the new version code at runtime is consistent with the API interface contained in the new version contract file;

[0009] After confirming consistency, traffic is routed to the new version service according to the preset canary release strategy, and the operation status of the new version service during the canary release period is monitored to see if any abnormalities occur.

[0010] If not, the old version of the service will be updated to the new version; if so, an exception handling mechanism will be triggered. In one or more possible embodiments, the preset constraint is that no incompatible changes have been introduced.

[0011] Confirming whether the comparison results meet preset constraints includes:

[0012] Confirm whether the comparison results contain incompatible changes; wherein, the incompatible changes include: interface deletion, parameter type change, and addition of required parameters;

[0013] If so, it is determined that the preset constraint condition is not met, and an alarm notification is sent;

[0014] If not, then the comparison result is determined to meet the preset constraints.

[0015] In one or more possible embodiments, before verifying whether the actual API interface of the new version code at runtime is consistent with the API interface included in the new version contract file, the method further includes:

[0016] Create an independent sandbox environment based on a custom class loader. This sandbox environment is isolated from the environment currently running older versions of services.

[0017] Load and initialize the bytecode corresponding to the new version code in the sandbox environment to create a new version service.

[0018] In one or more possible embodiments, verifying whether the actual API interface of the new version code at runtime is consistent with the API interface included in the new version contract file includes:

[0019] After the new version of the service is started, obtain the API interfaces actually exposed in the new version of the service;

[0020] The actual exposed API interfaces are compared with the API interfaces defined in the new version contract file.

[0021] In one or more possible embodiments, the triggering exception handling mechanism includes:

[0022] Invoke the rollback service to terminate the deployment of the new version of the service;

[0023] Verify the traffic routing rules to ensure that all traffic is routed to the older version of the service.

[0024] In one or more possible embodiments, the step of routing traffic to the new version service according to a preset canary release strategy and monitoring whether the running status of the new version service is abnormal during the canary release includes:

[0025] Test the new version of the service based on preset simulated requests;

[0026] Once the test is confirmed to be successful, a predetermined proportion of real traffic will be gradually routed to the new version service according to the preset canary release strategy, and the operation status of the new version service during the canary release period will be monitored to see if any abnormalities occur.

[0027] In one or more possible embodiments, updating the old version of the service to the new version includes:

[0028] After confirming that there are no abnormalities in the operating status, an atomic traffic switch is performed to switch user traffic from being routed to the old version service to being routed to the new version service; wherein, the atomic traffic switch is to update the routing rules or update the configuration of the service registry.

[0029] Secondly, this application provides a software update apparatus, comprising:

[0030] The contract generation module is used to generate a new version contract file based on the new version code. The new version contract file is used to provide a standardized description of the new version API.

[0031] The contract pre-verification module is used to obtain the comparison results between the new version of the contract file and the old version of the contract file, and to confirm whether the comparison results meet the preset constraints.

[0032] The runtime verification module is used to verify whether the actual API interface of the new version code at runtime is consistent with the API interface contained in the new version contract file when the comparison result meets the preset constraints.

[0033] The status monitoring module is used to route traffic to the new version service according to the preset canary release strategy after confirming consistency, and to monitor whether the running status of the new version service is abnormal during the canary release period.

[0034] The update and control module is used to update the old version of the service to the new version if there are no abnormalities in the running status, and to trigger the exception handling mechanism if there are abnormalities in the running status.

[0035] Thirdly, this application provides an electronic device, the electronic device comprising:

[0036] 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 to enable the at least one processor to perform any of the methods in the first aspect.

[0037] Fourthly, this application provides a computer storage medium storing a computer program for causing a computer to perform any of the methods described in the first aspect.

[0038] According to the software update method, apparatus, device and storage medium provided in this application, zero-interruption deployment of services can be achieved through contract pre-verification, sandbox isolation and atomic switching, which greatly improves compatibility testing and system reliability, effectively saves resources and ensures the continuity of critical services. Attached Figure Description

[0039] 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, and do not constitute an undue limitation of this application.

[0040] Figure 1 This is a schematic diagram of an application scenario provided according to an embodiment;

[0041] Figure 2 This is a software update flowchart provided according to an embodiment;

[0042] Figure 3 This is a flowchart illustrating a new version of the contract file generation process according to an embodiment.

[0043] Figure 4 This is a flowchart of a contract pre-verification process provided according to an embodiment;

[0044] Figure 5 This is a hot deployment flowchart provided according to an embodiment;

[0045] Figure 6 This is a flowchart of a runtime contract verification process provided according to an embodiment;

[0046] Figure 7 This is a diagram of a software update module according to an embodiment;

[0047] Figure 8 This is a schematic diagram of a software update device according to an embodiment;

[0048] Figure 9 This is a schematic diagram of an electronic device according to an embodiment;

[0049] Figure 10 This is a schematic diagram of a computer-readable storage medium provided according to an embodiment. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0051] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0052] Furthermore, in the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0053] Example 1

[0054] For ease of understanding, the software update method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings:

[0055] like Figure 1 The diagram illustrates an application scenario of the software update method provided in this application embodiment. The diagram includes: a network 10, a server 20, and a storage device 30. The server 20 can be an application server deployed with Java backend services (such as a micro-segmentation management platform, security-related management systems, etc.) in this application embodiment. This server needs to support core capabilities such as dynamic contract verification, sandbox isolation, and atomic traffic switching to achieve zero-aware hot updates of the Java backend services. The storage device 30 stores the old and new versions of the Java backend service source code, compiled JAR packages (containing Java bytecode), OpenAPI specification contract files (JSON format) generated by Swagger, and log data during hot deployment (such as sandbox creation logs, traffic switching logs, recycling logs, etc.). The network 10 is the data transmission channel between the server 20 and the storage device 30, and between the server 20 and clients (such as user access terminals, other related service nodes), supporting shadow traffic replication, traffic scheduling during canary releases, and route configuration synchronization during atomic switching.

[0056] The description in this application focuses only on a single server 20. However, those skilled in the art should understand that the illustrated network 10, server 20, and storage 30 are intended to represent the operational logic of the electronic device (client), application server (deploying Java backend services), and data storage device (storing contracts, code, and logs) involved in the technical solution of this application. The detailed description of a single server and storage is at least for ease of explanation and does not imply any limitation on the number, type, or location of servers. In practical applications, multiple servers can be deployed to form a cluster according to the service scale, and hot deployment of large-scale services can be achieved through load balancing and collaboration with a service registry (such as Consul). The storage can also adopt a distributed storage architecture to store contract files (associated with Git repositories), code packages (associated with Maven repositories), and log data (associated with log management systems) respectively.

[0057] It should be noted that adding additional modules (such as a service registry, monitoring dashboard, log analysis module, etc.) or removing individual modules from the illustrated environment (such as retaining only the core application server and storage nodes) will not change the underlying concept of the example embodiment of this application, namely the hot deployment core logic of "contract pre-verification - sandbox isolation - multi-stage verification - atomic switching - resource reclamation". Furthermore, although for ease of explanation... Figure 1 The image shows a bidirectional arrow from the storage 30 to the server 20. However, those skilled in the art will understand that the sending and receiving of data such as “transferring contract files and new version JAR packages from the storage 30 to the server 20” and “writing hot deployment logs and verification reports from the server 20 to the storage 30” also need to be achieved through the network 10. The network 10 needs to ensure the real-time performance and stability of data transmission in order to support the millisecond-level data comparison of shadow traffic testing and the instantaneous configuration update of atomic switching.

[0058] It should be noted that the storage 30 in this embodiment can be, for example, a caching system (such as Redis, used to temporarily store routing configurations and canary release strategies), hard disk storage (such as NAS, used to persistently store contract files and historical version JAR packages), memory storage (such as server local memory, used to temporarily store bytecode data loaded in the sandbox environment), etc. Furthermore, the software update method proposed in this application is not only applicable to… Figure 1 The "single application server + independent storage" application scenario shown can also be used for other possible application scenarios, such as multi-service collaborative hot deployment under microservice architecture, remote hot update of cross-regional distributed services, etc., and this application embodiment does not impose any limitations.

[0059] To address the aforementioned problems, this application provides a software update method, specifically as follows: Figure 2 As shown, it includes:

[0060] Step 201: Generate a new version contract file based on the new version code. The new version contract file is used to provide a standardized description of the new version API.

[0061] In one or more possible embodiments, the aforementioned new version of the contract file is generated in the following manner, the specific process of which is as follows: Figure 3 As shown: In IntelliJ IDEA, to configure common OpenAPIs, taking Swagger as an example, first import Swagger into the pom file, then configure Swagger information, add configuration information to the configuration class, start the application, view the generated JSON contract file in the browser, and then submit the contract file to the remote code repository; for example, the micro-segmentation management platform needs to upgrade the agent traffic statistics core system from version v1.0 to v2.0, and add the function of statistics on northbound traffic data, and requires the upgrade to achieve zero downtime. Specifically, this includes: adding Swagger configuration in IntelliJ IDEA, importing the Swagger package into the pom file, writing the Swagger configuration file, adding Swagger annotations to the relevant entity classes, and users using Swagger 3.0 to define the northbound traffic interface contract, including two interfaces: / northBoundTraffic / create and / northBoundTraffic / query, where the / northBoundTraffic / create interface adds northFlow as an optional field; it is worth noting It's worth noting that the aforementioned ` / northBoundTraffic / create` and ` / northBoundTraffic / query` interfaces represent creating and querying northbound traffic data records, respectively. The ` / northBoundTraffic / create` interface typically uses the POST method, responsible for receiving northbound traffic data submitted by the client (the request body contains relevant fields, such as the optional `northFlow`), and creating a new data record on the server side—it's a write operation. The ` / northBoundTraffic / query` interface, on the other hand, typically uses the GET method, responsible for receiving the client's query conditions (usually passed via URL parameters) and returning a list of matching northbound traffic data records. It's a read-only operation; that is, if no user sends a query request on the client side, the ` / northBoundTraffic / query` interface will not be called. Therefore, there's no need to impose mandatory or optional restrictions on a passive query interface like ` / northBoundTraffic / query`.

[0062] In one or more possible embodiments, by configuring a Maven plugin in the pom.xml file of the project (referring to the micro-segmentation management platform illustrated above, which needs to upgrade the agent traffic statistics core system from version v1.0 to v2.0, add the function of statistical northbound traffic data, and require a zero-downtime upgrade), the new version contract file is automatically generated. Then, by running a specific Maven command, the plugin automatically scans all interfaces in the project, generates the contract file corresponding to the new version, and stores it in target / openapi / openapi.json (representing the default storage path and filename of the OpenAPI contract file automatically generated by the Maven plugin in the project directory). Subsequently, using the Git version control tool, the generated contract file is committed to the Git repository, and the git tag command is used to tag the contract file to facilitate the differentiation and management of different versions. Finally, by associating the contract file with the corresponding code version, it is ensured that each code version has its own unique and immutable interface contract history, thereby facilitating tracking and backtracking. This process effectively integrates interface contract management into the version control system of software development, improving the standardization and traceability of interface management.

[0063] Step 202: Obtain the comparison results between the new version of the contract file and the old version of the contract file, and confirm whether the comparison results meet the preset constraints.

[0064] In one or more possible embodiments, before obtaining the comparison results of the new version contract file and the old version contract file, it is necessary to determine whether the new version contract file and the old version contract file exist. For example, by integrating the API of the version control system (such as Git), the two versions of the OpenAPI specification file (the OpenAPI specification file, which is the contract file in this application) can be automatically located and obtained according to the preset tag rules (e.g., the old version tag `traffic-v1.0-contract` and the new version tag `traffic-v2.0-contract`). The OpenAPI specification file is usually in JSON format. Then, by verifying the tags and commit history, the source of the contract file is ensured to be credible and the version is traceable, and the verification distortion caused by file tampering or version mismatch is eliminated. Finally, the two original contract files of the new and old versions are subjected to standardized preprocessing, including parsing the JSON structure and unifying the sorting rules, such as sorting by interface path and method, to eliminate noise caused by differences in format arrangement or internal references, and generate a new and old version benchmark file that can be used for accurate comparison.

[0065] In one or more possible embodiments, the above-mentioned preset constraint is that no incompatible changes are introduced; confirming whether the above comparison results meet the preset constraint includes: confirming whether the above comparison results contain incompatible changes; wherein, the above-mentioned incompatible changes include: interface deletion, parameter type change and addition of required parameters; if yes, it is determined that the above-mentioned preset constraint is not met and an alarm notification is sent; if no, it is determined that the above-mentioned comparison results meet the preset constraint; specifically, it includes: automatically comparing the old and new version benchmark files item by item, the comparison process includes: (1) detecting whether the new version contract file has removed the API interface that has been declared in the old version and can be called by the client; (2) detecting whether the type of request parameter under the same interface has changed; (3) detecting whether the new version contract file has added required parameters;

[0066] Based on the comparison results above, it is determined whether the new version of the contract file introduces incompatible changes. These incompatible changes include the following three types: the new version of the contract file removes API interfaces declared and callable by clients from the old version; the type of request parameters under the same interface changes; and the new version of the contract file adds required parameters. Once any of these incompatible changes is detected, it indicates that the preset constraints are not met, and an alarm mechanism is automatically triggered. A structured error report is output in the log, clearly indicating the specific location, type, and modification suggestions of the incompatible change. Then, the subsequent hot deployment process is simultaneously blocked to prevent defective versions from entering the sandbox environment, thus intercepting potential risks before deployment. Only when the comparison results show no incompatible changes is the preset constraints met, allowing the process to proceed to the next stage of sandbox environment creation. Simultaneously, the automatically generated structured difference report not only ensures the machine-level rigor of the version compatibility review but also provides users with clear problem location and repair guidelines. The specific process is as follows: Figure 4 As shown, it includes the following steps:

[0067] Step 401: Determine whether the tags corresponding to the new version contract file and the old version contract file exist respectively; if yes, proceed to step 402; if no, proceed to step 407.

[0068] Step 402: Obtain the new version contract file and the old version contract file based on the tags;

[0069] Step 403: Determine whether the versions corresponding to the new version contract file and the old version contract file are correct; if yes, proceed to step 404; if no, proceed to step 407.

[0070] Step 404: Perform standardization preprocessing on the new version contract file and the old version contract file to obtain the new and old version baseline files;

[0071] Step 405: Determine whether the new version contract file contains incompatible changes based on the old and new version baseline files; if not, proceed to step 406; if yes, proceed to step 407.

[0072] Step 406: Determine if the preset constraints are met and automatically generate a structured difference report;

[0073] Step 407: Trigger the alarm mechanism and generate a structured error report.

[0074] Step 203: When the above comparison results meet the preset constraints, verify whether the actual API interface of the new version code at runtime is consistent with the API interface contained in the new version contract file.

[0075] In one or more possible embodiments, before verifying whether the actual API interface of the new version code at runtime is consistent with the API interface contained in the new version contract file, the method further includes: creating an independent sandbox environment based on a custom class loader, wherein the sandbox environment is isolated from the environment currently running the old version service; loading and initializing the bytecode corresponding to the new version code in the sandbox environment, and creating a new version service. Specifically, after confirming that the new version contract file does not contain incompatible changes, the following hot deployment process will be executed: The hot deployment system can call a dedicated sandbox management module. The aforementioned sandbox management module first instantiates a custom class loader (e.g., named `HotDeployClassLoader`). The custom class loader inherits from `URLClassLoader` and overrides the `loadClass` and `findClass` methods. Specifically, it achieves strict code isolation through a variant of the parent delegation model: For classes that clearly belong to the new version package path (e.g., `com.example.service.v2`), they are loaded by themselves from the new version JAR package (e.g., `traffic-core-2.0.jar`); for other classes, they are delegated to the parent class loader (i.e., the original application class loader) for loading, thereby ensuring the physical isolation between the new version bytecode and the old version service during JVM runtime, and completely avoiding stability issues caused by class conflicts. Subsequently, an independent sandbox environment is created within the current JVM process. This independent sandbox environment has its own class definition domain and memory allocation area. All bytecode files required by the new version service are loaded through `HotDeployClassLoader`, completing the creation of the new version service instance. The initialization process of the new version service can be tracked by monitoring the log files of the target application. The target application refers to the new version software corresponding to the new version service mentioned in this application (e.g., the agent traffic statistics core system v2.0 mentioned above). For example, after the sandbox environment is successfully initialized, the log will output information such as `[Sandbox]TrafficServiceV2 initialized with 28 endpoints`, clearly indicating the number of API endpoints that the new service instance has been prepared and exposed. It can also show that the sandbox environment initially occupies about 1.5GB of heap memory, which is isolated from the memory space occupied by the old version service, providing a safe and independent execution environment for subsequent parallel operation and verification.

[0076] In one or more possible embodiments, this application also provides a method for confirming the completion status of hot deployment through log monitoring, mainly used to confirm whether the new version service has been successfully created and initialized in the sandbox environment, specifically as follows: Figure 5 As shown, it includes:

[0077] Step 501: Obtain the target application's log file;

[0078] Step 502: Confirm whether the above log file contains hot deployment process information. If yes, proceed to step 503; otherwise, proceed to step 504.

[0079] Step 503: Confirm whether the hot deployment was successful based on the hot deployment process information above; if yes, proceed to step 505; if no, proceed to step 506.

[0080] Step 504: Continue monitoring the target application's log files;

[0081] Step 505: Confirm hot deployment is complete;

[0082] Step 506: Troubleshooting based on the hot deployment process information described above.

[0083] In one or more possible embodiments, verifying whether the actual API interface of the new version code at runtime is consistent with the API interface contained in the new version contract file includes: obtaining the actual exposed API interface in the new version service after the new version service starts; comparing the actual exposed API interface with the API interface defined in the new version contract file. Specifically, this includes: obtaining class loading information in the sandbox environment in real time based on Java Agent technology to obtain the actual exposed API interface in the new version service; verifying whether the annotation attributes of key parameters are consistent with the new version contract file through reflection mechanism, including but not limited to checking whether the configuration of required parameter fields conforms to the agreement, such as ensuring that the northFlow parameter of TrafficControllerV2 meets the contract requirements of @RequestParam(required=false); comprehensively verifying whether the actual exposed interface path, HTTP method type, parameter data structure and API specification defined in the contract file are completely matched, thereby ensuring that the code implementation is consistent with the API interface definition in the new version contract file. For example, if an interface not declared in the contract is found, the exception handling mechanism will be directly triggered. The specific process is as follows: Figure 6 As shown, it includes:

[0084] Step 601: Scan the classes already loaded in the sandbox to obtain the API interfaces actually exposed in the new version of the service.

[0085] Step 602: Determine whether the actual exposed API interface is consistent with the API interface defined in the new version contract file. If yes, proceed to step 603; otherwise, proceed to step 605.

[0086] Step 603: Verify whether the annotation attributes of the key parameters conform to the new version contract agreement through reflection; if yes, proceed to step 604; if no, proceed to step 605.

[0087] Step 604: Confirm that there are no deviations at the code level;

[0088] Step 605: Send an alarm notification and terminate the process.

[0089] Step 204: After confirming consistency, route traffic to the new version service according to the preset canary release strategy, and monitor whether the running status of the new version service is abnormal during the canary release period; if not, proceed to step 205; if yes, proceed to step 206.

[0090] Step 205: Update the old version of the service to the new version.

[0091] Step 206: Trigger the exception handling mechanism.

[0092] In one or more possible embodiments, the above-mentioned routing of traffic to the new version service according to a preset canary release strategy, and monitoring whether the operation status of the new version service is abnormal during the canary release period, includes: testing the new version service according to a preset simulated request; after confirming that the test is passed, gradually routing a preset proportion of real traffic to the new version service according to the preset canary release strategy, and monitoring whether the operation status of the new version service is abnormal during the canary release period; after confirming that the operation status is not abnormal, performing atomic traffic switching to switch user traffic from being routed to the old version service to being routed to the new version service; wherein, the atomic traffic switching is to update the routing rules or update the configuration of the service registry. The detailed process includes the following steps: First, a series of pre-set simulated requests are sent to the newly initialized service. These requests cover core business scenarios and abnormal use cases to verify the basic functional correctness and performance benchmark of the service. After the simulation test passes, the system starts the shadow traffic test phase: approximately 5% of real online read-only requests (such as query operations) are copied and sent to both the old and new versions of the service. The response results from the old and new versions are collected. These response results may include key performance indicators (such as 99-line latency, throughput, and error rate) and business data consistency (such as the integrity of the returned results verified by MD5 hash). Typical data comparison examples are shown in the table below.

[0093] Old version service v1.0 New version service v2.0 99-line delay 210ms 195ms Traffic blocking rate 0.15％ 0.22％

[0094] Once the performance and consistency checks above are confirmed to be satisfactory, the canary release phase begins. The canary release adopts a gradual rollout strategy: firstly, during off-peak business hours (e.g., 02:00), 5% of real write traffic is routed to the new version service, while simultaneously monitoring the operational status of the new version service in real time. This operational status includes at least one of the following: CPU utilization, memory usage, thread pool status, request error rate, and response latency. During this period, if the operational status includes a request error rate, it needs to be determined whether the request error rate is consistently below 0.001%. If so, it is determined that the operational status is not abnormal. When the new version service is released within a preset time period… Only after the service remains stable will the update to the new version be performed. It's worth noting that, for example, an anomaly is only confirmed when CPU utilization rises by 20%. However, if a 5% increase in northbound traffic CPU utilization is detected, a dynamic rate-limiting strategy will be automatically triggered to maintain service stability, and the rate of increase will be gradually increased after adjusting the strategy (e.g., increasing the traffic ratio to 10% at 03:00). The aforementioned atomic traffic switching refers to instantly and seamlessly switching all user traffic to the new version service through atomic operations (such as updating the Nginx+Consul routing configuration). If an anomaly is detected during the canary release period, such as a request error rate reaching 0.1%, a rollback mechanism will be immediately triggered, redirecting all traffic back to the old version service and terminating the current release process.

[0095] In one or more possible embodiments, if the actual API interface of the new version code at runtime is inconsistent with the API interface contained in the new version contract file, an automatic rollback process will be triggered simultaneously. First, the rollback service will be called to terminate the current deployment, ensuring that any abnormal traffic is blocked from reaching the new version service, so as to achieve rapid service recovery and business continuity assurance.

[0096] In one or more possible embodiments, the system further includes: after all traffic has been switched to the new version and the service is running stably, automatically executing the old version resource unloading and recycling process. First, the listening port of the old version service instance (such as port 8081 originally occupied by v1.0) is safely closed, and the JVM heap memory and other resources it occupies are released, so that the total JVM memory is reduced from 24GB to 16GB. Then, the garbage collection logs confirm that the class loader and more than 6,000 class instances related to the old version have been successfully unloaded and recycled, completely avoiding memory leaks. After the resources are released, the system performs an overall performance verification of this upgrade. Key indicators show that the northbound traffic recognition rate has increased by 40%, and the peak throughput has increased from 80,000 TPS to 120,000 TPS, effectively confirming the successful execution of resource recycling and version switching.

[0097] According to a software update method provided in this application, such as Figure 7As shown, the process includes contract pre-verification, sandbox environment construction, runtime interface verification, gradual canary release, and atomic traffic switching. It achieves risk interception by automatically comparing the old and new API contracts, uses a custom class loader to achieve isolated parallel operation of the old and new versions in the same JVM, and completes closed-loop verification and lossless switching by relying on shadow traffic and multi-stage release strategies. It can achieve full-process coverage from code compatibility and runtime security to release stability, and ultimately achieve a highly reliable hot deployment effect with zero business interruption, efficient resource utilization, and second-level rollback capability, significantly improving the continuous delivery and security operation and maintenance level of critical systems.

[0098] Example 2

[0099] Corresponding to the above-described software update method, the present invention also proposes a software update apparatus, specifically, as follows: Figure 8 As shown, it includes:

[0100] Contract generation module 801 is used to generate a new version contract file based on the new version code. The new version contract file is used to provide a standardized description of the new version API.

[0101] The contract pre-verification module 802 is used to obtain the comparison results between the new version of the contract file and the old version of the contract file, and to confirm whether the comparison results meet the preset constraints.

[0102] The runtime verification module 803 is used to verify whether the actual API interface of the new version code at runtime is consistent with the API interface contained in the new version contract file when the above comparison results meet the preset constraints.

[0103] The status monitoring module 804 is used to route traffic to the new version service according to the preset canary release strategy after confirming consistency, and to monitor whether the running status of the new version service is abnormal during the canary release period.

[0104] The update and control module 805 is used to update the old version of the service to the new version if there is no abnormality in the running status, and to trigger the exception handling mechanism if there is an abnormality in the running status.

[0105] Since the device embodiments of the present invention correspond to the method embodiments described above, details not disclosed in the device embodiments can be referred to in the method embodiments described above, and will not be repeated in the present invention.

[0106] Example 3

[0107] This application also provides an electronic device, including 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, the instructions being executed by the at least one processor to enable the at least one processor to perform the above-described software update method.

[0108] like Figure 9 As shown, the device includes a processor 901, a memory 902, a communication interface 903, and a bus 904. The processor 901, memory 902, and communication interface 903 are interconnected via the bus 904.

[0109] Processor 901 is configured to read instructions from memory 902 and execute them, so that at least one processor can execute the software update method provided in the above embodiments.

[0110] The memory 902 is used to store various instructions and programs for the software update method provided in the above embodiments.

[0111] The 904 bus can be 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 representation, Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0112] Processor 901 can be a central processing unit (CPU), a network processor (NP), a graphics processing unit (GPU), or any combination of CPU, NP, and GPU. It can also be a hardware chip. The aforementioned hardware chip can be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0113] Example 4

[0114] In addition, this application also provides a computer-readable storage medium, such as Figure 10 As shown, the computer storage medium stores a computer program that is used to cause the computer to perform any of the methods described in the above embodiments.

[0115] The memory may include a readable medium in the form of volatile memory, such as random access memory (RAM) 1001 and / or cache memory 1002, and may further include read-only memory (ROM) 1003.

[0116] The memory may also include a program / utility 1005 having a set (at least one) of program modules 1004, such program modules 1004 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0117] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0118] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0119] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1The function specified in one or more boxes.

[0120] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0121] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A software update method, characterized in that, include: A new version contract file is generated based on the new version code. The aforementioned new version contract file is used to provide a standardized description of the new version API. Obtain the comparison results between the new version of the contract file and the old version of the contract file, and confirm whether the comparison results meet the preset constraints. When the comparison result is determined to meet the preset constraints, verify whether the actual API interface of the new version code at runtime is consistent with the API interface contained in the new version contract file; After confirming consistency, traffic is routed to the new version service according to the preset canary release strategy, and the operation status of the new version service during the canary release period is monitored to see if any abnormalities occur. If not, the old version of the service will be updated to the new version; if yes, the exception handling mechanism will be triggered.

2. The method according to claim 1, characterized in that, The preset constraint condition is that no incompatible changes are introduced; Confirming whether the comparison results meet preset constraints includes: Confirm whether the comparison results contain incompatible changes; wherein, the incompatible changes include: interface deletion, parameter type change, and addition of required parameters; If so, it is determined that the preset constraint condition is not met, and an alarm notification is sent; If not, then the comparison result is determined to meet the preset constraints.

3. The method according to claim 1, characterized in that, Before verifying whether the actual API interface of the new version code at runtime is consistent with the API interface contained in the new version contract file, the process also includes: Create an independent sandbox environment based on a custom class loader. This sandbox environment is isolated from the environment currently running older versions of services. Load and initialize the bytecode corresponding to the new version code in the sandbox environment to create a new version service.

4. The method according to claim 1, characterized in that, Verify whether the actual API interface of the new version code at runtime is consistent with the API interface contained in the new version contract file, including: After the new version of the service is started, obtain the API interfaces actually exposed in the new version of the service; The actual exposed API interfaces are compared with the API interfaces defined in the new version contract file.

5. The method according to claim 1, characterized in that, The exception handling mechanism includes: Invoke the rollback service to terminate the deployment of the new version of the service; Verify the traffic routing rules to ensure that all traffic is routed to the older version of the service.

6. The method according to claim 1, characterized in that, The step of routing traffic to the new version service according to a preset canary release strategy and monitoring whether the operation status of the new version service is abnormal during the canary release includes: Test the new version of the service based on preset simulated requests; Once the test is confirmed to be successful, a predetermined proportion of real traffic will be gradually routed to the new version service according to the preset canary release strategy, and the operation status of the new version service during the canary release period will be monitored to see if any abnormalities occur.

7. The method according to claim 6, characterized in that, The process of updating the old version of the service to the new version includes: After confirming that there are no abnormalities in the operating status, an atomic traffic switch is performed to switch user traffic from being routed to the old version service to being routed to the new version service; wherein, the atomic traffic switch is to update the routing rules or update the configuration of the service registry.

8. A software update device, characterized in that, include: The contract generation module is used to generate a new version contract file based on the new version code. The new version contract file is used to provide a standardized description of the new version API. The contract pre-verification module is used to obtain the comparison results between the new version of the contract file and the old version of the contract file, and to confirm whether the comparison results meet the preset constraints. The runtime verification module is used to verify whether the actual API interface of the new version code at runtime is consistent with the API interface contained in the new version contract file when the comparison result meets the preset constraints. The status monitoring module is used to route traffic to the new version service according to the preset canary release strategy after confirming consistency, and to monitor whether the running status of the new version service is abnormal during the canary release period. The update and control module is used to update the old version of the service to the new version if there are no abnormalities in the running status, and to trigger the exception handling mechanism if there are abnormalities in the running status.

9. An electronic device, characterized in that, The electronic device 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 to enable the at least one processor to perform any one of the methods claimed in claims 1-7.

10. A computer storage medium, characterized in that, The computer storage medium stores a computer program that causes the computer to perform any one of the methods claimed in claims 1-7.

Images