An upgrading method, device and equipment of a service system including a host and a platform

Abstract

The present application relates to the technical field of operation and maintenance, and in particular to a method, device and equipment for upgrading a service system comprising a host and a platform. The transaction processing logic of the platform side is deployed on the host server of the host side, and the transaction routing is set to send the transaction request of the platform side to the host side, so that the host server of the host side processes the transaction request. Therefore, when upgrading the server of the platform side, the work of all platform servers of the platform side can be stopped, and the platform servers are upgraded at the same time. After the upgrade is completed, the transaction routing is switched back to the platform side, so that the transaction request is processed by any platform server of the platform side. At the same time, the transaction data generated by the host server of the host side during the shutdown upgrade of the platform side is restored to all platform servers of the platform side, so that the upgrade is completed. Through the embodiments of the present application, the problem that the master and standby switching and shutdown upgrade cannot be performed on the platform side in the prior art is solved.

Description

Technical Field

[0001] This article relates to the field of operation and maintenance technology, and in particular to a method, apparatus and equipment for upgrading a service system including a host and a platform. Background Technology

[0002] In the banking and financial sectors, service systems consist of a host side and a platform side. The host side typically consists of two large sites: a primary site responsible for storing transaction data and a backup site for storing backup transaction data. The transaction data stored on the host side is used for subsequent traceability and auditing.

[0003] The platform consists of multiple servers, typically set up within a city or region, distributed across different areas. During normal operation, any one server handles transaction requests, while the others serve as backup servers. The server handling transaction requests is the primary database, and the backup servers are the standby databases. The primary database implements the transaction logic and stores data, synchronizing data to the standby databases. In the event of a primary database failure, the standby database takes over as the primary database to handle business operations, ensuring uninterrupted transaction processing.

[0004] After the platform's master database processes a transaction, it sends the transaction data to the host's master site. The master site stores the data and backs it up on the backup site.

[0005] Currently, when upgrading service systems including hosts and platforms, the primary site on the host side stops working, and the backup site stores the data and updates the version on the primary site. After the primary site's version update is complete, the backup site synchronizes the stored data to the primary site. The primary site then resumes data storage and updates the version on the backup site. After the update is complete, the primary site synchronizes the stored data to the backup site. However, this upgrade method is not suitable for upgrading the primary and backup databases on the platform side, for the following reasons:

[0006] (1) Because the number of servers on the platform side is much greater than that on the host side, the performance of the servers on the platform side is lower than that on the host side. If multiple switching in the replication direction is still performed as on the host side, the operation risk is high.

[0007] (2) For platform-side upgrades, if the fields in the transaction logic are modified, the backup database needs to be rebuilt. Because there are many backup databases, the reconstruction involves a wide range of issues and will cause a large amount of cross-site network traffic, which poses a security risk.

[0008] (3) During the upgrade of the platform-side server, transactions will be supported by a single database. Due to the performance limitations of the platform-side server, there is a single point of failure risk on the platform side.

[0009] (4) Development needs to be carried out at the application layer on the platform side. Because the services of servers in different cities or jurisdictions on the platform side may differ, and because the upgrade process is highly coupled with the business, it is difficult to achieve universal master-slave switching and shutdown upgrade on the platform side.

[0010] To address any of the above problems, there is an urgent need for an upgrade method that includes both the host and the platform service system, thereby resolving the issue that existing technologies cannot perform master-slave switching and downtime upgrades on the platform side. Summary of the Invention

[0011] To address the problems in the prior art, embodiments of this specification provide an upgrade method, apparatus, and device for a service system including a host and a platform. When the server on the platform side needs to be upgraded, the transaction processing logic of the server on the platform side is deployed to the server on the host side, and the server on the host side processes the transactions on the platform side. Then, all servers on the platform side are simultaneously shut down for upgrades. After the upgrade is completed, the transactions are switched back to the server on the platform side for processing.

[0012] To solve any of the above-mentioned technical problems, the specific technical solution presented in this paper is as follows:

[0013] On the one hand, the embodiments of this specification provide a method for optimizing a database execution plan, including,

[0014] Before the platform server on the target platform side is shut down for upgrade, the transaction processing logic for the target platform side is deployed in the host server on the host side, and the transaction routing is set to send transaction requests to the target platform side to the host side; wherein the host server stores all user data on the platform side;

