Version updating method, electronic equipment, storage medium and program product

Abstract

The embodiment of the invention provides a version updating method, electronic equipment, a storage medium and a program product. The method comprises the steps that when a first version where a target program is located is an abnormal version, the first version where the target program is located is switched back to a second version; first version data stored in the target client is switched to second version data obtained from the standby end, the first version data is version data for processing target data generated by the target client when a target program in the target client is in a first version, and the second version data is version data for processing target data generated by the target client when the target program in the target client is in a second version. The second version data is version data for processing the target data when the target program in the standby end is in the second version. The method is used for achieving the effect of solving the problem that a database is polluted by wrong new-version data.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a version updating method, electronic device, storage medium and program product. Background Art

[0002] During the promotion phase of a new version, the ratio of the new and old versions promoted in the client is usually controlled, and the promotion of the new version is gradually increased until all the old versions are replaced and an upgrade is completed.

[0003] When a new version is wrong, the client that has received the new version is usually forced to switch back to the old version to ensure the user experience.

[0004] However, before the new version is switched back to the old version, the data cached by the client in the new version causes the client's database to be polluted with erroneous data, and the server database also has erroneous data due to write logic errors, resulting in the problem of erroneous new version data polluting the database. Summary of the invention

[0005] The embodiments of the present application provide a version update method, electronic device, storage medium and program product, which are used to solve the problem of erroneous new version data polluting the database.

[0006] In a first aspect, an embodiment of the present application provides a version update method, applied to a target client, comprising:

[0007] When the first version of the target program is an abnormal version, switching the first version of the target program back to the second version;

[0008] The first version data stored in the target client is switched to the second version data obtained from the standby end, wherein the first version data is version data for processing the target data generated by the target client when the target program in the target client is in the first version, and the second version data is version data for processing the target data when the target program in the standby end is in the second version.

[0009] In a possible implementation, when the first version data is of a read logic type,

[0010] After switching the first version of the target program back to the second version, the method further includes:

[0011] According to the target program in the second version, the target data is read and processed to obtain the third version data.

[0012] In a possible implementation, switching the first version of the target program back to the second version includes:

[0013] receiving a version switchback instruction sent by the server, where the version switchback instruction is an instruction generated by the server in response to a user request, or an instruction generated according to a version period of the first version;

[0014] According to the version switching back instruction, the first version of the target program is switched back to the second version.

[0015] In a possible implementation, when the first version of the target program is a normal version, the method further includes:

[0016] According to the target program in the first version, the target data is read and processed to obtain the first version data;

[0017] The first version data is stored.

[0018] In a second aspect, an embodiment of the present application provides a version update method, which is applied to a server, wherein a standby terminal is provided in the server, comprising:

[0019] When the first version of the target program in the target client is an abnormal version, sending the second version to the target client so that the first version of the target program in the target client is switched back to the second version;

[0020] The second version data in the standby end is sent to the target client, and the second version data is used to replace the first version data stored in the target client, wherein the first version data is version data for processing target data generated by the target client when the target program in the target client is in the first version, and the second version data is version data for processing target data when the target program in the standby end is in the second version.

[0021] In a possible implementation, when the first version of the target program in the target client is an abnormal version, sending the second version to the target client so that the first version of the target program in the target client is switched back to the second version includes:

[0022] The second version and the version switchback instruction are sent to the target client. The version switchback instruction is an instruction generated by the server in response to a user request, or an instruction generated according to the version period of the first version, so that the target program in the target client switches back from the first version to the second version according to the second version and the version switchback instruction.

[0023] In a possible implementation, the server includes a first server, a target database is provided in the server, and the target database is used to store target data sent to the first server by all target clients, and the method further includes:

[0024] Receive a user request sent by a target client;

[0025] Determine, according to the user request, first target data in the target database, where the first target data represents target data sent by the target client to the first server;

[0026] When the first target data is of write logic type,

[0027] The user request is sent to the standby end, so that the program of the standby end determines the standby data according to the first target data under the second version.

[0028] In a possible implementation manner, before receiving the user request sent by the target client, the process includes:

[0029] According to the client list stored in the server, a target client and other clients are determined so that a target program in the target client with a first version processes target data with the first version, and a target program in other clients with a second version processes target data with the second version.

[0030] In a possible implementation, when the first version of the target program in the target client is an abnormal version, the method further includes:

[0031] Update the target database based on the backup data.

[0032] In a possible implementation, the server further includes a second server, the target database is further used to store other data sent to the second server by all other clients, and the method further includes:

[0033] Receive other requests sent by other clients;

[0034] Determine second target data in the target database according to other requests, where the second target data represents other data sent to the second server by other clients;

[0035] The program of the second server determines the user data according to the second target data under the second version.

[0036] In a third aspect, an embodiment of the present application provides a version update device, including:

[0037] A first processing module, configured to switch the first version of the target program back to the second version when the first version of the target program is an abnormal version;

