Version upgrading method and device for platform application based on load balancing

Abstract

The invention provides a version upgrading method and device for platform type applications based on load balancing, and relates to the technical field of data processing. The method comprises the following steps: in response to an instruction for upgrading the version of a platform type application, editing release batch information of the platform type application on at least one cluster through a preset release template to obtain a plurality of batches, a server identifier of each batch and the number of servers of each batch; isolating the external flow of the first batch of servers in the first cluster at the load balancing equipment end, and upgrading the version of the platform application on the first batch of servers when no flow access exists on the first batch of servers; and checking the platform type application after the version upgrading is completed, and if the checking is passed, recovering the external flow of the first batch of servers at the load balancing equipment end. According to the embodiment of the invention, the service flow can be smoothly removed from the load balance, and no perception to the outside during version upgrading is ensured.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and apparatus for version upgrade of platform applications based on load balancing. Background Technology

[0002] Blue-green deployment requires redundant deployment of the new version of the service. Generally, the instance specifications and number of the new version are consistent with the old version, essentially creating two identical deployment environments for the service. However, only the old version provides service externally, while the new version serves as a hot standby. When the service is upgraded, traffic is switched between blue-green, with the old version acting as the hot standby. Due to the redundant deployment, there's no need to worry about insufficient resources for the new version. If a serious problem occurs after the new version goes live, all traffic needs to be switched back to the old version, significantly shortening the fault recovery time. Once the new version has fixed the problem and been redeployed, traffic from the old version is switched back to the new version.

[0003] However, blue-green deployment is costly, and the cost snowballs when multiple scaling deployments are required. Furthermore, switching traffic between blue-green environments can interrupt current business requests. Careful consideration must be given to how to handle these interruptions. For transactions that are only partially processed, should an error message be displayed asking the user to retry, or should the transactions be attempted to be carried over to the new environment? One possible solution is to feed all transactions in parallel to both environments simultaneously. In this case, any duplicate data needs to be processed after deployment, making version upgrades inefficient. Therefore, this technical problem urgently needs to be solved. Summary of the Invention

[0004] In view of the above problems, this application is proposed to provide a method, apparatus, and electronic device for version upgrade of load-balanced platform applications that overcomes or at least partially solves the above problems. The technical solution is as follows: Firstly, a method for version upgrades of platform applications based on load balancing is provided. The platform applications are deployed in at least one cluster and provide services to the outside world simultaneously through dynamic domain names. The method includes: In response to the instruction to upgrade the version of a platform application, the release batch information of the platform application on at least one cluster is edited using a preset release template to obtain multiple batches, the server identifier of each batch, and the number of servers in each batch. Select any cluster from at least one cluster as the first cluster; External traffic to the first batch of servers in the first cluster is isolated at the load balancing device. Once there is no traffic access on the first batch of servers, the platform application version is upgraded on the first batch of servers. After the platform applications on the first batch of servers have been upgraded, the upgraded platform applications are checked. If the check passes, the external traffic to the first batch of servers is restored on the load balancer.

[0005] In one possible implementation, after the platform applications on the first batch of servers have completed their version upgrades, and after checking the upgraded platform applications, the method further includes: If the check fails, the platform application version will be rolled back on the first batch of servers, and the application upgrade will be terminated.

[0006] In one possible implementation, after the external traffic to the first batch of servers is restored at the load balancing device, the method further includes: During the process of the first batch of servers providing services to the outside world, the services are verified. After the verification is passed, the version upgrade of the platform application on the second batch of servers in the first cluster begins. External traffic to the second batch of servers in the first cluster is isolated on the load balancing device. When there is no traffic access on the second batch of servers, the version upgrade of the platform application is performed on the second batch of servers. After the platform applications on the second batch of servers have been upgraded, the upgraded platform applications will be checked. If the check passes, external traffic to the second batch of servers will be restored on the load balancer.

[0007] In one possible implementation, after the platform applications on the second batch of servers have completed their version upgrades, and after checking the upgraded platform applications, the method further includes: If the check fails, the platform application version will be rolled back on the second batch of servers, and the application upgrade will be terminated.

