Micro-service-based OTA upgrade method, system, device and storage medium

Abstract

The application relates to the technical field of OTA upgrading, and discloses an OTA upgrading method and system based on micro services, a computer device and a storage medium, the method comprising the following steps: a client sends a heartbeat information package to a server, the heartbeat information package at least comprising micro service upgrading deployment information of the client; the server queries whether a micro service upgrading material package of a specified version exists in an OTA upgrading platform according to the micro service upgrading deployment information in the heartbeat information package, the micro service upgrading material package containing at least one micro service upgrading package used for version upgrading of the client; if the micro service upgrading material package of the specified version exists in the OTA upgrading platform, the server sends the micro service upgrading material package to the client; and the client respectively performs upgrading deployment according to each micro service upgrading package in the micro service upgrading material package, so as to complete version upgrading of the client.

Description

Technical Field

[0001] This invention relates to the field of OTA upgrade technology, and in particular to an OTA upgrade method, system, computer device and storage medium based on microservices. Background Technology

[0002] With the development of internet technology, in order to achieve enterprise information deployment and meet the private scenario needs of different enterprise users, software platforms with microservice architecture design, such as SaaS platforms, have begun to be introduced. These software platforms typically customize different software services for different enterprise users. Customized software services are implemented through multiple separately deployed microservices to meet the needs of different private scenarios. In order to better meet the needs of enterprise users, the deployed microservices need to be continuously upgraded.

[0003] Traditional upgrade methods typically rely on upgrade packages, which contain complete software data, allowing for version upgrades with a single package. However, existing software platforms often deploy numerous microservices for different users and their respective private scenarios. Traditional upgrade methods are unsuitable for microservice architecture upgrades. When upgrading software platform services, using a single upgrade package makes it difficult to perform a comprehensive upgrade of all users' microservices. Instead, each user's private microservice needs to be manually upgraded on-site, resulting in low upgrade efficiency. Summary of the Invention

[0004] This invention provides an OTA upgrade method, system, computer device, and storage medium based on microservices to solve the problem that traditional upgrade methods cannot be applied to the upgrade needs of microservice architectures, and that manual upgrades of users' private microservices are required one by one, resulting in low upgrade efficiency.

[0005] A microservice-based OTA upgrade method, the method comprising:

[0006] The client sends a heartbeat message to the server, and the heartbeat message includes at least the client's microservice upgrade and deployment information;

[0007] The server queries the OTA upgrade platform to see if a microservice upgrade material package of a specified version exists, based on the microservice upgrade deployment information in the heartbeat information packet. The microservice upgrade material package contains at least one microservice upgrade package for the client to perform version upgrade.

[0008] If the OTA upgrade platform contains a specific version of the microservice upgrade material package, the server will send the microservice upgrade material package to the client.

[0009] The client performs upgrade deployment according to each microservice upgrade package in the microservice upgrade material package to complete the client version upgrade.

[0010] Optionally, in the above method, the client performs upgrade deployment according to each microservice upgrade package in the microservice upgrade material package to complete the client version upgrade, including:

[0011] The client decrypts the microservice upgrade material package using the first key to obtain a microservice image file. The microservice image file includes multiple microservice upgrade packages, a microservice image list, and microservice script files.

[0012] The client determines multiple target microservices to be upgraded based on the microservice image list;

[0013] The client executes the microservice script file to deploy the upgrade environment and configuration information for each target microservice;

[0014] The client uses an image installation and deployment method, updates the target microservice according to the microservice upgrade package, and traverses all the target microservices to complete the client version upgrade.

[0015] Optionally, in the above method, the microservice script file includes a mysql directory and corresponding mysql script files, as well as a configuration directory and corresponding configuration files; the client executes the microservice script file to deploy the upgrade environment and configuration information for each target microservice, including:

[0016] The client parses the microservice script file to obtain a mysql directory, a configuration directory, multiple mysql script files, and multiple configuration files;

[0017] The client matches the mysql directory and the configuration directory with the target microservices respectively to obtain the mysql script file and configuration file for each target microservice;

[0018] The client executes the MySQL script file for each of the target microservices to deploy the upgrade environment for the target microservices;

[0019] The client executes the configuration file of each target microservice to update the configuration information of the corresponding target microservice.

[0020] Optionally, after performing upgrade deployment according to each microservice upgrade package in the microservice upgrade material package, the method includes:

[0021] The client checks the status of the target microservice being upgraded to obtain the microservice status;

[0022] If all the microservices are in normal status, the client sends an upgrade success message to the server, so that the server updates the client's upgrade record status to upgrade success and records the client's current microservice version information.

[0023] If the microservice status is abnormal, the client performs a rollback operation to cancel the upgrade operation and sends an upgrade failure message to the server, so that the server updates the client's upgrade record status to upgrade failure status.

[0024] Optionally, in the above method, the heartbeat information includes a client ID and an encrypted information packet;

[0025] Specifically, the server queries the OTA upgrade platform to determine if a specific version of the microservice upgrade material package exists, based on the microservice upgrade deployment information in the heartbeat packet. This includes:

[0026] The server retrieves the second key from the OTA upgrade platform based on the client ID;

[0027] The server decrypts the encrypted information packet using the second key to obtain the microservice upgrade and deployment information;

[0028] The server queries the OTA upgrade platform to see if a specific version of the microservice upgrade material package exists, based on the microservice upgrade deployment information.

[0029] Optionally, in the above method, the client sending a heartbeat information packet to the server includes:

[0030] The client encrypts the microservice upgrade and deployment information of the client according to the first key to obtain an encrypted information packet;

[0031] The client packages the encrypted information packet and the client's client ID to obtain the heartbeat information packet;

[0032] The client sends the heartbeat information packet to the server.

[0033] Optionally, before the client sends the heartbeat information packet to the server, the method further includes:

[0034] The OTA upgrade platform receives a client registration request sent by the client;

[0035] The OTA upgrade platform responds to the client's registration request and registers registration parameters including at least the client ID and a second key. These registration parameters are used at least for version upgrades after the client is enabled.

[0036] A microservice-based OTA upgrade system includes a server, a client, and an OTA upgrade platform; wherein,

[0037] The client is used to send heartbeat information packets to the server, and the heartbeat information packets include at least the microservice upgrade and deployment information of the client.

[0038] The server is used to query whether a microservice upgrade material package of a specified version exists in the OTA upgrade platform based on the microservice upgrade deployment information in the heartbeat information packet. The microservice upgrade material package contains at least one microservice upgrade package for the server to perform version upgrade.

[0039] If a specified version of the microservice upgrade package exists in the OTA upgrade platform, the server is used to send the microservice upgrade material package to the client;

[0040] The client is configured to perform upgrade deployment according to each microservice upgrade package in the microservice upgrade material package to complete the client version upgrade.

[0041] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the various steps as described above for client and server execution.

[0042] A computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps described above for both client and server execution.

[0043] This invention discloses an OTA upgrade method, system, computer device, and storage medium based on microservices. In this invention, the server queries the OTA upgrade platform based on the microservice upgrade deployment information in the heartbeat packet sent by the client, checking if a specific version of the microservice upgrade material package exists. If the specified version of the microservice upgrade material package exists in the OTA upgrade platform, the server sends the microservice upgrade material package to the client, enabling the client to perform upgrade deployment according to each microservice upgrade package in the material package, thereby completing the client's version upgrade. This invention updates the microservice version information of different user clients on the OTA upgrade platform, allowing each client to promptly report version upgrade requests. When an upgrade is detected for a microservice on a client, the server sends the corresponding microservice upgrade material package to the client, enabling each client to upgrade and deploy at least one microservice of its own. The OTA upgrade platform achieves automated remote upgrade and management of microservices, eliminating the need for manual upgrades of microservices for different users one by one, effectively improving the efficiency of service upgrades. Attached Figure Description

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

[0045] Figure 1 This is a flowchart illustrating the implementation of a microservice-based OTA upgrade method disclosed in Embodiment 1 of the present invention.

[0046] Figure 2 This is a flowchart illustrating the implementation of step S104 in a microservice-based OTA upgrade method disclosed in Embodiment 1 of the present invention.

[0047] Figure 3 This is a flowchart illustrating the implementation of step S203 in a microservice-based OTA upgrade method disclosed in Embodiment 1 of the present invention.

[0048] Figure 4 This is another implementation flowchart of a microservice-based OTA upgrade method disclosed in Embodiment 1 of the present invention;

[0049] Figure 5 This is a flowchart illustrating the implementation of step S102 in a microservice-based OTA upgrade method disclosed in Embodiment 1 of the present invention.

[0050] Figure 6This is a flowchart of step S101 in a microservice-based OTA upgrade method disclosed in Embodiment 1 of the present invention;

[0051] Figure 7 This is a flowchart of another implementation of the microservice-based OTA upgrade method disclosed in Embodiment 1 of the present invention;

[0052] Figure 8 This is a flowchart illustrating the implementation of step 103 in a microservice-based OTA upgrade method disclosed in Embodiment 1 of the present invention.

[0053] Figure 9 This is a schematic diagram of the structure of an OTA upgrade system based on microservices disclosed in Embodiment 2 of the present invention;

[0054] Figure 10 This is a schematic diagram of the structure of a computer device disclosed in Embodiment 3 of the present invention. Detailed Implementation

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

[0056] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0057] It should also be understood that the term “and / or” as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0058] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0059] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0060] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of the invention include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0061] This invention discloses an OTA (Over-The-Air) method, system, computer device, and storage medium based on microservices. In this invention, the server, based on the microservice upgrade deployment information in the heartbeat packet sent by the client, queries the OTA upgrade platform to check if a specific version of the microservice upgrade material package exists. If the specified version of the microservice upgrade material package exists in the OTA upgrade platform, the server sends the microservice upgrade material package to the client, enabling the client to perform upgrade deployment according to each microservice upgrade package in the material package, thereby completing the client's version upgrade. As can be seen, this invention updates the microservice version information of different user clients on the OTA upgrade platform, allowing each client to promptly report version upgrade requests. When it detects that a microservice on the client can be upgraded, the server sends the corresponding microservice upgrade material package to the client, enabling each client to upgrade and deploy multiple microservices separately. The OTA upgrade platform achieves automated remote upgrade and management of microservices, eliminating the need for manual upgrades of microservices for different users one by one, effectively improving the efficiency of service upgrades. Specific embodiments are described below.

[0062] Example 1

[0063] like Figure 1 As shown in the figure, Embodiment 1 of the present invention discloses an implementation flowchart of an OTA upgrade method based on microservices. This method is applicable to system upgrades of electronic devices equipped with control systems or mechanical equipment equipped with control systems, such as OTA upgrades of vehicle systems, IoT platforms, and enterprise SaaS platforms.

[0064] Specifically, the method in this embodiment may include the following steps:

[0065] S101: The client sends a heartbeat information packet to the server.

