Method for updating micro-service instances and related device

Abstract

Embodiments of the present application disclose a method for updating micro-service instances, which is applied to a system for updating micro-service instances. In the system, multiple plug-ins in a plug-in center provide the capability to update micro-service instances of various working load types in various operating environments (such as cloud-native, virtualized, serverless, etc.). Therefore, after an instance to be updated is determined, a target plug-in adapted to a current operating environment may be dynamically determined on the basis of the working load type of the instance to be updated, so as to access a corresponding operating environment, thereby updating the instance to be updated in a micro-service cluster. Hence, by means of the present method, it is possible to efficiently update micro-service instances in different operating environments, thereby improving the updating efficiency of the micro-service cluster. The method can adapt to the requirements of various application scenarios, with high universality, and easy maintenance and management.

Description

A method for updating microservice instances and related equipment

[0001] This application claims priority to Chinese Patent Application No. 202410114585.3, filed on January 26, 2024, entitled "A Data Processing Method and Related Equipment", and to Chinese Patent Application No. 202410114585.3, filed on March 20, 2024, entitled "A Microservice Instance Update Method and Related Equipment", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of microservice technology, specifically to a method for updating microservice instances and related equipment. Background Technology

[0003] With the rapid development of cloud technology, various cloud application scenarios with different operating modes such as virtual machines, cloud native, and serverless have emerged. However, updating a large number of applications faces significant challenges in these diverse application scenarios.

[0004] Currently, a traditional method for updating microservices is to manually select microservice instances in the microservice cluster for the update.

[0005] However, due to the increasingly diverse operating environments of microservice clusters, such as physical machines, virtual machines, cloud-native environments, and serverless environments, traditional microservice update methods have poor versatility and are difficult to adapt to the update needs of diverse operating environments, resulting in low update efficiency for microservice instances.

[0006] Summary of the Invention

[0007] This application provides a method for updating microservice instances, which can update microservice instances in a microservice cluster under various operating environments. The update efficiency of the microservice cluster is high, and it can adapt to the needs of various application scenarios. This application also provides corresponding apparatus, devices, computer-readable storage media, and computer program products.

[0008] The first aspect of this application provides a microservice instance update method, applied to a microservice instance update system. The system is located in at least one data center and includes a communication interface, a plugin center, and an update component. The communication interface receives an update request, which instructs an update of a microservice cluster, including multiple microservice instances. The update component, based on the update request, determines the instance to be updated from among the multiple microservice instances in the microservice cluster. The plugin center, based on the workload type of the instance to be updated, determines a target plugin from among multiple plugins included in the plugin center. Different plugins among the multiple plugins provide interfaces for updating microservice instances with different workload types, and the target plugin provides an interface for updating microservice instances with the workload type of the instance to be updated. The update component calls the target plugin. The target plugin accesses the runtime environment of the instance to be updated to update the instance.

[0009] In the first aspect, multiple plugins provide the ability to update microservice instances with different workload types under various runtime environments (such as cloud-native, virtualization, serverless, etc.). Therefore, after determining the instance to be updated, the target plugin adapted to the current runtime environment can be dynamically determined based on the workload type of the instance to be updated, so as to access the corresponding runtime environment and realize the update of the instance to be updated in the microservice cluster. It is evident that the first aspect can efficiently update microservice instances under different runtime environments, improve the update efficiency of the microservice cluster, adapt to the needs of various application scenarios, has high versatility, and is easy to maintain and manage.

[0010] In one possible implementation of the first aspect, the workload type includes containers, virtual machines, and / or functions.

[0011] In this possible implementation, the operating mode of the microservice instance is called workload.

[0012] In one possible implementation of the first aspect, the update component determines the instance to be updated from multiple microservice instances in the microservice cluster according to the update request, including: the update component obtaining the status information of each microservice instance in the multiple microservice instances; and the update component determining the instance to be updated from the multiple microservice instances according to the status information of each microservice instance.

[0013] In this possible implementation, the status information of the microservice instance is used to indicate the attribute status and / or running status of the microservice instance. Alternatively, the status information can also directly indicate whether the microservice instance is an instance to be updated; for example, the microservice instance can be labeled as an instance to be updated based on its own running status and other information.

[0014] For example, the status information of a microservice instance may include one or more of the following:

[0015] Information indicating whether a microservice instance is a master or slave instance, information indicating the region to which a microservice instance belongs, information indicating the running status of a microservice instance, or information determining whether a microservice is updatable or not based on whether it is a master or slave instance, a busy or idle instance, etc.

[0016] In one possible implementation of the first aspect, the multiple microservice instances in the microservice cluster include a microservice instance as a master instance and microservice instances as slave instances, and the status information includes information indicating whether a microservice instance is a master instance or a slave instance; the update component determines the instance to be updated from the multiple microservice instances based on the status information of each microservice instance, including: the update component determines multiple instances to be updated from the multiple microservice instances and the update order of each instance to be updated, wherein, among the multiple instances to be updated, the update order of the microservice instance as a slave instance is higher than the update order of the microservice instance as a master instance.

[0017] In a microservice cluster, when there is a master-slave distinction between microservice instances, the interruption of the master instance will directly reduce the service level agreement (SLA) level. Furthermore, if the master instance is frequently switched during operation, it will cause a serious performance degradation of the microservice cluster.

[0018] Based on this, in this possible implementation, the state information of the microservice instance can be used to record whether the microservice instance is a master instance or a slave instance, thereby reasonably determining the instances to be updated in the microservice instance and the update order of each instance to be updated, avoiding frequent switching of the master instance during the update process of the microservice instance.

[0019] For example, multiple microservice instances to be updated and their update order can be determined from multiple microservice instances. Among these instances, those whose status information indicates they are slave instances are updated before those whose status information indicates they are master instances. Therefore, in this possible implementation, when multiple instances to be updated include both master and slave microservice instances, the slave instances can be updated first, followed by the master instances. This ensures that only one master instance switch is needed during the update process, avoiding the severe performance degradation of the microservice cluster caused by frequent master instance switching.

[0020] In one possible implementation of the first aspect, the status information includes information indicating the running status of the microservice instance, the running status being used to indicate whether the microservice instance is running; the update component determines the instance to be updated from multiple microservice instances based on the status information of each microservice instance, including: the update component determines the microservice instance whose running status is idle from the multiple microservice instances as the instance to be updated.

[0021] A microservice cluster includes both running and idle microservice instances, and the downtime costs for these two groups can differ significantly. For example, if a microservice instance running a long-running task is updated while the task is in progress, it can typically cause business disruption.

[0022] Based on this, in this possible implementation, the running status of each microservice instance can be recorded. This running status can indicate the task execution status of the microservice instance, such as whether the microservice instance is running, and the resource consumption of the running microservice instance. Microservice instances that are in a state where there will be no loss of business or minimal loss of business can be identified as instances to be updated. In other words, microservice instances with an idle running status are identified as instances to be updated, so as to reduce the loss of business during the microservice instance update process and ensure better business execution results.

[0023] In one possible implementation of the first aspect, the status information includes information indicating the region to which the microservice instance belongs, and multiple microservice instances belong to multiple regions; the update component determines the instance to be updated from the multiple microservice instances based on the status information of each microservice instance, including: the update component determines multiple instances to be updated from the multiple microservice instances, wherein the multiple instances to be updated belong to at least two regions, and the number of instances to be updated contained in each region is less than a number threshold.