[0015] Stop the operation of all platform servers on the target platform side of the upgrade, and simultaneously upgrade all platform servers on the target platform side of the upgrade to the same production version. During the downtime upgrade, the received transaction requests initiated by users will be sent to the host server according to the transaction route, so that the host server can process the transaction requests according to the user data and the transaction processing logic.

[0016] After all platform servers on the target platform side are successfully upgraded, the transaction data generated by the host server during the downtime upgrade will be restored to all platform servers on the target platform side. The transaction routing will be set to send transaction requests to any platform server on the target platform side, and the platform server that processes the transaction requests will be configured to back up the transaction data to the host server.

[0017] Furthermore, all platform servers on the target platform side of the upgrade are deployed by region, and each region includes at least two of the platform servers;

[0018] The platform server in a certain region that processes transaction requests is designated as the platform master server, and the remaining platform servers are designated as platform backup servers.

[0019] Furthermore, after all platform servers on the target platform side have been successfully upgraded, the method further includes:

[0020] The received transaction requests are sent to the platform master server for processing according to the transaction route set after the upgrade is successful, so that the platform master server can synchronize the generated transaction data to the platform backup server.

[0021] Furthermore, the method also includes:

[0022] If the platform's main server fails and the platform's backup server in the same region as the main server does not fail, the transaction route will be switched from the platform's main server to any platform backup server in the same region that does not fail, so that the platform backup server can process the transaction request.

[0023] If the platform's primary server fails and all backup servers in the same region as the primary server also fail, the transaction route will be switched from the primary server to any backup server in another region that is not currently experiencing a failure, so that the backup server can process the transaction request.

[0024] Furthermore, the host server on the host side includes a primary host server and a backup host server.

[0025] Furthermore, the method also includes:

[0026] Before the shutdown upgrade, the transaction processing logic of the target platform side of the upgrade is deployed in the backup host server on the host side, and the transaction routing is set to send the transaction request to the backup host server on the host side.

[0027] Stop the operation of the primary host server and all platform servers on the target platform side of the upgrade, and upgrade the primary host server and all platform servers at the same time. During the downtime upgrade, the transaction requests initiated by the user will be sent to the backup host server according to the transaction route, so that the backup host server can process the transaction requests according to the user data and the transaction processing logic.

[0028] After the primary host server and all platform servers on the target platform side are successfully upgraded, the transaction data generated by the backup host server during the downtime upgrade will be restored to the primary host server and all platform servers on the target platform side. The transaction routing will be set to send transaction requests to any platform server on the target platform side, and the platform server that processes the transaction requests will be configured to back up the transaction data to the primary host server.

[0029] The operation of the backup host server is stopped, and the backup host server is upgraded. After the upgrade is successful, the transaction data of the primary host server during the shutdown and upgrade of the backup host server is backed up to the backup host server.

[0030] Furthermore, restoring the transaction data generated by the host server during the downtime upgrade to all platform servers on the target platform side further includes:

[0031] If the data table structure of the upgraded platform server remains unchanged, the Q-ERP tool will be invoked to restore the transaction data to all platform servers.

[0032] If the data table structure of the upgraded platform server changes, the transaction data during the downtime upgrade period is extracted, the transaction data is formatted according to the changed data table structure, and the converted transaction data is restored to all platform servers.

[0033] On the other hand, embodiments of this specification also provide an upgrade apparatus for a service system including a host and a platform, the apparatus comprising:

[0034] The pre-upgrade deployment unit is used to deploy the transaction processing logic of the target platform side in the host server on the host side before the platform server on the target platform side is shut down for upgrade, and to set the transaction routing to send transaction requests to the target platform side to the host side, and to deploy the transaction processing logic of the target platform side in the host server on the host side; wherein the host server stores all user data on the platform side;

[0035] The shutdown and upgrade unit is used to stop the operation of all platform servers on the target platform side and simultaneously upgrade all platform servers on the target platform side to the same production version. During the shutdown and upgrade, the received user-initiated transaction requests will be sent to the host server according to the transaction route so that the host server can process the transaction requests according to the user data and the transaction processing logic.

[0036] The data recovery unit is used to restore the transaction data generated by the host server during the downtime upgrade to all platform servers on the target platform side after all platform servers on the target platform side have been successfully upgraded, and to set the transaction routing to send the transaction request to any platform server on the target platform side, and to configure the platform server that processes the transaction request to back up the transaction data to the host server.