[0066] The heartbeat information packet includes at least the microservice upgrade and deployment information for the client.

[0067] Firstly, microservice upgrade deployment information can contain only the client's current version information and the specified upgrade version information. In this case, the microservice upgrade deployment information is used to instruct the server to return the microservice upgrade material package of the specified version.

[0068] For example, if the client's current version is v1.0.1 and the specified upgrade version is v2.0.1, then the client needs to upgrade from v1.0.1 to v2.0.1. Accordingly, the microservice upgrade deployment information contained in the heartbeat information sent by the client to the server is used to instruct the server to return the microservice upgrade material package for version v2.0.1.

[0069] Secondly, microservice upgrade deployment information can also include only the client's current version information. When the client's current version information is not the latest version information, the client's current version information is used to instruct the server to return the latest version of the microservice upgrade material package.

[0070] For example, if the client's current version is v1.0.1, and the server receives the microservice upgrade deployment information when the client's latest version is v3.0.1, then the server returns the microservice upgrade material package for version v3.0.1.

[0071] S102: The server queries the OTA upgrade platform to see if a specific version of the microservice upgrade material package exists, based on the microservice upgrade deployment information in the heartbeat packet.

[0072] The microservice upgrade material package includes at least one microservice upgrade package for client version upgrades. It should be understood that the client in this embodiment is designed based on a microservice architecture and contains multiple microservices. Therefore, when upgrading the client, only one microservice, some microservices, or all microservices can be upgraded. Thus, the microservice upgrade material package includes at least one microservice upgrade package for client version upgrades.

[0073] In this specific implementation, the current version information and the specified upgrade version information contained in the microservice upgrade deployment information can be used to query the OTA upgrade platform to see if there is a microservice upgrade material package corresponding to the specified upgrade version information. If the specified version of the microservice upgrade material package exists in the OTA upgrade platform, step S103 and subsequent steps are executed. If the specified version of the microservice upgrade material package does not exist in the OTA upgrade platform, a no-upgrade-version prompt message is returned to the client, informing the client user that there is currently no specified version of the microservice upgrade material package in the OTA upgrade platform, and the upgrade is temporarily suspended.

[0074] S103: The server sends the microservice upgrade material package to the client.

[0075] In practice, data can be transmitted between the server and the client via OTA technology, that is, the server sends the microservice upgrade material package to the client via OTA technology.

[0076] S104: The client performs upgrade deployment according to each microservice upgrade package in the microservice upgrade material package to complete the client version upgrade.

[0077] In a specific implementation, the client in this embodiment can obtain all the microservice upgrade packages in the microservice upgrade material package, and then upgrade different microservices of the client according to the microservice upgrade steps and each microservice upgrade package.

[0078] It should be understood that the client deploys multiple microservices with different functions, each of which has its own version information, which is the original version of the microservice. Similarly, each microservice upgrade package in the microservice upgrade material package also has its own version information, which is the upgraded version of the microservice. The client upgrades the microservice from the original version to the upgraded version, thus completing the client's version upgrade.

[0079] For example, if one microservice on the client is version v1.2.1 and another is version v1.3.2, and one microservice upgrade package in the microservice upgrade material package is version v1.2.2 and another is version v1.3.3, then the microservice on the client with version v1.2.1 will be upgraded according to the microservice upgrade package with version v1.2.2, and the microservice on the client with version v1.3.3 will be upgraded according to the microservice upgrade package with version v1.3.2.

[0080] In summary, this invention discloses an OTA (Over-The-Air) method based on microservices. The server in this invention queries the OTA upgrade platform to check if a specific version of the microservice upgrade material package exists, based on the microservice upgrade deployment information in the heartbeat packet sent by the client. If the specified version of the microservice upgrade material package exists in the OTA upgrade platform, the server sends the microservice upgrade material package to the client, enabling the client to perform upgrade deployment according to each microservice upgrade package in the material package, thereby completing the client's version upgrade. It can be seen that this invention updates the microservice version information of different user clients on the OTA upgrade platform, allowing each client to promptly report version upgrade requests. When it detects that a microservice on the client can be upgraded, the server sends the corresponding microservice upgrade material package to the client, enabling each client to upgrade and deploy multiple microservices separately. The OTA upgrade platform achieves automated remote upgrade and management of microservices, eliminating the need for manual upgrades of microservices for different users one by one, effectively improving the efficiency of service upgrades.

[0081] Based on Figure 1 In its specific implementation, step S104 can be achieved through the following steps, as follows: Figure 2 As shown:

[0082] S201: The client decrypts the microservice upgrade material package using the first key to obtain the microservice image file, which includes multiple microservice upgrade packages, a microservice image list, and microservice script files.

[0083] It should be understood that data transmission between the client and server requires encryption to ensure the security of upgrade data, prevent hacker attacks and tampering, and thus guarantee the security of upgrade-related devices and the confidentiality of device data. Therefore, the first key can be the key used by the client to decrypt the upgrade material package sent by the server. After decrypting the microservice upgrade material package using the first key, the client obtains multiple microservice upgrade packages, a list of microservice images, and microservice script files. Based on these, the client then executes subsequent steps of the OTA upgrade process.

[0084] In a specific implementation, the upgrade material package in this embodiment can be an encrypted JSON file. The client decrypts the upgrade material package using the first key to obtain the decrypted JSON file. Then, the client parses the JSON file to obtain the multiple microservice upgrade packages, microservice image list, and microservice script files contained within it.