[0024] A microservice cluster includes microservice instances that are distributed according to disaster recovery requirements. In other words, different microservice instances can be deployed in different regions. If microservice instances in the same region are updated in a concentrated manner, the number of microservice instances that can provide services in that region will be reduced, thus reducing the disaster recovery capability of that region.

[0025] Based on this, in this possible implementation, multiple instances to be updated can be identified, and these multiple instances to be updated will not be concentrated in the same region. Moreover, the number of instances to be updated in each region is less than the number threshold (which can be determined according to disaster recovery requirements). This allows the instances to be updated to be distributed across multiple regions and not concentrated in one region, so as to ensure that the microservice instances in multiple regions can be updated synchronously and to ensure the disaster recovery capability of each region.

[0026] A second aspect of this application provides a microservice instance update system, which has the functionality to implement the method described in the first aspect or any possible implementation of the first aspect. This functionality can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functionality, such as a communication interface, an update component, and a plugin center.

[0027] A third aspect of this application provides a computing device cluster including at least one computing device, the at least one computing device including a processor and a memory, the memory of the at least one computing device storing computer-executable instructions that can run on the processor, and when the computer-executable instructions are executed by the processor, the processor executes a method as described in the first aspect or any possible implementation of the first aspect.

[0028] The fourth aspect of this application provides a computer-readable storage medium storing one or more computer-executable instructions, wherein when the computer-executable instructions are executed by a processor, the processor performs a method as described in the first aspect or any possible implementation thereof.

[0029] The fifth aspect of this application provides a computer program product that stores one or more computer-executable instructions, wherein when the computer-executable instructions are executed by a processor, the processor executes a method as described in the first aspect or any possible implementation thereof.

[0030] A sixth aspect of this application provides a chip system including a processor for supporting the processor in implementing the functions involved in the first aspect or any possible implementation thereof. In one possible design, the chip system may further include a memory for storing necessary program instructions and data. This chip system may be composed of chips or may include chips and other discrete devices.

[0031] The technical effects of the second to sixth aspects or any of their possible implementations can be found in the first aspect or the technical effects of its related possible implementations, and will not be repeated here. Attached Figure Description

[0032] Figure 1 is an exemplary schematic diagram of the cloud management platform and infrastructure provided in an embodiment of this application;

[0033] Figure 2 is an exemplary schematic diagram of the processing stage provided in an embodiment of this application;

[0034] Figure 3 is a schematic diagram of an exemplary framework structure provided in an embodiment of this application;

[0035] Figure 4 is a schematic diagram of an embodiment of the microservice instance update method provided in this application;

[0036] Figure 5a is an exemplary flowchart of a cloud-native scenario provided in an embodiment of this application;

[0037] Figure 5b is another exemplary flowchart of a cloud-native scenario provided in an embodiment of this application;

[0038] Figure 6a is an exemplary flowchart of an application scenario combining third-party software provided in an embodiment of this application.

[0039] Figure 6b is another exemplary flowchart of an application scenario combining third-party software provided in an embodiment of this application;

[0040] Figure 7a is an exemplary flowchart of a virtualized cluster scenario provided in an embodiment of this application.

[0041] Figure 7b is another exemplary flowchart of a virtualized cluster scenario provided in an embodiment of this application;

[0042] Figure 8 is an exemplary schematic diagram of a microservice instance update system provided in an embodiment of this application;

[0043] Figure 9 is a structural schematic diagram of a computing device provided in an embodiment of this application;

[0044] Figure 10 is a schematic diagram of a computing device cluster provided in an embodiment of this application;

[0045] Figure 11 is a schematic diagram of a computing device cluster provided in an embodiment of this application. Detailed Implementation

[0046] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0047] As will be known to those skilled in the art, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0048] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of singular or plural items. The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that comprises a series of units is not necessarily limited to those units, but may include other units not expressly listed or inherent to those processes, methods, products, or apparatus.

[0049] First, the concepts involved in the embodiments of this application will be introduced.

[0050] (1) Microservices

[0051] Microservices is a software architecture style that uses small building blocks, each focused on a single responsibility and function, to modularly assemble complex, large applications. These building blocks communicate using a set of language-independent / language-agnostic application programming interfaces (APIs).

[0052] When developing various services as microservices, a single business function can be completed through multiple microservices. For example, when a user shops on a shopping website, after browsing the product page, they initiate a purchase request. The purchase system then generates an order and initiates a payment request. In this scenario, the shopping system first calls the product browsing service, which in turn calls the order service, which in turn calls the payment service. Here, the product browsing service, order service, and payment service are each distinct microservices.

[0053] (2) Microservice Examples

[0054] A microservice, once instantiated, is called a microservice instance. For example, this microservice instance can run on a terminal device, a server, a server cluster, or at least one of a virtual machine (VM), container, etc.

[0055] (3) Microservice cluster

[0056] A microservice cluster is a collection of microservice instances with the same business responsibilities. In a microservice cluster architecture, a group of microservice instances with the same business responsibilities provides a single microservice to the outside world. Ideally, all microservice instances in a microservice cluster should be in the same state. However, in real-world scenarios, there are often differences between microservice instances in a microservice cluster at instantaneous states; for example, there may be master-slave relationships or different running states.

[0057] (4) Workload

[0058] The way a microservice instance runs is called a workload.

[0059] (5) Workload type

[0060] The workload type can indicate the type of operation of a microservice instance, and can also be considered as the workload type of the microservice instance.

[0061] In different operating environments, there can be multiple types of workloads (which can also be considered as workload types).

[0062] For example, workload types may include containers, virtual machines, and / or functions.

[0063] Furthermore, workload types can include subtypes such as containers, virtual machines, and / or functions, depending on the operating environment.

[0064] For example, Kubernetes, or K8s for short, is an open-source system for automating the deployment, scaling, and management of containerized applications in cloud-native runtime environments. Microservices in Kubernetes are classified as container workloads; specifically, Kubernetes provides workloads that can be stateful applications (StatefulSets). Furthermore, the third-party Kubernetes application OpenKruise also provides container workloads, specifically AdvancedStatefulSets.

[0065] It is understood that in existing or future operating environments, workload types can take other forms besides the examples mentioned above, and subtypes of types such as containers, virtual machines, and / or functions can also take other forms. For example, when the workload type is a container, further refined workload types can include Statefulset and AdvancedStatefulset, and other types are also possible. This application does not impose any limitations on these aspects.

[0066] (6) Operating environment

[0067] The runtime environment refers to the system environment required for software development and operation. In a microservices scenario, the runtime environment can involve cloud-native, virtualized clusters, and / or serverless environments.

[0068] (7) Cloud Native

[0069] Cloud native is a software development and deployment methodology based on cloud computing that allows applications and services to be designed as native applications in a cloud environment to achieve high availability, scalability, and flexibility.

[0070] In a cloud-native runtime environment, containerization can be achieved. That is, cloud-native uses containerization technology to package applications and services into containers to achieve application portability and scalability.

[0071] Cloud-native architecture can employ microservices, breaking down applications and services into multiple small service units, thereby improving application maintainability and scalability. In cloud-native scenarios, the workload type for microservices is containers.

[0072] An example of an open-source system in a cloud-native scenario could be Kubernetes.

