Version upgrade method, version rollback method and electronic device

Abstract

Embodiments of the present application provide a version upgrade method, a version rollback method and an electronic device. The method comprises: receiving an upgrade request sent by a client, the upgrade request being used to request version upgrade of a business system corresponding to the client, and a current version of the business system corresponding to the client being a first version; determining at least one second version according to the upgrade request, the second version being higher than the first version; determining a recommendation weight of each second version according to first version information of the first version and second version information of each second version; determining a target version in the at least one second version according to the recommendation weight of each second version, and upgrading the business system according to the target version. Through the above method, the target version with higher matching degree with the business system of the client can be provided for the client in the at least one second version according to the recommendation weight of each second version, and the robustness of version upgrade of the business system corresponding to the client is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a version upgrade method, a version rollback method, and an electronic device. Background Technology

[0002] The server can be used to deploy the corresponding business system (or simply system) for the client, which can then provide business services to the user. For example, the business system can be a Kubernetes (K8S) system.

[0003] In practical applications, business system versions may be updated, requiring frequent upgrades to reduce maintenance costs. In related technologies, users can upgrade business systems using container application platforms (e.g., OKD platforms). During the upgrade process, users typically define the next higher version or the latest version of the current business system as the target version and upgrade the system accordingly.

[0004] However, in the above process, when upgrading the business system corresponding to the client using the target version selected by the user, the upgrade may fail or the business system may malfunction when performing certain business processes after the upgrade is successful, resulting in poor robustness when the user upgrades the business system corresponding to the client. Summary of the Invention

[0005] This application provides a version upgrade method, a version rollback method, and an electronic device. This method can be used to improve the robustness of users when upgrading business systems.

[0006] In a first aspect, embodiments of this application provide a version upgrade method, the method comprising:

[0007] Receive an upgrade request sent by a client, the upgrade request being used to request a version upgrade of the business system corresponding to the client, the current version of the business system corresponding to the client being the first version;

[0008] Based on the upgrade request, at least one second version is determined, wherein the second version is superior to the first version;

[0009] Based on the first version information of the first version and the second version information of each second version, determine the recommendation weight of each second version;

[0010] Based on the recommendation weight of each second version, a target version is determined in the at least one second version, and the business system is upgraded according to the target version.

[0011] The above technical solution can provide the client with a target version that is more compatible with its own business system in at least one second version, based on the recommendation weight of each second version, thereby improving the robustness of upgrading the corresponding business system of the client.

[0012] In one possible implementation, for any second version; based on the first version information of the first version and the second version information of the second version, the recommendation weight of the second version is determined, including:

[0013] Obtain the custom weights corresponding to the second version;

[0014] The recommendation weight of the second version is determined based on the custom weight, the first version information, and the second version information.

[0015] The above technical solution considers both the impact of multiple changes in version information parameters on recommendation weight and the impact of user-defined parameters on recommendation weight, thereby improving the accuracy of determining the recommendation weight for the second version.

[0016] One possible implementation involves obtaining the custom weights corresponding to the second version, including:

[0017] Obtain the client's setting weight for the second version;

[0018] Obtain the API impact weight of the business system corresponding to the second version. The API impact weight is used to indicate the degree of influence of the API on the business system corresponding to the second version.

[0019] The custom weight is determined based on the set weight and the API influence weight.

[0020] The above technical solution not only takes into account users' choices of functions for different versions of the business system by setting weights, but also considers the impact of incompatible APIs on the business system during the upgrade process by using API influence weights, thereby improving the accuracy of custom weight determination and making the recommended weights of the second version more reflective of users' real needs.

[0021] One possible implementation involves obtaining the API impact weight of the business system corresponding to the second version, including:

[0022] Retrieve multiple call records of the business system being called by API from a preset database, wherein the call records include the version number corresponding to the business system;

[0023] Based on the version number of the second version, at least one target call record is determined from the plurality of call records, wherein the target call record is a call record that is called by an incompatible API;

[0024] The API impact weight is determined based on the target call records.

[0025] The above technical solution determines the API impact weight based on multiple call records of the business system being called by the API, which helps to reflect the impact of incompatible APIs on the upgrade of the business system version.

[0026] In one possible implementation, determining the target version among the at least one second version based on the recommendation weight of each second version includes:

[0027] The second version with the highest recommendation weight among the at least one second version is determined as the target version.

[0028] The higher the recommendation weight of the above technical solution, the higher the matching degree between the second version and the corresponding business system of the client. Selecting the second version with the highest recommendation weight as the target version is conducive to ensuring the stability of the business system after the version upgrade.

[0029] In one possible implementation, determining the target version among the at least one second version based on the recommendation weight of each second version includes:

[0030] Send the second version information and recommendation weight of at least one second version to the client;

[0031] Receive the target version information sent by the client;

[0032] The target version is determined based on the target version information.

[0033] The above technical solution can send at least one second version information and recommendation weight to the client, allowing users to choose the target version from these at least one second version through the client, thus improving the flexibility of users in determining the target version.

[0034] In one possible implementation, the method further includes:

[0035] Intercept multiple call requests from the client to the business system, wherein the call requests include the version number of the API calling the business system;

[0036] Based on the version number of the API, the multiple call requests are filtered to obtain multiple target call requests, wherein the version number of the API included in the target call requests is a preset version number;

[0037] The multiple call records are generated based on the multiple target call requests, and the multiple call records are stored in the preset database.

[0038] The above technical solution allows users to set filtering rules according to their needs, and to intercept and filter multiple call requests based on the filtering rules to obtain the target call request and generate multiple call records, thereby improving the flexibility of call request interception and processing.

[0039] In one possible implementation, the method further includes:

[0040] Receive the first call request from the client to the business system, wherein the first call request includes first API information of the first API;

[0041] Based on the first call request, determine whether the first API is compatible with the current version of the API service;

[0042] If not, then determine the second API information of the first API based on the current version of the API service;

[0043] The first API information in the first call request is transformed according to the second API information to obtain a second call request, wherein the second call request includes the second API information of the first API;

[0044] Perform business processing based on the second call request.

[0045] The above technical solution can handle incompatible APIs to ensure that the business system can receive call requests from the client and perform business processing normally after the version upgrade, which helps to improve the robustness of the business system upgrade.

[0046] In one possible implementation, the first version information includes the first version number of the first version, the first online time of the first version, and the first offline time of the first version;

[0047] The second version information includes the second version number of the second version, the second launch time of the second version, and the first offline time of the second version.

[0048] The recommendation weights of the second version satisfy the following formula:

[0049]

[0050] Wherein, 'a' is a preset coefficient, and 'V' is a preset coefficient. time The usage duration of the second version, the V φxV is the difference between the major version number in the second version number and the major version number in the first version number. φy V is the difference between the minor version number in the second version number and the minor version number in the first version number. φz The difference between the patch version number in the second version number and the patch version number in the first version number, where P1, P2, and P3 are preset weight values, and A is... customer For custom weights, the V age The duration of the second version's online life, the V current For the second online time, the V unsupport This is the second offline time.

[0051] The above technical solution improves the accuracy of the recommendation weight calculation for the second version by combining parameters from multiple official versions and user-defined parameters.

[0052] Secondly, embodiments of this application provide a version rollback method, the method further comprising:

[0053] Receive an upgrade failure message sent by the client, the upgrade failure message being used to indicate that the upgrade of the business system corresponding to the client from the first version to the target version has failed;

[0054] Based on the upgrade failure message, at least one rollback version is determined;

[0055] Determine the recommendation weight for each rollback version;

[0056] Based on the recommendation weight of each rollback version, a target rollback version is determined among the at least one rollback version, and the business system is updated according to the target rollback version.

[0057] The above technical solution can provide the client with a target rollback version that is more compatible with its own business system in at least one rollback version, based on the recommendation weight of each rollback version, thereby improving the robustness of the client's corresponding business system when performing version rollback.

[0058] In one possible implementation, for any rollback version, the recommendation weight of the rollback version is determined, including:

[0059] Obtain the custom weight corresponding to the rollback version, and the rollback version information of the rollback version;

[0060] Obtain the target version information of the target version;

[0061] The recommended weight of the rollback version is determined based on the custom weight, the rollback version information, and the target version information.

[0062] The above technical solution considers both the impact of changes in multiple version information parameters on recommendation weight and the impact of user-defined parameters on recommendation weight, thereby improving the accuracy of determining the recommendation weight of the rollback version.

[0063] One possible implementation involves obtaining the custom weight corresponding to the rollback version, including:

[0064] Obtain the client's setting weight for the rollback version;

[0065] Obtain the API impact weight of the business system corresponding to the rollback version. The API impact weight is used to indicate the degree of impact of the API on the calls to the business system corresponding to the rollback version.

[0066] The custom weight is determined based on the set weight and the API influence weight.

[0067] The above technical solution not only considers users' choices of functions for different versions of the business system by setting weights, but also considers the impact of incompatible APIs on the business system during the rollback process by using API influence weights. This improves the accuracy of the custom weight determination and makes the recommended weight of the rollback version more reflective of users' real needs.

[0068] One possible implementation involves obtaining the API impact weight of the business system corresponding to the rollback version, including:

[0069] Retrieve multiple call records of the business system being called by API from a preset database, wherein the call records include the version number corresponding to the business system;

[0070] Based on the version number of the rollback version, at least one target call record is determined from the plurality of call records, and the target call record is the call record that was called by the incompatible API;

[0071] The API impact weight is determined based on the target call records.

[0072] The above technical solution determines the API impact weight based on multiple call records of the business system being called by the API, which helps to reflect the impact of incompatible APIs on the rollback of the business system version.

[0073] In one possible implementation, determining a target rollback version among the at least one rollback version based on the recommendation weight of each rollback version includes:

[0074] The rollback version with the highest recommendation weight among the at least one rollback version is determined as the target rollback version.