[0008] In one possible implementation, after restoring external traffic to the second batch of servers on the load balancing device side, the method further includes: If all servers on the first cluster have completed the version upgrade of the platform application, the service is verified during the process of the servers on the first cluster providing services to the outside world. After the verification is passed, any cluster other than the first cluster is selected from at least one cluster as the second cluster. External traffic to the third batch of servers in the second cluster is isolated at the load balancing device. When there is no traffic access on the third batch of servers, the platform application version is upgraded on the third batch of servers. After the platform applications on the third batch of servers have been upgraded, the upgraded platform applications will be checked. If the check passes, the external traffic to the third batch of servers will be restored on the load balancer.

[0009] In one possible implementation, after the platform applications on the third batch of servers have completed their version upgrades, and after checking the upgraded platform applications, the method further includes: If the check fails, the platform application version will be rolled back on the third batch of servers, and the application upgrade will be terminated.

[0010] In one possible implementation, after restoring external traffic to the third batch of servers on the load balancing device side, the method further includes: During the process of providing services to the outside world on the third batch of servers, the services are verified. After the verification is passed, the version upgrade of the platform application on the fourth batch of servers in the second cluster begins. The external traffic of the fourth batch of servers in the second cluster is isolated on the load balancing device. When there is no traffic access on the fourth batch of servers, the version upgrade of the platform application is performed on the fourth batch of servers. After the platform applications on the fourth batch of servers have been upgraded, the upgraded platform applications will be checked. If the check passes, the external traffic to the fourth batch of servers will be restored on the load balancer.

[0011] In one possible implementation, after restoring external traffic to the fourth batch of servers on the load balancing device side, the method further includes: If all servers on the second cluster have completed the version upgrade of platform applications, the services provided by the servers on the second cluster are verified. After the verification is passed, any cluster other than the first and second clusters is selected from at least one cluster as the third cluster. This process is repeated to upgrade the version of platform applications on each batch of servers in the third cluster.

[0012] Secondly, a version upgrade device for a platform application based on load balancing is provided. The platform application is deployed in at least one cluster and provides services to the outside world simultaneously through dynamic domain names. The device includes: The editing unit is used to respond to the instruction to upgrade the version of the platform application. It edits the release batch information of the platform application on at least one cluster through a preset release template to obtain multiple batches, the server identifier of each batch and the number of servers in each batch. A selection unit is used to select any cluster from at least one cluster as the first cluster; The upgrade unit is used to isolate external traffic to the first batch of servers in the first cluster on the load balancer. When there is no traffic access to the first batch of servers, the platform application is upgraded on the first batch of servers. After the platform application is upgraded on the first batch of servers, the upgraded platform application is checked. If the check passes, the external traffic to the first batch of servers is restored on the load balancer.

[0013] In one possible implementation, the upgrade unit is further configured to: After the platform applications on the first batch of servers have been upgraded, the upgraded platform applications will be checked. If the check fails, the platform application versions will be rolled back on the first batch of servers, and the application upgrade will be terminated.

[0014] In one possible implementation, the upgrade unit is further configured to: After restoring external traffic to the first batch of servers on the load balancer, the services provided by the first batch of servers are verified. After successful verification, the platform application version upgrade is started on the second batch of servers in the first cluster. External traffic to the second batch of servers in the first cluster is isolated on the load balancer. When there is no traffic access on the second batch of servers, the platform application version upgrade is performed on the second batch of servers. After the platform applications on the second batch of servers have been upgraded, the upgraded platform applications will be checked. If the check passes, external traffic to the second batch of servers will be restored on the load balancer.

[0015] In one possible implementation, the upgrade unit is further configured to: After the platform applications on the second batch of servers have been upgraded, the upgraded platform applications will be checked. If the check fails, the platform application versions will be rolled back on the second batch of servers, and the application upgrade will be terminated.

[0016] In one possible implementation, the upgrade unit is further configured to: After the external traffic of the second batch of servers is restored on the load balancing device, if all servers on the first cluster have completed the version upgrade of the platform application, the service is verified during the process of the servers on the first cluster providing services to the outside world. After the verification is passed, any cluster other than the first cluster is selected from at least one cluster as the second cluster. External traffic to the third batch of servers in the second cluster is isolated at the load balancing device. When there is no traffic access on the third batch of servers, the platform application version is upgraded on the third batch of servers. After the platform applications on the third batch of servers have been upgraded, the upgraded platform applications will be checked. If the check passes, the external traffic to the third batch of servers will be restored on the load balancer.