[0038] The second processing module is used to switch the first version data stored in the target client to the second version data obtained from the standby end, wherein the first version data is the version data for processing the target data generated by the target client when the target program in the target client is in the first version, and the second version data is the version data for processing the target data when the target program in the standby end is in the second version.

[0039] In a fourth aspect, an embodiment of the present application provides a version update device, including:

[0040] A third processing module is used to send the second version to the target client when the first version of the target program in the target client is an abnormal version, so that the first version of the target program in the target client is switched back to the second version;

[0041] The fourth processing module is used to send to the target client according to the second version data in the standby end, and the second version data is used to replace the first version data stored in the target client, wherein the first version data is the version data for processing the target data generated by the target client when the target program in the target client is in the first version, and the second version data is the version data for processing the target data when the target program in the standby end is in the second version.

[0042] In a fifth aspect, an embodiment of the present application provides a version update device, including: a memory, a processor;

[0043] Memory stores computer-executable instructions;

[0044] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0045] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect above and / or various possible implementations of the first aspect.

[0046] In a seventh aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementation methods of the first aspect.

[0047] The embodiments of the present application provide a version update method, electronic device, storage medium and program product. When the first version being tried out is an abnormal version, the target program on the target client switches back from the first version to the second version, and at the same time the standby end processes the target data generated by the target client with the stable second version, thereby replacing the erroneous first version data stored in the target client with the second version data. This technical means achieves the effect of solving the problem of the erroneous new version data polluting the database. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0049] Figure 1 A schematic diagram of a scenario of a version update method provided in an embodiment of the present application;

[0050] Figure 2 A schematic diagram of a version update method provided in an embodiment of the present application Figure 1 ;

[0051] Figure 3 A schematic diagram of a version update method provided in an embodiment of the present application Figure 2 ;

[0052] Figure 4 A schematic diagram of a version update device provided in an embodiment of the present application Figure 1 ;

[0053] Figure 5 A schematic diagram of a version update device provided in an embodiment of the present application Figure 2 ;

[0054] Figure 6 A schematic diagram of the structure of a version update device provided in an embodiment of the present application.

[0055] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0056] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0057] First, the terms involved in this application are explained:

[0058] Grayscale cluster: refers to an independent small-scale cluster separated from the existing production environment when the server is upgraded to a new version. It is used to deploy and test the new version of the application or service.

[0059] Online cluster: refers to the production environment cluster that is currently providing services to users and runs verified and stable old versions of applications or services;

[0060] Bypass cluster: A parallel cluster set up outside the existing production environment (online cluster), mainly used to back up and verify key operations, especially write operations. The main difference between it and the online cluster is that it has an independent target database, and its main task is to capture and process key data operations from the grayscale cluster to ensure fast data recovery and system rollback even when problems occur in the main system.

[0061] During the release phase of a new version, because the new version is relatively unstable and has not been extensively tested to verify its feasibility, the extent to which the new version is promoted in the client will be controlled. As the new version is successfully tested, the scope of promotion of the new version will be gradually expanded. If a business failure occurs when the new version is released to the client, in order to restore the business as soon as possible, a version switchback is usually adopted, using the old version that is running stably to ensure the user experience. However, for the client that has released the new version, it has interacted with the server running the new version. When the client under the new version performs a read operation, it is likely that data of the wrong read logic type is cached, and the data written under the wrong write logic type when the client performs a write operation is also stored in the databases corresponding to the server and the client, causing the databases of both the client and the server to be polluted, and there is a problem of the wrong new version data polluting the database.

[0062] The present application provides a version update method. In order to ensure the correctness of the client database, a backup end is provided in the server. The backup end can be used to process the target data representing the user request data with a stable second version, so that the target data is processed under the correct version and with the correct logic to obtain the second version data. When it is detected that the first version corresponding to the target program of the running version in the client is an abnormal version, the correct second version data can be returned to the client, so that the first version data in the client is replaced by the second version data, and the client version is switched back from the erroneous first version to the correct second version, thereby solving the problem of the client database being polluted. The database of the server is also updated according to the correct data of the backup end, so that the database before and after switching back to the old version is correct while ensuring data consistency, thereby solving the problem of the erroneous new version data polluting the database.

[0063] Figure 1 A schematic diagram of a scenario of a version update method provided in an embodiment of the present application, such as Figure 1 As shown, the execution subject of the method can be a client and a server, and the server includes a management server, a gray server, an online server and a bypass server.

[0064] The management server is used for grayscale management. The client traffic corresponding to the grayscale version is configured in the management server so that the corresponding client traffic enters different grayscale servers. At the same time, the management server can also manage the switchback function and switchback status, so that the switchback function of a grayscale server is turned on or off, and monitor the switchback status. In addition, the management server will back up the data read by the grayscale manager when the switchback function is turned on, register which data is read during the switchback function on stage, and back up the write logic data type, copy it to the bypass server through traffic, replay the write data logic, and register and store the corresponding logic calculation data. The grayscale server is used to divide the server for releasing the new version when upgrading the new version. There can be multiple grayscale clusters on the grayscale server. The online server is used to run the old version service. The online server and the grayscale server share a set of data storage, and there is an online cluster on the online server. There is a bypass cluster on the bypass server for backing up data. The version it runs is the same as the online server, but the bypass server has a separate database.