[0075] In the above technical solution, the higher the recommendation weight, the higher the matching degree between the rollback version and the corresponding business system of the client. Selecting the rollback version with the highest recommendation weight as the target rollback version is beneficial to ensuring the robustness of the business system version after rollback.

[0076] In one possible implementation, determining a target rollback version among the at least one rollback version based on the recommendation weight of each rollback version includes:

[0077] Send the rollback version information and recommendation weight of the at least one rollback version to the client;

[0078] Receive the target rollback version information sent by the client;

[0079] The target rollback version is determined based on the target rollback version information.

[0080] The above technical solution can send rollback version information and recommendation weight of at least one rollback version to the client, allowing users to choose the target rollback version from these at least one rollback version through the client, thus improving the flexibility of users in determining the target rollback version.

[0081] In one possible implementation, the method further includes:

[0082] Intercept multiple call requests from the client to the business system, wherein the call requests include the version number of the API calling the business system;

[0083] Based on the version number of the API, the multiple call requests are filtered to obtain multiple target call requests, wherein the version number of the API included in the target call requests is a preset version number;

[0084] The multiple call records are generated based on the multiple target call requests, and the multiple call records are stored in the preset database.

[0085] The above technical solution allows users to set filtering rules according to their needs, and to intercept and filter multiple call requests based on the filtering rules to obtain the target call request and generate multiple call records, thereby improving the flexibility of call request interception and processing.

[0086] In one possible implementation, the method further includes:

[0087] Receive the first call request from the client to the business system, wherein the first call request includes first API information of the first API;

[0088] Based on the first call request, determine whether the first API is compatible with the current version of the API service;

[0089] If not, then determine the second API information of the first API based on the current version of the API service;

[0090] The first API information in the first call request is transformed according to the second API information to obtain a second call request, wherein the second call request includes the second API information of the first API;

[0091] Perform business processing based on the second call request.

[0092] The above technical solution can handle incompatible APIs to ensure that the business system can receive call requests from the client and perform business processing normally after version rollback, which helps to improve the robustness of the business system rollback.

[0093] In one possible implementation, the rollback version information includes the rollback version number, the launch time of the rollback version, and the decommissioning time of the rollback version;

[0094] The target version information includes the target version number, the launch time of the target version, and the decommissioning time of the target version;

[0095] The recommendation weight of the fallback version satisfies the following formula:

[0096]

[0097] Wherein, 'a' is a preset coefficient, and 'V' is a preset coefficient. time The duration of use of the rollback version, the V φx V is the difference between the major version number in the rollback version number and the major version number in the target version number. φy V is the difference between the minor version number in the rollback version number and the minor version number in the target version number. φz The difference between the patch version number in the rollback version number and the patch version number in the target version number, where P1, P2, and P3 are preset weight values, and A is... customer For custom weights, the V age The duration of the rollback version's availability, V current The V is the launch time of the rollback version. unsupport This refers to the time when the rollback version was taken offline.

[0098] The above technical solution improves the accuracy of the recommendation weight calculation for rollback versions by combining parameters from multiple official versions and user-defined parameters.

[0099] Thirdly, embodiments of this application provide a version upgrade device, which includes a receiving module, a determining module, and an upgrade module, wherein...

[0100] The receiving module is used to receive an upgrade request sent by a client. The upgrade request is used to request a version upgrade of the business system corresponding to the client. The current version of the business system is the first version.

[0101] The determining module is used to determine at least one second version based on the upgrade request, wherein the second version is higher than the first version;

[0102] The determining module is further configured to determine the recommendation weight of each second version based on the first version information of the first version and the second version information of each second version;

[0103] The determining module is further configured to determine a target version among the at least one second version based on the recommendation weight of each second version;

[0104] The upgrade module is used to upgrade the business system according to the target version.

[0105] The above technical solution can provide the client with a target version that is more compatible with its own business system in at least one second version, based on the recommendation weight of each second version, thereby improving the robustness of upgrading the corresponding business system of the client.

[0106] In one possible implementation, for any second version; the determining module is specifically used for:

[0107] Obtain the custom weights corresponding to the second version;

[0108] The recommendation weight of the second version is determined based on the custom weight, the first version information, and the second version information.

[0109] The above technical solution considers both the impact of multiple changes in version information parameters on recommendation weight and the impact of user-defined parameters on recommendation weight, thereby improving the accuracy of determining the recommendation weight for the second version.

[0110] In one possible implementation, the determining module is further configured to:

[0111] Obtain the client's setting weight for the second version;

[0112] Obtain the API impact weight of the business system corresponding to the second version. The API impact weight is used to indicate the degree of influence of the API on the business system corresponding to the second version.

[0113] The custom weight is determined based on the set weight and the API influence weight.

[0114] The above technical solution not only takes into account users' choices of functions for different versions of the business system by setting weights, but also considers the impact of incompatible APIs on the business system during the upgrade process by using API influence weights, thereby improving the accuracy of custom weight determination and making the recommended weights of the second version more reflective of users' real needs.

[0115] In one possible implementation, the determining module is further configured to:

[0116] Retrieve multiple call records of the business system being called by API from a preset database, wherein the call records include the version number corresponding to the business system;

[0117] Based on the version number of the second version, at least one target call record is determined from the plurality of call records, wherein the target call record is a call record that is called by an incompatible API;

[0118] The API impact weight is determined based on the target call records.

[0119] The above technical solution determines the API impact weight based on multiple call records of the business system being called by the API, which helps to reflect the impact of incompatible APIs on the upgrade of the business system version.

[0120] In one possible implementation, the determining module is further configured to:

[0121] The second version with the highest recommendation weight among the at least one second version is determined as the target version.

[0122] The higher the recommendation weight of the above technical solution, the higher the matching degree between the second version and the corresponding business system of the client. Selecting the second version with the highest recommendation weight as the target version is conducive to ensuring the stability of the business system after the version upgrade.

[0123] In one possible implementation, the determining module is further configured to:

[0124] Send the second version information and recommendation weight of at least one second version to the client;

[0125] Receive the target version information sent by the client;

[0126] The target version is determined based on the target version information.

[0127] The above technical solution can send at least one second version information and recommendation weight to the client, allowing users to choose the target version from these at least one second version through the client, thus improving the flexibility of users in determining the target version.

[0128] In one possible implementation, the version upgrade device further includes an interception module, a filtering module, and a generation module, wherein:

[0129] The interception module is used to intercept multiple call requests from the client to the business system, wherein the call requests include the version number of the API calling the business system;

[0130] The filtering module is used to filter the multiple call requests according to the version number of the API to obtain multiple target call requests, wherein the version number of the API included in the target call requests is a preset version number;

[0131] The generation module is used to generate the multiple call records based on the multiple target call requests, and store the multiple call records in the preset database.

[0132] The above technical solution allows users to set filtering rules according to their needs, and to intercept and filter multiple call requests based on the filtering rules to obtain the target call request and generate multiple call records, thereby improving the user's flexibility in intercepting and processing call requests.

[0133] In one possible implementation, the version upgrade device further includes a judgment module and a conversion module, wherein:

[0134] The receiving module is further configured to receive a first call request from the client to the business system, wherein the first call request includes first API information of the first API.

[0135] The judgment module is used to determine whether the first API is compatible with the current version of the API service based on the first call request.

[0136] The judgment module is further configured to, if not, determine the second API information of the first API based on the current version of the API service;

[0137] The conversion module is used to convert the first API information in the first call request according to the second API information to obtain a second call request, wherein the second call request includes the second API information of the first API.

[0138] The conversion module is also used to perform business processing based on the second call request.

[0139] The above technical solution can handle incompatible APIs based on the conversion pipeline, ensuring that the business system can receive call requests sent by the client and perform business processing normally after the version upgrade, which helps to improve the robustness of the business system upgrade.

[0140] In one possible implementation, the first version information includes the first version number of the first version, the first online time of the first version, and the first offline time of the first version;

[0141] The second version information includes the second version number of the second version, the second launch time of the second version, and the second decommissioning time of the second version.

[0142] The recommendation weights of the second version satisfy the following formula:

[0143]

[0144] Wherein, 'a' is a preset coefficient, and 'V' is a preset coefficient. time The usage duration of the second version, the V φx V is the difference between the major version number in the second version number and the major version number in the first version number. φy V is the difference between the minor version number in the second version number and the minor version number in the first version number. φz The difference between the patch version number in the second version number and the patch version number in the first version number, where p1, p2, and p3 are preset weight values, and A is... customer For custom weights, the V age The duration of the second version's online life, the V current For the second online time, the V unsupport This is the second offline time.

[0145] The above technical solution improves the accuracy of the recommendation weight calculation for the second version by combining parameters from multiple official versions and user-defined parameters.

[0146] Fourthly, embodiments of this application provide a version rollback device, which includes a receiving module, a determining module, and an updating module, wherein...

[0147] The receiving module is used to receive an upgrade failure message sent by the client, the upgrade failure message being used to indicate that the upgrade of the business system corresponding to the client from the first version to the target version failed;

[0148] The determining module is used to determine at least one rollback version based on the upgrade failure message;

[0149] The determining module is also used to determine the recommendation weight of each rollback version;

[0150] The determining module is further configured to determine a target rollback version among the at least one rollback version based on the recommendation weight of each rollback version;

[0151] The update module is used to update the business system according to the target rollback version.

[0152] The above technical solution can provide the client with a target rollback version that is more compatible with its own business system in at least one rollback version, based on the recommendation weight of each rollback version, thereby improving the robustness of the client's corresponding business system when performing version rollback.

[0153] In one possible implementation, the determining module is specifically used for:

[0154] Obtain the custom weight corresponding to the rollback version, and the rollback version information of the rollback version;

[0155] Obtain the target version information of the target version;

[0156] The recommended weight of the rollback version is determined based on the custom weight, the rollback version information, and the target version information.

