Microservice upgrade method, electronic device and readable storage medium

Abstract

The embodiments of the present invention relate to the field of cloud computing, and disclose a microservice upgrade method, an electronic device, and a readable storage medium. In the present invention, the microservice upgrade method includes: identifying the development framework to which the microservice to be upgraded belongs; obtaining basic information for upgrading through an application programming interface corresponding to the identified development framework, the basic information at least including a target version number; extracting an upgrade script package according to the target version number; and executing the upgrade script package to upgrade the microservice. Some implementation methods of the present invention can realize convenient upgrade management of microservices and reduce the difficulty of developing a microservice upgrade management architecture.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of cloud computing, and in particular to a microservice upgrade method, an electronic device, and a readable storage medium. Background Art

[0002] With the rise of cloud computing services, the original monolithic architecture cannot meet the increasingly complex business needs. With the increase in users and the increasing number of visits, the application concurrency capacity of the monolithic architecture is very limited. Based on the shortcomings of the monolithic architecture system, microservice architecture is proposed, such as PaaS (Platform-as-a-Service) cloud platform based on container microservices.

[0003] Microservice architecture is to develop a single program into a microservice. Each microservice runs in its own process and uses a lightweight mechanism to communicate, usually HTTP RESTFUL interface. These services are divided around business capabilities and deployed independently through automated deployment mechanisms. These services can use different programming languages, different databases, and different development frameworks to ensure centralized management. Each microservice is deployed independently, independent of each other, and decoupled from each other. It has strong horizontal expansion capabilities. In the face of high concurrency scenarios, services can be deployed in clusters to enhance system load capacity.

[0004] However, due to the mutual independence of microservices, there are some problems in the unified management of the database access layer of the microservice platform. Especially when the microservices need to be upgraded, the unified upgrade management is more difficult. Summary of the invention

[0005] The purpose of the embodiments of the present invention is to provide a microservice upgrade method, an electronic device and a readable storage medium, so as to conveniently upgrade and manage microservices and reduce the difficulty of developing a microservice upgrade management architecture.

[0006] To solve the above technical problems, an embodiment of the present invention provides a microservice upgrade method, comprising: identifying a development framework to which a microservice to be upgraded belongs; obtaining basic information for upgrading through an application programming interface corresponding to the identified development framework, wherein the basic information includes at least a target version number; extracting an upgrade script package according to the target version number; and executing the upgrade script package to upgrade the microservice.

[0007] An embodiment of the present invention also provides a microservice upgrade device, comprising: an identification module for identifying a development framework to which a microservice to be upgraded belongs; an acquisition module for acquiring basic information for upgrading through an application programming interface corresponding to the identified development framework, wherein the basic information includes at least a target version number; an extraction module for extracting an upgrade script package according to the target version number; and an execution module for executing the upgrade script package to upgrade the microservice.

[0008] An embodiment of the present invention also provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the microservice upgrade method as described above.

[0009] An embodiment of the present invention further provides a computer-readable storage medium storing a computer program, wherein the computer program implements the microservice upgrade method as described above when executed by a processor.

[0010] Compared with the prior art, the implementation method of the present invention obtains the basic information required for upgrading by docking with the development framework of the microservice, avoiding the existing upgrade management of each microservice on the service platform by developing another management microservice. Since the difficulty of docking with the development framework to which the microservice belongs and calling the information required for upgrading is much lower than the difficulty of developing another microservice, the upgrade scheme in this application can reduce the development difficulty of the architecture required for upgrade management and shorten the development cycle. In addition, since the development frameworks available on different microservice platforms are consistent, microservices from different microservice platforms can be uniformly managed by docking with the development framework. Even if the microservices to be upgraded come from different service platforms, they can be uniformly managed and upgraded. It can be seen that the microservice upgrade method in this application is applicable to various service platforms and has a wider application scenario.

[0011] As a further improvement, the target version number is one of the following: the first target version number of the microservice, the second target version number of the platform to which the microservice belongs, or a combination of the first target version number and the second target version number. It can be seen that the target version number can be selected according to the upgrade needs, making the upgrade plan more flexible and changeable.