[0037] On the other hand, embodiments of this specification also provide a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the above-described method.

[0038] On the other hand, embodiments of this specification also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0039] Finally, this specification also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method.

[0040] Using the embodiments in this specification, the transaction processing logic on the platform side is deployed on the host server on the host side, and the transaction routing is set to send transaction requests to the host side, where the host server processes the transaction requests. Therefore, when upgrading the platform-side servers, all platform servers on the platform side can be stopped and upgraded simultaneously. After the upgrade is complete, the transaction routing is switched back to the platform side, allowing any platform server on the platform side to process the transaction requests. Simultaneously, transaction data generated by the host server on the host side during the platform-side downtime upgrade is restored to all platform servers on the platform side, thus completing the upgrade. This achieves simultaneous downtime upgrades of all platform servers on the platform side, solving the problem in existing technologies where master / slave failover and downtime upgrades cannot be performed on the platform side. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the accompanying drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this document. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 The diagram shown is a schematic representation of an implementation system for an upgrade method of a service system including a host and a platform, as described in an embodiment of this specification.

[0043] Figure 2 The diagram shown is a flowchart illustrating an upgrade method for a service system including a host and a platform, according to an embodiment of this specification.

[0044] Figure 3 The diagram illustrates the steps for processing transactions after deploying platform servers according to regions in an embodiment of this specification.

[0045] Figure 4 The diagram illustrates the steps in this embodiment of the process of restoring transaction data generated by the host server during the downtime upgrade to all platform servers on the target platform side of the upgrade.

[0046] Figure 5 The diagram illustrates the steps for simultaneously shutting down and upgrading both the primary host server and the platform server in an embodiment of this specification.

[0047] Figure 6 The diagram shown is a structural schematic of an upgrade device for a service system including a host and a platform, as described in an embodiment of this specification.

[0048] Figure 7 The diagram shown is a structural schematic of the computer device in an embodiment of this specification.

[0049] [Explanation of Figure Markers]:

[0050] 101. Host side;

[0051] 1011. Primary host server;

[0052] 1012, Backup Host Server;

[0053] 102. Platform side;

[0054] 1021. Platform server;

[0055] 601. Pre-upgrade deployment unit;

[0056] 602. Shutdown and Upgrade Unit;

[0057] 603. Data Recovery Unit;

[0058] 702. Computer equipment;

[0059] 704. Processing equipment;

[0060] 706. Storage resources;

[0061] 708. Drive mechanism;

[0062] 710. Input / Output Module;

[0063] 712. Input devices;

[0064] 714. Output devices;

[0065] 716. Presentation equipment;

[0066] 718. Graphical User Interface;

[0067] 720. Network interface;

[0068] 722. Communication link;

[0069] 724. Communication bus. Detailed Implementation

[0070] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this document, and not all embodiments. Based on the embodiments described herein, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this document.

[0071] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings herein 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 described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0072] It should be noted that the acquisition, storage, use, and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations.

[0073] like Figure 1 The diagram shown is a schematic of an implementation system for an upgrade method of a service system including a host and a platform, as described in this specification. The system includes a host side 101 and a platform side 102. The host side 101 is responsible for storing transaction data, and the platform side 102 is responsible for processing user transaction requests. After processing the transaction request, the platform side 102 sends the transaction data to the host side 101 for storage.

[0074] Typically, the host side 101 includes two host servers: a primary host server 1011 and a backup host server 1012. The primary host server 1011 receives and stores transaction data sent from the platform side 102. Additionally, the primary host server 1011 sends transaction data to the backup host server 1012, which backs up the transaction data. The platform side 102 typically includes two or more platform servers 1021. Platform servers 1021 can be deployed according to regions (e.g., cities, districts, etc.). Two platform servers 1021 can be deployed within a single region. During normal operation, only one platform server 1021 within a region serves as the primary platform server, while the others serve as backup platform servers. The primary platform server processes transactions and backs up the transaction data to the backup server and the primary host server on the host side. If the primary platform server on the platform side fails, it can be determined whether a line failure occurred in the region where the primary platform server is located. If not, another backup server within the same region is promoted to primary platform server; if so, a primary platform server is determined in another region.