[0157] The above technical solution considers both the impact of changes in multiple version information parameters on recommendation weight and the impact of user-defined parameters on recommendation weight, thereby improving the accuracy of determining the recommendation weight of the rollback version.

[0158] In one possible implementation, the determining module is further configured to:

[0159] Obtain the client's setting weight for the rollback version;

[0160] Obtain the API impact weight of the business system corresponding to the rollback version. The API impact weight is used to indicate the degree of impact of the API on the calls to the business system corresponding to the rollback version.

[0161] The custom weight is determined based on the set weight and the API influence weight.

[0162] The above technical solution not only considers users' choices of functions for different versions of the business system by setting weights, but also considers the impact of incompatible APIs on the business system during the rollback process by using API influence weights. This improves the accuracy of the custom weight determination and makes the recommended weight of the rollback version more reflective of users' real needs.

[0163] In one possible implementation, the determining module is further configured to:

[0164] Retrieve multiple call records of the business system being called by API from a preset database, wherein the call records include the version number corresponding to the business system;

[0165] Based on the version number of the rollback version, at least one target call record is determined from the plurality of call records, and the target call record is the call record that was called by the incompatible API;

[0166] The API impact weight is determined based on the target call records.

[0167] The above technical solution determines the API impact weight based on multiple call records of the business system being called by the API, which helps to reflect the impact of incompatible APIs on the rollback of the business system version.

[0168] In one possible implementation, the determining module is further configured to:

[0169] The rollback version with the highest recommendation weight among the at least one rollback version is determined as the target rollback version.

[0170] In the above technical solution, the higher the recommendation weight, the higher the matching degree between the rollback version and the corresponding business system of the client. Selecting the rollback version with the highest recommendation weight as the target rollback version is beneficial to ensuring the robustness of the business system version after rollback.

[0171] In one possible implementation, the determining module is further configured to:

[0172] Send the rollback version information and recommendation weight of the at least one rollback version to the client;

[0173] Receive the target rollback version information sent by the client;

[0174] The target rollback version is determined based on the target rollback version information.

[0175] The above technical solution can send rollback version information and recommendation weight of at least one rollback version to the client, allowing users to choose the target rollback version from these at least one rollback version through the client, thus improving the flexibility of users in determining the target rollback version.

[0176] In one possible implementation, the version rollback device further includes an interception module, a filtering module, and a generation module, wherein:

[0177] The interception module is used to intercept multiple call requests from the client to the business system, wherein the call requests include the version number of the API calling the business system;

[0178] The filtering module is used to filter the multiple call requests according to the version number of the API to obtain multiple target call requests, wherein the version number of the API included in the target call requests is a preset version number;

[0179] The generation module is used to generate the multiple call records based on the multiple target call requests, and store the multiple call records in the preset database.

[0180] The above technical solution allows users to set filtering rules according to their needs, and to intercept and filter multiple call requests based on the filtering rules to obtain the target call request and generate multiple call records, thereby improving the user's flexibility in intercepting and processing call requests.

[0181] In one possible implementation, the version rollback device further includes a judgment module and a conversion module, wherein:

[0182] The receiving module is further configured to receive a first call request from the client to the business system, wherein the first call request includes first API information of the first API.

[0183] The judgment module is used to determine whether the first API is compatible with the current version of the API service based on the first call request.

[0184] The judgment module is further configured to, if not, determine the second API information of the first API based on the current version of the API service;

[0185] The conversion module is used to convert the first API information in the first call request according to the second API information to obtain a second call request, wherein the second call request includes the second API information of the first API.

[0186] The conversion module is also used to perform business processing based on the second call request.

[0187] The above technical solution can handle incompatible APIs based on the conversion pipeline, so as to ensure that the business system can receive the call requests sent by the client and perform business processing normally after the version rollback, which helps to improve the robustness of the business system rollback.

[0188] In one possible implementation, the rollback version information includes the rollback version number, the launch time of the rollback version, and the decommissioning time of the rollback version;

[0189] The target version information includes the target version number, the launch time of the target version, and the decommissioning time of the target version;

[0190] The recommendation weight of the fallback version satisfies the following formula:

[0191]

[0192] Wherein, 'a' is a preset coefficient, and 'V' is a preset coefficient. time The duration of use of the rollback version, the V φx V is the difference between the major version number in the rollback version number and the major version number in the target version number. φy V is the difference between the minor version number in the rollback version number and the minor version number in the target version number. φz The difference between the patch version number in the rollback version number and the patch version number in the target version number, where P1, P2, and P3 are preset weight values, and A is... customer For custom weights, the V age The duration of the rollback version's availability, V current The V is the launch time of the rollback version. unsupport This refers to the time when the rollback version was taken offline.

[0193] The above technical solution improves the accuracy of the recommendation weight calculation for rollback versions by combining parameters from multiple official versions and user-defined parameters.

[0194] Fifthly, embodiments of this application provide an electronic device, a processor, and a memory;

[0195] The memory is used to store computer-executed instructions;

[0196] The processor is configured to execute computer execution instructions stored in the memory, causing the processor to perform the method as described in any of the first aspects.

[0197] The above technical solution can provide clients with a target version that is more compatible with their own business systems based on the recommendation weight of at least one second version, thereby improving the robustness of upgrading the corresponding business systems of clients.

[0198] Sixthly, embodiments of this application provide an electronic device, a processor, and a memory;

[0199] The memory is used to store computer-executed instructions;

[0200] The processor is configured to execute computer execution instructions stored in the memory, causing the processor to perform the method as described in any of the second aspects.

[0201] The above technical solution can provide clients with a target rollback version that is more compatible with their own business system based on the recommendation weight of at least one rollback version, thereby improving the robustness of version rollback for the client's corresponding business system.

[0202] In a seventh aspect, embodiments of this application provide a chip for performing the method described in any of the first aspects.

[0203] Eighthly, embodiments of this application provide a chip for performing the method described in any of the second aspects.

[0204] In a ninth aspect, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions that, when executed by a computer, implement the method as described in any one of the first aspects.

[0205] In a tenth aspect, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions that, when executed by a computer, implement the method as described in any one of the second aspects.

[0206] Eleventhly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects.

[0207] In a twelfth aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the second aspects.

[0208] The version upgrade method, version rollback method, and electronic device provided in this application can receive an upgrade request sent by a client, determine at least one second version based on the upgrade request, determine the recommendation weight of each second version based on the version information of the first version and the second version information of each second version, determine the target version among the at least one second version based on the recommendation weight of each second version, and upgrade the business system based on the target version. Through the above method, based on the recommendation weight of each second version, a target version with a higher degree of matching with the client's own business system can be provided to the client among at least one second version, improving the robustness of version upgrades for the client's corresponding business system. Attached Figure Description

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

[0210] Figure 1 A schematic diagram illustrating the application scenarios provided in the embodiments of this application;

[0211] Figure 2 A flowchart illustrating a version upgrade method provided in an embodiment of this application;

[0212] Figure 3 This application provides a schematic diagram of an upgrade DAG during a version upgrade process.

[0213] Figure 4 A flowchart illustrating a version rollback method provided in an embodiment of this application;

[0214] Figure 5 A schematic diagram of a rollback DAG during a version rollback process provided in this application embodiment;

[0215] Figure 6 A flowchart illustrating a method for obtaining custom weights provided in an embodiment of this application;

[0216] Figure 7 This is a schematic diagram illustrating an application scenario of a conversion pipeline provided in an embodiment of this application;

[0217] Figure 8 A schematic diagram illustrating the conversion process of incompatible API call requests in a conversion pipeline, provided as an embodiment of this application;

[0218] Figure 9 This is a schematic diagram illustrating the working process of a conversion pipeline provided in an embodiment of this application;

[0219] Figure 10 A system architecture diagram of a version upgrade method provided in this application embodiment;

[0220] Figure 11 This is a schematic diagram illustrating an application scenario of a DAG module provided in an embodiment of this application;

[0221] Figure 12 A system architecture diagram of an API service provided in this application embodiment;

[0222] Figure 13A flowchart illustrating another version upgrade method provided in this application embodiment;

[0223] Figure 14 This application provides a schematic diagram of the API proxy workflow during a business system upgrade process.

[0224] Figure 15 This is a schematic diagram of the structure of a version upgrade device provided in an embodiment of this application;

[0225] Figure 16 This is a schematic diagram of another version upgrade device provided in an embodiment of this application;

[0226] Figure 17 This is a schematic diagram of the structure of a version rollback device provided in an embodiment of this application;

[0227] Figure 18 A schematic diagram of another version rollback device provided in this application embodiment;

[0228] Figure 19 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0230] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0231] To facilitate understanding of the embodiments of this application, the concepts involved in the embodiments of this application will be explained first.

[0232] Directed Acyclic Graph (DAG): In graph theory, a directed graph is a graph in which it is impossible to return to a given vertex by any number of edges.

[0233] Container: A virtualization technology in computer operating systems.

[0234] Container group (POD): contains multiple containers.

[0235] Injector: refers to the injection component in the version upgrade device, used to inject a container of Application Program Interface (API) proxies into the user POD.

[0236] Figure 1 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 The electronic device includes a business system, a version upgrade device, and / or a version rollback device. The business system can have multiple versions. The version upgrade device can be used to analyze the version of the business system corresponding to the client, determine multiple upgradable versions of the business system, identify the target upgradable version among these versions, and upgrade the business system from the current version to the target upgradable version. The version rollback device can be used to determine multiple rollback versions for a business system that has failed to upgrade, identify the target rollback version among these versions, and roll back the business system to the target rollback version.

[0237] In related technologies, users can upgrade their business systems using container application platforms (e.g., OKD platforms). During the upgrade process, users typically define the next higher version or the latest version of the current business system as the target version and upgrade accordingly. However, in this process, using the user-selected target version to upgrade the client's business system may result in upgrade failure or, even after a successful upgrade, malfunctions in certain business processes, leading to poor robustness when upgrading the client's business system.