[0017] In one possible implementation, the upgrade unit is further configured to: After the platform applications on the third batch of servers have been upgraded, the upgraded platform applications will be checked. If the check fails, the platform application versions will be rolled back on the third batch of servers, and the application upgrade will be terminated.

[0018] In one possible implementation, the upgrade unit is further configured to: After restoring external traffic to the third batch of servers on the load balancer side, the services provided by the third batch of servers are verified. After the verification is successful, the version upgrade of the platform application on the fourth batch of servers in the second cluster begins. External traffic to the fourth batch of servers in the second cluster is isolated on the load balancer side. When there is no traffic access on the fourth batch of servers, the version upgrade of the platform application is performed on the fourth batch of servers. After the platform applications on the fourth batch of servers have been upgraded, the upgraded platform applications will be checked. If the check passes, the external traffic to the fourth batch of servers will be restored on the load balancer.

[0019] In one possible implementation, the upgrade unit is further configured to: After restoring external traffic to the fourth batch of servers on the load balancing device, if all servers on the second cluster have completed the version upgrade of platform applications, the services provided by the servers on the second cluster are verified. After the verification is passed, any cluster other than the first and second clusters is selected from at least one cluster as the third cluster. This process is repeated to upgrade the platform applications on each batch of servers in the third cluster.

[0020] Thirdly, an electronic device is provided, comprising a processor and a memory, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the version upgrade method for a load-balanced platform application as described in any of the preceding claims.

[0021] Using the above technical solutions, the present application provides a method, apparatus, and electronic device for upgrading platform applications based on load balancing. The method responds to an instruction to upgrade the version of a platform application by editing the batch information of the platform application's release on at least one cluster using a preset release template to obtain multiple batches, server identifiers for each batch, and the number of servers in each batch. It then selects any one of the at least one clusters as the first cluster. At the load balancing device, it isolates external traffic to the first batch of servers in the first cluster. When there is no traffic access to the first batch of servers, it performs a version upgrade of the platform application on the first batch of servers. After the version upgrade of the platform application on the first batch of servers is completed, it checks the upgraded platform application. If the check passes, it restores external traffic to the first batch of servers at the load balancing device. As can be seen, the embodiments of this application can smoothly remove business traffic from the load balancer, ensuring that there is no external awareness during version upgrades. This solves the problem of interruption of current business requests when traffic switches between blue and green modes in the prior art. Furthermore, this embodiment can achieve automatic switching by configuring the release template, improving the version upgrade efficiency of platform applications, reducing operational risks, and solving the problems of numerous manual operation steps, complex upgrade steps, and high error rates involved in blue-green switching in the prior art. It realizes a seamless version upgrade of cluster systems based on the principle of load balancing isolation. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0023] Figure 1 A flowchart illustrating a version upgrade method for a load-balanced platform application provided in an embodiment of this application is shown. Figure 2 This paper illustrates a structural diagram of a version upgrade device for a platform application based on load balancing, as provided in an embodiment of this application. Figure 3 A structural diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0024] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the term "comprising" and its variations should be interpreted as open-ended terms meaning "including but not limited to."

[0026] To address the aforementioned technical issues, this application provides a method for upgrading the version of a platform application based on load balancing. Here, the platform application is deployed in at least one cluster and provides services to the outside world simultaneously through a dynamic domain name.

[0027] like Figure 1 As shown, the version upgrade method for this load-balancing-based platform application may include the following steps S101 to S104: Step S101: In response to the instruction to upgrade the version of the platform application, the release batch information of the platform application on at least one cluster is edited using a preset release template to obtain multiple batches, the server identifier of each batch, and the number of servers in each batch. Step S102: Select any cluster from at least one cluster as the first cluster; Step S103: Isolate the external traffic of the first batch of servers in the first cluster on the load balancing device. When there is no traffic access on the first batch of servers, upgrade the version of the platform application on the first batch of servers. Step S104: After the platform applications on the first batch of servers have been upgraded, check the upgraded platform applications. If the check passes, restore the external traffic of the first batch of servers on the load balancing device.