[0065] The server can refer to a computer or program that provides services, which can be used to listen to a specific network port, wait for the client's connection request, and respond to the client's request. The client can refer to a computer or program that consumes services, which can be used to actively initiate a connection request to the server and receive the server's response. The client can be various types of devices and applications, such as browsers, mobile applications, and desktop applications. The client communicates with the server through a secure network connection.

[0066] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0067] Figure 2 A schematic diagram of a version update method provided in an embodiment of the present application Figure 1 , applied to the target client, such as Figure 2 As shown, the method includes:

[0068] S201: When the first version of the target program is an abnormal version, switch the first version of the target program back to the second version.

[0069] Among them, the client can refer to a hardware device or software program. The client connects to the server to obtain services, data or resources. The client can be a computer, a smart phone, or a tablet computer. The target client can refer to a device or software environment that needs to perform a version update or a switchback operation. The target client is selected according to pre-set rules. The pre-set rules can be determined based on the user's usage, version launch indicators, etc. In an embodiment of the present application, the target client user is used to distinguish the client to which the new version is pushed.

[0070] The target program may refer to an application on the client, which may perform a specific task or provide a series of functions to the client. For example, when it is necessary to read data input by the user, the target program may be used.

[0071] A version may refer to a group of numbers or alphanumeric combinations used to identify different development stages or states of the software. The first version may refer to the version of the target program that is currently running. The first version may be the latest version that is actively updated, or it may be the target version that is installed on the target client due to demand. The second version may refer to the version used for switching back. When a problem occurs with the first version, the system can choose to switch back to the previous stable running version, i.e., the second version. In an embodiment of the present application, the first version is the latest version promoted, and the second version is the version that was stably running before the new version was promoted. Distinguishing between the first version and the second version can gradually increase the proportion of users promoting the new version, while not affecting the group of people running the stable version, so that the user experience is guaranteed.

[0072] The abnormal version may refer to the first version that has defects or problems, which may cause the program to be unstable, malfunction or exhibit other unexpected behaviors. Therefore, it is necessary to restore the program from the abnormal version to the previous working version.

[0073] In the embodiment of the present application, the grayscale management system in the server is used to distribute versions, switch back, and register backup data. The grayscale policy management module in the grayscale management system performs grayscale management, that is, the management of the first version. The grayscale policy can be configured in the grayscale management system, and the traffic that hits the grayscale policy will be routed to the grayscale cluster. The grayscale management system also supports the grayscale end function. After the new version is confirmed to have no problems, the grayscale function of the corresponding function can be ended. At the end, the backup data will be deleted to reduce unnecessary data storage.

[0074] Switching back the first version of the target program to the second version may refer to restoring the target program and its related configuration to an earlier second version that has been verified to be stable when an abnormality or problem is detected in the currently used first version.

[0075] In the embodiment of the present application, switching the first version of the target program back to the second version includes:

[0076] receiving a version switchback instruction sent by the server, where the version switchback instruction is an instruction generated by the server in response to a user request, or an instruction generated according to a version period of the first version;

[0077] According to the version switching back instruction, the first version of the target program is switched back to the second version.

[0078] A server can refer to a computer system or application that provides services, resources, or data. In the context of version updates and failbacks, a server can refer to a core system that manages software distribution, configuration management, and fault recovery. The server is responsible for monitoring the status of the client, responding to user requests, and sending necessary instructions to perform operations such as version failback. A server can be a physical machine, a virtual machine, a cloud service instance, or part of a distributed system.

[0079] The version switchback instruction may refer to a specific command or message generated by the server and sent to the target client, instructing the target client to switch the target program on it from the current first version to the previous second version. The version switchback instruction contains specific details about how to perform the switchback, such as files to be downloaded, scripts to be executed, configuration changes, etc. In an embodiment of the present application, the version switchback instruction may be automatically triggered, such as based on a version expiration date, or manually triggered, such as in response to a user's request operation.

[0080] User requests can refer to actions initiated by users through a certain interface, requesting to revert the target program version. The interface can be a web page, mobile application, desktop software, etc. Users may want to return to a more stable old version because they find problems with the new version, or choose to revert to a new version based on business needs. User requests can be implemented by clicking buttons, submitting forms, selecting menu items, etc., and ultimately cause the server to generate a version reversion instruction. The client calculates whether the version is expired by agreeing on the version life span with the grayscale management system. If it is found to be expired, it needs to actively synchronize the version.