[0012] As a further improvement, when the target version number is a combination of the first target version number and the second target version number, the step of extracting the upgrade script package according to the target version number includes: extracting the microservice script package according to the first target version number, extracting the platform general function script package in the platform script package according to the second target version number; and using the microservice script package and the platform general function script package as the upgrade script package. The above scheme implements the storage of the platform general function script package in the platform script package, and the platform general function script package may not be repeatedly stored in the microservice upgrade package, which is conducive to reducing the amount of code in the microservice upgrade script package and shortening the creation time of the upgrade script package.

[0013] As a further improvement, the executing the upgrade script package to upgrade the microservice specifically includes: reporting information to the bus at a preset upgrade node. The above scheme presets an upgrade node for reporting information, which facilitates the customization of the upgrade process and enriches the implementation of the upgrade process.

[0014] As a further improvement, after executing the upgrade script package, the method further includes: reporting the upgrade result to the bus of the platform to which the microservice belongs. The above solution facilitates understanding of the microservice upgrade result by adding the reporting of the upgrade result.

[0015] As a further improvement, after executing the upgrade script package, the process includes: when a microservice to be upgraded fails to be upgraded, rolling back the microservice that failed to be upgraded. The above solution ensures the normal use of microservices by automatically rolling back the microservices that failed to be upgraded.

[0016] As a further improvement, the development framework to which the microservice to be upgraded belongs is identified according to a preset adaptation rule. The above solution identifies the development framework to which the microservice belongs through the adaptation rule, so that the identification result is correct.

[0017] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0019] Figure 1 is a flow chart of a microservice upgrade method according to a first embodiment of the present invention;

[0020] Figure 2 is a flow chart of a microservice upgrade method according to a second embodiment of the present invention;

[0021] Figure 3 is a flow chart of a microservice upgrade method according to a third embodiment of the present invention;

[0022] Figure 4 is a schematic diagram of the architecture of a microservice upgrade system according to a fourth embodiment of the present invention;

[0023] Figure 5 is a schematic diagram of the structure of a microservice upgrading device according to a fifth embodiment of the present invention;

[0024] Figure 6 FIG. 4 is a schematic structural diagram of an electronic device according to a third embodiment of the present invention. DETAILED DESCRIPTION

[0025] To make the purpose, technical scheme and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the embodiments of the present invention, many technical details are proposed in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can be implemented. The division of the following embodiments is for the convenience of description, and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined and referenced with each other without contradiction.

[0026] The first embodiment of the present invention relates to a microservice upgrade method. The process is as follows Figure 1 As shown, the details are as follows:

[0027] Step 101, identifying the development framework to which the microservice to be upgraded belongs.

[0028] Specifically, a service platform can include multiple service development frameworks, such as ZTE Cloud, Alibaba Cloud, etc. Microservices belong to various development frameworks, such as dropwizard, springboot, oscp, springcloud, etc. Different development frameworks use different development languages.

[0029] To continue, this embodiment can identify the development framework to which the microservice to be upgraded belongs through a preset adaptation rule. Among them, the preset adaptation rule can be, for example, an identification sequence package corresponding to a certain development framework. An example of a program package is as follows:

[0030]

[0031] It can be seen that the recognition results are accurate by using the program packages corresponding to different development frameworks.

[0032] Step 102: acquiring basic information for upgrading through an application programming interface corresponding to the identified development framework.

[0033] Specifically, the application programming interface, or API. The APIs corresponding to each development framework are listed as follows: the API corresponding to the development framework dropwizard is the ServerLifecycleListener interface; the API corresponding to the development framework springboot is the ApplicationRunner interface; the API corresponding to the development framework oscp is the MainServiceBase interface.

[0034] More specifically, after the development framework is identified, the microservice will start the upgrade function because the upgrade method in this implementation is connected to the API corresponding to the development framework. For example: the development framework dropwizard uses the ServerLifecycleListener interface hk2 to start the upgrade function; the development framework springboot uses the ApplicationRunner interface @Autowired annotation to start the function; the development framework oscp uses the MainServiceBase interface to directly implement new.