[0073] (8) Virtualization Cluster

[0074] In virtualization technology, virtualizing physical servers allows multiple virtual machines to be deployed on a single physical server, effectively improving the resource utilization of the physical server. A resource pool consisting of multiple physical servers with deployed virtual machines is called a virtualization cluster. In other words, a virtualization cluster comprises multiple virtual machines.

[0075] (9) No server

[0076] In serverless architecture, traditional applications can be finely divided into functions, each of which performs a part of the application's functionality, turning an application into a combination of functions.

[0077] Function as a Service (FaaS), also known as "Function as a Service," is a representative service model of serverless architecture. It allows developers to build, compute, run, and manage their own application packages in the form of functions, without maintaining the backend infrastructure. FaaS is a transaction-driven execution model that runs in a stateless container, where functions utilize the services of the FaaS provider to manage server-side logic and state.

[0078] In a serverless architecture, the workload type of a microservice is a function.

[0079] (10) Upgrade Domain

[0080] When upgrading microservices, a subset of microservice instances in the microservice cluster are grouped according to technical limitations or business requirements, and updates are performed on a group-by-group basis. This grouping is called an upgrade domain. In practical applications, the selected set of instances to be updated can serve as the upgrade domain.

[0081] With the rapid development of cloud technology, various cloud application scenarios with different operating modes such as virtual machines, cloud native, and serverless have emerged. However, updating a large number of applications faces significant challenges in these diverse application scenarios.

[0082] Currently, the traditional methods for updating microservices may include the following:

[0083] 1. The update is performed by manually selecting a microservice instance in the microservice cluster.

[0084] This traditional update method results in slow iteration speed and requires high manual labor costs, making it difficult to meet current requirements for iteration speed. Furthermore, the selection of upgrade domains based on manual experience is often difficult to adapt to the more variable application scenarios, leading to inaccurate selection of upgrade domains and affecting the execution effect of the task.

[0085] 2. Perform random updates on microservice instances in the microservice cluster.

[0086] In real-world applications, even though microservice instances within the same microservice cluster share the same business responsibilities, they often exhibit differences in their instantaneous states. For example:

[0087] A microservice cluster includes running and idle microservice instances, and the interruption costs for these two can differ significantly.

[0088] A microservice cluster includes microservice instances that are distributed according to disaster recovery requirements. That is to say, different microservice instances can be deployed in different regions. If all or most of the microservice instances in the same region are updated, the disaster recovery capability will be reduced.

[0089] In a microservice cluster, microservice instances have a master-slave distinction. Therefore, the failure of the master instance will directly reduce the service level agreement (SLA) level.

[0090] It is evident that randomly updating microservice instances in a microservice cluster may affect the performance, stability, or disaster recovery capabilities of the microservice cluster, resulting in poor business execution performance.

[0091] 3. Update the microservices using a third-party update tool.

[0092] In real-world applications, microservices typically have a common need for updates. Therefore, using different third-party update tools for different microservices can lead to significant additional investment in adaptation work, resulting in poor versatility and often limited functionality.

[0093] Furthermore, due to the increasingly diverse operating environments of microservice clusters, such as physical machines, virtual machines, cloud-native environments, and serverless environments, traditional microservice instance update methods have poor versatility and are difficult to adapt to the update needs of diverse operating environments, resulting in low update efficiency for microservice instances.

[0094] Based on this, this application provides a microservice instance update method that can update microservice instances in a microservice cluster under various operating environments. The update efficiency of the microservice cluster is high, adaptable to the needs of various application scenarios. Furthermore, in some examples, the microservice instance to be updated can be dynamically selected for automated updates in various application scenarios, meeting the needs of multiple application scenarios and reducing or even avoiding the impact on business execution.

[0095] The method described in this application embodiment can be applied to a computing device cluster, which may include one or more computing devices.

[0096] The type of computing device is not limited here. For example, any computing device can be a terminal device, a server, a container, or a virtual machine, etc.

[0097] In one example, the computing device cluster can be used to implement a microservice instance update system located in at least one data center, which includes communication interfaces, a plugin center, and update components.

[0098] The at least one data center may be located in one or more regions, each region may include one or more data centers, and the at least one data center may include a cloud management platform and infrastructure.

[0099] A cloud management platform is used to manage the infrastructure that provides cloud services, which may include one or more servers.

[0100] The cloud management platform and infrastructure are described below with reference to an architecture diagram shown in Figure 1.

[0101] In Figure 1, the cloud management platform interacts with one or more servers in the infrastructure (Server 1 and Server 2 in Figure 1) through an internal network. The servers consist of a hardware layer and a software layer. The hardware layer includes the server's hardware configuration, where PCI devices can be, for example, network interface cards (NICs), graphics processing units (GPUs), offloading cards, or other devices that can be plugged into the server's Peripheral Component Interconnect (PCI) or Peripheral Component Interconnect Express (PCIe) slots. The software layer includes the operating system installed and running on the server (the operating system relative to the virtual machine can be called the host operating system). The host operating system contains a virtual machine manager (also called a hypervisor), whose role is to implement compute virtualization, network virtualization, and storage virtualization of the virtual machines and to manage them. A virtual machine (VM) refers to a complete computer system simulated by software, possessing full hardware system functionality and running in a completely isolated environment. In the system architecture shown in Figure 1, servers can be used to run virtual machines, and the specifications of the virtual machines can be the same or different. Virtual machines can also be called cloud servers (elastic compute service, ECS), elastic instances, etc., and different cloud service providers may have different names for them.

[0102] In one example of the embodiments of this application, the cloud management platform can be a public cloud platform. In this case, cloud service providers such as individuals or software developers with cloud resource development capabilities can provide cloud services to users. Users obtain cloud services through the Internet, but do not own cloud computing resources.

[0103] Specifically, in the example shown in Figure 1, the cloud management platform can provide an access interface (such as a user interface or application programming interface (API)). Cloud platform users and cloud service providers can operate the client to remotely access the access interface to register a cloud account and password on the cloud management platform. After the cloud management platform successfully authenticates the cloud account and password, they can log in to the cloud management platform to create, manage, log in to and operate virtual machines in the cloud data center.

[0104] In this example, some enterprises, organizations, or individuals can purchase cloud resources such as virtual machines to deploy and apply microservices to perform business operations. Alternatively, some enterprises, organizations, or individuals can purchase cloud services in which microservices can be deployed, allowing users to perform business operations based on the microservices.

[0105] Of course, the cloud management platform can also be other types of cloud platforms, and this application does not limit this. Optionally, this application can integrate the instance update system into the cloud management platform, or it can be independent of the cloud management platform, allowing users to interact with the instance update system through the cloud management platform. The cloud management platform and the instance update system can be deployed in the same data center or in different data centers. In other embodiments provided in this application, the cloud platform is optional, and the instance update system can run without a cloud management platform, and this application does not limit this.

[0106] The microservice instance update system may include, but is not limited to, communication interfaces, a plugin center, and update components.

[0107] The following describes the functions of various components in the microservice instance update system, such as the communication interface, plugin center, and update component, through the microservice instance update method of this application embodiment. It should be noted that the components in this application embodiment can be considered functional components. In actual software systems, these components can be implemented through different services or software modules, or one or more components can be integrated into the same service or software module. This application embodiment does not limit the actual form of each component.