[0081] The version expiration date can refer to the validity period or life cycle set for each version. Once this period is exceeded, the server may automatically initiate a switchback process to ensure that all clients are running a fully tested and stable version. The version expiration date can be based on time, number of uses, occurrence of specific events, or other predefined conditions. When a version exceeds its set expiration date, the server will automatically generate a version switchback instruction to ensure the security and stability of the system.

[0082] In the embodiment of the present application, the server maintains a connection with the target client through a persistent connection. When the first version changes, the update of the first version can be received in a timely manner.

[0083] S202. Switch the first version data stored in the target client to the second version data obtained from the standby end, wherein the first version data is version data for processing target data generated by the target client when the target program in the target client is in the first version, and the second version data is version data for processing target data when the target program in the standby end is in the second version.

[0084] Version data refers to the result data after the original data provided by the user is processed by the target program under a specific version. Different versions may process the same input data differently, resulting in different outputs or state changes. Therefore, version data reflects how a specific version affects and transforms the user's data.

[0085] The first version data may refer to the result data generated after the data provided by the user is processed by the target program on the target client in the first version. The first version data includes all data operated, modified or generated by the target program under this version. The second version data may refer to the result data obtained after the same or similar data provided by the user is processed by the target program in the second version.

[0086] The standby end may refer to an additional system or environment used to store different versions of applications and their processed version data. The standby end may be located on a local server, cloud storage, or other secure location. The standby end is mainly used in scenarios such as disaster recovery and version rollback to ensure that even if a problem occurs in the main system, it can quickly switch to a known good state. In an embodiment of the present application, the version in the standby end is the second version, that is, the standby end processes the user's original data with a stable version, thereby ensuring that the user's business logic or data will not be negatively affected by version errors.

[0087] The target data generated by the target client may refer to any type of data generated by the application on the target client based on the input or interaction provided by the user during the operation of the application on the target client. The target client includes but is not limited to files, records, configuration settings, and progress save points.

[0088] When the target client performs an operation according to the user request, different user requests will correspond to different response data under the first version. When the user request is to read specified data, the obtained version data conforms to the read logic type. Therefore, in the embodiment of the present application, when the first version data is the read logic type, after switching the first version of the target program back to the second version, the method further includes:

[0089] According to the target program in the second version, the target data is read and processed to obtain the third version data.

[0090] The read logic type may refer to a logic type for reading data from a storage medium, and the storage medium may be a target database or a file system. In an embodiment of the present application, when the user's requirement is to read data, the data to be read is marked as a read logic type.

[0091] Read processing may refer to the operations performed by the target program of the second version on the target data after the program is switched back to the second version, and reading the data of the read logic type. Read processing includes loading data, parsing the data format, applying necessary conversions to be compatible with the second version, and ensuring that the data can be correctly understood and used by the program.

[0092] The third version data may refer to the data generated after the target program under the second version completes the reading process. The third version data ensures that even if the version is switched back, the user's business logic or data remains consistent and complete.

[0093] In the embodiment of the present application, when the first version of the target program is a normal version, the method further includes:

[0094] According to the target program in the first version, the target data is read and processed to obtain the first version data;

[0095] The first version data is stored.

[0096] Among them, a normal version can refer to a stable and functional version. The normal version has been fully tested, has no known major defects or problems, and can correctly process user data as expected. When the target program is in a normal version, the client will continue to use this version for data processing and storage operations.

[0097] When the target program is in a normal version, the system uses this version to read and process the user data and generate the first version data, which is then stored securely. This ensures the accuracy and consistency of data processing, provides a reliable foundation for future version updates or switchbacks, and enhances the overall stability and reliability of the system.

[0098] The embodiment of the present application provides a version update method, which switches the target program from the abnormal first version to the previously stable second version according to the version switchback instruction sent by the server when an abnormality occurs in the first version of the target program, and switches the first version data stored in the client to the second version data in the backup end. This ensures that even if there is a problem with the new version, the user can quickly restore to the stable version to maintain service continuity and data consistency. In addition, for read logic type data, the client can re-read the data according to the stable second version after switching back, thereby ensuring the accuracy of the client's target database.

[0099] Figure 3 A schematic diagram of a version update method provided in an embodiment of the present application Figure 2 , applied to the server, which has a spare terminal, such as Figure 3 As shown, in this embodiment Figure 2 Based on the embodiment, a version update method is described in detail, the method comprising:

[0100] S301: When a first version of a target program in a target client is an abnormal version, a second version is sent to the target client, so that the first version of the target program in the target client is switched back to the second version.

[0101] In the embodiment of the present application, when the first version of the target program in the target client is an abnormal version, sending the second version to the target client so that the first version of the target program in the target client is switched back to the second version includes:

[0102] The second version and the version switchback instruction are sent to the target client. The version switchback instruction is an instruction generated by the server in response to a user request, or an instruction generated according to the version period of the first version, so that the target program in the target client switches back from the first version to the second version according to the second version and the version switchback instruction.