[0035] To continue the explanation, after the development framework to which the microservice to be upgraded belongs is identified in step 101, for different development frameworks, the microservice startup interface in the development framework is connected to obtain basic information for the upgrade, and the basic information includes at least: the target version number. In actual applications, the basic information specifically includes: information about the microservice and information about the platform to which the microservice belongs (i.e., environment variables), including: database connection information, microservice name, and other information. By connecting to the API to obtain basic information, it can be learned that when the microservice is started, the database upgrade management system will be automatically loaded, and the injection of the upgrade management system in this application can be achieved. It can be seen that the above process actually describes the process of injecting environment variables.

[0036] It should also be noted that, for the convenience of management, the microservices to be upgraded can have a unified microservice name in advance, such as using the "development framework-microservice name" naming method. Specifically, the microservice topology of the development framework oscp can be named "oscp-topology", so that microservices from different microservice platforms can be managed in a unified manner.

[0037] Step 103: extract the upgrade script package according to the target version number.

[0038] Specifically, the target version number can be the first target version number of the microservice or the second target version number of the platform to which the microservice belongs. The first target version number can come from the information of the microservice obtained in step 102, and the second target version number can come from the information of the platform to which the microservice belongs in step 102. In actual applications, it can be determined which version number to select for the microservice version upgrade based on business needs. For example, if there are three microservices a, b, and c to be upgraded, the second target version number of the platform to which the microservice belongs is selected to obtain the upgrade script package. If three more microservices 1, 2, and 3 to be upgraded are subsequently added, these three microservices can use the first target version number of the microservice to extract the upgrade script package. Since the version numbers are independent of each other, different microservices will not affect each other even if different types of target version numbers are selected for upgrade.

[0039] Step 104: Execute the upgrade script package.

[0040] Specifically, when an upgrade script package of a microservice is extracted in step 103, the upgrade script package can be executed to upgrade the microservice.

[0041] It can be seen that this implementation method obtains the basic information of the microservices required for upgrading by docking with the development framework of the microservice, avoiding the existing upgrade management of each microservice on the service platform by developing another management microservice. Since the difficulty of docking with the development framework to which the microservice belongs and calling the information required for upgrading is much lower than the difficulty of developing another microservice, the upgrade solution in this application can reduce the development difficulty of the architecture required for upgrade management and shorten the development cycle. In addition, since the development frameworks available on different microservice platforms are consistent, microservices from different microservice platforms can be uniformly managed by docking with the development framework. Even if the microservices to be upgraded come from different service platforms, they can be uniformly managed and upgraded. It can be seen that the microservice upgrade method in this application is applicable to various service platforms and has a wider application scenario. Furthermore, the upgrade method in the implementation method of this application can be called and executed by the microservice, so there is no need to disclose the username and password of the database to the outside world, which improves security.

[0042] The second embodiment of the present invention relates to a microservice upgrade method. The second embodiment is basically the same as the first embodiment, and the main difference is that: in the first embodiment, the upgrade script package is extracted according to the first target version number of the microservice or the second target version number of the platform to which the microservice belongs, while in this embodiment, part of the upgrade script package is extracted according to the first target version number and the second target version number, so that the code amount of the microservice upgrade script package can be minimized and the creation time of the upgrade script package can be shortened.

[0043] Specifically, the process of the microservice upgrade method in this embodiment is as follows: Figure 2 As shown, the details are as follows:

[0044] Step 201 and step 202 are similar to step 101 and step 102 in the first embodiment, and are not described in detail here.

[0045] Step 203: extract the upgrade script package according to the target version number.