[0108] As shown in Figure 2, the microservice instance update method of this application embodiment may include one or more of the following processing stages:

[0109] Plugin registration, instance status collection, and instance updates.

[0110] It should be noted that the order of the steps in the above processing stages can be executed sequentially according to plugin registration, instance status collection and instance update. Alternatively, some steps in certain processing stages may not be executed in the above order. This application embodiment does not limit this.

[0111] The following sections provide exemplary descriptions of each processing stage.

[0112] 1. Plugin Registration

[0113] In this embodiment of the application, plugins can be developed and registered to enable the updating capability of microservice instances with different workload types in various operating environments.

[0114] Different plugins are used to provide interfaces for updating microservice instances with different workload types.

[0115] The following section, using the plugin center as an example, introduces the plugin registration process.

[0116] In the exemplary framework shown in Figure 3, a plugin center can be created in the microservice instance update system. This plugin center is used to develop and register multiple plugins according to workload type. Different plugins are used to provide interfaces for updating microservice instances of different workload types. For example, it can provide interfaces for the runtime environment of microservice instances of different workload types, so as to access the runtime environment and update the microservice instances of the corresponding workload type.

[0117] For example, if the workload types include Statefulset (container-based workloads) in a cloud-native Kubernetes environment, AdvancedStatefulset (container-based workloads provided by third-party applications in a cloud-native environment), or virtual machine-based workloads, then a plugin 1 can be developed for Statefulset (container-based workloads). This plugin 1 can provide an interface to the cloud-native Kubernetes runtime environment to update the microservice instances of Statefulset (container-based workloads). Similarly, a plugin 2 can be developed for AdvancedStatefulset (container-based workloads). This plugin 2 can provide an interface to third-party applications in the cloud-native Kubernetes runtime environment to update the microservice instances of AdvancedStatefulset (container-based workloads). And a plugin 3 can be developed for virtual machine-based workloads. This plugin 3 can provide an interface to the virtualization cluster to update the microservice instances of virtual machine-based workloads.

[0118] After registering multiple plugins, the workload type corresponding to each plugin can be stored.

[0119] For example, after plugin registration is implemented, the plugin center can store the mapping between plugins and workload types. In addition, the plugin center can also transfer the mapping between plugins and workload types to the registration center.

[0120] For example, in the example above, plugin 1 corresponds to the StatefulSet container type workload, plugin 2 corresponds to the AdvancedStatefulSet container type workload, and plugin 3 corresponds to the virtual machine type workload.

[0121] After plugin registration, the plugin center can provide the ability to update microservice instances of different working service types in various operating environments.

[0122] The specific process of enabling microservice instance updates in various runtime environments through plugins in the plugin center can be found in steps 403-405 of the instance update phase, and will not be repeated here.

[0123] 2. Instance Status Collection

[0124] In this embodiment of the application, after the microservice cluster starts, the status information of the microservice instances in the microservice cluster can be collected by the status awareness component.

[0125] The status information of a microservice instance can indicate the attribute status and / or running status of the microservice instance, or it can directly indicate whether the microservice instance is an instance to be updated.

[0126] For example, the state information of a microservice instance may include one or more of the following:

[0127] Information indicating whether a microservice instance is a primary or secondary instance, information indicating the region to which the microservice instance belongs, and information indicating the running status of the microservice instance.

[0128] From the perspectives of geographical location and network latency, regions within the same area share the same resource pool (which can be understood as sharing public services such as elastic computing, block storage, object storage, VPC networks, elastic public IPs, and images). A region can be used to describe the location of a data center; a region can include one or more data centers, and different regions may contain different data centers.

[0129] The following section uses the state-aware component shown in Figure 3 as an example to introduce the operation of instance state collection. This state-aware component is used to collect and store the state information of microservice instances; therefore, it can also be considered a state center or state repository.

[0130] In this embodiment, the status of microservice instances can be collected and recorded under specified conditions. Specifically, the identifier of each microservice instance and the corresponding status information can be recorded. The specified conditions can be varied; for example, it could indicate that the microservice has started, or it could indicate that a specified instruction has been received (e.g., a user-input instruction).

[0131] There are several ways for a state-aware component to obtain the state information of a microservice instance, including one or more of the following:

[0132] (1) Receiving Status Reports: The microservice cluster actively transmits the identifiers of the deployed microservice instances, their corresponding workload types, and the status information of the microservice instances in the microservice cluster to the status awareness component. For example, this can be transmitted periodically to the status awareness component, and / or when a change in the status of a microservice instance is detected.

[0133] (2) Actively acquire information: If the microservice cluster provides information about the status detection interface during the workload registration process, the status awareness component can periodically perform status detection on the microservice instance through the status detection interface to obtain status information.

[0134] In this way, the state-aware component can provide state information of microservice instances to determine which instances need to be updated.

[0135] For example, a state-aware component can receive the identifier of a microservice (such as an ID or a uniform resource locator, URL), and then query and return the state information of the microservice instance based on the microservice identifier.

[0136] For details on how to query state information and determine the instance to be updated using the state-aware component, please refer to step 402 of the instance update phase. These details will not be repeated here.

[0137] 3. Instance Update

[0138] As shown in Figure 4, in some embodiments, the microservice instance update method may include steps 401-405.

[0139] Step 401: Obtain update request through communication interface.

[0140] The update request instructs that an update be performed on the microservice instances in the microservice cluster.

[0141] For example, the update request could be initiated by a user through a client inputting information about the microservice instance update system's communication interface. For instance, the computing device cluster could provide a configuration interface via a configuration tool such as a browser, allowing the user to input an update request for the microservice cluster by calling the communication interface through a client. Alternatively, the update request could be triggered by the computing device cluster based on specified conditions. For example, the update request could be triggered when the computing device cluster's configuration tool detects information such as update data packets from the microservice cluster.

[0142] For example, the update request may carry the identifier of the microservice cluster, such as the name, number, or address information of the microservice cluster (e.g., the namespace or URL of the microservice cluster).

[0143] As shown in the example in Figure 3, the configuration tool includes a communication interface. The configuration tool can receive update requests from users through the communication interface, and can also generate update requests based on information input by users (such as the identifier of the microservice cluster and update instructions) or specified conditions (such as detecting update data packets of the microservice cluster). The update request is then transmitted to the update component through the communication interface to call the update component to perform subsequent operations.

[0144] Step 402: The update component determines the instance to be updated from multiple microservice instances in the microservice cluster based on the update request.

[0145] In this embodiment of the application, after obtaining the update request, the update component can determine one or more instances to be updated from at least one microservice instance in the microservice cluster. The one or more instances to be updated can be considered as the upgrade domain of this microservice update.

[0146] There are several ways to determine the instance to be updated.

[0147] For example, you can identify microservice instances from multiple microservice instances that will not cause business disruption when performing update operations as the instances to be updated.

[0148] In addition, microservice instances or third-party applications can use tags to indicate whether they can be updated. The computing device cluster determines whether a microservice instance is an instance to be updated based on the tags of the microservice instance.

[0149] In some embodiments, step 402 specifically includes:

[0150] The update component retrieves the status information of each microservice instance across multiple microservice instances;

[0151] The update component determines the instance to be updated from multiple microservice instances based on the status information of each microservice instance.