[0085] S202: The client determines multiple target microservices to be upgraded based on the microservice image list.

[0086] It should be understood that the microservice image list specifies in detail which microservices in the client need to be upgraded during this OTA upgrade process, and these microservices that need to be upgraded are the target microservices.

[0087] Specifically, the microservice image list in this embodiment may include the original version information and upgrade version information of the target microservice, which is used to instruct the client to update each target microservice from the original version to the upgrade version in this OTA upgrade.

[0088] S203: The client executes the microservice script file to deploy the upgrade environment and configuration information for each target microservice.

[0089] In this specific implementation, the microservice script file in this embodiment includes at least a script file for setting up the upgrade environment of the target microservice and a configuration file for deploying configuration information for the target microservice. The client calls the script file in the microservice script file for deploying the upgrade environment of the target microservice to complete the deployment of the upgrade environment for each target microservice, and calls the configuration file in the microservice script file for deploying configuration information for the target microservice to complete the deployment of configuration information for each target microservice.

[0090] S204: The client uses an image installation and deployment method, updates the target microservice according to the microservice upgrade package, and traverses the target microservice to complete the client version upgrade.

[0091] After the client completes the deployment of the upgrade environment and configuration information for each target microservice, it uses the image installation deployment method to update the target microservice according to each microservice upgrade package, so that each target microservice is upgraded from the original version to the target version. In this way, after traversing and completing the version upgrade of each target microservice, the client version upgrade is completed.

[0092] In this specific implementation, the client in this embodiment can traverse each microservice upgrade package. During the traversal, the client can execute the image installation and deployment of each microservice upgrade package through a shell script. After traversing the microservice upgrade packages, the client completes the version upgrade of each target microservice through a shell script, thus completing the client's version upgrade.

[0093] For example, consider upgrading a microservice on a client from version 3.1.2 to version 3.1.6. The client uses the upgrade package for version 3.1.6 to upgrade its own version 3.1.2 microservice. After completion, a check script checks the upgrade status of the 3.1.2 microservice. If the upgrade is successful, a message indicating a successful upgrade is sent to the server, informing it that the microservice upgrade was successful. This allows the server to record the client's upgrade status as successful on the OTA upgrade platform. If the upgrade fails, a message indicating an upgrade failure is sent to the server, causing the server to record the client's upgrade status as failed on the OTA upgrade platform and invoke a pre-defined rollback script to roll back the microservice to version 3.1.2. Thus, the client can still use the 3.1.2 version, improving client reliability. Alternatively, after the client completes the rollback, it can retry upgrading the microservice from version 3.1.2 to version 3.1.6. Or, after the staff of the OTA upgrade platform make adaptive modifications to the microservice upgrade package for version 3.1.6, the client can obtain the microservice upgrade package for version 3.1.6 from the PTA upgrade platform and then retry upgrading the microservice from version 3.1.2 to version 3.1.6.

[0094] In summary, this embodiment uses image installation and deployment to update the target microservice according to each microservice upgrade package, which greatly improves the client update efficiency compared to the traditional installation method of releasing and initializing the application.

[0095] based on Figure 2 In its specific implementation, step S203 can be achieved through the following steps, as follows: Figure 3 As shown:

[0096] S301: The client parses the microservice script files and obtains the mysql directory, configuration directory, multiple mysql script files, and multiple configuration files.

[0097] It should be understood that the client parses the microservice script files, obtaining a mysql directory and a configuration directory. The mysql directory contains multiple mysql script files, and the configuration directory contains multiple configuration files. The number of mysql script files and configuration files is the same as the number of target microservices, and each mysql script file and configuration file corresponds one-to-one with a target microservice.

[0098] For example, the MySQL script files in the MySQL directory can be as follows: database v2.1.5.sql, database v2.2.5.sql, database v2.3.5.sql, etc.

[0099] For example, the configuration files in the configuration directory can be as follows: multiple configuration files such as microservice v2.1.5.txt, microservice v2.2.5.txt, and microservice v2.3.5.txt.

[0100] S302: The client matches the mysql directory and configuration directory with the target microservices to obtain the mysql script files and configuration files for each target microservice.

[0101] In the specific implementation, the MySQL script files in the MySQL directory and the configuration files in the configuration directory in this embodiment have certain matching rules with the target microservices. The MySQL script files and configuration files are matched with the target microservices according to the matching rules to obtain the MySQL script files and configuration files of each target microservice.

[0102] For example, in this embodiment, each MySQL script file and configuration file can carry the upgrade version information of the target microservice. The upgrade version information of the target microservice is matched with the original version information of the target microservice to obtain the MySQL script file and configuration file of the target microservice.

[0103] For example, taking a MySQL script file with upgrade version information v2.1.5 and another with upgrade version information v2.2.5 as examples, if the original version information of one target microservice is V2.1.3 and the original version information of the other target microservice is V2.2.2, then the target microservice with the original version information V2.1.3 will be matched with the MySQL script file with upgrade version information v2.1.5, and the target microservice with the original version information V2.2.2 will be matched with the MySQL script file with upgrade version information v2.2.5. Based on this, the MySQL script file for each target microservice can be matched.

[0104] S303: The client executes the MySQL script file for each target microservice to deploy the upgrade environment for the target microservice.

[0105] In this specific implementation, the client can execute the MySQL script file of each target microservice through a preset MySQL call command, thereby deploying the upgrade environment for each target microservice.

[0106] S304: The client executes the configuration file for each target microservice to update the configuration information of the corresponding target microservice.