[0238] In view of this, embodiments of this application provide a version upgrade method, which can determine at least one second version that the client can upgrade to, as well as the recommended weight of each second version, based on the upgrade request sent by the client. Based on the recommended weight of each second version, the method provides the client with a target version that has a higher matching degree with its corresponding business system from at least one second version, thereby improving the robustness of version upgrades for the client's corresponding business system.

[0239] The technical solutions of the embodiments of this application will be described in detail below with specific examples. These specific examples can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0240] Figure 2 This is a flowchart illustrating a version upgrade method provided in an embodiment of this application. Please refer to [link / reference]. Figure 2 The method may include:

[0241] S201, Receive upgrade request sent by client.

[0242] The execution subject of this application embodiment can be an electronic device or a version upgrade device in an electronic device. Optionally, the version upgrade device can be implemented by software or by a combination of software and hardware. The electronic device includes, but is not limited to, an independent physical server, a server cluster composed of multiple physical servers, a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms, and can also be a smartphone, smartwatch, tablet computer, laptop, smart in-vehicle device, desktop computer, laptop computer, or virtual reality / augmented reality / mixed reality device, etc.

[0243] An upgrade request is used to request a version upgrade for the business system corresponding to the client. In this embodiment, the business system can be a K8S (Kubernetes) system. The client can be an application or a web browser.

[0244] In this embodiment of the application, the current version of the business system is the first version. For example, if the current version of the business system is 1.18.3, then the first version is 1.18.3.

[0245] In this embodiment of the application, the upgrade request may include first version information of the first version, which may include the version number of the first version, the first online time of the first version, and the first offline time of the first version.

[0246] S202. Determine at least one second version based on the upgrade request.

[0247] In this embodiment, the second version is superior to the first version. For example, suppose there are 5 versions of the business system, namely version 1 to version 5, and they are ordered according to the order of their release: version 1 < version 2 < version 3 < version 4 < version 5. If the first version is version 3, then there are two second versions, version 4 and version 5.

[0248] In this embodiment of the application, the second version information may include the version number of the second version, the second launch time of the second version, and the second decommissioning time of the second version.

[0249] S203. Based on the first version information of the first version and the second version information of each second version, determine the recommendation weight of each second version.

[0250] In this embodiment of the application, the recommendation weight of the second version can be determined as follows: obtain the custom weight corresponding to the second version; determine the recommendation weight of the second version based on the custom weight, the information of the first version, and the information of the second version.

[0251] In the specific implementation process, the recommendation weight of each second version can be determined based on the following formula:

[0252]

[0253] in:

[0254] 'a' is a preset coefficient. For example, 'a' can be 4.

[0255] V time This represents the usage duration of the second version, in days. This usage duration reflects the historical usage of the second version by the business system. If a user has not used the second version, the usage duration is 0.

[0256] V φx This is the difference between the major version number in the second version and the major version number in the first version. In this embodiment, the version number can be represented as XYZ, where X represents the major version number, Y represents the minor version number, and Z represents the patch version number. For example, the first version number is 1.2.3, and its major version number is 1; the second version number is 3.6.7, and its major version number is 3; the difference between the major version number in the second version and the major version number in the first version is 3-1=2, i.e., V φx =2.

[0257] V φy This is the difference between the minor version number in the second version and the minor version number in the first version. For example, if the first version is 1.2.5 and its minor version number is 2; and the second version is 3.6.7 and its minor version number is 6, then the difference between the minor version number in the second version and the minor version number in the first version is 6 - 2 = 4, which is V. φy =4.

[0258] V φzThis is the difference between the patch version number in the second version and the patch version number in the first version. For example, if the first version is 1.2.5 and its patch version number is 5, and the second version is 3.6.7 and its patch version number is 7, then the difference between the patch version number in the second version and the patch version number in the first version is 7 - 5 = 2, which is V. φz =2.

[0259] P1, P2, and P3 are preset weight values. For example, the preset weight value P1 corresponding to the major version number can be set to 10, the preset weight value P2 corresponding to the minor version number can be set to 5, and the preset weight value P3 corresponding to the patch version number can be set to 1.

[0260] A customer For example, custom weights can include user-defined weights for the second version and API influence weights.

[0261] V age This refers to the duration of the second version's availability on the official website. For example, if the second version has been available on the official website for one year, then the duration of the second version's availability would be 365 × 1 = 365 days.

[0262] V current For the second time online, V unsupport This refers to the second offline time. The second launch time is the moment the second version is launched or released on the official website, and the second offline time indicates that the official website will no longer provide support or maintenance for the second version from that moment onwards. For example, if the second launch time is 9:00 AM on December 20, 2020, and the second offline time is 9:00 AM on December 20, 2021, then V... current -V unsupport = -1 year, for any second version, when V current With V unsupport The larger the difference, the higher the calculated recommendation weight value.

[0263] In this embodiment of the application, the above formula covers both the impact of changes in the official version parameters on the recommendation weight and the impact of user-defined parameters on the recommendation weight, so that users can determine the recommendation weight of each second version based on the actual usage scenario of the business system, making it easier for users to select the target version that meets their own business needs.

[0264] Understandably, the higher the recommendation weight of the second version, the better the second version matches the business needs of the business system.

[0265] In this embodiment of the application, the version upgrade device can store multiple second versions that the business system can choose to upgrade to, as well as the second version information and recommendation weights of these second versions, by upgrading the DAG.

[0266] For example, an upgrade DAG may include at least one node, and each node may store version information and recommendation weights for a second version. If the upgrade DAG includes multiple nodes, it may include multiple directed edges, which can connect these nodes in the order they appear.

[0267] Each node can correspond to a second version, and the sequence number of each node can correspond to the sequence number of that second version among multiple second versions. For example, among multiple second versions, these multiple second versions can be sorted according to the order in which they were launched to obtain the sequence number of each second version among multiple second versions.

[0268] Each directed edge stores the sequence number of the originating second version among multiple second versions, and the sequence number of the pointing second version among multiple second versions. Each directed edge points from a lower version to a higher version, and users can use this directed edge to clarify the order relationship between the various second versions.

[0269] Below, in conjunction with Figure 3 This section provides an example illustration of the upgrade DAG during the version upgrade process.

[0270] Figure 3 This is a schematic diagram of an upgrade DAG during a version upgrade process provided in an embodiment of this application. Please refer to [link / reference]. Figure 3 The upgraded DAG graph can include 4 nodes and 6 directed edges, with the 4 nodes connected by these 6 directed edges. Each node can store 3 parameters: the version number of the second version, the data package of the second version, and the recommendation weight of the second version. For example, node 0 stores the version number of the second version as 1.18.3, the data package of the second version as hci.io / X, and the recommendation weight of the second version as 3.1198.