[0075] The primary host server 1011 and the backup host server 1012 on the host side 101, the multiple platform servers 1021 on the platform side 102, and the platform side 102 and the host side 101 can all communicate through a network. The network can include a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and is connected to the website, user equipment (e.g., computing devices), and backend systems.

[0076] In addition, it should be noted that, Figure 1 The example shown is merely one application environment provided by this disclosure. In practical applications, other application environments may also be included, and this specification does not impose any limitations.

[0077] In the existing technology, because the number of platform servers 1021 on the platform side 102 is much larger than that on the host side, and the performance of platform servers 1021 on the platform side 102 is lower than that of the primary host server 1011 and the backup host server 1012 on the host side 101, if the platform side 102 adopts the method of shutting down and upgrading the platform primary server and promoting the platform backup server to become the platform primary server to process transactions, all platform servers will be shut down and upgraded in turn. This will cause the transaction data generated during the upgrade to switch multiple times in the replication direction, which is extremely risky. Moreover, if the fields in the transaction logic of the platform side 102 are modified, the backup database needs to be rebuilt. Because there are many backup databases, the reconstruction involves a wide range of aspects and will cause a large amount of cross-site network traffic, which poses a security risk.

[0078] To address the problems existing in the prior art, embodiments of this specification provide an upgrade method for a service system including a host and a platform. This method enables the deployment of transaction logic on the platform side on the host side, with the host side processing transactions during the platform server shutdown upgrade. Subsequently, all platform servers on the platform side can be shut down for upgrades. After the upgrade is successful, transaction requests are switched back to the platform side for processing. Figure 2 The diagram illustrates a flowchart of an upgrade method for a service system including a host and a platform, according to an embodiment of this specification. The upgrade process of the service system including a host and a platform is described in this diagram. The order of steps listed in the embodiment is merely one possible execution order among many and does not represent the only possible execution order. In actual system or device products, the method can be executed sequentially or in parallel according to the embodiment or the accompanying drawings. Specifically, as shown... Figure 2 As shown, the method may include:

[0079] Step 201: Before the platform server on the target platform side is shut down for upgrade, the transaction processing logic of the target platform side is deployed in the host server on the host side, and the transaction routing is set to send transaction requests from the target platform side to the host side; wherein the host server stores all user data from the platform side.

[0080] Step 202: Stop the operation of all platform servers on the target platform side of the upgrade, and simultaneously upgrade all platform servers on the target platform side of the upgrade to the same production version. During the downtime upgrade, the received transaction requests initiated by users will be sent to the host server according to the transaction route, so that the host server can process the transaction requests according to the user data and the transaction processing logic.

[0081] Step 203: After all platform servers on the target platform side are successfully upgraded, restore the transaction data generated by the host server during the downtime upgrade to all platform servers on the target platform side, set the transaction routing to send transaction requests to any platform server on the target platform side, and configure the platform server that processes the transaction requests to back up the transaction data to the host server.

[0082] Using the embodiments in this specification, the transaction processing logic on the platform side is deployed on the host server on the host side, and the transaction routing is set to send transaction requests to the host side, where the host server processes the transaction requests. Therefore, when upgrading the platform-side servers, all platform servers on the platform side can be stopped and upgraded simultaneously. After the upgrade is complete, the transaction routing is switched back to the platform side, allowing any platform server on the platform side to process the transaction requests. Simultaneously, transaction data generated by the host server on the host side during the platform-side downtime upgrade is restored to all platform servers on the platform side, thus completing the upgrade. This achieves simultaneous downtime upgrades of all platform servers on the platform side, solving the problem in existing technologies where master / slave failover and downtime upgrades cannot be performed on the platform side.

[0083] In the embodiments of this specification, the transaction request sent by the user needs to go through the transaction route first, and the transaction route sends the transaction to the corresponding server. The transaction route in the embodiments of this specification can be deployed on a "container baffle" and the transaction is sent to the corresponding server through the "container baffle".

[0084] In the embodiments of this specification, because the host server on the host side needs to store transaction data from multiple platform sides—for example, transaction data generated by the platform sides of city A, city B, and city C—all need to be backed up to the host server on the host side, the performance of the host server needs to be much greater than that of the platform servers on the platform sides. Therefore, if the upgrade requirement includes upgrades to two or more platform sides, an upgrade plan can be formulated based on the processing capacity of the host server, either by upgrading each platform side sequentially or by upgrading multiple platform sides simultaneously. This embodiment of the specification does not impose any limitations on this.