[0103] When the target program in the target client is in an abnormal version, the server sends the second version and the version switchback instruction to the target client. The version switchback instruction is generated by the server according to the user request or the version expiration date of the first version, and guides the target client to safely switch back from the abnormal first version to the stable second version, ensuring service continuity and data consistency.

[0104] In the embodiment of the present application, the server includes a first server, a target database is provided in the server, and the target database is used to store target data sent to the first server by all target clients, and the method further includes:

[0105] Receive a user request sent by a target client;

[0106] Determine, according to the user request, first target data in the target database, where the first target data represents target data sent by the target client to the first server;

[0107] When the first target data is of write logic type,

[0108] The user request is sent to the standby end, so that the program of the standby end determines the standby data according to the first target data under the second version.

[0109] Among them, the first server may refer to a server that sends the first version to the target client and receives user-generated data under the first version. The first server not only manages the distribution of the new version, but is also responsible for collecting and processing all data generated by the user when using the first version. The first server ensures that the new version can be smoothly deployed to the client, and that the user's interactive data can be correctly received, processed and stored. In an embodiment of the present application, the first server is a grayscale cluster that processes the new version. There may be multiple grayscale clusters, corresponding to new versions of different applications. For example, grayscale cluster A corresponds to software A, and grayscale cluster B corresponds to software B. When software A has a version update, grayscale cluster A sends the new version to the target client and monitors the usage status of the target client. When there is a problem with the new version, the repaired version is updated to the target client in a timely manner.

[0110] In some embodiments, the first server is a server with a switchback function.

[0111] The switchback function can be set for each grayscale cluster individually and is disabled by default. When the switchback function is enabled for a grayscale cluster, it can determine whether the traffic entering the grayscale cluster needs to be switched back to the stable version, ensuring that even if there is a problem with the new version, it can quickly return to the previous stable state, thereby ensuring service continuity and data security.

[0112] The reversal function does not need to be enabled. For example, an online shopping platform selected a small number of VIP users as target clients in the early stages of grayscale release of a new version of the payment system. These users have understood and agreed to participate in the test. Since the new version has undergone rigorous internal testing and is considered to be more stable, it was decided not to enable the reversal function. VIP users' payment requests are directly processed by the new version, focusing on collecting feedback and monitoring performance. If serious problems are found in the new version during the grayscale test, the first server can quickly switch the problematic traffic back to the old version (the second version) by enabling the reversal function to avoid affecting the user experience.

[0113] In an embodiment of the present application, the retry management module of the grayscale management system performs retry function management and retry status management. The retry function management can enable the retry function for each grayscale policy setting. The retry status is closed by default. When a problem occurs in a grayscale version, it is necessary to confirm that the current grayscale has a problem in the grayscale management system and enable automatic retry, which means that the first version is an abnormal version.

[0114] The target database may refer to a database storing all target data sent by the target client to the first server under the first version. The target database stores the original data provided by the user and the result data processed by the first version program, ensuring the security and persistence of the data and providing a basis for subsequent data retrieval, analysis and switchback operations.

[0115] The first target data may refer to target data associated with a specific user request determined from a target database. The first target data is sent by a target client to a first server under a first version and is recorded in a target database. The first target data may be any form of data, such as a file, a record, a configuration setting, etc., depending on the requirements of the application.

[0116] The write logic type can refer to the type of operation that modifies, updates, or creates data. When a user request involves changing the state of existing data (such as submitting new information or editing existing content), the data involved in the request is classified as a write logic type.

[0117] Backup data can refer to data generated in the backup end after processing based on the program under the second version. When the user request is a write logic type, in order to ensure data consistency and security, the request will be forwarded to the backup end, allowing the backup end to process the data under the stable version to generate backup data. This step ensures that the accuracy and integrity of the data can be maintained even if problems occur.

[0118] In an embodiment of the present application, a bypass cluster is used as a backup end, and the deployment version of the bypass cluster is a stable version, that is, the second version. The bypass cluster has a separate target database for backing up the data of the current write operation. After the bypass cluster is executed, the response data will be registered to the target database for data recovery. Using the information management module of the gray management system, the data reading when the switchback function is turned on is backed up and managed, and which data is read during the switchback function turning on stage is registered. Back up the write function data, copy it to the bypass system through traffic, replay the write data logic, and register the corresponding logic calculation data in the information management module.

[0119] In some embodiments, client request data corresponding to multiple grayscale clusters are processed in a unified bypass cluster, which not only reduces resource waste, improves resource utilization, but also simplifies management and maintenance. During the version update phase, once the new version has been fully tested and confirmed to be stable, you can choose to shut down the bypass cluster to further reduce bandwidth usage and resource consumption, thereby optimizing system performance and operating costs. This design ensures efficient data backup and verification, while maximizing resource savings without affecting services.