[0046] Specifically, in this implementation, the table structure of some platform common functions can be placed in the upgrade script package corresponding to the platform version number, such as performance, alarm, random ID generation, etc., and the table structure specific to some microservices can be placed in the upgrade package file of the microservice itself. It can be found that some functions that need to be upgraded in the microservice are platform common functions, so multiple microservices need to upgrade these common functions, so the upgrade script package corresponding to each microservice must contain the upgrade script of this part of the common functions, and this implementation stores the script package of this part of the platform common functions in the upgrade script package corresponding to the platform version number, so even if the microservice to be upgraded needs to upgrade these common functions, the corresponding script package can be extracted from the platform script package, and the upgrade package of the microservice itself does not need to repeat the upgrade script of this part of the function, effectively reducing the amount of code of the upgrade script package of the microservice and shortening the creation time of the upgrade script package. It can be found that in this application, the extraction path of two types of script packages is determined by the combination of two target version numbers, forming a combination of two types of paths, making the extraction of the upgrade package more flexible and changeable.

[0047] Furthermore, the target version number in this embodiment is a combination of the first target version number and the second target version number. For example, if there is a microservice to be upgraded, named inv-basic, the first target version number of the microservice is 16.19.v1, and the second target version number of the platform to which it belongs is 12.19.10.b11, the microservice version number can be spliced ​​on the basis of the platform version number to form a new target version number 12.19.10.b11-16.19.v1. It can be seen that the new target version number includes both the first target version number and the second target version number.

[0048] This step specifically includes the following steps when extracting the upgrade script package according to the target version number:

[0049] Step 2031: extract the microservice script package according to the first target version number.

[0050] Specifically, the upgrade script package corresponding to the microservice itself can be extracted according to the first target version number, and this part of the script package can only include the upgrade scripts of the microservice-specific functions.

[0051] Step 2032: extract the platform common function script package in the platform script package according to the second target version number.

[0052] Specifically, a platform general function script package may be extracted according to the second target version number, and this script package corresponds to the upgrade of the platform general function.

[0053] Step 2033: The microservice script package and the platform general function script package confirm the upgrade script package.

[0054] Specifically, this step can combine the microservice script package extracted in step 2031 and the platform general function script package extracted in step 2032 into an upgrade script package.

[0055] In actual applications, the target version number can also be determined based on the second target version number. For example, if only general functions need to be upgraded, the general function script package can be obtained based on the second target version number and used as the upgrade script package. On the other hand, the target version number can also be determined based on the first target version number. For example, if only general functions need to be upgraded, the microservice-specific function script package can be obtained based on the first target version number and used as the upgrade script package.

[0056] The above steps 2031 to 2033 specifically describe the specific execution process of extracting the upgrade script package according to the target version number in step 203. In this embodiment, the platform general function script package is extracted after the microservice script package is extracted, but in actual application, it can also be extracted before the microservice script package, that is, the execution order of step 2031 and step 2032 is not limited here.

[0057] Step 204 is similar to step 104 in the first embodiment and will not be described in detail herein.

[0058] It can be seen that this implementation method specifically combines the platform target version number and the microservice target version number into a new target version number, so that when the microservice is upgraded, two parts of the upgrade package are extracted according to the two types of version numbers. In this way, the platform general function script package is stored in the platform script package, and the platform general function script package can be stored in the microservice upgrade package without duplication, which is conducive to reducing the amount of code in the microservice upgrade script package and shortening the creation time of the upgrade script package.

[0059] The third embodiment of the present invention relates to a microservice upgrade method. The third embodiment is a further improvement on the first embodiment, and the main improvement is that: in the third embodiment of the present invention, an upgrade node is preset, and a message body is returned at the preset upgrade node, so that custom steps can be inserted into the upgrade process, making the implementation process of microservice upgrade more flexible and changeable.

[0060] The flowchart of the microservice upgrade method in this embodiment is as follows Figure 3 As shown, the details are as follows:

[0061] Step 301 and step 302 are similar to step 101 and step 102 in the first embodiment, and are not described in detail here.

[0062] Step 303: register the observation action.