[0085] According to one embodiment of the present invention, continuing as follows Figure 1 In the implementation scenario shown, all platform servers on the target platform side are deployed by region, and each region includes at least two of the platform servers.

[0086] The platform server in a certain region that processes transaction requests is designated as the platform master server, and the remaining platform servers are designated as platform backup servers.

[0087] Specifically, according to one embodiment of the present invention, such as Figure 3 As shown, the method further includes:

[0088] Step 301: If the platform master server fails and the platform backup server in the same region as the platform master server does not fail, then the transaction route is switched from the platform master server to any platform backup server in the same region that does not fail, so that the platform backup server can process the transaction request.

[0089] Step 302: If the platform master server fails and all platform backup servers in the same region as the platform master server fail, then the transaction route is switched from the platform master server to any platform backup server in another region that is not failed, so that the platform backup server can process the transaction request.

[0090] This can be understood as follows: after deploying platform servers by region, although only one platform server processes transaction requests as the primary platform server, and the rest serve as backup servers to back up transaction data, if the primary platform server fails, it can be further determined whether a line failure has occurred in the region where the primary platform server is located, causing all platform servers in that region to malfunction. If only the primary platform server fails, and not a line failure in that region, then based on the principle of minimizing the primary / backup switchover path, a backup server in the same region can be promoted to the primary platform server, improving the primary / backup switchover speed.

[0091] If a line failure occurs in this area, any platform server in another area where the line failure has not occurred can act as the platform master server to continue processing transaction requests, thereby ensuring that transactions are not interrupted.

[0092] Therefore, by deploying all platform servers on the target platform side according to regions, as described in the embodiments of this specification, and including at least two of the platform servers in any region, the robustness of the platform side and the availability of the platform servers can be maximized.

[0093] According to one embodiment of the present invention, after all platform servers on the target platform side have been successfully upgraded, the method further includes:

[0094] The received transaction requests are sent to the platform master server for processing according to the transaction route set after the upgrade is successful, so that the platform master server can synchronize the generated transaction data to the platform backup server.

[0095] In the embodiments described in this specification, after a successful upgrade, the transaction routing is switched back to the platform side, that is, the transaction routing is set to send the transaction request to the platform master server on the target platform side for transaction logic processing.

[0096] In the embodiments described in this specification, after a successful upgrade, the host server on the host side can simultaneously restore the transaction data generated during the platform-side downtime upgrade to both the platform master server and the platform backup server. This avoids the problem of the platform master server being under heavy workload and affecting processing performance due to only restoring the transaction data to the platform master server and then synchronizing the transaction data to the platform backup server.

[0097] According to one embodiment of the present invention, such as Figure 4 As shown, restoring the transaction data generated by the host server during the downtime upgrade to all platform servers on the target platform side further includes:

[0098] Step 401: If the data table structure of the upgraded platform server has not changed, then call the Q-ERP tool to restore the transaction data to all platform servers;

[0099] Step 402: If the data table structure of the upgraded platform server has changed, extract the transaction data during the downtime upgrade, convert the format of the transaction data according to the changed data table structure, and restore the converted transaction data to all platform servers.

[0100] In the embodiments of this specification, if the data table structure of the upgraded platform server remains unchanged, the Q-ERP tool is used to directly restore the transaction data to all platform servers. However, if the table structure has changed, direct data restoration is not possible. Therefore, the embodiments of this specification extract the transaction data to be restored and then perform format conversion on the transaction data according to the changed data table structure. For example, for fields deleted from the data table structure, the corresponding fields in the transaction data are deleted; for fields added to the data table structure, special characters (such as the special character 0) are assigned to the new fields for field alignment. Finally, the converted transaction data is restored to all platform servers.

[0101] It should be noted that the database type of the host server and platform server in the embodiments of this specification can be MySQL database. Other types of databases can also be deployed according to actual business needs. The backup and recovery methods of transaction data can be adjusted according to the deployed database type. This specification does not impose any restrictions.

[0102] In some other embodiments of the invention, the following continues... Figure 1 As shown, the host server of the host side 101 includes a primary host server 1011 and a backup host server 1012.