[0028] This application embodiment can smoothly remove business traffic from the load balancer, ensuring that the upgrade is seamless and unnoticed by external parties. It solves the problem of interruption of current business requests when traffic switches between blue and green modes in the prior art. Furthermore, this embodiment can achieve automatic switching by configuring the release template, improving the efficiency of version upgrades for platform applications, reducing operational risks, and solving the problems of numerous manual operation steps, complex upgrade steps, and high error rates involved in blue-green switching in the prior art. It realizes a seamless version upgrade of cluster systems based on the principle of load balancing isolation.

[0029] This application embodiment provides a possible implementation method. After the platform application version upgrade is completed on the first batch of servers, step S104 above, after checking the platform application after the version upgrade, may further include the following step A1: If the check fails in step A1, the platform application version will be rolled back on the first batch of servers, and the application upgrade will be terminated.

[0030] This embodiment uses strict checkpoints and rollback strategies to control upgrade risks to the greatest extent possible, ensuring the stability and continuity of online business.

[0031] This application embodiment provides a possible implementation method. After restoring the external traffic of the first batch of servers on the load balancing device side, step S104 above may further include the following steps B1 and B2: Step B1: During the process of the first batch of servers providing services to the outside world, the services are verified. After the verification is passed, the version upgrade of the platform application on the second batch of servers in the first cluster is started. The external traffic of the second batch of servers in the first cluster is isolated on the load balancing device. When there is no traffic access on the second batch of servers, the version upgrade of the platform application is performed on the second batch of servers. Step B2: After the platform applications on the second batch of servers have been upgraded, check the upgraded platform applications. If the check passes, restore the external traffic to the second batch of servers on the load balancer.

[0032] This embodiment implements a phased upgrade process. The load balancer first isolates the first batch of servers from the service pool, preventing them from receiving new external traffic. After their existing connections naturally clear or time out, the upgrade is then performed on these servers. Once completed, traffic is switched back to the upgraded first batch, and service verification is immediately performed. After successful verification, a similar process is repeated for the second batch. This means that throughout the entire upgrade window, some servers (such as the first batch) are always online and processing user requests normally, thus avoiding service interruptions caused by the upgrade and achieving a seamless or smooth upgrade.

[0033] This application embodiment provides a possible implementation method. After the platform application version upgrade is completed on the second batch of servers, step B2 above, after checking the upgraded platform application, may further include the following step B3: Step B3: If the check fails, roll back the platform application version on the second batch of servers and end the application upgrade process.

[0034] This embodiment uses strict checkpoints and rollback strategies to control upgrade risks to the greatest extent possible, ensuring the stability and continuity of online business.

[0035] This application embodiment provides a possible implementation method. After step B2 above restores the external traffic of the second batch of servers on the load balancing device side, it may further include the following steps C1 to C3: Step C1: If all servers on the first cluster have completed the version upgrade of the platform application, the service is verified during the process of the servers on the first cluster providing services to the outside world. After the verification is passed, any cluster other than the first cluster is selected from at least one cluster as the second cluster. Step C2: Isolate external traffic to the third batch of servers in the second cluster on the load balancing device. When there is no traffic access on the third batch of servers, upgrade the version of the platform application on the third batch of servers. Step C3: After the platform applications on the third batch of servers have been upgraded, check the upgraded platform applications. If the check passes, restore the external traffic of the third batch of servers on the load balancer.

[0036] This embodiment is an implementation method for performing batch rolling upgrades of platform applications on servers in multiple clusters under a load-balanced environment, which can safely and smoothly complete the system upgrade while ensuring high availability of services.

[0037] This application embodiment provides a possible implementation method. After the platform application version upgrade is completed on the third batch of servers, step C3 above, after checking the upgraded platform application, may further include the following step C4: If the check fails in step C4, the platform application version will be rolled back on the third batch of servers, and the application upgrade will be terminated.