[0152] In this embodiment, the status information of a microservice instance is used to indicate the attribute status and / or running status of the microservice instance. Alternatively, the status information can also directly indicate whether the microservice instance is an instance to be updated. For example, the microservice instance can be labeled as an instance to be updated based on its own running status and other information.

[0153] For example, the status information of a microservice instance may include one or more of the following:

[0154] Information indicating whether a microservice instance is a primary or secondary instance, information indicating the region to which the microservice instance belongs, and information indicating the running status of the microservice instance.

[0155] For example, the status information of the microservice instance can be continuously collected by the status awareness component, etc., through the above-mentioned instance status collection and processing stage. When executing step 402, the update component instructs the status awareness component to find the status information of the microservice instance in the microservice cluster indicated by the update request from the status information collected in the instance status collection and processing stage and return it to the update component.

[0156] For example, in the example shown in Figure 3, after receiving an update request from the configuration tool, the update component can parse the request to obtain its specific content, such as the identifier of the microservice cluster to be updated. Then, based on the identifier, it can query the status information of the microservice instances within that cluster from the status-aware component. After retrieving the status information of the microservice instances based on their identifier, the status-aware component can transmit this information to the update component, enabling it to make a decision based on this status information and determine the instances to be updated.

[0157] In different application scenarios, the specific methods for determining the instance to be updated based on the status information can vary.

[0158] The following sections provide examples of specific methods for determining the instance to be updated based on status information in different application scenarios.

[0159] 1) Master-slave scenario

[0160] In some embodiments, multiple microservice instances in a microservice cluster include a microservice instance as a master instance and a microservice instance as a slave instance, and the status information includes information indicating whether a microservice instance is a master instance or a slave instance.

[0161] Step 402 above includes:

[0162] The update component determines multiple instances to be updated from multiple microservice instances, as well as the update order for each instance.

[0163] Among the multiple instances to be updated, the update order of the microservice instance that is a slave instance takes precedence over the update order of the microservice instance that is a master instance.

[0164] In a microservice cluster, when there is a master-slave distinction between microservice instances, the interruption of the master instance will directly reduce the SLA level. Furthermore, during operation, frequent switching of the master instance will lead to a serious performance degradation of the microservice cluster.

[0165] Based on this, in this embodiment of the application, the status information of the microservice instance can be used to record whether the microservice instance is a master instance or a slave instance, thereby reasonably determining the instances to be updated in the microservice instance and the update order of each instance to be updated, and avoiding frequent switching of the master instance during the update process of the microservice instance.

[0166] Specifically, when updating the microservice instance that is currently the master instance, the master instance needs to be switched from that microservice instance to another microservice instance that is currently the slave instance. For example, the master instance is switched from microservice instance A to microservice instance B, and after microservice instance A is changed to a slave instance, microservice instance A is updated.

[0167] In this embodiment of the application, we consider a scenario where, after updating microservice instance A, microservice instance B is then randomly selected for updating. In this case, the primary instance needs to be switched from microservice instance B to microservice instance C, and microservice instance B needs to be updated after it becomes a secondary instance. Therefore, the current random update method is likely to cause frequent switching of the primary instance in the microservice cluster, which will seriously affect the performance of the microservice cluster.

[0168] In this embodiment of the application, multiple instances to be updated and the update order of each instance to be updated can be determined from multiple microservice instances. Among the multiple instances to be updated, the update order of the microservice instance that is a slave instance is higher than the update order of the microservice instance that is a master instance.

[0169] As can be seen in this embodiment, when multiple instances to be updated include a microservice instance as the master instance and a microservice instance as a slave instance, the microservice instance as the slave instance can be updated first, and then the microservice instance as the master instance can be updated. This way, only one master instance switch is needed during the update process of all instances to be updated, avoiding the situation where frequent master instance switching causes a serious performance degradation of the microservice cluster.

[0170] 2) Disaster recovery scenario

[0171] In some embodiments, the status information includes information indicating the region to which a microservice instance belongs, and multiple microservice instances belong to multiple regions;

[0172] Step 402 includes:

[0173] The update component determines multiple instances to be updated from multiple microservice instances, wherein the multiple instances to be updated belong to at least two regions, and the number of instances to be updated contained in each region is less than a number threshold.

[0174] A microservice cluster includes microservice instances that are distributed according to disaster recovery requirements. In other words, different microservice instances can be deployed in different regions. If microservice instances in the same region are updated in a concentrated manner, the number of microservice instances that can provide services in that region will be reduced, thus reducing the disaster recovery capability of that region.

[0175] Based on this, in the embodiments of this application, multiple instances to be updated can be identified, and these multiple instances to be updated will not be concentrated in the same region, but can be distributed in multiple regions, and the number of instances to be updated contained in each region is less than a number threshold (the number threshold can be determined according to disaster recovery requirements), so that the instances to be updated will not be concentrated in a certain region, so as to ensure that the microservice instances in multiple regions can be updated synchronously and to ensure the disaster recovery capability of each region.

[0176] 3) Task execution scenario

[0177] In some embodiments, the status information includes information indicating the running status of a microservice instance, which is used to indicate whether the microservice instance is running;

[0178] Step 402 includes:

[0179] The update component identifies microservice instances that are in an idle state from among multiple microservice instances as the instances to be updated.

[0180] A microservice cluster includes both running and idle microservice instances, and the downtime costs for these two groups can differ significantly. For example, if a microservice instance running a long-running task is updated while the task is in progress, it can typically cause business disruption.

[0181] Based on this, in this embodiment of the application, the running status of each microservice instance can be recorded. This running status can indicate the task execution status of the microservice instance, such as whether the microservice instance is running, and also the resource consumption of the running microservice instance. Thus, based on the running status, microservice instances that are in a state where there will be no loss of business or minimal loss of business are determined as instances to be updated. In other words, microservice instances with an idle running status are determined as instances to be updated, so as to reduce the loss of business during the microservice instance update process and ensure better business execution effect.

[0182] There are several ways to determine the idle state. For example, the running state of a microservice instance whose resource utilization (such as processor utilization and / or memory utilization) is less than a specified threshold can be determined as an idle state. Alternatively, the running state of a microservice instance that is not in a task execution state can be determined as an idle state.

[0183] It should be noted that the actual application scenario may involve any of the above scenarios, or a combination of the above scenarios. The specific methods for determining the instance to be updated can be executed independently or in combination to determine the instance to be updated in the actual application scenario.

[0184] Step 403: The plugin center determines the target plugin from the multiple plugins included in the plugin center based on the workload type of the instance to be updated.

[0185] Among these, different plugins provide interfaces for updating microservice instances of different workload types, while the target plugin provides an interface for updating microservice instances of the workload type of the instance to be updated.

[0186] After identifying the instance to be updated, the workload type of the instance can be obtained, thereby determining the target plugin from multiple plugins, so as to provide the ability to update microservice instances in the runtime environment of the microservice cluster through the target plugin.

[0187] In many scenarios, the workload types of microservice instances in a microservice cluster are the same. Therefore, the workload type corresponding to the microservice cluster can be used as the workload type of the instance to be updated.