[0271] Each directed edge stores two parameters, including: the second version of the originating edge (in...). Figure 3 The ordinal number of the four second versions (represented by Ori) and the pointer to the end of the second version (in Figure 3 In this context, Des represents the index of the second version in the four second versions. For example, in a directed edge from node 0 to node 3, the version number of the originating end is 1.18.3, and its index in the four second versions is 0; the version number of the pointing end is 1.26.5, and its index in the four second versions is 3; there are three versions between these two second versions.

[0272] For example, assuming there are multiple second versions, the second version with the highest recommendation weight can be highlighted in the upgrade DAG to quickly find the second version with the highest recommendation weight among multiple second versions. For example, in Figure 3 In the data, version 1.26.5 has a recommended weight value of 12.5947, which is the highest among the four versions. This indicates that version 1.26.5 is the most suitable target version for this user. The node corresponding to version 1.26.5 can be displayed in green, while the nodes corresponding to the other versions can be displayed in white.

[0273] S204. Based on the recommendation weight of at least one second version, determine the target version in at least one second version, and upgrade the business system according to the target version.

[0274] In this embodiment of the application, the target version can be determined in the following two ways:

[0275] Scenario 1: The target version is determined by the electronic device. Specifically, the electronic device can identify the second version with the highest recommendation weight among at least one second version as the target version.

[0276] Scenario 2: Determining the target version through interaction between the electronic device and the client. Specifically, the electronic device can send at least one second version of information and its recommendation weight to the client; receive the target version information sent by the client; and determine the target version based on the target version information.

[0277] Understandably, when users select a target version through the client, they can choose the second version with the highest recommended weight or another second version as the target version for upgrading the business system.

[0278] When the client receives at least one second version information and recommendation weight from the electronic device, it can display it to the user in the form of a visual table, allowing the user to clearly and quickly select the target version from at least one second version. For example, the version information and recommendation weight value of the second version with the highest recommendation weight can be displayed in bold in the visual table. For instance, the visual table could be as shown in Table 1:

[0279] Table 1

[0280]

[0281] In the version upgrade method provided in this application embodiment, at least one second version that the client's corresponding business system can be upgraded to, as well as the recommended weight of each second version, can be determined based on the upgrade request sent by the client. Based on the recommended weight of each second version, a target version with a higher matching degree to the client's corresponding business system can be provided to the client in at least one second version, thereby improving the robustness of version upgrades for the client's corresponding business system.

[0282] During the upgrade of a business system from version 1 to a target version, the upgrade may fail. Therefore, embodiments of this application can also provide a version rollback method to revert a failed upgrade of a business system. The following describes this method in conjunction with... Figure 4 The version rollback method provided in the embodiments of this application will be described.

[0283] Figure 4 This is a flowchart illustrating a version rollback method provided in an embodiment of this application. Please refer to... Figure 4 The method may include:

[0284] S401: Receive an upgrade failure message sent by the client.

[0285] The execution subject of this application embodiment can be an electronic device or a version rollback device in an electronic device. Optionally, the version rollback device can be implemented by software or by a combination of software and hardware.

[0286] The upgrade failure message indicates that the upgrade of the client's corresponding business system from version 1 to the target version failed.

[0287] For example, the upgrade failure message may include version information of the first version and version information of the target version.

[0288] S402. Based on the upgrade failure message, determine at least one rollback version.

[0289] The rollback version can include version 1 and version 3, with version 3 being lower than version 1.

[0290] For example, suppose there are 5 versions of a business system, namely version 1 to version 5, and they are ordered according to the order of their release: version 1 < version 2 < version 3 < version 4 < version 5. If the first version is version 4, then there are 3 third versions, from version 1 to version 3. The rollback version can include version 1 to version 4.

[0291] S403. Determine the recommended weight for each rollback version.

[0292] In this embodiment, the recommended weight of each rollback version can be determined as follows: obtain the custom weight corresponding to the rollback version and the first version information of the rollback version; obtain the target version information of the target version; and determine the recommended weight of the rollback version based on the custom weight, the first version information, and the target version information.

[0293] The rollback version information can include the rollback version number, the rollback version's launch time, and the rollback version's decommissioning time. The target version information can include the target version number, the target version's launch time, and the target version's decommissioning time.

[0294] Specifically, in this application embodiment, the recommendation weight of each rollback version can be determined based on the following formula:

[0295]

[0296] Where: a′ is a preset coefficient. For example, a′ can be 4; V time ′ represents the duration of the rollback version; V φx ′ represents the difference between the major version number in the rollback version number and the major version number in the target version number; V φy The difference between the minor version number in the rollback version number and the minor version number in the target version number; V φz P1′ represents the difference between the patch version number in the rollback version number and the patch version number in the target version number; P1′, P2′, and P3′ are preset weight values; A customer ′ represents a custom weight; V age ′ represents the duration of the rollback version; V current ′ represents the release date of the rollback version; V unsupport ′ indicates the time when the rollback version went offline.

[0297] In this embodiment, the version upgrade device can store multiple rollback versions that the business system can choose to roll back to, as well as rollback version information and recommendation weights for these rollback versions, through a rollback DAG.

[0298] Below, in conjunction with Figure 5 This section provides an example illustration of the rollback DAG during the version rollback process.

[0299] Figure 5 This is a schematic diagram of a rollback DAG provided for an embodiment of this application. Please refer to [link / reference]. Figure 5 The fallback DAG consists of 4 nodes and 6 edges. Each node stores the fallback version information and recommendation weight for each fallback version, and each edge of the fallback DAG indicates the order relationship between fallback versions. Figure 5In the diagram, node 3 corresponds to the first version (shown in shaded area), and nodes 1 through 3 correspond to three third versions.

[0300] S404. Based on the recommendation weight of each rollback version, determine the target rollback version in at least one rollback version, and update the business system according to the target rollback version.

[0301] In this embodiment of the application, the target rollback version can be determined in the following two ways:

[0302] Scenario 1: The target rollback version is determined by the electronic device. Specifically, the electronic device can identify the rollback version with the highest recommendation weight among at least one rollback version as the target rollback version.

[0303] Scenario 2: Determining the target rollback version through interaction between the electronic device and the client. Specifically, the electronic device can send rollback version information and recommendation weight of at least one rollback version to the client; receive target rollback version information sent by the client; and determine the target rollback version based on the target rollback version information.

[0304] Understandably, when the client receives rollback version information and recommendation weights for at least one rollback version from the electronic device, it can also display this information to the user in a visual table format, allowing the user to clearly and quickly select the target rollback version from at least one rollback version. The visual table can be found in Table 1 of S204, and will not be elaborated upon here.

[0305] In the version rollback method provided in this application embodiment, at least one rollback version of the client's corresponding business system can be determined based on the upgrade failure message sent by the client, as well as the recommended weight of each rollback version. Based on the recommended weight of each rollback version, a target rollback version with a higher matching degree to the client's corresponding business system is provided among at least one rollback version, thereby improving the robustness of the client's corresponding business system when performing version rollback after upgrade failure.

[0306] Based on the above embodiments, the method for obtaining the custom weights corresponding to the second version will be explained below through specific examples.

[0307] Figure 6 This is a flowchart illustrating a method for obtaining custom weights according to an embodiment of this application. Please refer to... Figure 6 The method may include:

[0308] S601, Obtain the client's setting weight for the second version.

[0309] For example, users can set a weight for the second version through the client according to their needs. This weight can consist of multiple parameters. For instance, suppose a user believes that a new feature in a second version meets their business development needs, they can increase the recommendation weight of that second version by adding a weight.

[0310] S602. Retrieve multiple call records of the business system being called by the API from the preset database.

[0311] In this embodiment of the application, the preset database can be ETCD.

[0312] In this embodiment, multiple call records can be obtained and stored in a preset database in the following manner: intercepting multiple call requests from clients to the business system, wherein the call requests include the version number of the API calling the business system; filtering the multiple call requests according to the API version number to obtain multiple target call requests, wherein the target call requests include the API version number as a preset version number; generating multiple call records according to the multiple target call requests, and storing the multiple call records in the preset database.

[0313] For example, each call record may include the POD name, API identifier, business system version number, and the number of calls to each API for each version of the business system. For instance, multiple call records can be shown in Table 2:

[0314] Table 2

[0315] POD1 API-1 Version number of the first version 300 POD2 API-2 Version number of the first version 400 ...... ...... ...... ......

[0316] S603. Based on the version number of the second version, determine at least one target call record among multiple call records.

[0317] The target call record can be a call record that was invoked by an incompatible API.

[0318] Business systems can provide services to clients through APIs, and clients can call services within the business system through APIs. When a business system is upgraded, both the APIs and API services will be updated. For example, if the business system is a Kubernetes (K8S) system, and a user upgrades their K8S system from version 1 to version 3, the API services will also be updated to version 3. The APIs will also be adaptively upgraded across three versions: Alpha (internal beta), Beta (public beta), and Stable. However, while K8S maintains compatibility with Stable APIs and provides long-term support for Beta APIs during upgrades, there is a significant risk of incompatibility with Alpha APIs. Therefore, after a K8S system upgrade, some APIs and API services may become incompatible, causing client API call requests to fail.

[0319] In this application embodiment, if the version of the business system is upgraded from the first version to the second version, it may cause incompatibility between the API and the API service. Therefore, it is necessary to obtain the call record of the incompatible API from multiple call records.

[0320] For example, the target call record can be determined as follows: Based on the version number of the second version, query the version numbers of multiple APIs supported by the API service corresponding to the second version in a preset database; based on the API identifier in each call record, query the version number of the API corresponding to each call record; based on the version numbers of the multiple APIs supported by the API service and the version number of the API corresponding to each call record, determine in turn whether the version number of the API corresponding to each call record is an API version number supported by the API service; if yes, it indicates that the API corresponding to the call record is compatible with the API service; if no, it indicates that the API corresponding to the call record is incompatible with the API service, and the call record is determined as the target call record.

[0321] For example, suppose the second version supports an API with version number Beta. The version upgrade mechanism retrieves three call records. Call records 1 and 2 contain APIs with Beta versions, while call record 3 contains an API with an Alpha version. Understandably, when the business system upgrades to the second version, the API in call record 3 will be incompatible. Therefore, call record 3 can be identified as the target call record.

[0322] S604. Determine the API impact weight based on the target call record.

[0323] In this embodiment of the application, the API influence weight is used to indicate the degree of influence of the API on the calls to the business system corresponding to the second version.

[0324] For example, the API influence weight can be determined as follows: based on the target call records, identify at least one incompatible API and the number of each incompatible API; among multiple call records, determine the client's usage weight for each incompatible API; for any incompatible API, determine the API influence weight based on the number of times the incompatible API is called and the usage weight of the incompatible API.

[0325] For example, suppose we can identify two incompatible APIs based on the target call records: API-1 and AP1-2. API-1 has 10 target call records, meaning there are 10 API-1 APIs, and API-2 has 20 target call records, meaning there are 20 AP1-2 APIs.

[0326] For example, in practical implementation, at least one API requested by the client can be determined based on multiple call records. The usage weight of each API can be determined based on the proportion of call records corresponding to each API within the total number of call records. For instance, the usage weight of each API can be calculated using the following table:

[0327] Table 3

[0328] API-1 150 500 0.3 API-2 100 500 0.2 API-3 250 500 0.5

[0329] In Table 3, each API identifier corresponds to one API. As mentioned above, assuming API-1 and API-2 are incompatible APIs, then the influence weight of the API = 10 × 0.3 + 20 × 0.2 = 7.

[0330] S605. Determine the custom weights based on the set weights and the weights affected by the API.

[0331] For example, custom weights can be the sum of the set weights and the weights affected by the API.

[0332] The method for obtaining custom weights provided in this application embodiment can determine custom weights by setting weights and API influence weights. In the above process, not only are user choices regarding different versions of the business system's functions considered by setting weights, but the impact of incompatible APIs on the business system during upgrades is also considered through API influence weights, making the determined custom weights more accurate.

[0333] Understandably, the specific execution process for obtaining the custom weights corresponding to the rollback version can also be referenced. Figure 6The method for obtaining custom weights provided in the embodiments will not be described again in this application.

[0334] To better understand the transformation process of the transformation pipeline for incompatible API call requests, the following section will combine... Figure 7 The application scenarios of conversion pipelines are explained; combined with Figure 8 This section explains the conversion process for incompatible API call requests in the conversion pipeline.

[0335] Figure 7 This is a schematic diagram illustrating an application scenario of a conversion pipeline provided in an embodiment of this application. Please refer to... Figure 7 The electronic device is equipped with a version upgrade mechanism, and this mechanism includes a conversion pipeline. Figure 7 In this context, clients can send API call requests to an API service to access resources within the business system. If the API call request includes incompatible APIs, a conversion pipeline can be used to transform the incompatible APIs into compatible ones, allowing the client to send API call requests correctly and access resources in the business system through the compatible APIs. For example, in... Figure 7 If the first version of the API is incompatible with the API service, a conversion pipeline can be used to convert the first version of the API to the second version, making the API version compatible with the API service so that the client can send API call requests to the API service normally.

[0336] Figure 8 This is a schematic diagram illustrating the conversion process of incompatible API call requests in a conversion pipeline, as provided in an embodiment of this application.

[0337] Please see Figure 8 The method may include:

[0338] S801, Obtain the client's first call request to the business system.

[0339] The first call request includes first API information for the first API. For example, the first API information may be the first version information of the first API.

[0340] S802. Based on the first call request, determine whether the first API is compatible with the current version of the API service.

[0341] If so, business processing is performed directly based on the first call request. For example, the API service can forward the call request sent by the client to the business system normally through the first API information, and perform business processing based on the call request.

[0342] If not, the first call request needs to be processed for compatibility. The specific execution process is described in S803 to S805.

[0343] S803. If not, determine the second API information of the first API based on the current version of the API service.

[0344] For example, the second API information can be the second version information of the first API.

[0345] S804. The first API information in the first call request is converted according to the second API information to obtain the second call request.

[0346] The second call request includes the second API information of the first API.

[0347] In this embodiment of the application, S803 to S804 can be executed by switching pipelines. The following describes the process in conjunction with... Figure 9 The working process of the conversion pipeline is explained.

[0348] Figure 9 This is a schematic diagram illustrating the working process of a conversion pipeline provided in an embodiment of this application. Please refer to... Figure 9 The conversion pipeline can be used to convert incompatible call requests into compatible call requests. The specific execution process is as follows: Based on the current version of the API service, determine at least one API information of the first API supported by the current version of the API service; if the number of such API information is one, then determine the API information as the second API information; if the number of such API information is multiple, then prioritize these multiple API information according to time order, and determine the API information closest to the current time as the second API information; extract the abstract (type) information from the first API information in the first call request and convert it into a format supported by API-Schema; based on the second API information, select adapters of different schemas to perform conversion processing on the converted type information to obtain the second call request.

[0349] S805. Perform business processing based on the second call request.

[0350] For example, the API service can enable the client to call services in the business system through the first API in the API service, thereby performing business processing, based on the second API information in the first call request.

[0351] The method for converting incompatible API call requests provided in this application embodiment can convert the API information of an incompatible first API by setting up a conversion pipeline. This allows the API service to still forward the call requests sent by the client and perform business processing based on the call requests after the business system is upgraded, which helps to improve the robustness of the business system upgrade.

[0352] The following is combined with Figure 10 Taking the business system as an example, the system architecture of a version upgrade device involved in the embodiments of this application will be described.

[0353] Figure 10 This is a schematic diagram of the system architecture for a version upgrade method provided in an embodiment of this application. Please refer to [link / reference]. Figure 10 The version upgrade mechanism includes a validator, an injector, an API proxy module, and a DAG module. Among them:

[0354] The injector is used to intercept a user's POD creation request. Once the validator verifies the container group creation request, it automatically creates an API proxy container for that container group.

[0355] The API proxy module includes: a container group (POD), a transformation pipeline, a Kubernetes API service (Server), an interceptor, a filter, an ETCD, and a proxy manager. The API proxy module collects user access data, analyzes API call records, and reports them to the DAG module. Specifically: the container group can acquire multiple call requests from electronic devices to the business system; the interceptor intercepts these multiple call requests; the filter processes these multiple call requests to obtain multiple target call requests; the ETCD stores these target call requests; and the proxy manager queries the ETCD for multiple API call records and reports them to the DAG module. The transformation pipeline transforms incompatible APIs among the multiple call requests to ensure that any of the multiple call requests can be sent to the Kubernetes API service. Furthermore, filtering rules for the filters can be configured according to user business needs, allowing the filters to perform filtering according to these configured rules.

[0356] The DAG module can include a scoring module and an upgrade data generation module. The DAG module can be used to determine the recommendation weight of each version, and to generate a DAG based on the version information and recommendation weight of each version. Specifically: the scoring module is used to determine the recommendation weight of each version; the upgrade data generation module can be used to generate the DAG and API call information, and the DAG can be used to store the version information and recommendation weight of each version.

[0357] The structure of the version upgrade device illustrated in the embodiments of this application does not constitute a specific limitation on the version upgrade device. In some embodiments, the version upgrade device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0358] Below, in conjunction with Figure 11 The application scenarios of the DAG module proposed in the embodiments of this application will be described in detail.