[0038] This embodiment uses strict checkpoints and rollback strategies to control upgrade risks to the greatest extent possible, ensuring the stability and continuity of online business.

[0039] This application embodiment provides a possible implementation method. After step C3 above restores the external traffic of the third batch of servers on the load balancing device side, it may also include the following steps D1 and D2: Step D1: During the process of providing services to the outside world on the third batch of servers, the services are verified. After the verification is passed, the version upgrade of the platform application on the fourth batch of servers in the second cluster is started. The external traffic of the fourth batch of servers in the second cluster is isolated on the load balancing device. When there is no traffic access on the fourth batch of servers, the version upgrade of the platform application is performed on the fourth batch of servers. Step D2: After the platform applications on the fourth batch of servers have been upgraded, check the upgraded platform applications. If the check passes, restore the external traffic of the fourth batch of servers on the load balancer.

[0040] In this embodiment, the load balancer acts as a traffic scheduling hub during the upgrade process. It achieves a seamless upgrade for users by isolating (step D1) and restoring (step D2) external traffic to the fourth batch of servers at specific time points. This means that throughout the entire upgrade window, user requests can always be handled by the upgraded third batch of servers or other healthy servers within the cluster, thus avoiding service interruptions and ensuring a smooth user experience.

[0041] This application embodiment provides a possible implementation method. After step D2 above restores the external traffic of the fourth batch of servers on the load balancing device, it may further include the following step E1: Step E1: If all servers on the second cluster have completed the version upgrade of platform applications, the services provided by the servers on the second cluster are verified. After the verification is passed, any cluster other than the first and second clusters is selected from at least one cluster as the third cluster. This process is repeated to upgrade the version of platform applications on each batch of servers in the third cluster.

[0042] This embodiment encapsulates a repeatable and standardized upgrade process (the operation process for the first, second, and third clusters is similar), which is highly suitable for automation and can significantly reduce the risk of human error and communication costs in complex operation and maintenance. At the same time, it demonstrates good horizontal scalability; by upgrading and verifying cluster by cluster, this process can be applied to large-scale systems managing dozens or even hundreds of clusters.

[0043] The above introduces Figure 1 The embodiments shown have various implementation methods for each stage. The following will further explain the version upgrade method of the load-balancing platform application of this application through specific embodiments.

[0044] In this specific embodiment, taking the bank's front-end system as an example, the application version upgrade is carried out in four batches for cluster deployment.

[0045] 1) Platform applications are deployed in a cluster, providing services simultaneously to the outside world through dynamic domain names. Before upgrading the application, batch information is edited using a release template, allowing for flexible arrangement of the batches to be changed and the number of servers in each batch.

[0046] 2) Isolate the external traffic of the first batch of servers in cluster A on the load balancer F5 end. When there is no traffic access on the first batch of servers, perform the version upgrade on the first batch of servers.

[0047] In this step, F5 is the name of the load balancing device. Its working logic is as follows: it receives all client requests and then intelligently distributes them to the normal backend servers using a preset load balancing algorithm (such as round-robin, least connections, etc.). After the backend server processes the request, it usually returns the response to the F5 device first, and then the F5 returns it to the client. In this way, the client only interacts with the virtual IP of the F5 and does not need to be aware of the complex backend server structure.

[0048] 3) After the first batch of application upgrades is completed, the application release will be thoroughly checked. If any problems are found and cannot be resolved in a short time, a rollback will be immediately implemented, and the application upgrade will be terminated. If the check is successful, the traffic from the first batch will be restored through load balancing, and the business will be thoroughly verified after traffic restoration.

[0049] 4) After the first batch of verifications is complete, the second batch of cluster upgrades will begin. External traffic to the second batch of servers in the cluster will be isolated on the load balancer F5. When there is no traffic access to the second batch of servers, the version upgrade will be performed on the second batch of servers. After the second batch of upgrades is completed, the upgrades will be verified and traffic will be restored. At this point, the entire A cluster has been upgraded. The A cluster will be verified through manual verification, business verification, transaction monitoring and other means.