[0188] For example, as shown in Figure 3, during the plugin registration process, the registry can store the identifier of the microservice cluster and the corresponding workload type. Then, in step 403, the update component can query the registry for the workload type corresponding to the microservice cluster based on its identifier, and use this workload type as the workload type of the instance to be updated. Furthermore, in this scenario, since microservice instances within a microservice cluster share the same workload type, in some examples, a single query can be performed on the registry for the update request to determine the workload types of all instances in the microservice cluster to be updated. In other examples, a separate workload type query can be performed on the registry for each instance to be updated. Alternatively, the update component can directly query the plugin center for the target plugin corresponding to the workload type of the instance to be updated. The plugin center then identifies the plugin whose workload type matches the workload type of the instance to be updated as the target plugin.

[0189] For example, in the example shown in Figure 3, the update component can query the plugin center for the corresponding plugin based on the workload type of the instance to be updated, using it as the target plugin. After finding the target plugin, the plugin center can return the information of the target plugin to the update component, allowing the update component to call the target plugin.

[0190] In this way, when a microservice instance needs to be updated, it can be matched among multiple plugins based on the workload type, so that the appropriate plugin can be adaptively selected by the plugin center to access the corresponding runtime environment and perform the microservice instance update operation.

[0191] Step 404: Update the component to call the target plugin.

[0192] In this embodiment of the application, the plugin center or registration center can return information such as the identifier of the target plugin to the updating component, so that the updating component can call the target plugin through the identifier of the target plugin and other information.

[0193] As shown in Figure 3, the update component can call the target plugin from the plugin center.

[0194] Step 405: The target plugin is connected to the runtime environment of the instance to be updated in order to update the instance.

[0195] For example, the operating environment of a microservice cluster can be cloud-native, or it can be a virtualized, serverless, or other similar operating environment.

[0196] In this embodiment, since the target plugin provides the ability to update microservice instances within the microservice cluster's runtime environment, it can be invoked to connect to the microservice cluster's runtime environment and perform update operations on the instances to be updated. The runtime environment of the microservice cluster refers to the runtime environment of the instances to be updated within the microservice cluster. There are various ways to implement the update operation on the instances to be updated by invoking the target plugin; the specific method can be determined based on the update method configured in the corresponding runtime environment.

[0197] In the example shown in Figure 3, after the update component calls the target plugin, the target plugin can access the runtime environment of the instance to be updated in order to update the instance to be updated in the microservice cluster.

[0198] Furthermore, in the example shown in Figure 3, if the instances to be updated identified in step 402 are only a portion of the microservice cluster, for example, due to quantity limitations, each execution of step 402 can only identify no more than a specified number of instances to be updated. Then, after executing step 405, if there are still required microservice instances in the microservice cluster, steps 402-405 can be executed iteratively through updating components and the plugin center to traverse all instances to be updated in the microservice cluster and implement the update operation for all instances. Of course, in other examples, the instances to be updated in step 402 include all instances to be updated in the microservice cluster, and steps 402-405 may not need to be executed iteratively.

[0199] In addition, during the above steps, the updated components can periodically return indication information to the configuration tool to indicate the current update progress, etc. Alternatively, after the microservice cluster update is completed, the updated microservice cluster can be returned to the configuration tool to indicate that the update is complete.

[0200] In this embodiment, multiple plugins provide the ability to update microservice instances under various operating environments (e.g., cloud-native, virtualization, serverless, etc.). Therefore, after determining the instance to be updated, the target plugin adapted to the current operating environment can be dynamically determined based on the workload type of the instance to be updated, thereby enabling the updating of the instance in the microservice cluster. It is evident that this embodiment can efficiently update microservice instances under different operating environments, improve the update efficiency of the microservice cluster, adapt to the needs of various application scenarios, has high versatility, and is easy to maintain and manage.

[0201] The following three exemplary scenarios illustrate some possible specific implementations of the embodiments of this application.

[0202] 1. Microservice cluster updates in cloud-native scenarios

[0203] In this exemplary scenario, the microservice cluster runs on Kubernetes, and its workload is a container type, specifically a StatefulSet.

[0204] 1) Microservice deployment and registration

[0205] As shown in Figure 5a, the process of deploying and applying microservices may include the following steps:

[0206] a. The deployment tool submits the Kubernetes StatefulSet (with its update policy set to update on deletion) to Kubernetes to enable microservice deployment. The update policy provided in the StatefulSet is update on deletion, which means that the old version instance is deleted by deleting the instance to be updated, and then the old version instance is replaced by the new version instance.

[0207] b. Kubernetes starts a Statefulset based on the content of YAML ("yet another markup language"), which is not a markup language, to start a microservice cluster in Kubernetes;

[0208] c. When the registry center listens for a new Statefulset running in Kubernetes, it obtains the registration information, records the address (namespace and object name) of the new Statefulset, and matches the Statefulset workload type with the corresponding plugin in the plugin center.

[0209] d. During the operation of the microservice cluster, microservice instances periodically mark their current status information using tags. This status information can directly indicate whether a microservice instance is an instance to be updated. For example, the status information can indicate that the microservice instance is in an idle state and can be used as an instance to be updated. Alternatively, it can identify whether the microservice instance is a master instance or a slave instance, or it can identify the region to which the microservice instance belongs, etc.

[0210] e. The state update component listens for and reads the tags of microservice instances to retrieve state information;

[0211] f. The status update component updates the list of status information for microservice instances in the microservice cluster based on the monitored content.

[0212] 2) Updating the instance to be updated

[0213] As shown in Figure 5b, updating the instance to be updated includes the following steps:

[0214] a. The configuration tool sends an update request to the update component, which includes the identifier of the microservice cluster (such as the name of the microservice cluster, namespace, workload information, etc.), where the update component can act as an upgrade controller;

[0215] b. Update components use microservice cluster information to locate the actual location of a specific microservice cluster in the registry center;

[0216] c. The update component queries the state-aware component for the state information of the microservice instances in the microservice cluster;

[0217] d. After determining the instance to be updated based on the status information, the update component can submit the workload type information of the instance to be updated to the plugin center;

[0218] e. The plugin center returns the target plugin. The update component connects to Kubernetes through the target plugin and performs the update operation on the instance to be updated. In this example, the update function of the target plugin is implemented according to the update strategy provided in the StatefulSet. Specifically, the instance to be updated is deleted to delete the old version instance, and then the new version instance is used to replace the deleted old version instance.

[0219] 2. Use third-party software to collaboratively update microservice instances.

[0220] In this exemplary scenario, the microservice cluster runs on the third-party software OpenKruise in Kubernetes, and the workload type of the microservice cluster is container type, specifically the new workload AdvancedStatefulset provided by OpenKruise, which has the ability to update new instances.

[0221] 1) Microservice deployment and registration

[0222] As shown in Figure 6a, the process of deploying and applying microservices may include the following steps:

[0223] a. The deployment tool submits the microservice's YAML to the Kubernetes cluster where OpenKruise is deployed for microservice deployment;

[0224] b. When Kubernetes receives a request to create a new AdvancedStatefulSet, it notifies OpenKruise to start the microservice cluster;

[0225] c. OpenKruise starts AdvancedStatefulset;

[0226] AdvancedStatefulSet proactively sends registration information to the registry center, or the registry center proactively scans to obtain registration information;

[0227] d. The registry center listens for new Statefulsets running in Kubernetes, records the address (namespace and object name) of the new Statefulset, and matches the Statefulset workload type with the corresponding plugin in the plugin center;

[0228] e.AdvancedStatefulset continuously refreshes the state information of the microservice instance to the state-aware component based on its own running status.