[0359] Figure 11 This is a schematic diagram illustrating an application scenario of a DAG module provided in an embodiment of this application. Please refer to [link / reference]. Figure 11 The electronic device is equipped with a version upgrade device and a version rollback device. The version upgrade device includes an upgrade DAG module, and the version rollback device includes a rollback DAG module. An upgrade request can be sent to the upgrade DAG module from a client. After receiving the upgrade request, the upgrade DAG module generates corresponding available upgrade data and sends it to the client. The available upgrade data includes version information and a recommendation weight for at least one second version. Alternatively, an upgrade failure message can be sent to the rollback DAG module from a client. After receiving the upgrade failure message, the rollback DAG module generates corresponding available rollback data and sends it to the client. The available rollback data may include version information and a recommendation weight for at least one rollback version.

[0360] To facilitate understanding of the API call process of the API service provided in the embodiments of this application, the following is combined with... Figure 12 The system architecture of the API service in the embodiments of this application will be described.

[0361] Figure 12 This is a system architecture diagram of an API service provided in an embodiment of this application. Please refer to [link / reference]. Figure 12The API service comprises an API layer, an access control layer, a registry layer, and an ETCD cluster. The API layer primarily provides multiple external API interfaces; the access control layer handles authentication, authorization, and access control; the registry layer stores all resource objects of the business system; and the ETCD cluster persistently stores these resource objects. The API proxy module can automatically inject proxies into newly created PODs and collect client API call records based on access control mechanisms.

[0362] It should be noted that the system architecture and application scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application.

[0363] Based on the above system architecture and application scenarios, the following section combines... Figures 13-14 The version upgrade method provided in the embodiments of this application will be further described in detail.

[0364] Figure 13 This is a flowchart illustrating another version upgrade method provided in an embodiment of this application. Please refer to... Figure 13 The method specifically includes:

[0365] S1301, The client sends an upgrade request to the version upgrade device.

[0366] In this embodiment, the client can be a web browser or an application. The upgrade request may include first version information and recommendation weight.

[0367] S1302, The version upgrade device determines whether there is available upgrade data based on the upgrade request.

[0368] If not, then execute S1303;

[0369] If so, then execute S1304 to S1310.

[0370] In this embodiment of the application, the availability of upgrade data can be determined as follows: obtain the recommendation weight of the first version according to the upgrade request; obtain the recommendation weight of each second version in the upgrade DAG stored in the current version upgrade device; if the recommendation weight of the first version is greater than or equal to the recommendation weight of any second version, it is determined that there is no available upgrade data; if the recommendation weight of the first version is less than the recommendation weight of any second version, it is determined that there is available upgrade data.

[0371] S1303, The version upgrade device sends an indication message to the client that no upgrade data is available.

[0372] S1304, The version upgrade device determines at least one second version based on the upgrade request.

[0373] S1305, the version upgrade device determines the recommended weight of at least one second version based on the first version information and at least one second version information.

[0374] In this embodiment, the version upgrade device can periodically execute S1305 according to a preset duration to update the recommendation weight of the second version stored in the version upgrade device in a timely manner. For example, the preset duration can be 1 day.

[0375] S1306, The version upgrade device generates usable upgrade data based on at least one second version's second version information and recommendation weight.

[0376] S1307, The version upgrade device sends available upgrade data to the client.

[0377] Available upgrade data may include version information and recommendation weights for at least one second version.

[0378] S1308. The client determines the target upgrade version information based on the available upgrade data.

[0379] S1309. The client sends the target upgrade version information to the version upgrade device.

[0380] S1310 The version upgrade device determines the target version based on the target upgrade version information and upgrades the business system according to the target version.

[0381] It should be noted that the specific execution process of S1301 to S1310 can refer to the execution process of the version upgrade method in the above embodiments, and will not be repeated here.

[0382] In this embodiment of the application, if the business system version upgrade fails, the following steps can also be performed:

[0383] S1311, The client sends an upgrade failure message to the version rollback device.

[0384] S1312, The version rollback device determines at least one rollback version based on the upgrade failure message.

[0385] S1313, The version rollback device determines the recommended weight of at least one rollback version based on the target version information and at least one rollback version information.

[0386] S1314. The version rollback device generates usable rollback data based on the rollback version information and recommendation weight of at least one rollback version.

[0387] S1315, The version rollback device sends available rollback data to the client.

[0388] S1316. The client determines the target rollback version information based on the available rollback data.

[0389] S1317. The client sends the target rollback version information to the version rollback device.

[0390] S1318. The version rollback device determines the target rollback version based on the target rollback version information and updates the business system according to the target rollback version.

[0391] It should be noted that the execution process of S1311 to S1318 can refer to the execution process of the version rollback method in the above embodiments, and will not be repeated here.

[0392] The version upgrade method provided in this application embodiment can provide users with information on multiple second versions and recommendation weights when upgrading the business system corresponding to the client, so that users can choose a suitable version to upgrade the business system; it can also provide users with information on multiple rollback versions and recommendation weights after the business system upgrade fails, so that users can choose a suitable rollback version to roll back, thereby improving the robustness and flexibility of users when upgrading the business system.

[0393] Figure 14 This is a schematic diagram illustrating the workflow of an API proxy during a business system upgrade process, as provided in an embodiment of this application. Please refer to [link / reference]. Figure 14 The method specifically includes:

[0394] S1401, The API proxy module sends a container group creation interception request to the K8S API service.

[0395] In this embodiment of the application, the container group creation interception request is used to intercept the creation of new container groups by the client in the business system.

[0396] S1402, the K8S API service sends a container group creation event to the API proxy module.

[0397] S1403, The API proxy module sends a container injection request to the K8S API service.

[0398] In this embodiment of the application, when the API proxy module obtains the container group creation event, it needs to inject a container into the newly created container group so that the container group can be proxied in the future.

[0399] S1404, Kubernetes API service creates container groups.

[0400] S1405, The API proxy module sends a call request to the K8S API service and intercepts the request.

[0401] S1406, K8S API service sends call requests to API proxy module.

[0402] S1407 The API proxy module filters the call requests to obtain the target call request.

[0403] In this embodiment, multiple call requests can be filtered according to preset filtering rules. For example, if the API version number includes Alpha, Beta, and Stable, the preset filtering rule is to filter out call requests for the Stable version and retain call requests for the Alpha and Beta versions.

[0404] S1408, The API proxy module stores the target call request in the preset database.

[0405] In this embodiment, the API proxy module and the K8S API service can periodically execute S1401 to S1408 according to a preset duration, so that the API proxy module can promptly monitor new container groups created by clients and intercept and store their call requests. For example, the preset duration can be 1 day.

[0406] S1409. The client sends a filter configuration request to the API proxy module.

[0407] In this embodiment, the filter configuration request may include filter configuration rules. Users can set the filter configuration rules through a client.

[0408] S1410, The API proxy module configures the filter according to the filter configuration request.

[0409] In this embodiment of the application, the API proxy module can configure the filter according to the filter configuration rules in the filter configuration request.

[0410] S1411, The API proxy module sends a configuration success indication message to the client.

[0411] S1412, The client sends an upgrade request to the API proxy module.

[0412] An upgrade request may include the current version information of the business system and the target version information of the business system after the upgrade.

[0413] S1413. The API proxy module obtains API call information based on the upgrade request.

[0414] The API proxy module can obtain API call information through the DAG module.

[0415] For example, API call information may include POD name, API identifier, the number of calls and compatibility of each API when the business system is in its current version, and the compatibility of each API when the business system is in its target version. S1414, the API proxy module sends API call information to the client.

[0416] S1415. The client selects the API proxy upgrade mode based on the API call information.

[0417] For example, the client can generate visualized API call information based on the API call information. For instance, visualized API call information can be shown in the table below:

[0418] Table 4

[0419]

[0420] In this embodiment, the API proxy upgrade mode includes a compatible upgrade mode and a forced upgrade mode. If the user selects the compatible upgrade mode, steps S1416 to S1421 are executed; if the user selects the forced upgrade mode, steps S1422 to S1424 are executed.

[0421] The following section, in conjunction with S1416 to S1421, explains the compatibility upgrade mode of the API proxy.

[0422] S1416. The client sends a call request to the target system to the API proxy module.

[0423] S1417. The API proxy module proxies the call requests from the business system and converts the proxies into calls from the business system through a conversion channel.

[0424] S1418, The API proxy module sends the converted business system call request to the K8S API service.

[0425] S1419 and K8S API services determine the target resources corresponding to the call requests of the business systems based on the transformed call requests.

[0426] The S1420 and K8S API services send target resources to the API proxy module.

[0427] S1421, The API proxy module sends the target resource to the client.

[0428] In this embodiment, if the user selects the compatibility upgrade mode, an API proxy module and a conversion channel are added between the client and the K8S API service. The API proxy module proxies all business system call requests from the client, and the conversion channel converts incompatible business system call requests into compatible business system call requests, so that the call requests sent by the client after the business system upgrade can be sent to the K8S API service normally.

[0429] The forced upgrade mode of the API proxy will be explained below, in conjunction with S1422 to S1424.

[0430] S1422. The client sends a request to the K8S API service to invoke the business system.

[0431] S1423, the K8S API service determines the target resource corresponding to the call request of the business system.

[0432] The S1424 and K8S API services send the corresponding target resources to the client.

[0433] In this embodiment of the application, if the user selects the forced upgrade mode, the client directly sends a business system call request to the K8S API service to obtain the target resource. However, if the business system call request is an incompatible call request, the K8S API service will be unable to receive the business system call request, resulting in the failure of the target resource call.

[0434] The API proxy workflow provided in this application's embodiments during business system upgrades allows for timely monitoring of user container group creation and configuration of filters according to user needs, improving the flexibility of users in intercepting and handling call requests. Furthermore, during business system upgrades, API call information can be sent to the client, enabling the client to display visualized API call information to users. This allows users to understand the compatibility relationship between their API calls after the upgrade and the upgraded API services, thus flexibly choosing the API proxy upgrade mode and enhancing the flexibility and robustness of business system upgrades.

[0435] Figure 15 This is a schematic diagram of a version upgrade device provided in an embodiment of this application. Please refer to... Figure 15 The version upgrade device 10 includes a receiving module 11, a determining module 12, and an upgrade module 13, wherein...

[0436] The receiving module 11 is used to receive an upgrade request sent by the client. The upgrade request is used to request a version upgrade of the business system corresponding to the client. The current version of the business system is the first version.

[0437] The determining module 12 is used to determine at least one second version based on the upgrade request, wherein the second version is higher than the first version;

[0438] The determining module 12 is further configured to determine the recommendation weight of each second version based on the first version information of the first version and the second version information of each second version;

[0439] The determining module 12 is further configured to determine a target version in the at least one second version according to the recommendation weight of each second version;

[0440] The upgrade module 13 is used to upgrade the business system according to the target version.

[0441] The version upgrade device provided in this application embodiment can be used to execute the technical solutions shown in any of the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0442] In one possible implementation, for any second version; the determining module 12 is specifically used for:

[0443] Obtain the custom weights corresponding to the second version;

[0444] The recommendation weight of the second version is determined based on the custom weight, the first version information, and the second version information.

[0445] In one possible implementation, the determining module 12 is further configured to:

[0446] Obtain the client's setting weight for the second version;

[0447] Obtain the API impact weight of the business system corresponding to the second version. The API impact weight is used to indicate the degree of influence of the API on the business system corresponding to the second version.

[0448] The custom weight is determined based on the set weight and the API influence weight.

[0449] In one possible implementation, the determining module 12 is further configured to:

[0450] Retrieve multiple call records of the business system being called by API from a preset database, wherein the call records include the version number corresponding to the business system;

[0451] Based on the version number of the second version, at least one target call record is determined from the plurality of call records, wherein the target call record is a call record that is called by an incompatible API;

[0452] The API impact weight is determined based on the target call records.

[0453] In one possible implementation, the determining module 12 is further configured to:

[0454] The second version with the highest recommendation weight among the at least one second version is determined as the target version.

[0455] In one possible implementation, the determining module 12 is further configured to:

[0456] Send the second version information and recommendation weight of at least one second version to the client;

[0457] Receive the target version information sent by the client;

[0458] The target version is determined based on the target version information.

[0459] Figure 16 This is a schematic diagram of another version upgrade device provided in an embodiment of this application. Please refer to... Figure 16 ,exist Figure 15 Based on the version upgrade device shown, the version upgrade device 10 may further include an interception module 14, a filtering module 15, a generation module 16, a judgment module 17, and a conversion module 18, wherein,

[0460] The interception module 14 is used to intercept multiple call requests from the client to the business system, wherein the call requests include the version number of the API of the business system being called;

[0461] The filtering module 15 is used to filter the multiple call requests according to the version number of the API to obtain multiple target call requests, wherein the version number of the API included in the target call requests is a preset version number;

[0462] The generation module 16 is used to generate the multiple call records based on the multiple target call requests, and store the multiple call records in the preset database.

[0463] In one possible implementation, the receiving module 11 is further configured to receive the client's first call request to the business system, wherein the first call request includes first API information of the first API;

[0464] The judgment module 17 is used to determine whether the first API is compatible with the current version of the API service based on the first call request;

[0465] The judgment module 17 is further configured to, if not, determine the second API information of the first API based on the current version of the API service;

[0466] The conversion module 18 is used to convert the first API information in the first call request according to the second API information to obtain a second call request, wherein the second call request includes the second API information of the first API.

[0467] The conversion module 18 is also used to perform business processing based on the second call request.

[0468] In one possible implementation, the first version information includes the first version number of the first version, the first online time of the first version, and the first offline time of the first version.

[0469] The second version information includes the second version number of the second version, the second launch time of the second version, and the second decommissioning time of the second version.

[0470] In one possible implementation, the recommendation weight of the second version satisfies the following formula:

[0471]

[0472] Wherein, 'a' is a preset coefficient, and 'V' is a preset coefficient. time The usage duration of the second version, the V φx V is the difference between the major version number in the second version number and the major version number in the first version number. φy V is the difference between the minor version number in the second version number and the minor version number in the first version number. φz The difference between the patch version number in the second version number and the patch version number in the first version number, where P1, P2, and P3 are preset weight values, and A is... customer For custom weights, the V age The duration of the second version's online life, the V current For the second online time, the V unsupport This is the second offline time.

[0473] The version upgrade device provided in this application embodiment can be used to execute the technical solutions shown in any of the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0474] Figure 17 This is a schematic diagram of a version rollback device provided in an embodiment of this application. Please refer to... Figure 17The version rollback device 20 includes a receiving module 21, a determining module 22, and an updating module 23, wherein...

[0475] The receiving module 21 is used to receive an upgrade failure message sent by the client, the upgrade failure message being used to indicate that the upgrade of the business system corresponding to the client from the first version to the target version failed;

[0476] The determining module 22 is used to determine at least one rollback version based on the upgrade failure message;

[0477] The determining module 22 is also used to determine the recommendation weight of each rollback version;