[0107] In a specific implementation, the client in this embodiment can execute the configuration file of each target microservice through the configuration center interface to update the configuration information of the corresponding target microservice.

[0108] In summary, this embodiment upgrades different microservices on the client according to each microservice upgrade package, and finally completes the client version upgrade, which can meet the upgrade needs of clients based on microservice architecture design.

[0109] based on Figure 1 In its specific implementation, after step S104, the following steps may also be included, as follows: Figure 4 As shown:

[0110] S105: The client checks the status of the target microservice for the upgrade and obtains the microservice status.

[0111] If the microservice is in a normal state, proceed to step S106, whereby the client sends an upgrade success message to the server, so that the server updates the client's upgrade record status to the upgrade success state and records the client's current microservice version information. If the microservice is in an abnormal state, proceed to step S107, whereby the client performs a rollback operation to cancel the upgrade operation and sends an upgrade failure message to the server, so that the server updates the client's upgrade record status to the upgrade failure state.

[0112] In this implementation, the client can use a check script to check the upgrade status of each target microservice in turn. If the microservice status of all target microservices is normal, the client sends an upgrade success message to the server, so that the server updates the client's upgrade record status to the upgrade success status and records the client's current microservice version information. If the microservice status of one or more target microservices is abnormal, the client performs a rollback operation to cancel the upgrade operation and sends an upgrade failure message to the server, so that the server updates the client's upgrade record status to the upgrade failure status.

[0113] S106: The client sends an upgrade success message to the server, so that the server updates the client's upgrade record status to the upgrade success status and records the client's current microservice version information.

[0114] When the client detects that the upgrade status of the target microservice is normal, it sends an upgrade success message to the server, indicating that the client has successfully upgraded. Based on the upgrade success message, the server updates the client's upgrade record status to the upgrade success status and records the version information of all microservices after the client's update, so as to facilitate the client's next update.

[0115] S107: The client performs a rollback operation to cancel the upgrade operation and sends an upgrade failure message to the server so that the server updates the client's upgrade record status to the upgrade failure status.

[0116] When the client detects that the target microservice's upgrade status is abnormal, the client performs a rollback operation to eliminate the current upgrade installation and deployment operation, keeping the client's microservice version at the version before the upgrade, and sends an upgrade failure message to the server. The server then updates the client's upgrade record status to the upgrade failure status based on the upgrade failure message, so as to wait for the next upgrade.

[0117] In one embodiment, after the client receives the upgrade material package and generates the corresponding material file, it determines the current upgrade mode based on the parsed file. When the current upgrade mode is determined to be automatic upgrade, the client starts the automatic upgrade program and automatically installs and deploys the target microservice according to the parsed file. When the current upgrade mode is determined to be manual upgrade, the client does not perform the installation and deployment operation on the parsed file. The client waits to receive the installation and deployment operation from the enterprise client manager or the server staff, and then installs the material file parsed from the upgrade material package step by step according to the installation and deployment operation.

[0118] In summary, this embodiment uses microservice status checks to quickly determine whether the client's version upgrade was successful. If the upgrade fails, a rollback script is invoked to quickly revert the client's version to the previous version, avoiding a prolonged period of unusability due to upgrade failure. This improves the stability and reliability of the client system.

[0119] based on Figure 1 In its specific implementation, step S102 can be achieved through the following steps, such as... Figure 5 As shown:

[0120] In the specific implementation, the heartbeat information packet includes a client ID and an encrypted information packet. Based on the client ID and the encrypted information packet, the following steps are performed:

[0121] S501: The second key obtained by the server from the OTA upgrade platform based on the client ID.

[0122] In this implementation, the client ID and second key are obtained by the client through pre-registration on the OTA upgrade platform. The client ID is used to activate the client, and the second key is used to decrypt encrypted packets sent by the client. The client ID and second key are stored on the OTA upgrade platform. Therefore, the server can retrieve the second key from the OTA upgrade platform based on the client ID.

[0123] S502: The server decrypts the encrypted information packet using the second key to obtain the microservice upgrade and deployment information.

[0124] The second key and the first key mentioned above can be either symmetric keys or asymmetric keys. That is, when the second key and the first key are symmetric keys, the second key and the first key are the same; when the second key and the first key are asymmetric keys, the second key and the first key are different.

[0125] It should be noted that the encryption algorithm used in this embodiment includes, but is not limited to, symmetric encryption algorithms and asymmetric encryption algorithms. This embodiment does not impose any restrictions on the encryption algorithm used.

[0126] In one implementation, the encrypted packet also includes client information, which can be addressed through the following steps:

[0127] After step S502, the server updates the initial client information and initial microservice upgrade deployment information of the client in the OTA upgrade platform based on the client ID.

[0128] The client information includes, but is not limited to, the client name, the deployed version number, the client IP address, and the client MAC address. In this embodiment, no specific limitations are imposed.

[0129] Understandably, the OTA upgrade platform has a separate information archive for each client to facilitate information backtracking. Based on the client ID, the initial client information and initial microservice upgrade deployment information in the OTA upgrade platform are updated to the client information and microservice upgrade deployment information in the encrypted information packet.

[0130] S503: The server queries the OTA upgrade platform to see if a specific version of the microservice upgrade material package exists, based on the microservice upgrade deployment information.