[0120] For example, there is an online shopping platform that is currently conducting a grayscale release of multiple new features. One is an improved payment system, corresponding to grayscale cluster A, and the other is an optimized recommendation algorithm, corresponding to grayscale cluster B. Each grayscale cluster corresponds to a small number of users. While these users are using new features A and B, their write operations are backed up in the bypass cluster running the stable second version.

[0121] The clients to which the new version is pushed are usually determined by preset rules in the server. The preset rules can be set by R&D personnel or changed dynamically according to the application of the new version. When the user response to the new version is good, the number of clients to which the new version is pushed will be gradually increased.

[0122] In some embodiments, before receiving the user request sent by the target client, the process includes:

[0123] According to the client list stored in the server, a target client and other clients are determined so that a target program in the target client with a first version processes target data with the first version, and a target program in other clients with a second version processes target data with the second version.

[0124] The client list may refer to a list stored in the server, which contains information about all registered or managed clients. This list is used to identify and distinguish different clients so that specific tasks or versions can be assigned to each client according to preset rules. The client list may include a client ID, which is a number or string that uniquely identifies each client, a version status that indicates the target program version currently running, and other attributes, such as geographic location, device type, frequency of use, and other auxiliary information, for more refined management and configuration of clients.

[0125] Other clients may refer to those clients that are not in the target client list, or clients that are in the list but are specified to run a different version from the target client. Other clients usually run a verified and stable old version (second version) to ensure that the normal experience of most users is not affected.

[0126] Other clients represent the majority of the user base and handle the main business traffic, while the target client may be a small number of users or a specific user group for testing new features. Because other clients run well-tested older versions, other clients provide higher stability and reliability and reduce the scope of potential problems.

[0127] In the embodiment of the present application, the client traffic is divided into grayscale clusters and online clusters, and the online cluster provides normal old version services. When the user request is sent to the server, the traffic management service module in the server divides the traffic corresponding to the client into different grayscale clusters and different online clusters according to the client list, and configures the traffic distribution of the grayscale cluster according to the user ID to avoid different traffic of the same user entering different grayscale clusters as much as possible. For users participating in the grayscale test, each user request has its own corresponding grayscale cluster identifier.

[0128] In some embodiments, the online cluster in the microservice also forwards the upstream and downstream request routing through the identifier. When the grayscale cluster calls the upstream and downstream of the microservice, if there is a corresponding cluster downstream, it will also go to the corresponding grayscale downstream.

[0129] S302. Send to the target client according to the second version data in the standby end, the second version data is used to replace the first version data stored in the target client, wherein the first version data is version data for processing the target data generated by the target client when the target program in the target client is in the first version, and the second version data is version data for processing the target data when the target program in the standby end is in the second version.

[0130] In the embodiment of the present application, when the first version of the target program in the target client is an abnormal version, the method further includes:

[0131] Update the target database based on the backup data.

[0132] When the first version of the target program in the target client is an abnormal version, the system will not only switch back to the stable version, but also update the target database based on the backup data. This process ensures that even if there is a problem with the new version, the user's business logic and data remain consistent and complete, minimizing the impact on user experience. Through a strict verification and update mechanism, the system can resume normal service in the shortest time, ensuring the security and reliability of data.

[0133] For example, in an online shopping platform, when an order processing error is detected in the first version of the shopping application in the target client (such as the order cannot be saved correctly), the application is switched back to the stable second version. At the same time, the system updates the affected records in the target database based on the backup data saved in the bypass cluster, which is the order information accurately processed and backed up under the second version. In this way, even if there is a problem with the new version, the user's order data can be quickly restored to the correct state, ensuring business continuity and data consistency.

[0134] In some embodiments, the server further includes a second server, the target database is further used to store other data sent to the second server by all other clients, and the method further includes:

[0135] Receive other requests sent by other clients;

[0136] Determine second target data in the target database according to other requests, where the second target data represents other data sent to the second server by other clients;

[0137] The program of the second server determines the user data according to the second target data under the second version.

[0138] The second server can refer to a server that specializes in processing other client requests and managing their data. It works with the first server to ensure that different versions of the program can run independently and handle their own traffic. The second server is responsible for receiving data requests sent by other clients and processing these requests under the second version.

[0139] Other data may refer to data sent by other clients to the second server. Other data may include user's order information, configuration settings, interaction records, etc., depending on the function of the application.

[0140] Other requests may refer to various requests initiated by other clients to obtain or operate their data on the second server. These requests may involve read, write, update or delete operations, such as querying order status, submitting new orders, etc. in an online shopping platform.

[0141] The second target data may refer to data determined from the target database and associated with a specific other request. The second target data is a record sent by other clients to the second server and stored in the target database, reflecting the operation results of other clients under the second version.

[0142] User data may refer to specific user information or operation results determined by the second server according to the second target data under the second version. User data may be processed order details, user configuration or any other user-related data, ensuring the accuracy and consistency of data when the user uses the second version.