[0229] 2) Updating the instance to be updated

[0230] As shown in Figure 6b, updating the instance to be updated includes the following steps:

[0231] a. The configuration tool sends an update request to the update component, which includes the identifier of the microservice cluster (such as the name of the microservice cluster, namespace, workload information, etc.), where the update component can act as an upgrade controller;

[0232] b. Update components use microservice cluster information to locate the actual location of a specific microservice cluster in the registry center;

[0233] c. The update component queries the state-aware component for the state information of the microservice instances in the microservice cluster;

[0234] d. After determining the instance to be updated based on the status information, the update component can submit the workload type information of the instance to be updated to the plugin center;

[0235] e. The plugin center returns the target plugin, the updated component accesses OpenKruise through the target plugin, and updates the tag of the microservice instance in OpenKruise and the priority definition of the tag, so as to mark the instance to be updated by the tag;

[0236] f. After OpenKruise monitoring detects a change in the label of a microservice instance, it performs the actual update operation.

[0237] 3. Microservice cluster updates in virtualization scenarios

[0238] In this exemplary scenario, the microservice cluster runs in a virtualized cluster environment, and the workload type of the microservice cluster is a virtual machine.

[0239] 1) Microservice deployment and registration

[0240] As shown in Figure 7a, the process of deploying and applying microservices may include the following steps:

[0241] a. Deployment tools deploy microservices in virtualized clusters;

[0242] b. Start the microservice cluster in the virtualized cluster;

[0243] c. Virtual machine type workloads in the virtualization cluster register information with the registry center;

[0244] d. During the operation of the microservice cluster, the status information of the microservice instances is reported to the status awareness component;

[0245] e. The state-aware component refreshes the state information of the microservice instance.

[0246] 2) Updating the instance to be updated

[0247] As shown in Figure 7b, updating the instance to be updated includes the following steps:

[0248] a. The configuration tool sends an update request to the updating component;

[0249] b. Update components use microservice cluster information to locate the actual location of a specific microservice cluster in the registry center;

[0250] c. The update component queries the state-aware component for the state information of the microservice instances in the microservice cluster;

[0251] d. After determining the instance to be updated based on the status information, the update component can submit the workload type information of the instance to be updated to the plugin center;

[0252] e. The plugin center returns the target plugin. The updated component accesses the virtualization cluster through the target plugin and performs the update operation on the instance to be updated. Specifically, the new version instance can replace the old version instance.

[0253] The above describes the microservice instance update method provided by the embodiments of this application from multiple aspects. The microservice instance update system provided by the embodiments of this application is described below with reference to the accompanying drawings.

[0254] As shown in Figure 8, this application embodiment provides a microservice instance update system 80, which includes a communication interface 801, a plugin center 802, and an update component 803.

[0255] Communication interface 801 is used to: obtain update requests, which indicate that an update should be performed on the microservice cluster, which includes multiple microservice instances;

[0256] The update component 803 is used to: determine the instance to be updated from multiple microservice instances in the microservice cluster based on the update request;

[0257] Plugin Center 802 is used to: determine the target plugin from multiple plugins included in the plugin center based on the workload type of the instance to be updated. Among the multiple plugins, different plugins are used to provide interfaces for updating microservice instances of different workload types, and the target plugin is used to provide interfaces for updating microservice instances of the workload type of the instance to be updated.

[0258] The update component 803 is used to: invoke the target plugin so that the target plugin can access the runtime environment of the instance to be updated in order to update the instance.

[0259] Optionally, the workload type includes one or more of the following types: container, virtual machine, function.

[0260] Optionally, component 803 is updated for:

[0261] Retrieve the status information of each microservice instance among multiple microservice instances;

[0262] Based on the status information of each microservice instance, determine the instance to be updated from multiple microservice instances.

[0263] Optionally, the multiple microservice instances in the microservice cluster include a microservice instance as the master instance and a microservice instance as the slave instance, and the status information includes information indicating whether the microservice instance is a master instance or a slave instance;

[0264] The update component 803 is used to: determine multiple instances to be updated from multiple microservice instances and the update order of each instance to be updated, wherein, among the multiple instances to be updated, the update order of the microservice instance as a slave instance takes precedence over the update order of the microservice instance as a master instance.

[0265] Optionally, the status information includes information indicating the running status of the microservice instance, which is used to indicate whether the microservice instance is running;

[0266] The update component 803 is used to: identify microservice instances that are in an idle state from multiple microservice instances as instances to be updated.

[0267] Optionally, the status information includes information indicating the region to which the microservice instance belongs, and multiple microservice instances belong to multiple regions;

[0268] The update component 803 is used to: determine multiple instances to be updated from multiple microservice instances, wherein the multiple instances to be updated belong to at least two regions, and the number of instances to be updated contained in each region is less than a number threshold.

[0269] In this embodiment, the module is an example of a software functional unit. The microservice instance update system may include code running on a computing instance. The computing instance may be at least one of a physical host (computing device), a virtual machine, a container, or other computing devices. Further, the aforementioned computing device may be one or more. For example, the microservice instance update system may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the application may be distributed in the same region or in different regions. The multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0270] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a single region. Communication between two VPCs within the same region, and between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0271] As an example of a hardware functional unit, a microservice instance update system may include at least one computing device, such as a server. Alternatively, the microservice instance update system may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The aforementioned PLD can be a complex PLD (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0272] The microservice instance update system comprises multiple computing devices that can be distributed within the same region or across different regions. These computing devices can also be distributed within the same Availability Zone (AZ) or across different AZs. Similarly, they can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. These computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0273] It should be noted that, in other embodiments, the communication interface can be used to execute any step in the microservice instance update method, the update component can be used to execute any step in the microservice instance update method, and the plugin center can be used to execute any step in the microservice instance update method. The steps implemented by the communication interface, the update component, and the plugin center can be specified as needed. By implementing different steps in the microservice instance update method through the communication interface, the update component, and the plugin center, the full functionality of the microservice instance update system can be achieved.

[0274] This application also provides a computing device 90. As shown in FIG9, the computing device 90 includes a bus 92, a processor 94, a memory 96, and a communication interface 98. The processor 94, the memory 96, and the communication interface 98 communicate with each other via the bus 92. The computing device 90 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 90.

[0275] Bus 92 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 9, but this does not imply that there is only one bus or one type of bus. Bus 94 can include pathways for transmitting information between various components of computing device 90 (e.g., memory 96, processor 94, communication interface 98).

[0276] Processor 94 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0277] The memory 96 may include volatile memory, such as random access memory (RAM). The processor 94 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0278] The memory 96 stores executable program code, and the processor 94 executes the executable program code to implement the functions of the aforementioned communication interface, update component and plug-in center, thereby realizing the microservice instance update method applied to the computing device cluster in the above embodiment. That is, the memory 96 stores instructions for executing the microservice instance update method applied to the computing device cluster in the above embodiment.

[0279] The communication interface 98 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 90 and other devices or communication networks.

[0280] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0281] As shown in Figure 10, the computing device cluster includes at least one computing device 90. The memory 96 of one or more computing devices 90 in the computing device cluster may store the same instructions for executing microservice instance update methods.