[0131] In this specific implementation, the server can query the OTA upgrade platform to see if there is a microservice upgrade material package corresponding to the specified upgrade version information, based on the current version information and the specified upgrade version information contained in the microservice upgrade deployment information. If the specified version of the microservice upgrade material package exists in the OTA upgrade platform, the server sends the microservice upgrade material package to the client. If the specified version of the microservice upgrade material package does not exist in the OTA upgrade platform, the server returns a no-upgrade-version prompt message to the client, informing the client user that there is currently no specified version of the microservice upgrade material package in the OTA upgrade platform, and the upgrade is temporarily suspended.

[0132] In summary, this embodiment uses symmetric or asymmetric keys to encrypt microservice upgrade and deployment information, which can effectively ensure the security of microservice upgrade and deployment information during data transmission.

[0133] based on Figure 1 In its specific implementation, step S101 can be achieved through the following steps, such as... Figure 6 As shown:

[0134] S601: The client encrypts the client's microservice upgrade deployment information using the first key to obtain an encrypted information packet.

[0135] It should be understood that when a client sends data packets to the server, the data packets need to be encrypted. The first key is the key used by the client to encrypt the microservice upgrade material package. The client's microservice upgrade deployment information is then encrypted using the first key to obtain an encrypted information packet.

[0136] S602: The client packages the encrypted information packet and the client's client ID to obtain the heartbeat information packet.

[0137] It should be understood that the client ID is only packaged together with the encrypted information packet, but the client ID itself is not encrypted. This allows the server to query the key used to decrypt the encrypted information packet from the OTA upgrade platform based on the client ID.

[0138] S603: The client sends the heartbeat information packet to the server.

[0139] In practice, data transmission between the server and the client can be achieved through OTA technology, whereby the client sends heartbeat information packets to the server via OTA technology.

[0140] In summary, this embodiment uses symmetric or asymmetric keys to encrypt microservice upgrade and deployment information, which can effectively ensure the security of microservice upgrade and deployment information during data transmission.

[0141] based on Figure 1In its specific implementation, the following steps are included before step S101, as follows: Figure 7 As shown:

[0142] S108: The OTA upgrade platform receives a client registration request sent by the client.

[0143] The client can be installed on electronic devices including but not limited to mobile phones, tablets, and office computers. When a user clicks on the registration page displayed by the client and enters user information, a client registration request is sent to the OTA upgrade platform.

[0144] It should be understood that in this embodiment, the client can directly send a client registration request to the OTA upgrade platform, or the client can send a client registration request to the server, and then the server can forward the client registration request to the OTA upgrade platform.

[0145] S109: The OTA upgrade platform responds to the client's registration request and obtains registration parameters including at least the client ID and the second key.

[0146] The registration parameters are used at least for version upgrades after the client is enabled.

[0147] In this implementation, after responding to the client's registration request, the OTA upgrade platform in this embodiment randomly generates a client ID according to a preset client ID generation rule, and generates a second key and a first key according to a preset key generation algorithm. The first key is used for confidentiality when the server receives data packets from the client, or for decrypting data packets sent from the server to the client; the second key is used for confidentiality when the client receives data packets from the server, or for decrypting data packets sent from the client to the server; the client ID is used for client account login and version upgrades after the client is enabled.

[0148] based on Figure 1 In its specific implementation, step S103 can be achieved through the following steps, as follows: Figure 8 As shown:

[0149] S801: The server encrypts the microservice upgrade material package based on the second key.

[0150] It should be understood that the server needs to encrypt data packets when sending them to the client, and the second key is the key used by the server to encrypt the microservice upgrade material package. The microservice upgrade material package is then encrypted using the second key to obtain the encrypted microservice upgrade material package.

[0151] S802: The server sends the encrypted microservice upgrade material package to the client.

[0152] In practice, data can be transmitted between the server and the client via OTA technology, whereby the server sends the encrypted microservice upgrade material package to the client via OTA technology.

[0153] In summary, this embodiment uses symmetric or asymmetric keys to encrypt the microservice upgrade material package, which can effectively ensure the security of the microservice upgrade material package during data transmission.

[0154] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0155] Example 2

[0156] refer to Figure 9 The diagram shown is a schematic representation of a microservice-based OTA upgrade system disclosed in Embodiment 2 of the present invention.

[0157] In a specific implementation, the system in this embodiment can be as follows:

[0158] The client is used to send heartbeat packets to the server. The heartbeat packets must include at least the client's microservice upgrade and deployment information.

[0159] The server is used to query whether a microservice upgrade material package of a specified version exists in the OTA upgrade platform based on the microservice upgrade deployment information in the heartbeat information packet. The microservice upgrade material package contains multiple microservice upgrade packages for the server to perform version upgrades.

[0160] If a specific version of the microservice upgrade package exists in the OTA upgrade platform, the server is used to send the microservice upgrade material package to the client.

[0161] The client is used to upgrade and deploy each microservice upgrade package in the microservice upgrade material package to complete the client version upgrade.

[0162] In summary, this invention discloses a microservice-based OTA system. In this system, the server, based on the microservice upgrade deployment information in the heartbeat packet sent by the client, queries the OTA upgrade platform to check if a specific version of the microservice upgrade material package exists. If the specified version of the microservice upgrade material package exists in the OTA upgrade platform, the server sends the microservice upgrade material package to the client, enabling the client to perform upgrade deployment according to each microservice upgrade package in the material package, thereby completing the client's version upgrade. It can be seen that this invention updates the microservice version information of different user clients on the OTA upgrade platform, allowing each client to promptly report version upgrade requests. When it detects that a microservice on the client can be upgraded, the server sends the corresponding microservice upgrade material package to the client, enabling each client to upgrade and deploy its multiple microservices separately. The OTA upgrade platform achieves automated remote upgrade and management of microservices, eliminating the need for manual upgrades of microservices for different users one by one, effectively improving the efficiency of service upgrades.