[0103] like Figure 5 As shown, the method further includes:

[0104] Step 501: Before the shutdown upgrade, deploy the transaction processing logic of the target platform side of the upgrade in the backup host server on the host side, and set the transaction route to send the transaction request to the backup host server on the host side.

[0105] Step 502: Stop the operation of the primary host server and all platform servers on the target platform side of the upgrade, and upgrade the primary host server and all platform servers at the same time. During the downtime upgrade, the received transaction requests initiated by users will be sent to the backup host server according to the transaction routing, so that the backup host server can process the transaction requests according to the user data and the transaction processing logic.

[0106] Step 503: After the primary host server and all platform servers on the target platform side are successfully upgraded, restore the transaction data generated by the backup host server during the downtime upgrade to the primary host server and all platform servers on the target platform side, set the transaction routing to send transaction requests to any platform server on the target platform side, and configure the platform server that processes the transaction requests to back up the transaction data to the primary host server.

[0107] Step 504: Deactivate the backup host server and upgrade the backup host server. After successful upgrade, back up the transaction data of the primary host server during the shutdown and upgrade period to the backup host server.

[0108] In the embodiments described in this specification, if both the host side and the platform side need to be upgraded, a host server is required to deploy transaction processing logic to handle transaction requests from the platform side during the downtime upgrade of other host servers and all platform servers. This is because, in this embodiment, after the upgrade is completed and the version is put into production, the platform's main server processes transaction requests and needs to synchronize transaction data to the primary host server on the host side in real time. Furthermore, after one host server on the host side is successfully upgraded, another host server also needs to be upgraded, and the transaction data from the downtime upgrade period needs to be synchronized after the upgrade is successful.

[0109] For example, a primary host server deploys transaction processing logic while other host servers and platform servers undergo shutdown upgrades. If the primary host server (Server A) is selected to deploy the transaction processing logic, and the backup host server (Server B) and all platform servers are upgraded simultaneously, then after the backup host server (Server B) and all platform servers are successfully upgraded, the primary host server (Server A) needs to synchronize the transaction data generated during the shutdown upgrade to the successfully upgraded backup host server (Server B). Only after successful synchronization can the primary / backup switch be performed (in current primary / backup technology, the primary usually sends the synchronized data, and the backup receives the synchronized data; because the backup does not process business, it cannot actively synchronize data to the primary). The backup host server (Server B) then becomes the primary host server, and the original primary host server (Server A) undergoes shutdown upgrades.

[0110] However, after the platform server and the standby host server (Server B) are successfully upgraded, the primary host server (Server A) needs to synchronize all transaction data generated during the downtime upgrade period to the upgraded standby host server (Server B) before a switchover can be performed. If the version is deployed before the switchover, because the platform server and the standby host server (Server B) are down simultaneously, the primary host server (Server A) remains the primary host server on the platform server side. Therefore, the transaction data generated by the platform server still needs to be synchronized to the currently un-upgraded primary host server (Server A). However, because the version of the primary host server (Server A) is different from the version of the platform server, there may be inconsistencies in transaction data fields. Therefore, the platform server cannot synchronize the generated transaction data to the un-upgraded primary host server (Server A). Therefore, even after a successful upgrade, the platform server cannot immediately proceed to production deployment. It needs to wait for the un-upgraded primary host server (Server A) to synchronize the transaction data generated during the downtime upgrade to the upgraded standby host server (Server B) before a primary / standby switch can occur. Then, the platform server sends the transaction data to the switched-off primary host server (Server B) to enable production deployment. Thus, Method 1 suffers from the problem of not being able to immediately deploy the version after a successful platform server upgrade, leading to transaction interruptions.

[0111] Therefore, in this embodiment, the transaction processing logic is deployed on the backup host server (Server B), allowing both the primary host server (Server A) and the platform server to be upgraded simultaneously. Both the primary host server (Server A) and the platform server are shut down concurrently. On the platform server side, the primary host server (Server A) remains the primary host server. After the primary host server (Server A) and the platform server successfully upgrade, because the platform server still records Server A as the primary host server, it will still send transaction data to the upgraded Server A during version deployment, allowing for immediate version deployment. At this time, Server B stops processing transactions. Because Server B promoted itself to the primary host server during Server A's shutdown upgrade, after Server A's successful upgrade, Server B can still synchronize the transaction data generated during the shutdown upgrade to Server A. After synchronization, Server B can then perform its own shutdown upgrade without affecting the version deployment after the platform server upgrade is complete, and without causing transaction interruption.