[0282] In some possible implementations, the memory 96 of one or more computing devices 90 in the computing device cluster may also store partial instructions for executing the microservice instance update method. In other words, a combination of one or more computing devices 90 can jointly execute the instructions for executing the microservice instance update method.

[0283] It should be noted that the memory 96 in different computing devices 90 within the computing device cluster can store different instructions, each used to execute a portion of the microservice instance update method's functionality. That is, the instructions stored in the memory 96 of different computing devices 90 can implement the functionality of one or more modules in the communication interface, update components, and plugin center.

[0284] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 11 illustrates one possible implementation. As shown in Figure 11, two computing devices 90A and 90B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this type of possible implementation, the memory 96 in computing device 90A can store instructions for performing the functions of the update component. Simultaneously, the memory 96 in computing device 90B can store instructions for performing the functions of the plug-in center. Alternatively, the memory 96 in computing device 90A can store instructions for performing part of the functions of the update component. Simultaneously, the memory 96 in computing device 90B can store instructions for performing another part of the functions of the update component.

[0285] It should be understood that the functions of computing device 90A shown in Figure 11 can also be performed by multiple computing devices 90. Similarly, the functions of computing device 90B can also be performed by multiple computing devices 90.

[0286] This application also provides another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similarly referred to the connection method of the computing device clusters in Figures 10 and 11. The difference is that the memory 96 of one or more computing devices 90 in this computing device cluster can store the same instructions for executing the microservice instance update method.

[0287] In some possible implementations, the memory 96 of one or more computing devices 90 in the computing device cluster may also store partial instructions for executing the microservice instance update method. In other words, a combination of one or more computing devices 90 can jointly execute the instructions for executing the microservice instance update method.

[0288] It should be noted that the memory 96 in different computing devices 90 within the computing device cluster can store different instructions for executing parts of the microservice instance update method. That is, the instructions stored in the memory 96 of different computing devices 90 can implement the functions of one or more modules in the communication interface, update components, and plugin center.

[0289] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions capable of running on a computing device or stored on any usable medium. When the computer program product runs on at least one computing device, it causes the at least one computing device to execute a microservice instance update method.

[0290] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center that includes one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute a microservice instance update method.

[0291] This application also provides a chip system including a processor for implementing the steps performed by the aforementioned computing device cluster. In one possible design, the chip system may further include a memory for storing necessary program instructions and data. This chip system may be composed of chips or may include chips and other discrete devices.

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

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

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

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

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

Claims

1. A method for updating microservice instances, characterized in that, An application to a microservice instance update system, the system being located in at least one data center, the system including a communication interface, a plugin center, and update components, the method comprising: The communication interface receives an update request, which indicates an update to the microservice cluster, which includes multiple microservice instances. The update component determines the instance to be updated from multiple microservice instances in the microservice cluster based on the update request; The plugin center determines a target plugin from a plurality of plugins included in the plugin center based on the workload type of the instance to be updated. Different plugins among the plurality of plugins are used to provide interfaces for updating microservice instances of different workload types, and the target plugin is used to provide an interface for updating microservice instances of the workload type of the instance to be updated. The update component calls the target plugin; The target plugin accesses the runtime environment of the instance to be updated in order to update the instance.

2. The method according to claim 1, characterized in that, The workload type includes one or more of the following types: container, virtual machine, function.

3. The method according to claim 1 or 2, characterized in that, The system also includes a state-aware component, which determines the instance to be updated from multiple microservice instances in the microservice cluster based on the update request, including: The state-aware component obtains the state information of each microservice instance among the plurality of microservice instances; The update component determines the instance to be updated from the plurality of microservice instances based on the status information of each microservice instance.

4. The method according to claim 3, characterized in that, The multiple microservice instances in the microservice cluster include a microservice instance as a master instance and a microservice instance as a slave instance, and the status information includes information indicating whether the microservice instance is a master instance or a slave instance; The update component determines the instance to be updated from the plurality of microservice instances based on the status information of each microservice instance, including: The update component determines multiple instances to be updated and the update order of each instance from the plurality of microservice instances, wherein the update order of the microservice instance as a slave instance is prior to the update order of the microservice instance as a master instance among the plurality of instances to be updated.

5. The method according to claim 3 or 4, characterized in that, The status information includes information indicating the running status of the microservice instance, which is used to indicate whether the microservice instance is running; The update component determines the instance to be updated from the plurality of microservice instances based on the status information of each microservice instance, including: The update component determines the microservice instances whose running state is idle from among the multiple microservice instances as the instances to be updated.

6. The method according to any one of claims 3 to 5, characterized in that, The status information includes information indicating the region to which the microservice instance belongs, and the multiple microservice instances belong to multiple regions; The update component determines the instance to be updated from the plurality of microservice instances based on the status information of each microservice instance, including: The update component determines multiple instances to be updated from the multiple microservice instances, wherein the multiple instances to be updated belong to at least two regions, and the number of instances to be updated contained in each region is less than a quantity threshold.

7. A microservice instance update system, characterized in that, The system is located in at least one data center, and the system includes a communication interface, a plugin center, and an update component. The communication interface is used to: obtain an update request, the update request indicating an update to the microservice cluster, the microservice cluster including multiple microservice instances; The update component is used to: determine the instance to be updated from multiple microservice instances in the microservice cluster according to the update request; The plugin center is used to: determine from multiple plugins included in the plugin center based on the workload type of the instance to be updated. The target plugin is used to provide an interface for updating microservice instances of different workload types among the plurality of plugins. The update component is used to: invoke the target plugin so that the target plugin can access the runtime environment of the instance to be updated, so as to update the instance to be updated.

8. The system according to claim 7, characterized in that, The workload type includes one or more of the following types: container, virtual machine, function.

9. The system according to claim 7 or 8, characterized in that, The update component is used for: Obtain the status information of each microservice instance among the multiple microservice instances; Based on the status information of each microservice instance, determine the instance to be updated from the plurality of microservice instances.

10. The system according to claim 9, characterized in that, The multiple microservice instances in the microservice cluster include a microservice instance as a master instance and a microservice instance as a slave instance, and the status information includes information indicating whether the microservice instance is a master instance or a slave instance; The update component is used to: determine multiple instances to be updated and the update order of each instance to be updated from the plurality of microservice instances, wherein, among the plurality of instances to be updated, the update order of the microservice instance as a slave instance is prior to the update order of the microservice instance as a master instance.

11. The system according to claim 9 or 10, characterized in that, The status information includes information indicating the running status of the microservice instance, which is used to indicate whether the microservice instance is running; The update component is used to: determine from the plurality of microservice instances that the microservice instance in the idle state is the instance to be updated.

12. The system according to any one of claims 9-11, characterized in that, The status information includes information indicating the region to which the microservice instance belongs, and the multiple microservice instances belong to multiple regions; The update component is used to: determine multiple instances to be updated from the multiple microservice instances, wherein the multiple instances to be updated belong to at least two regions, and the number of instances to be updated contained in each region is less than a number threshold.

13. A computing device cluster, characterized in that, It includes at least one computing device, said at least one computing device including a processor and a memory; The processor is configured to execute instructions stored in the memory to cause the computing device cluster to perform the method as described in any one of claims 1-6.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when run on a processor, causes the processor to perform the method as described in any one of claims 1-6.

15. A computer program product containing instructions, characterized in that, When the instructions are executed by the processor, the method described in any one of claims 1-6 is implemented.

Images