[0163] In one implementation, each microservice upgrade package includes a microservice script file, a microservice configuration directory, and a microservice image address;

[0164] The client can be used for:

[0165] The client decrypts the microservice upgrade material package using the first key to obtain the microservice image file, which includes multiple microservice upgrade packages, a list of microservice images, and microservice script files.

[0166] The client identifies multiple target microservices to be upgraded based on the microservice image list;

[0167] The client executes the microservice script file to deploy the upgrade environment and configuration information for each target microservice;

[0168] The client uses an image installation and deployment method, updates the target microservice according to the microservice upgrade package, and iterates through all target microservices to complete the client version upgrade.

[0169] In summary, this embodiment upgrades different microservices on the client according to each microservice upgrade package, and finally completes the client version upgrade, which can meet the upgrade needs of clients based on microservice architecture design.

[0170] In one implementation, the microservice script files include a mysql directory and corresponding mysql script files, as well as a configuration directory and corresponding configuration files; the client is used for:

[0171] The client parses the microservice script files, obtaining a mysql directory, a configuration directory, multiple mysql script files, and multiple configuration files;

[0172] The client matches the MySQL directory and configuration directory with the target microservices to obtain the MySQL script files and configuration files for each target microservice.

[0173] The client executes the MySQL script file for each target microservice to deploy the upgrade environment for the target microservice;

[0174] The client executes the configuration file for each target microservice to update the configuration information of the corresponding target microservice.

[0175] In one implementation, the client can be used

[0176] The client checks the status of the target microservice for the upgrade and obtains the microservice status.

[0177] If all microservices are in a normal state, the client sends an upgrade success message to the server, so that the server updates the client's upgrade record status to the upgrade success status and records the client's current microservice version information.

[0178] If the microservice status is abnormal, the client will perform a rollback operation to cancel the upgrade operation and send an upgrade failure message to the server so that the server will update the client's upgrade record status to the upgrade failure status.

[0179] In one implementation, the heartbeat information includes the client ID and an encrypted packet;

[0180] The server can be used for:

[0181] The server retrieves the second key from the OTA upgrade platform based on the client ID;

[0182] The server decrypts the encrypted packet using the second key to obtain the microservice upgrade and deployment information;

[0183] The server queries the OTA upgrade platform to see if the specified version of the microservice upgrade material package exists, based on the microservice upgrade deployment information.

[0184] In one implementation, the client can be used for:

[0185] The client encrypts the client's microservice upgrade and deployment information using the first key to obtain an encrypted information packet;

[0186] The client packages the encrypted information packet and the client's client ID together to obtain the heartbeat information packet;

[0187] The client sends the heartbeat information packet to the server.

[0188] In summary, this embodiment uses symmetric or asymmetric keys to encrypt microservice upgrade and deployment information, which can effectively ensure the security of microservice upgrade and deployment information during data transmission.

[0189] In one implementation, the OTA upgrade platform can also be used for:

[0190] The OTA upgrade platform receives a client registration request from the client.

[0191] The OTA upgrade platform responds to the client's registration request and obtains registration parameters, including at least the client ID and a second key. These registration parameters are used for version upgrades after the client is enabled.

[0192] In summary, this embodiment uses symmetric or asymmetric keys to encrypt the microservice upgrade material package, which can effectively ensure the security of the microservice upgrade material package during data transmission.

[0193] For specific limitations regarding the microservice-based OTA upgrade system, please refer to the limitations of the microservice-based OTA upgrade method mentioned above, which will not be repeated here. Each module in the aforementioned microservice-based OTA upgrade system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0194] Example 3

[0195] Embodiment 3 of this application discloses a computer device, which can be a server, and its internal structure diagram can be as follows: Figure 10 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it performs the various steps executed by the server and client as described in any of the above embodiments.

[0196] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, a server and a client perform the following steps:

[0197] The client sends a heartbeat message to the server. The heartbeat message includes at least the client's microservice upgrade and deployment information.

[0198] Based on the microservice upgrade deployment information in the heartbeat packet, the server queries the OTA upgrade platform to see if there is a microservice upgrade material package for a specified version. The microservice upgrade material package contains at least one microservice upgrade package for the client to perform version upgrade.

[0199] If a microservice upgrade material package of a specified version exists in the OTA upgrade platform, the server will send the microservice upgrade material package to the client.

[0200] The client performs upgrades and deployments according to each microservice upgrade package in the microservice upgrade material package to complete the client version upgrade.

[0201] Example 4

[0202] Embodiment 4 of this application discloses a computer-readable storage medium that, when executed by a processor in a computer device, enables the computer device to perform the various steps executed by the server and client as described in any embodiment of the microservice-based OTA upgrade method disclosed in this invention. The computer-readable storage medium may be non-volatile or volatile.

[0203] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0204] The client sends a heartbeat message to the server. The heartbeat message includes at least the client's microservice upgrade and deployment information.

[0205] Based on the microservice upgrade deployment information in the heartbeat packet, the server queries the OTA upgrade platform to see if there is a microservice upgrade material package for a specified version. The microservice upgrade material package contains at least one microservice upgrade package for the client to perform version upgrade.

[0206] If a microservice upgrade material package of a specified version exists in the OTA upgrade platform, the server will send the microservice upgrade material package to the client.