[0063] Specifically, the observation actions registered in this embodiment are composed of basic actions and extended actions. The current basic execution actions include four upgrade nodes, namely, the action before the upgrade, the action after the definition language is executed, the action after the data manipulation language is executed, and the action after the upgrade. The above four actions are the basic callback interfaces in the upgrade method in this embodiment. A single microservice can implement them directly or not, that is, do nothing. On the other hand, the extended action can be implemented through the IServiceObserver interface in this embodiment, and then the custom upgrade node is registered in the observation queue to realize the registration of the extended action. It can be seen that the extended action can realize the custom observation action. This step fully releases the potential of the upgrade process and meets the functional requirements of complex microservices.

[0064] Step 304 is similar to step 103 in the first embodiment and will not be described in detail herein.

[0065] Step 305: Execute the upgrade script package.

[0066] Specifically, in this implementation, since the observation action is pre-registered, during the upgrade process, this step can report information to the bus at the preset upgrade node, where the reported information can be a return message body, specifically a return DbMsgEnum message body, to achieve observation of the upgrade process.

[0067] If the registered upgrade node includes the upgrade, then after executing the upgrade script package, the upgrade result is reported to the bus of the platform to which the microservice belongs. The above scheme facilitates understanding of the upgrade results of the microservice by reporting the upgrade results. Specifically, in the implementation process of this embodiment, the kafka message is sent to the message bus of the pass platform for aggregation, and the result is reflected on the user interface. In actual applications, information reporting can also be achieved through other methods, which will not be listed here one by one.

[0068] It should also be noted that if all the microservices to be upgraded are successfully upgraded, the next step will be performed. If a microservice to be upgraded is not successfully upgraded, the microservice that has not been successfully upgraded will be rolled back. Among them, rollback refers to the behavior of restoring the program or data to the last correct state when a program or data processing error occurs. At the same time, rollback includes program rollback and data rollback. The above solution ensures the normal use of microservices by automatically rolling back the microservices that have not been successfully upgraded.

[0069] It can be seen that the present implementation mode presets an upgrade node for reporting information, which facilitates the customization of the upgrade process and enriches the implementation of the upgrade process. Among them, the upgrade result can be added to facilitate the understanding of the microservice upgrade result. At the same time, the normal use of the microservice is ensured by automatically rolling back the microservice that has not been successfully upgraded.

[0070] The microservice upgrade method in the first to third embodiments can be performed as follows: Figure 4 The microservice upgrade system implementation shown in the figure includes: an adaptation layer, a functional layer, and a database layer. The adaptation layer is used to connect to the microservices in the microservice cloud. Specifically, the microservice cloud includes microservices to be upgraded. When there are multiple microservices to be upgraded, they can come from one microservice cloud platform or multiple microservice cloud platforms. The functional layer can be used to provide functions such as version number resolution and registration of observation nodes; the database layer is used to find the corresponding upgrade script package according to the target version number, and is also used to handle the links of different types of databases.

[0071] It can be seen that after the various implementation methods of the present application are combined, the microservice upgrade method is compatible with various development languages ​​and development frameworks of microservices. After adding dependencies, different microservice structures can be automatically identified, and upgrade script packages can be extracted in different ways. An observation interface for the upgrade process is provided during the entire upgrade process, and the ability to intervene in the upgrade process is provided. The upgrade system has nothing to do with the type of database used, and is adaptable to various cloud computing pass platforms. It simplifies the maintenance process of the microservice database, simplifies the complexity of the cloud computing platform's management of the database access layer, and improves the development and use efficiency of business deployment.

[0072] A fourth embodiment of the present invention relates to a microservice upgrade device, such as Figure 5 As shown, specifically including:

[0073] The identification module is used to identify the development framework to which the microservice to be upgraded belongs.

[0074] The acquisition module is used to acquire basic information for upgrading through an application programming interface corresponding to the identified development framework. Specifically, the basic information at least includes a target version number.

[0075] The extraction module is used to extract the upgrade script package according to the target version number.

[0076] The execution module is used to execute the upgrade script package to upgrade the microservice.