[0112] Based on the same inventive concept, embodiments of this specification also provide an upgrade device for a service system including a host and a platform, such as... Figure 6 As shown, it includes:

[0113] The pre-upgrade deployment unit 601 is used to deploy the transaction processing logic of the target platform side in the host server on the host side before the platform server on the target platform side is shut down for upgrade, and to set the transaction routing to send the transaction request to the target platform side to the host side, and to deploy the transaction processing logic of the target platform side in the host server on the host side; wherein the host server stores all user data on the platform side;

[0114] The shutdown and upgrade unit 602 is used to stop the operation of all platform servers on the target platform side of the upgrade and simultaneously upgrade all platform servers on the target platform side of the upgrade to the same production version. During the shutdown and upgrade, the received transaction requests initiated by users will be sent to the host server according to the transaction route so that the host server can process the transaction requests according to the user data and the transaction processing logic.

[0115] The data recovery unit 603 is used to restore the transaction data generated by the host server during the downtime upgrade to all platform servers on the target platform side after all platform servers on the target platform side have been successfully upgraded, and to set the transaction routing to send the transaction request to any platform server on the target platform side, and to configure the platform server that processes the transaction request to back up the transaction data to the host server.

[0116] Since the principle of the above-mentioned device in solving the problem is similar to that of the above-mentioned method, the implementation of the above-mentioned device can refer to the implementation of the above-mentioned method, and the repeated parts will not be described again.

[0117] like Figure 7The diagram illustrates the structure of a computer device according to an embodiment of this specification. The apparatus described herein can be the computer device in this embodiment, performing the methods described above. The computer device 702 may include one or more processing devices 704, such as one or more central processing units (CPUs), each of which can implement one or more hardware threads. The computer device 702 may also include any storage resource 706 for storing information of any kind, such as code, settings, data, etc. Without limitation, for example, the storage resource 706 may include any type of RAM, any type of ROM, flash memory, hard disk, optical disk, etc. More generally, any storage resource can use any technology to store information. Furthermore, any storage resource can provide volatile or non-volatile retention of information. Further, any storage resource may represent a fixed or removable component of the computer device 702. In one case, when the processing device 704 executes associated instructions stored in any storage resource or combination of storage resources, the computer device 702 can perform any operation of the associated instructions. The computer device 702 also includes one or more drive mechanisms 708 for interacting with any storage resource, such as a hard disk drive mechanism, an optical disk drive mechanism, etc.

[0118] Computer device 702 may also include an input / output module 710 (I / O) for receiving various inputs (via input device 712) and providing various outputs (via output device 714). A specific output mechanism may include a presentation device 716 and an associated graphical user interface (GUI) 718. In other embodiments, the input / output module 710 (I / O), input device 712, and output device 714 may be omitted, and the device may function solely as a computer device within a network. Computer device 702 may also include one or more network interfaces 720 for exchanging data with other devices via one or more communication links 722. One or more communication buses 724 couple the components described above together.

[0119] Communication link 722 can be implemented in any way, such as via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, or any combination thereof. Communication link 722 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0120] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0121] This specification also provides computer-readable instructions, wherein when a processor executes the instructions, the program therein causes the processor to perform the above-described method.

[0122] It should be understood that in the various embodiments described herein, the sequence number of each process does 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 in this specification.

[0123] It should also be understood that, in the embodiments of this specification, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0124] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this document.

[0125] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0126] In the embodiments provided herein, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, or they may be electrical, mechanical, or other forms of connection.

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

[0128] Furthermore, the functional units in the various embodiments of this document can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0130] This document uses specific embodiments to illustrate the principles and implementation methods of this document. The descriptions of the embodiments above are only for the purpose of helping to understand the methods and core ideas of this document. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this document. Therefore, the content of this specification should not be construed as a limitation of this document.

Claims