[0207] The client performs upgrades and deployments according to each microservice upgrade package in the microservice upgrade material package to complete the client version upgrade.

[0208] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0209] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0210] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A microservice-based OTA upgrade method, characterized in that, The method includes: The client sends a heartbeat message to the server, and the heartbeat message includes at least the client's microservice upgrade and deployment information; The server queries the OTA upgrade platform to see if a microservice upgrade material package of a specified version exists, based on the microservice upgrade deployment information in the heartbeat information packet. The microservice upgrade material package contains at least one microservice upgrade package for the client to perform version upgrade. If the OTA upgrade platform contains a specific version of the microservice upgrade material package, the server will send the microservice upgrade material package to the client. The client performs upgrade deployment according to each microservice upgrade package in the microservice upgrade material package to complete the client version upgrade; The client performs upgrade deployment according to each microservice upgrade package in the microservice upgrade material package to complete the client version upgrade, including: the client decrypts the microservice upgrade material package according to the first key to obtain a microservice image file, the microservice image file including multiple microservice upgrade packages, a microservice image list and a microservice script file; the client determines multiple target microservices to be upgraded according to the microservice image list; the client executes the microservice script file to deploy the upgrade environment and configuration information of each target microservice; the client adopts the image installation deployment method, updates the target microservices according to the microservice upgrade packages, and traverses all target microservices to complete the client version upgrade; The client executes the microservice script file to deploy the upgrade environment and configuration information of each target microservice, including: the client parses the microservice script file to obtain a mysql directory, a configuration directory, multiple mysql script files, and multiple configuration files; the client matches the mysql directory and the configuration directory with the target microservices respectively to obtain the mysql script file and configuration file for each target microservice. The client executes the MySQL script file for each target microservice to deploy the upgrade environment for the target microservice; the client executes the configuration file for each target microservice to update the configuration information of the corresponding target microservice.

2. The method as described in claim 1, characterized in that, After performing upgrade deployment according to each microservice upgrade package in the microservice upgrade material package, the method includes: The client checks the status of the target microservice being upgraded to obtain the microservice status; If all the microservices are in normal status, the client sends an upgrade success message to the server, so that the server updates the client's upgrade record status to upgrade success and records the client's current microservice version information. If the microservice status is abnormal, the client performs a rollback operation to cancel the upgrade operation and sends an upgrade failure message to the server, so that the server updates the client's upgrade record status to upgrade failure status.

3. The method as described in claim 1, characterized in that, The heartbeat information includes the client ID and an encrypted information packet; Specifically, the server queries the OTA upgrade platform to determine if a specific version of the microservice upgrade material package exists, based on the microservice upgrade deployment information in the heartbeat packet. This includes: The server retrieves the second key from the OTA upgrade platform based on the client ID; The server decrypts the encrypted information packet using the second key to obtain the microservice upgrade and deployment information; The server queries the OTA upgrade platform to see if a specific version of the microservice upgrade material package exists, based on the microservice upgrade deployment information.

4. The method as described in claim 1, characterized in that, The client sends heartbeat information packets to the server, including: The client encrypts the microservice upgrade and deployment information of the client according to the first key to obtain an encrypted information packet; The client packages the encrypted information packet and the client's client ID to obtain the heartbeat information packet; The client sends the heartbeat information packet to the server.

5. The method according to any one of claims 1-4, characterized in that, Before the client sends a heartbeat packet to the server, the method further includes: The OTA upgrade platform receives a client registration request sent by the client; The OTA upgrade platform responds to the client's registration request and registers registration parameters including at least the client ID and a second key. These registration parameters are used at least for version upgrades after the client is enabled.

6. A microservice-based OTA upgrade system, characterized in that, The system includes a server, a client, and an OTA upgrade platform; wherein... The client is used to send heartbeat information packets to the server, and the heartbeat information packets include at least the microservice upgrade and deployment information of the client. The server is used to query whether a microservice upgrade material package of a specified version exists in the OTA upgrade platform based on the microservice upgrade deployment information in the heartbeat information packet. The microservice upgrade material package contains at least one microservice upgrade package for the server to perform version upgrade. If a specified version of the microservice upgrade package exists in the OTA upgrade platform, the server is used to send the microservice upgrade material package to the client; The client is configured to perform upgrade deployment according to each microservice upgrade package in the microservice upgrade material package to complete the client version upgrade; The client performs upgrade deployment according to each microservice upgrade package in the microservice upgrade material package to complete the client version upgrade, including: the client decrypts the microservice upgrade material package according to the first key to obtain a microservice image file, the microservice image file including multiple microservice upgrade packages, a microservice image list and a microservice script file; the client determines multiple target microservices to be upgraded according to the microservice image list; the client executes the microservice script file to deploy the upgrade environment and configuration information of each target microservice; the client adopts the image installation deployment method, updates the target microservices according to the microservice upgrade packages, and traverses all target microservices to complete the client version upgrade; The client executes the microservice script file to deploy the upgrade environment and configuration information of each target microservice, including: the client parses the microservice script file to obtain a mysql directory, a configuration directory, multiple mysql script files, and multiple configuration files; the client matches the mysql directory and the configuration directory with the target microservices respectively to obtain the mysql script file and configuration file for each target microservice. The client executes the MySQL script file for each target microservice to deploy the upgrade environment for the target microservice; the client executes the configuration file for each target microservice to update the configuration information of the corresponding target microservice.

7. A computer device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the various steps performed by the client and server as described in any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the various steps performed by the client and server as described in any one of claims 1 to 5.

Images