[0143] In the embodiment of the present application, other clients may refer to clients that are served by the online cluster, and the online cluster runs a stable second version. The server that distinguishes other clients from the target client can ensure that the new and old versions run independently, and the data of the first server and the second server are stored in the target database, so that the user's data can be kept consistent. For example, in the version A stage of software A, the user has certain interactive operations with the second server that processes version A, and then participates in the version B stage of software A, and has certain interactive operations with the first server that processes version B. The interactive operations of the two stages should be stored in one database, so that the user's search, write and other operation data are consistent.

[0144] A version update provided by an embodiment of the present application, when the target program in the target client is in an abnormal first version, the server sends the second version and the version switchback instruction to the target client, instructing it to safely switch back from the abnormal version to the stable second version. At the same time, a target database is provided in the first server, which is used to store the data sent by all target clients, and after receiving the user request, forwards the specific traffic to the backup end for processing according to the request type to ensure the consistency and security of the data. The backup end uses the second version to process these write operations, generates backup data, and then updates the target database. In addition, the system also includes a second server, which is responsible for processing requests from other clients and managing their data, ensuring that different versions of the program run independently and the data is consistent. In this way, even if there is a problem with the new version, the service can be quickly restored, ensuring the user experience and data security.

[0145] Figure 4 A schematic diagram of a version update device provided in an embodiment of the present application Figure 1 ,like Figure 4 As shown, the version updating device 40 provided in this embodiment includes:

[0146] The first processing module 401 is used to switch the first version of the target program back to the second version when the first version of the target program is an abnormal version;

[0147] The second processing module 402 is used to switch the first version data stored in the target client to the second version data obtained from the standby end, wherein the first version data is version data for processing the target data generated by the target client when the target program in the target client is in the first version, and the second version data is version data for processing the target data when the target program in the standby end is in the second version.

[0148] In a possible implementation, the first processing module 401 is further configured to switch back the first version of the target program to the second version, including:

[0149] receiving a version switchback instruction sent by the server, where the version switchback instruction is an instruction generated by the server in response to a user request, or an instruction generated according to a version period of the first version;

[0150] According to the version switching back instruction, the first version of the target program is switched back to the second version.

[0151] In a possible implementation, the first processing module 401 is further configured to, when the first version of the target program is a normal version,

[0152] According to the target program in the first version, the target data is read and processed to obtain the first version data;

[0153] The first version data is stored.

[0154] In a possible implementation, the second processing module 402 is further configured to, when the first version data is of a read logic type,

[0155] After switching the target program from the first version to the second version,

[0156] According to the target program in the second version, the target data is read and processed to obtain the third version data.

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

[0158] Figure 5 A schematic diagram of a version update device provided in an embodiment of the present application Figure 2 ,like Figure 5 As shown, the version updating device 50 provided in this embodiment includes:

[0159] The third processing module 501 is used to send the second version to the target client when the first version of the target program in the target client is an abnormal version, so that the first version of the target program in the target client is switched back to the second version;

[0160] The fourth processing module 502 is used to send to the target client according to the second version data in the standby end, and the second version data is used to replace the first version data stored in the target client, wherein the first version data is the version data for processing the target data generated by the target client when the target program in the target client is in the first version, and the second version data is the version data for processing the target data when the target program in the standby end is in the second version.

[0161] In a possible implementation, the third processing module 501 is further configured to send the second version to the target client when the first version of the target program in the target client is an abnormal version, so that the first version of the target program in the target client is switched back to the second version, including:

[0162] The second version and the version switchback instruction are sent to the target client. The version switchback instruction is an instruction generated by the server in response to a user request, or an instruction generated according to the version period of the first version, so that the target program in the target client switches back from the first version to the second version according to the second version and the version switchback instruction.

[0163] In a possible implementation, the server includes a first server, a target database is provided in the server, and the target database is used to store target data sent by all target clients to the first server. The third processing module 501 is further used to receive a user request sent by the target client;

[0164] Determine, according to the user request, first target data in the target database, where the first target data represents target data sent by the target client to the first server;

[0165] When the first target data is of write logic type,

[0166] The user request is sent to the standby end, so that the program of the standby end determines the standby data according to the first target data under the second version.

[0167] In a possible implementation, the third processing module 501 is further configured to, before receiving the user request sent by the target client, include:

[0168] According to the client list stored in the server, a target client and other clients are determined so that a target program in the target client with a first version processes target data with the first version, and a target program in other clients with a second version processes target data with the second version.

[0169] In a possible implementation, the server further includes a second server, the target database is further used to store other data sent by all other clients to the second server, and the third processing module 501 is further used to receive other requests sent by other clients;

[0170] Determine second target data in the target database according to other requests, where the second target data represents other data sent to the second server by other clients;

[0171] The program of the second server determines the user data according to the second target data under the second version.

[0172] In a possible implementation, the fourth processing module 502 is further configured to update the target database according to the backup data when the first version of the target program in the target client is an abnormal version.

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