1. A method for upgrading a service system including a host and a platform, characterized in that, The method includes: Before the platform server on the target platform side is shut down for upgrade, the transaction processing logic for the target platform side is deployed on the host server on the host side, and the transaction routing is set to send transaction requests to the target platform side to the host side; wherein the host server stores all user data on the platform side; Stop the operation of all platform servers on the target platform side of the upgrade, and simultaneously upgrade all platform servers on the target platform side of the upgrade to the same production version. During the downtime upgrade, the received transaction requests initiated by users will be sent to the host server according to the transaction route, so that the host server can process the transaction requests according to the user data and the transaction processing logic. After all platform servers on the target platform side are successfully upgraded, the transaction data generated by the host server during the downtime upgrade will be restored to all platform servers on the target platform side. The transaction routing will be set to send transaction requests to any platform server on the target platform side, and the platform server that processes the transaction requests will be configured to back up the transaction data to the host server.

2. The method according to claim 1, characterized in that, All platform servers on the target platform side of the upgrade are deployed by region, and each region includes at least two of the platform servers; The platform server in a certain region that processes transaction requests is designated as the platform master server, and the remaining platform servers are designated as platform backup servers.

3. The method according to claim 2, characterized in that, After all platform servers on the target platform side have been successfully upgraded, the method further includes: The received transaction requests are sent to the platform master server for processing according to the transaction route set after the upgrade is successful, so that the platform master server can synchronize the generated transaction data to the platform backup server.

4. The method according to claim 2, characterized in that, The method further includes: If the platform's main server fails and the platform's backup server in the same region as the main server does not fail, the transaction route will be switched from the platform's main server to any platform backup server in the same region that does not fail, so that the platform backup server can process the transaction request. If the platform's primary server fails and all backup servers in the same region as the primary server also fail, the transaction route will be switched from the primary server to any backup server in another region that is not currently experiencing a failure, so that the backup server can process the transaction request.

5. The method according to claim 1, characterized in that, The host servers on the host side include a primary host server and a backup host server.

6. The method according to claim 5, characterized in that, The method further includes: Before the shutdown upgrade, the transaction processing logic of the target platform side of the upgrade is deployed in the backup host server on the host side, and the transaction routing is set to send the transaction request to the backup host server on the host side. Stop the operation of the primary host server and all platform servers on the target platform side of the upgrade, and upgrade the primary host server and all platform servers at the same time. During the downtime upgrade, the transaction requests initiated by the user will be sent to the backup host server according to the transaction route, so that the backup host server can process the transaction requests according to the user data and the transaction processing logic. After the primary host server and all platform servers on the target platform side are successfully upgraded, the transaction data generated by the backup host server during the downtime upgrade will be restored to the primary host server and all platform servers on the target platform side. The transaction routing will be set to send transaction requests to any platform server on the target platform side, and the platform server that processes the transaction requests will be configured to back up the transaction data to the primary host server. The operation of the backup host server is stopped, and the backup host server is upgraded. After the upgrade is successful, the transaction data of the primary host server during the shutdown and upgrade of the backup host server is backed up to the backup host server.

7. The method according to claim 1, characterized in that, Restoring the transaction data generated by the host server during the downtime upgrade to all platform servers on the target platform side of the upgrade further includes: If the data table structure of the upgraded platform server remains unchanged, the Q-ERP tool will be invoked to restore the transaction data to all platform servers. If the data table structure of the upgraded platform server changes, the transaction data during the downtime upgrade period is extracted, the transaction data is formatted according to the changed data table structure, and the converted transaction data is restored to all platform servers.

8. An upgrade device for a service system including a host and a platform, characterized in that, include: The pre-upgrade deployment unit is used to deploy the transaction processing logic of the target platform side in the host server on the host side before the platform server on the target platform side is shut down for upgrade, and to set the transaction routing to send transaction requests to the target platform side to the host side; wherein the host server stores all user data on the platform side; The shutdown and upgrade unit is used to stop the operation of all platform servers on the target platform side and simultaneously upgrade all platform servers on the target platform side to the same production version. During the shutdown and upgrade, the received user-initiated transaction requests will be sent to the host server according to the transaction route so that the host server can process the transaction requests according to the user data and the transaction processing logic. The data recovery unit is used to restore the transaction data generated by the host server during the downtime upgrade to all platform servers on the target platform side after all platform servers on the target platform side have been successfully upgraded, and to set the transaction routing to send the transaction request to any platform server on the target platform side, and to configure the platform server that processes the transaction request to back up the transaction data to the host server.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 7.

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

11. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images