[0050] 5) After verifying cluster A, begin upgrading cluster B. The load balancer (F5) isolates traffic to the third batch of servers in cluster B. When there is no traffic access, begin upgrading the third batch of servers. After the upgrade is complete, check the third batch of servers. Once the check is complete, remove the load balancer traffic isolation and perform business verification on the third batch of servers.

[0051] 6) After the third batch of servers in cluster B completes its upgrade, traffic isolation begins for the fourth batch of servers. The load balancer (F5) manages external traffic to the fourth batch of servers in cluster B. When there is no traffic access to the fourth batch of servers, the version upgrade is performed on them. Once the fourth batch of servers has completed its upgrade and the load balancer traffic has recovered, a final overall verification is conducted. This ensures that the new version of the application provides service simultaneously in both clusters A and B, thus completing the seamless deployment.

[0052] It should be noted that the sequence numbers of the steps in the above embodiments do not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. In practical applications, all the above possible implementation methods can be arbitrarily combined in a combined manner to form possible embodiments of this application, which will not be described in detail here.

[0053] Based on the load-balancing-based platform application version upgrade method provided in the above embodiments, and based on the same inventive concept, this application also provides a load-balancing-based platform application version upgrade device.

[0054] Figure 2 This is a structural diagram of a version upgrade device for a platform application based on load balancing, provided in an embodiment of this application. For example... Figure 2 As shown, the version upgrade device for the load-balanced platform application may specifically include an editing unit 210, a selection unit 220, and an upgrade unit 230.

[0055] The editing unit 210 is used to respond to the instruction to upgrade the version of the platform application. It edits the release batch information of the platform application on at least one cluster through a preset release template to obtain multiple batches, the server identifier of each batch and the number of servers in each batch. Here, the platform application is deployed in at least one cluster and provides services to the outside world simultaneously through dynamic domain names. Selection unit 220 is used to select any cluster from at least one cluster as the first cluster; Upgrade unit 230 is used to isolate external traffic to the first batch of servers in the first cluster at the load balancer. When there is no traffic access to the first batch of servers, the platform application is upgraded on the first batch of servers. After the platform application is upgraded on the first batch of servers, the upgraded platform application is checked. If the check passes, the external traffic to the first batch of servers is restored at the load balancer.

[0056] This application embodiment provides a possible implementation, wherein the upgrade unit 230 is further configured to: After the platform applications on the first batch of servers have been upgraded, the upgraded platform applications will be checked. If the check fails, the platform application versions will be rolled back on the first batch of servers, and the application upgrade will be terminated.

[0057] This application embodiment provides a possible implementation, wherein the upgrade unit 230 is further configured to: After restoring external traffic to the first batch of servers on the load balancer, the services provided by the first batch of servers are verified. After successful verification, the platform application version upgrade is started on the second batch of servers in the first cluster. External traffic to the second batch of servers in the first cluster is isolated on the load balancer. When there is no traffic access on the second batch of servers, the platform application version upgrade is performed on the second batch of servers. After the platform applications on the second batch of servers have been upgraded, the upgraded platform applications will be checked. If the check passes, external traffic to the second batch of servers will be restored on the load balancer.

[0058] This application embodiment provides a possible implementation, wherein the upgrade unit 230 is further configured to: After the platform applications on the second batch of servers have been upgraded, the upgraded platform applications will be checked. If the check fails, the platform application versions will be rolled back on the second batch of servers, and the application upgrade will be terminated.

[0059] This application embodiment provides a possible implementation, wherein the upgrade unit 230 is further configured to: After the external traffic of the second batch of servers is restored on the load balancing device, if all servers on the first cluster have completed the version upgrade of the platform application, the service is verified during the process of the servers on the first cluster providing services to the outside world. After the verification is passed, any cluster other than the first cluster is selected from at least one cluster as the second cluster. External traffic to the third batch of servers in the second cluster is isolated at the load balancing device. When there is no traffic access on the third batch of servers, the platform application version is upgraded on the third batch of servers. After the platform applications on the third batch of servers have been upgraded, the upgraded platform applications will be checked. If the check passes, the external traffic to the third batch of servers will be restored on the load balancer.

[0060] This application embodiment provides a possible implementation, wherein the upgrade unit 230 is further configured to: After the platform applications on the third batch of servers have been upgraded, the upgraded platform applications will be checked. If the check fails, the platform application versions will be rolled back on the third batch of servers, and the application upgrade will be terminated.