[0174] Figure 6 A schematic diagram of the structure of a version update device provided in an embodiment of the present application. Figure 6 As shown, the version update device 60 provided in this embodiment includes: at least one processor 601 and a memory 602. Optionally, the device 60 also includes a communication component 603. The processor 601, the memory 602 and the communication component 603 are connected via a bus 604.

[0175] In a specific implementation process, at least one processor 601 executes the computer execution instructions stored in the memory 602, so that at least one processor 601 executes the above method.

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

[0177] In the above embodiments, it should be understood that the processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the invention can be directly implemented as a hardware processor, or can be implemented by a combination of hardware and software modules in the processor.

[0178] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (NVM), such as at least one disk storage.

[0179] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of this application is not limited to only one bus or one type of bus.

[0180] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0181] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

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

[0183] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0184] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

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

[0186] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0187] If the function is implemented in the form of 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 the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0188] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0189] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A version update method, applied to a target client, characterized in that: include: When the first version of the target program is an abnormal version, switching the first version of the target program back to the second version; Switch the first version data stored in the target client to the second version data obtained from the standby end, wherein the first version data is version data for processing the target data generated by the target client when the target program in the target client is in the first version, and the second version data is version data for processing the target data when the target program in the standby end is in the second version.

2. The method according to claim 1, characterized in that When the first version data is of a read logic type, After switching the first version of the target program back to the second version, the method further includes: The target data is read and processed according to the target program under the second version to obtain the third version data.

3. The method according to claim 1, characterized in that Switching the first version of the target program back to the second version includes: receiving a version switchback instruction sent by a server, where the version switchback instruction is an instruction generated by the server in response to a user request, or an instruction generated according to a version period of the first version; According to the version switching back instruction, the first version of the target program is switched back to the second version.

4. The method according to claim 1, characterized in that: When the first version of the target program is a normal version, the method further includes: According to the target program in the first version, the target data is read and processed to obtain the first version data; The first version data is stored.

5. A version update method, applied to a server, characterized in that: The server is provided with a standby terminal, including: When the first version of the target program in the target client is an abnormal version, sending the second version to the target client, so that the first version of the target program in the target client is switched back to the second version; The second version data in the standby end is sent to the target client, and the second version data is used to replace the first version data stored in the target client, wherein the first version data is version data for processing target data generated by the target client when the target program in the target client is under the first version, and the second version data is version data for processing the target data when the target program in the standby end is under the second version.

6. The method according to claim 5, characterized in that When the first version of the target program in the target client is an abnormal version, sending the second version to the target client so that the first version of the target program in the target client is switched back to the second version, including: The second version and a version switchback instruction are sent to the target client, where the version switchback instruction is an instruction generated by the server in response to a user request, or an instruction generated according to the version period of the first version, so that the target program in the target client switches back from the first version to the second version according to the second version and the version switchback instruction.

7. The method according to claim 5, characterized in that The server includes a first server, a target database is provided in the server, and the target database is used to store the target data sent by all the target clients to the first server. The method further includes: Receive a user request sent by a target client; Determine, according to the user request, first target data in the target database, where the first target data represents the target data sent by the target client to the first server; When the first target data is of write logic type, The user request is sent to the standby end, so that the program of the standby end determines the standby data according to the first target data under the second version.

8. The method according to claim 7, characterized in that Before receiving the user request sent by the target client, it includes: The target client and other clients are determined according to the client list stored in the server, so that the target program in the target client at the first version processes the target data with the first version, and the target program in the other clients at the second version processes the target data with the second version.

9. The method according to claim 7, characterized in that: When the first version of the target program in the target client is an abnormal version, the method further includes: The target database is updated according to the standby data.

10. The method according to claim 5, characterized in that The server further includes a second server, the target database is further used to store other data sent to the second server by all other clients, and the method further includes: Receive other requests sent by other clients; Determine, according to the other request, second target data in the target database, where the second target data represents other data sent by the other client to the second server; The program of the second server determines the user data according to the second target data under the second version.

11. A version updating device, characterized in that: include: A first processing module, configured to switch the first version of the target program back to the second version when the first version of the target program is an abnormal version; The second processing module is used to switch the first version data stored in the target client to the second version data obtained from the standby end, wherein the first version data is the version data for processing the target data generated by the target client when the target program in the target client is under the first version, and the second version data is the version data for processing the target data when the target program in the standby end is under the second version.

12. A version updating device, characterized in that: include: A third processing module is used for sending the second version to the target client when the first version of the target program in the target client is an abnormal version, so that the first version of the target program in the target client is switched back to the second version; A fourth processing module is used to send second version data in the standby end to the target client, wherein the second version data is used to replace the first version data stored in the target client, wherein the first version data is version data for processing the target data generated by the target client when the target program in the target client is in the first version, and the second version data is version data for processing the target data when the target program in the standby end is in the second version.

13. A version update device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 10.

14. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 10 when executed by a processor.

15. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 10 when being executed by a processor.

Images