[0478] The determining module 22 is further configured to determine a target rollback version among the at least one rollback version based on the recommendation weight of each rollback version;

[0479] The update module 23 is used to update the business system according to the target rollback version.

[0480] The version rollback device provided in this application embodiment can be used to execute the technical solutions shown in any of the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0481] In one possible implementation, the determining module 22 is specifically used for:

[0482] Obtain the custom weight corresponding to the rollback version, and the rollback version information of the rollback version;

[0483] Obtain the target version information of the target version;

[0484] The recommended weight of the rollback version is determined based on the custom weight, the rollback version information, and the target version information.

[0485] In one possible implementation, the determining module 22 is further configured to:

[0486] Obtain the client's setting weight for the rollback version;

[0487] Obtain the API impact weight of the business system corresponding to the rollback version. The API impact weight is used to indicate the degree of impact of the API on the calls to the business system corresponding to the rollback version.

[0488] The custom weight is determined based on the set weight and the API influence weight.

[0489] In one possible implementation, the determining module 22 is further configured to:

[0490] Retrieve multiple call records of the business system being called by API from a preset database, wherein the call records include the version number corresponding to the business system;

[0491] Based on the version number of the rollback version, at least one target call record is determined from the plurality of call records, and the target call record is the call record that was called by the incompatible API;

[0492] The API impact weight is determined based on the target call records.

[0493] In one possible implementation, the determining module 22 is further configured to:

[0494] The rollback version with the highest recommendation weight among the at least one rollback version is determined as the target rollback version.

[0495] In one possible implementation, the determining module 22 is further configured to:

[0496] Send the rollback version information and recommendation weight of the at least one rollback version to the client;

[0497] Receive the target rollback version information sent by the client;

[0498] The target rollback version is determined based on the target rollback version information.

[0499] Figure 18 A schematic diagram of another version rollback device provided in an embodiment of this application. Please refer to... Figure 18 ,exist Figure 17 Based on the version rollback device shown, the version rollback device 20 may further include an interception module 24, a filtering module 25, a generation module 26, a judgment module 27, and a conversion module 28, wherein,

[0500] The interception module 24 is used to intercept multiple call requests from the client to the business system, wherein the call requests include the version number of the API calling the business system;

[0501] The filtering module 25 is used to filter the multiple call requests according to the version number of the API to obtain multiple target call requests, wherein the version number of the API included in the target call requests is a preset version number;

[0502] The generation module 26 is used to generate the multiple call records based on the multiple target call requests, and store the multiple call records in the preset database.

[0503] In one possible implementation, the receiving module 21 is further configured to receive a first call request from the client to the business system, wherein the first call request includes first API information of the first API;

[0504] The judgment module 27 is used to determine whether the first API is compatible with the current version of the API service based on the first call request;

[0505] The judgment module 27 is further configured to, if not, determine the second API information of the first API based on the current version of the API service;

[0506] The conversion module 28 is used to convert the first API information in the first call request according to the second API information to obtain a second call request, wherein the second call request includes the second API information of the first API.

[0507] The conversion module 28 is also used to perform business processing based on the second call request.

[0508] In one possible implementation, the rollback version information includes the rollback version number, the launch time of the rollback version, and the decommissioning time of the rollback version;

[0509] The target version information includes the target version number, the launch time of the target version, and the decommissioning time of the target version;

[0510] The recommendation weight of the fallback version satisfies the following formula:

[0511]

[0512] Wherein, 'a' is a preset coefficient, and 'V' is a preset coefficient. time The duration of use of the rollback version, the V φx V is the difference between the major version number in the rollback version number and the major version number in the target version number. φy V is the difference between the minor version number in the rollback version number and the minor version number in the target version number. φz The difference between the patch version number in the rollback version number and the patch version number in the target version number, where P1, P2, and P3 are preset weight values, and A is... customer For custom weights, the V age The duration of the rollback version's availability, V current The V is the launch time of the rollback version. unsupport This refers to the time when the rollback version was taken offline.

[0513] The version rollback device provided in this application embodiment can be used to execute the technical solutions shown in any of the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0514] Figure 19 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Please refer to... Figure 19 The electronic device 30 may include a processor 31 and a memory 32. The processor 31 and the memory 32 can communicate; for example, the processor 31 and the memory 32 communicate via a communication bus 33.

[0515] The memory 32 is used to store computer execution instructions;

[0516] The processor 31 is used to execute computer execution instructions stored in the memory 32, so that the processor 31 executes the technical solution as shown in the above method embodiment.

[0517] Optionally, the electronic device 30 may also include a communication interface, which may include a transmitter and / or a receiver.

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

[0519] The electronic device provided in this application embodiment can be used to execute the technical solutions shown in any of the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0520] This application also provides a chip for executing the version upgrade method as described in any of the above method embodiments. The implementation principle and technical effect are similar, and will not be described in detail here.

[0521] This application also provides a chip for executing the version rollback method as described in any of the above method embodiments. The implementation principle and technical effect are similar, and will not be described in detail here.

[0522] This application also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed by a computer, they implement the version upgrade method executed in any of the above method embodiments. The implementation principle and technical effect are similar, and will not be described in detail here.

[0523] This application also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed by a computer, they implement the version rollback method executed in any of the above method embodiments. The implementation principle and technical effect are similar, and will not be described in detail here.

[0524] This application also provides a computer program product, including a computer program. When the computer program is executed by a computer, it implements the version upgrade method executed in any of the above method embodiments. The implementation principle and technical effect are similar, and will not be described in detail here.

[0525] This application also provides a computer program product, including a computer program. When the computer program is executed by a computer, it implements the version upgrade method executed in any of the above method embodiments. The implementation principle and technical effect are similar, and will not be described in detail here.

[0526] All or part of the steps in the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.

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

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

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

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

[0531] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes 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. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

Claims

1. A version upgrade method, characterized in that, include: Receive an upgrade request sent by a client, the upgrade request being used to request a version upgrade of the business system corresponding to the client, the current version of the business system corresponding to the client being the first version; Based on the upgrade request, at least one second version is determined, wherein the second version is superior to the first version; For any second version, obtain the custom weight corresponding to the second version; Based on the custom weights, the first version information of the first version, and the second version information of each second version, the recommendation weight of each second version is determined. Based on the recommendation weight of each second version, a target version is determined in the at least one second version, and the business system is upgraded according to the target version; The first version information includes the first version number of the first version, the first online time of the first version, and the first offline time of the first version; The second version information includes the second version number of the second version, the second launch time of the second version, and the second decommissioning time of the second version; The recommendation weights of the second version satisfy the following formula: Among them, the As a preset coefficient, the The usage duration of the second version, the The difference between the major version number in the second version number and the major version number in the first version number, wherein... The difference between the minor version number in the second version number and the minor version number in the first version number, wherein... The difference between the patch version number in the second version number and the patch version number in the first version number, wherein... The above and stated These are preset weight values, the For custom weights, the The duration of the second version's launch, the For the second online time, the This is the second offline time.

2. The method according to claim 1, characterized in that, Obtain the custom weights corresponding to the second version, including: Obtain the client's setting weight for the second version; Obtain the API impact weight of the business system corresponding to the second version. The API impact weight is used to indicate the degree of influence of the API on the business system corresponding to the second version. The custom weight is determined based on the set weight and the API influence weight.

3. The method according to claim 2, characterized in that, Obtain the API impact weight of the business system corresponding to the second version, including: Retrieve multiple call records of the business system being called by API from a preset database, wherein the call records include the version number corresponding to the business system; Based on the version number of the second version, at least one target call record is determined from the plurality of call records, wherein the target call record is a call record that is called by an incompatible API; The API impact weight is determined based on the target call records.

4. The method according to any one of claims 1-3, characterized in that, Based on the recommendation weight of each second version, a target version is determined in the at least one second version, including: The second version with the highest recommendation weight among the at least one second version is determined as the target version.

5. The method according to any one of claims 1-3, characterized in that, Based on the recommendation weight of each second version, a target version is determined in the at least one second version, including: Send the second version information and recommendation weight of at least one second version to the client; Receive the target version information sent by the client; The target version is determined based on the target version information.

6. The method according to claim 3, characterized in that, The method further includes: Intercept multiple call requests from the client to the business system, wherein the call requests include the version number of the API calling the business system; Based on the version number of the API, the multiple call requests are filtered to obtain multiple target call requests, wherein the API version number included in the target call requests is a preset version number; The multiple call records are generated based on the multiple target call requests, and the multiple call records are stored in the preset database.

7. The method according to claim 6, characterized in that, The method further includes: Receive the first call request from the client to the business system, wherein the first call request includes first API information of the first API; Based on the first call request, determine whether the first API is compatible with the current version of the API service; If not, then determine the second API information of the first API based on the current version of the API service; The first API information in the first call request is transformed according to the second API information to obtain a second call request, wherein the second call request includes the second API information of the first API; Perform business processing based on the second call request.

8. The method according to claim 1, characterized in that, The method further includes: Receive an upgrade failure message sent by the client, the upgrade failure message being used to indicate that the upgrade of the business system corresponding to the client from the first version to the target version has failed; Based on the upgrade failure message, at least one rollback version is determined; Determine the recommendation weight for each rollback version; Based on the recommendation weight of each rollback version, a target rollback version is determined among the at least one rollback version, and the business system is updated according to the target rollback version.

9. The method according to claim 8, characterized in that, For any rollback version; determine the recommendation weight of the rollback version, including: Obtain the custom weight corresponding to the rollback version, and the first version information of the rollback version; Obtain the target version information of the target version; The recommended weight of the rollback version is determined based on the custom weight, the first version information, and the target version information.

10. An electronic device, characterized in that, include: Processor and memory; The memory is used to store computer-executed instructions; The processor is configured to execute computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1 to 9.

Images