[0061] This application embodiment provides a possible implementation, wherein the upgrade unit 230 is further configured to: After restoring external traffic to the third batch of servers on the load balancer side, the services provided by the third batch of servers are verified. After the verification is successful, the version upgrade of the platform application on the fourth batch of servers in the second cluster begins. External traffic to the fourth batch of servers in the second cluster is isolated on the load balancer side. When there is no traffic access on the fourth batch of servers, the version upgrade of the platform application is performed on the fourth batch of servers. After the platform applications on the fourth batch of servers have been upgraded, the upgraded platform applications will be checked. If the check passes, the external traffic to the fourth batch of servers will be restored on the load balancer.

[0062] This application embodiment provides a possible implementation, wherein the upgrade unit 230 is further configured to: After restoring external traffic to the fourth batch of servers on the load balancing device, if all servers on the second cluster have completed the version upgrade of platform applications, the services provided by the servers on the second cluster are verified. After the verification is passed, any cluster other than the first and second clusters is selected from at least one cluster as the third cluster. This process is repeated to upgrade the platform applications on each batch of servers in the third cluster.

[0063] Based on the same inventive concept, embodiments of this application also provide an electronic device, including a processor and a memory, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the version upgrade method of a load-balancing platform application of any of the above embodiments.

[0064] In an exemplary embodiment, an electronic device is provided, such as Figure 3 As shown, Figure 3 The illustrated electronic device 300 includes a processor 301 and a memory 303. The processor 301 and the memory 303 are connected, for example, via a bus 302. Optionally, the electronic device 300 may also include a transceiver 304. It should be noted that in practical applications, the transceiver 304 is not limited to one type, and the structure of this electronic device 300 does not constitute a limitation on the embodiments of this application.

[0065] Processor 301 may be a CPU (Central Processing Unit), GPU (Graphics Processing Unit), DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 301 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0066] Bus 302 may include a pathway for transmitting information between the aforementioned components. Bus 302 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 302 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 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.

[0067] The memory 303 may be a ROM (Read Only Memory) or other type of static storage device capable of storing static information and instructions, RAM (Random Access Memory) or other type of dynamic storage device capable of storing information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0068] The memory 303 stores computer program code that executes the scheme of this application, and its execution is controlled by the processor 301. The processor 301 executes the computer program code stored in the memory 303 to implement the content shown in the foregoing method embodiments.

[0069] Among them, electronic devices include, but are not limited to: mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), and in-vehicle terminals (such as in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 3 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0070] Those skilled in the art will clearly understand that the specific working process of the systems, devices, and modules described above can be referred to the corresponding process in the foregoing method embodiments. For the sake of brevity, it will not be repeated here.

[0071] Those skilled in the art will understand that the technical solution of this application, or all or part of it, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several program instructions to cause an electronic device (e.g., a personal computer, server, or network device) to execute all or part of the steps of the methods described in the embodiments of this application when running the program instructions. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0072] Alternatively, all or part of the steps of the foregoing method embodiments can be implemented by hardware (such as electronic devices like personal computers, servers, or network devices) associated with program instructions. The program instructions can be stored in a computer-readable storage medium. When the program instructions are executed by the processor of the electronic device, the electronic device executes all or part of the steps of the methods described in the embodiments of this application.

[0073] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that within the spirit and principles of this application, modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the corresponding technical solutions to leave the protection scope of this application.

Claims

1. A method for version upgrade of a platform application based on load balancing, characterized in that, Platform applications are deployed in at least one cluster and provide services to the outside world simultaneously through dynamic domain names. The method includes: In response to the instruction to upgrade the version of a platform application, the release batch information of the platform application on at least one cluster is edited using a preset release template to obtain multiple batches, the server identifier of each batch, and the number of servers in each batch. Select any cluster from at least one cluster as the first cluster; External traffic to the first batch of servers in the first cluster is isolated at the load balancing device. Once there is no traffic access on the first batch of servers, the platform application version is upgraded on the first batch of servers. After the platform applications on the first batch of servers have been upgraded, the upgraded platform applications are checked. If the check passes, the external traffic to the first batch of servers is restored on the load balancer.