[0077] In one example, the target version number is one of the following: a first target version number of the microservice, a second target version number of the platform to which the microservice belongs, or a combination of the first target version number and the second target version number.

[0078] In one example, when the target version number is a combination of a first target version number and a second target version number, the extraction module specifically includes:

[0079] The extraction submodule is used to extract the microservice script package according to the first target version number, and to extract the platform general function script package in the platform script package according to the second target version number.

[0080] A submodule is determined, which is used to determine an upgrade script package from a microservice script package and a platform general function script package.

[0081] In one example, the execution module is specifically configured to report information to the bus at a preset upgrade node.

[0082] In one example, the microservice upgrade device further includes: a reporting module, configured to report the upgrade result to a bus of a platform to which the microservice belongs.

[0083] In one example, the microservice upgrade device further includes: a rollback module, which is used to roll back the microservice that has not been successfully upgraded after executing the upgrade script package if there is a microservice to be upgraded that has not been successfully upgraded.

[0084] In one example, the identification module identifies the development framework to which the microservice to be upgraded belongs specifically according to a preset adaptation rule.

[0085] A fifth embodiment of the present invention relates to an electronic device, such as Figure 6 As shown, including:

[0086] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute any one of the microservice upgrade methods described in the first to third embodiments above.

[0087] Among them, the memory and the processor are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors and memories together. The bus can also connect various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The data processed by the processor is transmitted on a wireless medium via an antenna, and further, the antenna also receives data and transmits the data to the processor.

[0088] The processor is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory can be used to store data used by the processor when performing operations.

[0089] The sixth embodiment of the present invention relates to a computer-readable storage medium storing a computer program, which implements the above method embodiment when executed by a processor.

[0090] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In hardware implementations, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those of ordinary skill in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0091] Those skilled in the art will appreciate that the above-mentioned embodiments are specific examples for implementing the present invention, and in actual applications, various changes may be made thereto in form and detail without departing from the spirit and scope of the present invention.

Claims

1. A microservice upgrade method, characterized in that: include: Identify the development framework of the microservice to be upgraded; Acquiring basic information for upgrading through an application programming interface corresponding to the identified development framework, the basic information including at least a target version number; Extracting an upgrade script package according to the target version number; The upgrade script package is executed to upgrade the microservice.

2. The microservice upgrade method according to claim 1, characterized in that: The target version number is one of the following: a first target version number of a microservice, a second target version number of a platform to which the microservice belongs, or a combination of the first target version number and the second target version number.

3. The microservice upgrade method according to claim 2, characterized in that: When the target version number is a combination of the first target version number and the second target version number, extracting the upgrade script package according to the target version number includes: Extract the microservice script package according to the first target version number, and extract the platform general function script package in the platform script package according to the second target version number; The upgrade script package is confirmed by the microservice script package and the platform general function script package.

4. The microservice upgrade method according to claim 1, characterized in that: The executing the upgrade script package to upgrade the microservice specifically includes: reporting information to a bus at a preset upgrade node.

5. The microservice upgrade method according to claim 4, characterized in that: After executing the upgrade script package, the method includes: reporting the upgrade result to the bus of the platform to which the microservice belongs.

6. The microservice upgrade method according to claim 4, characterized in that: After executing the upgrade script package, the method includes: when a microservice to be upgraded fails to be upgraded, a rollback operation is performed on the microservice that has not been upgraded successfully.

7. The microservice upgrade method according to any one of claims 1 to 6, characterized in that: Identify the development framework to which the microservice to be upgraded belongs according to the preset adaptation rules.

8. A microservice upgrade device, characterized in that: include: Identification module, used to identify the development framework to which the microservice to be upgraded belongs; An acquisition module, configured to acquire basic information for upgrading through an application programming interface corresponding to the identified development framework, wherein the basic information includes at least a target version number; An extraction module, used to extract an upgrade script package according to the target version number; An execution module is used to execute the upgrade script package to upgrade the microservice.

9. An electronic device, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the microservice upgrade method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the microservice upgrade method described in any one of claims 1 to 7 is implemented.

Images