2. The method according to claim 1, characterized in that, After the first batch of platform applications on the servers have completed their version upgrades, and after checking the upgraded platform applications, the method further includes: If the check fails, the platform application version will be rolled back on the first batch of servers, and the application upgrade will be terminated.

3. The method according to claim 1 or 2, characterized in that, After restoring external traffic to the first batch of servers on the load balancing device, the method further includes: During the process of the first batch of servers providing services to the outside world, the services are verified. After the verification is passed, the version upgrade of the platform application on the second batch of servers in the first cluster begins. External traffic to the second batch of servers in the first cluster is isolated on the load balancing device. When there is no traffic access on the second batch of servers, the version upgrade of the platform application is performed on the second batch of servers. After the platform applications on the second batch of servers have been upgraded, the upgraded platform applications will be checked. If the check passes, external traffic to the second batch of servers will be restored on the load balancer.

4. The method according to claim 3, characterized in that, After the platform applications on the second batch of servers have been upgraded, and the upgraded platform applications have been inspected, the method further includes: If the check fails, the platform application version will be rolled back on the second batch of servers, and the application upgrade will be terminated.

5. The method according to claim 3, characterized in that, After restoring external traffic to the second batch of servers on the load balancing device side, the method further includes: If all servers on the first cluster have completed the version upgrade of the platform application, the service is verified during the process of the servers on the first cluster providing services to the outside world. After the verification is passed, any cluster other than the first cluster is selected from at least one cluster as the second cluster. External traffic to the third batch of servers in the second cluster is isolated at the load balancing device. When there is no traffic access on the third batch of servers, the platform application version is upgraded on the third batch of servers. After the platform applications on the third batch of servers have been upgraded, the upgraded platform applications will be checked. If the check passes, the external traffic to the third batch of servers will be restored on the load balancer.

6. The method according to claim 5, characterized in that, After the platform applications on the third batch of servers have completed their version upgrades, and after inspecting the upgraded platform applications, the method further includes: If the check fails, the platform application version will be rolled back on the third batch of servers, and the application upgrade will be terminated.

7. The method according to claim 5, characterized in that, After restoring external traffic to the third batch of servers on the load balancing device side, the method further includes: During the process of providing services to the outside world on the third batch of servers, the services are verified. After the verification is passed, the version upgrade of the platform application on the fourth batch of servers in the second cluster begins. The external traffic of the fourth batch of servers in the second cluster is isolated on the load balancing device. When there is no traffic access on the fourth batch of servers, the version upgrade of the platform application is performed on the fourth batch of servers. After the platform applications on the fourth batch of servers have been upgraded, the upgraded platform applications will be checked. If the check passes, the external traffic to the fourth batch of servers will be restored on the load balancer.

8. The method according to claim 7, characterized in that, After restoring external traffic to the fourth batch of servers on the load balancing device side, the method further includes: If all servers on the second cluster have completed the version upgrade of platform applications, the services provided by the servers on the second cluster are verified. After the verification is passed, any cluster other than the first and second clusters is selected from at least one cluster as the third cluster. This process is repeated to upgrade the version of platform applications on each batch of servers in the third cluster.

9. A version upgrade device for a platform application based on load balancing, characterized in that, Platform applications are deployed in at least one cluster and provide services to the outside world simultaneously through dynamic domain names. The device includes: The editing unit is used to respond to the instruction to upgrade the version of the platform application. It edits the release batch information of the platform application on at least one cluster through a preset release template to obtain multiple batches, the server identifier of each batch and the number of servers in each batch. A selection unit is used to select any cluster from at least one cluster as the first cluster; The upgrade unit is used to isolate external traffic to the first batch of servers in the first cluster on the load balancer. When there is no traffic access to the first batch of servers, the platform application is upgraded on the first batch of servers. After the platform application is upgraded on the first batch of servers, the upgraded platform application is checked. If the check passes, the external traffic to the first batch of servers is restored on the load balancer.

10. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform a version upgrade method for a load-balanced platform application as described in any one of claims 1 to 8.

Images