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 microservice instance update method and related equipment

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on January 26, 2024, with Chinese application number 202410114585.3 and application name “A data processing method and related equipment”, and claims priority to the Chinese patent application filed with the State Intellectual Property Office on March 20, 2024, with Chinese application number 202410323293.0 and application name “A microservice instance update method and related equipment”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of microservice technology, and in particular to a microservice instance updating method and related equipment. Background Art

[0003] With the vigorous development of cloud technology, various cloud application scenarios have been developed, including virtual machines, cloud native, and serverless. However, the update of a large number of applications faces huge challenges in diverse application scenarios.

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

[0005] However, as the operating environment of microservice clusters is becoming increasingly diverse, for example, there can be multiple operating environments such as physical machines, virtual machines, cloud native, and serverless machines. Traditional microservice update methods have poor versatility and are difficult to adapt to the update needs in diverse operating environments, resulting in low update efficiency of microservice instances.

[0006] Summary of the Invention

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

[0008] A first aspect of the present application provides a microservice instance update method, which is applied to a microservice instance update system, which is arranged in at least one data center. The system includes a communication interface, a plug-in center and an update component, wherein the communication interface obtains an update request, the update request indicates to update a microservice cluster, and the microservice cluster includes multiple microservice instances; the update component determines an instance to be updated from multiple microservice instances in the microservice cluster according to the update request; the plug-in center determines a target plug-in from multiple plug-ins included in the plug-in center according to the workload type of the instance to be updated, wherein different plug-ins among the multiple plug-ins are used to provide interfaces for updating microservice instances of different workload types, and the target plug-in 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 plug-in; the target plug-in accesses the running environment of the instance to be updated to update the instance to be updated.

[0009] In the first aspect, multiple plug-ins provide the ability to update microservice instances with different workload types in a variety of operating environments (e.g., cloud native, virtualized, serverless, etc.). Therefore, after determining the instance to be updated, the target plug-in adapted to the current operating environment can be dynamically determined based on the workload type of the instance to be updated, so as to access the corresponding operating environment and update the instance to be updated in the microservice cluster. As can be seen, in the first aspect, microservice instances in different operating environments can be efficiently updated, improving the update efficiency of the microservice cluster, adapting to the needs of various application scenarios, having high versatility, and facilitating maintenance and management.

[0010] In a possible implementation of the first aspect, the workload type includes a container, a virtual machine, and / or a function.

[0011] In this possible implementation, the running form of a microservice instance is called a workload.

[0012] In a possible implementation of the first aspect, the update component determines, based on the update request, an instance to be updated from multiple microservice instances in the microservice cluster, including: the update component obtains status information of each microservice instance in the multiple microservice instances; and the update component determines, based on the status information of each microservice instance, the instance to be updated from the multiple microservice instances.

[0013] In this possible implementation, the status information of the microservice instance is used to indicate the attribute status and / or operating status of the microservice instance. Alternatively, the status information may directly indicate whether the microservice instance is an instance to be updated. For example, the microservice instance may be marked as an instance to be updated using a tag or other means based on its own operating status and other information.

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

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

[0016] In a possible implementation of the first aspect, multiple microservice instances in a microservice cluster include a microservice instance serving as a master instance and a microservice instance serving as a slave instance, and the status information includes information indicating whether the microservice instance is a master instance or a slave instance; and an update component determines, based on the status information of each microservice instance, instances to be updated from the multiple microservice instances, including: the update component determines, from the multiple microservice instances, multiple instances to be updated and an update order for each instance to be updated, wherein, among the multiple instances to be updated, the update order of the microservice instance serving as the slave instance precedes the update order of the microservice instance serving as the 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. Moreover, if the master instance is frequently switched during operation, the performance of the microservice cluster will be seriously degraded.

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

[0019] For example, multiple instances to be updated and the update order of each instance to be updated can be determined from multiple microservice instances, wherein, among the multiple instances to be updated, the update order of the instance to be updated whose status information indicates that it is a slave instance precedes the update order of the instance to be updated whose status information indicates that it is a master instance. It can be seen that in this possible implementation, when the multiple instances to be updated include a microservice instance as a 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, so that in the process of updating all instances to be updated, only one master instance switch needs to be performed, avoiding the situation where frequent switching of the master instance causes a serious performance degradation of the microservice cluster.

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

[0021] A microservice cluster includes both active and idle microservice instances, and the interruption costs of the two can vary significantly. For example, if a microservice instance running a long-running task is updated while the task is in progress, it often results in business losses.

[0022] Based on this, in this possible implementation method, the running status of each microservice instance can be recorded. The running status can indicate the task execution status of the microservice instance, for example, whether the microservice instance is running. In addition, it can also indicate the resource occupancy of the running microservice instance, etc., to determine the microservice instance that is currently in a state of no business loss or less business loss as the instance to be updated. That is to say, the microservice instance with an idle running status is determined as the instance to be updated, so as to reduce the business loss during the microservice instance update process and ensure better business execution effect.

[0023] In a possible implementation of the first aspect, the status information includes information indicating a region to which a microservice instance belongs, and multiple microservice instances belong to multiple regions; and the update component determines, based on the status information of each microservice instance, an instance to be updated from the multiple microservice instances, 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.

[0024] A microservice cluster includes microservice instances that are distributed and deployed according to disaster recovery requirements. That is, different microservice instances can be deployed in different regions. If microservice instances in the same region are updated centrally, fewer microservice instances will be available in that region, reducing the region's disaster recovery capabilities.

[0025] Based on this, in this possible implementation method, multiple instances to be updated can be determined, and these multiple instances to be updated will not be concentrated in the same area, and the number of instances to be updated contained in each area is less than the quantity threshold (the quantity threshold can be determined according to the disaster recovery requirements), so that the instances to be updated can be dispersed in multiple areas and will not be concentrated in a certain area, so as to ensure that the microservice instances in multiple areas can be updated synchronously and the disaster recovery capability of each area is guaranteed.

[0026] A second aspect of the present application provides a microservice instance update system that implements the method of the first aspect or any possible implementation of the first aspect. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions, such as a communication interface, an update component, and a plug-in center.

[0027] A third aspect of the present application provides a computing device cluster, which includes at least one computing device, and the at least one computing device includes a processor and a memory. The memory of at least one computing device stores computer-executable instructions that can be run on the processor. When the computer-executable instructions are executed by the processor, the processor executes the method as described in the first aspect or any possible implementation of the first aspect.

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

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

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

[0031] Among them, the technical effects brought about by the second to sixth aspects or any possible implementation methods thereof can refer to the technical effects brought about by the first aspect or the relevant possible implementation methods of the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] FIG1 is an exemplary schematic diagram of a cloud management platform and infrastructure provided by an embodiment of the present application;

[0033] FIG2 is an exemplary schematic diagram of a processing stage provided in an embodiment of the present application;

[0034] FIG3 is a schematic diagram of an exemplary framework structure provided in an embodiment of the present application;

[0035] FIG4 is a schematic diagram of an embodiment of a method for updating a microservice instance provided in an embodiment of the present application;

[0036] FIG5a is a schematic diagram of an exemplary process of a cloud native scenario provided by an embodiment of the present application;

[0037] FIG5 b is another exemplary flow diagram of a cloud-native scenario provided by an embodiment of the present application;

[0038] FIG6 a is a schematic diagram of an exemplary process of an application scenario incorporating third-party software according to an embodiment of the present application;

[0039] FIG6 b is another exemplary flow diagram of an application scenario incorporating third-party software provided in an embodiment of the present application;

[0040] FIG7 a is a schematic diagram of an exemplary process of a virtualization cluster scenario provided by an embodiment of the present application;

[0041] FIG7 b is another exemplary flow diagram of a virtualization cluster scenario provided by an embodiment of the present application;

[0042] FIG8 is an exemplary schematic diagram of a microservice instance update system provided in an embodiment of the present application;

[0043] FIG9 is a schematic diagram of a structure of a computing device provided in an embodiment of the present application;

[0044] FIG10 is a schematic diagram of a structure of a computing device cluster provided in an embodiment of the present application;

[0045] FIG11 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0046] The following describes the embodiments of the present application in conjunction with the accompanying drawings. The terms used in the implementation methods of the present application are only used to explain the specific embodiments of the present application and are not intended to limit the present application.

[0047] Those skilled in the art will appreciate that, 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" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of singular or plural items. The terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchangeable where appropriate. This is merely a way of distinguishing objects with the same properties when describing them in the embodiments of this application. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a list of elements is not necessarily limited to those elements but may include other elements not expressly listed or inherent to such process, method, product, or apparatus.

[0049] First, the concepts involved in the embodiments of the present application are introduced.

[0050] (1) Microservices

[0051] Microservices is a software architectural style that uses a modular approach to compose complex, large applications, based on small building blocks focused on a single responsibility and function. These building blocks communicate using a set of language-independent (or language-agnostic) application programming interfaces (APIs).

[0052] When developing various services as microservices, a single business can be completed by multiple microservices. For example, when a user browses a product on a shopping website, they initiate a purchase request. The purchasing system generates an order and initiates a payment request. In this case, the shopping system first calls the product browsing service, which in turn calls the order service, which in turn calls the payment service. The product browsing service, order service, and payment service are all separate microservices.

[0053] (2) Microservice Instance

[0054] After being instantiated, a microservice is called a microservice instance. For example, the microservice instance can run on at least one of a terminal device, a server, a server cluster, a virtual machine (VM), a container, and the like.

[0055] (3) Microservice Cluster

[0056] A microservice cluster is a collection of microservice instances with the same business responsibilities. Within a microservice cluster architecture, a group of microservice instances with the same business responsibilities provide a single microservice. Ideally, all microservice instances in a microservice cluster maintain a consistent state. However, in real-world scenarios, microservice instances in a microservice cluster often experience transient differences, such as master-slave relationships or varying operational states.

[0057] (4) Workload

[0058] The running form of a microservice instance is called a workload.

[0059] (5) Workload type

[0060] The workload type may indicate the type of running state of the microservice instance, and the workload type may also be considered as the workload type of the microservice instance.

[0061] Under different operating environments, there may be various workload types (also known as workload types).

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

[0063] Furthermore, in different operating environments, workload types may include subtypes such as containers, virtual machines, and / or functions.

[0064] For example, Kubernetes, or K8s for short, is an open-source system for automating the deployment, scaling, and management of containerized applications, used in cloud-native environments. Microservices in Kubernetes use containers as workloads. Specifically, the workload type provided by Kubernetes is the stateful application Statefulset. Furthermore, OpenKruise, a third-party Kubernetes application, also provides containers as workloads, specifically AdvancedStatefulset.

[0065] It is understood that in existing or subsequently developed operating environments, workload types may have other forms besides the above examples, and subtypes of types such as containers, virtual machines, and / or functions may also have other forms. For example, when the workload type is a container, further refined workload types may include Statefulset and AdvancedStatefulset, and other types may also be available. This is not limited in the embodiments of the present application.

[0066] (6) Operating environment

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

[0068] (7) Cloud Native

[0069] Cloud Native is a cloud computing-based software development and deployment methodology that designs applications and services as native applications in cloud environments to achieve high availability, scalability, and flexibility.

[0070] In a cloud-native operating 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 can adopt a microservices architecture, splitting applications and services into multiple small service units to improve application maintainability and scalability. In cloud native scenarios, the workload type of microservices is containers.

[0072] An exemplary open source system in a cloud-native scenario may 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 increasing 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 includes multiple virtual machines.

[0075] (9) Serverless

[0076] In a serverless architecture, traditional applications can be segmented into fine-grained parts, with each function taking on 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 form of serverless architecture. It allows developers to build, compute, run, and manage their own application packages in the form of functions, without having to maintain backend infrastructure. Function as a Service is a transaction-driven execution model that runs in stateless containers. Functions utilize the FaaS provider's services 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, you group some microservice instances within a microservice cluster based on technical constraints or business requirements. These groups are then updated in units called upgrade domains. In practical scenarios, the selected set of instances to be updated can serve as the upgrade domain.

[0081] With the vigorous development of cloud technology, various cloud application scenarios have been developed, including virtual machines, cloud native, and serverless. However, the update of a large number of applications faces huge challenges in diverse application scenarios.

[0082] Currently, there are several traditional ways to update microservices:

[0083] 1. Manually select the microservice instances in the microservice cluster for update.

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

[0085] 2. Randomly update the microservice instances in the microservice cluster.

[0086] In actual application scenarios, in the same microservice cluster, although the business responsibilities of each microservice instance are the same, there are usually differences between different microservice instances in the transient state, for example:

[0087] A microservice cluster includes both running and idle microservice instances, and the interruption costs of the two can vary significantly.

[0088] A microservice cluster includes microservice instances that are distributed and deployed based on disaster recovery requirements. This means that different microservice instances can be deployed in different regions. Updating all or most microservice instances in the same region will reduce disaster recovery capabilities.

[0089] There is a master-slave distinction between microservice instances in a microservice cluster. If the master instance is interrupted, the service level agreement (SLA) level will be directly reduced.

[0090] It can be seen 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 results.

[0091] 3. Update microservices using third-party update tools.

[0092] In actual application scenarios, all microservices usually have the common requirement of updating. Therefore, different microservices use different third-party update tools, which will result in a large amount of additional investment in adaptation work, poor versatility, and generally limited functionality.

[0093] In addition, as the operating environment of microservice clusters is becoming more and more diverse, for example, there can be multiple operating environments such as physical machines, virtual machines, cloud native, and serverless machines, the traditional microservice instance update method has poor versatility and is difficult to adapt to the update needs in diverse operating environments, resulting in low update efficiency of microservice instances.

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

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

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

[0097] In one example, the computing device cluster can be used to implement a microservice instance update system, which is set in at least one data center and includes a communication interface, a plug-in center, and an update component.

[0098] The at least one data center may be set 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] The cloud management platform is used to manage the infrastructure that provides cloud services. The infrastructure may include one or more servers.

[0100] The following describes the cloud management platform and infrastructure with reference to an architectural diagram shown in FIG1 .

[0101] In Figure 1, the cloud management platform exchanges information with one or more servers in the infrastructure (such as Server 1 and Server 2 in Figure 1) through an internal network. The server includes a hardware layer and a software layer. The hardware layer includes the hardware configured on the server, where PCI devices can be, for example, network cards, graphics processing units (GPUs), offload cards, and other devices that can be plugged into the peripheral component interconnect (PCI) or peripheral component interconnect express (PCIe) slots of the server. The software layer includes the operating system installed and running on the server (relative to the operating system of the virtual machine, it can be called the host operating system). The host operating system is equipped with a virtual machine manager (also known as a hypervisor). The role of the virtual machine manager is to implement computing virtualization, network virtualization, and storage virtualization of the virtual machine, and to manage the virtual machine. Among them, a virtual machine refers to a complete computer system with complete hardware system functions simulated by software and running in a completely isolated environment. In the system architecture shown in Figure 1, the server can be used to run virtual machines, and the specifications of each virtual machine can be the same or different. Among them, virtual machines can also be called cloud servers (elastic compute services, ECS), elastic instances, etc. Different cloud service providers may have different names.

[0102] In one example of an embodiment of the present application, the cloud management platform may 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 an interface or application programming interface (API)). Users of the cloud platform and cloud service providers can operate the client remote access access interface to register a cloud account and password on the cloud management platform, and after the cloud management platform successfully authenticates the cloud account and password, log in to the cloud management platform, thereby creating, managing, logging in and operating virtual machines in the cloud data center.

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

[0105] Of course, the cloud management platform can also be other types of cloud platforms, and this is not limited in the embodiments of this application. 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 operate without the cloud management platform, and this is not limited in this application.

[0106] The microservice instance update system may include but is not limited to a communication interface, a plug-in center, and an update component.

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

[0108] As shown in FIG2 , the microservice instance update method according to an embodiment of the present application may include one or more of the following processing stages:

[0109] Plug-in registration, instance status collection, and instance update.

[0110] It should be noted that the order of steps in the above-mentioned processing stages can be executed in sequence according to plug-in registration, instance status collection and instance update, or some steps in some processing stages may not be executed in the above-mentioned order. This is not limited in the embodiments of the present application.

[0111] The following is an exemplary introduction to each processing stage.

[0112] 1. Plugin registration

[0113] In an embodiment of the present application, plug-ins may be developed and registered to subsequently implement the ability to update microservice instances of different workload types in various operating environments through the plug-ins.

[0114] Different plug-ins are used to provide interfaces for updating microservice instances of different workload types.

[0115] The following describes the operation of plug-in registration in conjunction with the plug-in center.

[0116] In the exemplary framework shown in FIG3 , a plug-in center can be created in the microservice instance update system, which is used to develop and register multiple plug-ins according to workload types. Different plug-ins are used to provide interfaces for updating microservice instances of different workload types. For example, an interface for the operating environment of microservice instances of different workload types can be provided to access the operating environment and update the microservice instances of the corresponding workload types.

[0117] For example, if the workload types include the container type workload Statefulset under the cloud native scenario Kubernetes, the container type workload AdvancedStatefulset provided by third-party applications in the cloud native scenario, or the virtual machine type, then you can develop a plug-in 1 corresponding to the container type workload Statefulset, which can provide an interface to the cloud native operating environment Kubernetes to update the microservice instances of the container type workload Statefulset. You can also develop a plug-in 2 corresponding to the container type workload AdvancedStatefulset, which can provide an interface to third-party applications in the cloud native operating environment Kubernetes to update the microservice instances of the container type workload AdvancedStatefulset, and develop a plug-in 3 corresponding to the virtual machine type, which can provide an interface to the virtualization cluster to update the microservice instances of the virtual machine type workload.

[0118] After multiple plug-ins are registered, the workload type corresponding to each of the multiple plug-ins may be stored.

[0119] For example, after the plug-in registration is implemented, the correspondence between the plug-in and the workload type can be stored in the plug-in center. In addition, the plug-in center can also transmit the correspondence between the plug-in and the workload type to the registration center.

[0120] For example, in the preceding example, plugin 1 corresponds to Statefulset workloads, plugin 2 corresponds to AdvancedStatefulset workloads, and plugin 3 corresponds to VM workloads.

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

[0122] The specific process of implementing the microservice instance update capability in various operating environments through the plug-in in the plug-in center can be referred to the relevant introduction of steps 403-405 in the instance update phase, which will not be repeated here.

[0123] 2. Instance status collection

[0124] In an embodiment of the present application, after the microservice cluster is started, the state information of the microservice instances in the microservice cluster can be collected through the state perception component.

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

[0126] Exemplarily, the status information of a microservice instance may include one or more of the following information:

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

[0128] Based on geographic location and network latency, the same region uses the same resource pool (which can be understood as shared public services such as elastic computing, block storage, object storage, VPC networks, elastic public IP addresses, and mirroring). Regions can be used to describe the location of data centers. A region can include one or more data centers, and different regions can include different data centers.

[0129] The following describes the operation of instance state collection using the state awareness component shown in Figure 3 as an example. The state awareness component is used to collect and store the state information of microservice instances. Therefore, the state awareness component can also be considered a state center or state warehouse.

[0130] In an embodiment of the present application, the status of the microservice instance can be collected under specified conditions, and the status information of each microservice instance can be recorded. Specifically, the identifier of each microservice instance and the status information corresponding to the identifier can be recorded. Among them, the specified conditions can have various situations, for example, it can indicate that the microservice is started, or it can also indicate that a specified instruction (such as an instruction input by a user, etc.) has been received.

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

[0132] (1) Receiving status reports: The microservice cluster proactively transmits the identifiers of deployed microservice instances, the corresponding workload types, and the status information of the microservice instances in the microservice cluster to the state-aware component. For example, this information may be transmitted to the state-aware component periodically and / or upon detecting a change in the state of a microservice instance.

[0133] (2) Actively obtain information: If the status detection interface information is provided during the workload registration process of the microservice cluster, 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 the microservice instances to determine the instances to be updated.

[0135] For example, the state awareness component may receive an identifier of a microservice (eg, an ID or a uniform resource locator (URL), etc.), and thereby query and return the state information of a microservice instance of the microservice based on the identifier of the microservice.

[0136] The specific process of implementing state information query and determining the instance to be updated through the state awareness component can be referred to the relevant introduction of step 402 in the instance update phase, which will not be repeated here.

[0137] 3. Instance update

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

[0139] Step 401: The communication interface obtains an update request.

[0140] The update request indicates that a microservice instance of a microservice cluster is updated.

[0141] Exemplarily, the update request can be input by a user through a client into the communication interface of the microservice instance update system. For example, the computing device cluster can provide a configuration interface through a configuration tool such as a browser, and the user can use the client to call the communication interface on this configuration interface to input the update request for the microservice cluster. Alternatively, the computing device cluster can be triggered based on specified conditions. For example, the update request can be triggered when the computing device cluster's configuration tool detects information such as an update data packet for the microservice cluster.

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

[0143] In the example shown in Figure 3, the configuration tool includes a communication interface. The configuration tool can receive update requests input by the user through the communication interface, or generate update requests based on user input information (such as the identifier of the microservice cluster and update instructions, etc.) or specified conditions (such as detecting an update data packet of the microservice cluster, etc.), and transmit the update request to the update component through the communication interface to call the update component to perform subsequent operations.

[0144] In step 402 , the update component determines an instance to be updated from multiple microservice instances in the microservice cluster according to the update request.

[0145] In an embodiment of the present application, after obtaining the update request, the update component can determine one or more instances to be updated from at least one microservice instance of the microservice 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 multiple ways to determine the instance to be updated.

[0147] For example, a microservice instance that will not cause business loss when performing an update operation can be determined from multiple microservice instances as the instance to be updated.

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

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

[0150] The update component obtains the status information of each microservice instance in 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 the embodiments of the present application, the status information of a microservice instance is used to indicate the attribute status and / or operating status of the microservice instance. Alternatively, the status information may directly indicate whether the microservice instance is an instance to be updated. For example, the microservice instance may be marked as an instance to be updated using a tag or other form based on its own operating status and other information.

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

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

[0155] Exemplarily, the state information of the microservice instance can be continuously collected by the state perception component, etc. through the above-mentioned instance state collection and processing stage, and when executing step 402, the update component instructs the state perception component to search for the state information of the microservice instance in the microservice cluster indicated by the update request from the state information collected in the instance state collection and processing stage and return it to the update component.

[0156] For example, in the example shown in FIG3 , after receiving the update request transmitted by the configuration tool, the update component can parse the update request to obtain the specific content of the update request, for example, the identifier of the microservice cluster to be updated. Then, based on the identifier of the microservice cluster, the state-aware component can query the state information of the microservice instances in the microservice cluster. After the state-aware component obtains the state information of the microservice instances in the microservice cluster based on the identifier of the microservice, it can pass the state information of the microservice instances in the microservice cluster to the update component, so that the update component can make a decision based on the state information and determine the instance to be updated.

[0157] In different application scenarios, the specific method of determining the instance to be updated according to the status information may be different.

[0158] The following is an exemplary introduction to specific methods of determining the instance to be updated based on status information in different application scenarios.

[0159] 1) Master-slave scenario

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

[0161] The above step 402 includes:

[0162] The update component determines multiple instances to be updated and an update order for each instance to be updated from multiple microservice instances.

[0163] Among the multiple instances to be updated, the update order of the microservice instance serving as the slave instance is earlier than the update order of the microservice instance serving as the 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. Moreover, if the master instance is frequently switched during operation, the performance of the microservice cluster will be seriously degraded.

[0165] Based on this, in an embodiment of the present 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, so as to reasonably determine the instances to be updated in the microservice instance and the update order of each instance to be updated, thereby 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, you need to first switch the master instance from the microservice instance to another microservice instance that is currently the slave instance. For example, switch the master instance from microservice instance A to microservice instance B, and after microservice instance A is transformed into a slave instance, update microservice instance A.

[0167] In an embodiment of the present application, a situation is taken into consideration, that is, after updating microservice instance A, microservice instance B is randomly selected to be updated, then the master instance needs to be switched from microservice instance B to microservice instance C, and after microservice instance B is transformed into a slave instance, microservice instance B is updated. Therefore, the current random update method is likely to cause frequent switching of the master instance in the microservice cluster, seriously affecting the performance of the microservice cluster.

[0168] In an embodiment of the present application, multiple instances to be updated and the update order of each instance to be updated can be determined from multiple microservice instances, wherein, among the multiple instances to be updated, the update order of the microservice instance serving as a slave instance precedes the update order of the microservice instance serving as a master instance.

[0169] It can be seen that in the embodiment of the present application, when multiple instances to be updated include a microservice instance as a master instance and a microservice instance as a slave instance, the microservice instance as a slave instance can be updated first, and then the microservice instance as the master instance can be updated, so that in the process of updating all instances to be updated, only one master instance switch is required, avoiding the situation where frequent switching of the master instance causes serious performance degradation of the microservice cluster.

[0170] 2) Disaster Recovery Scenario

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

[0172] Step 402 includes:

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

[0174] A microservice cluster includes microservice instances that are distributed and deployed according to disaster recovery requirements. That is, different microservice instances can be deployed in different regions. If microservice instances in the same region are updated centrally, fewer microservice instances will be available in that region, reducing the region's disaster recovery capabilities.

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

[0176] 3) Task running scenario

[0177] In some embodiments, the state information includes information indicating an operating state of the microservice instance, where the operating state is used to indicate whether the microservice instance is running;

[0178] Step 402 includes:

[0179] The update component determines, from multiple microservice instances, a microservice instance in an idle state as an instance to be updated.

[0180] A microservice cluster includes both active and idle microservice instances, and the interruption costs of the two can vary significantly. For example, if a microservice instance running a long-running task is updated while the task is in progress, it often results in business losses.

[0181] Based on this, in an embodiment of the present application, the running status of each microservice instance can be recorded. The running status can indicate the task execution status of the microservice instance, for example, it can indicate whether the microservice instance is running. In addition, it can also indicate the resource occupancy of the running microservice instance, etc., so as to determine the microservice instance that is currently in a state of no business loss or less business loss as the instance to be updated according to the running status. That is to say, the microservice instance with an idle running status is determined as the instance to be updated, so as to reduce the business loss during the microservice instance update process and ensure better business execution effect.

[0182] There are many specific ways to determine the idle state. For example, the running state of a microservice instance whose resource utilization rate (such as processor occupancy and / or memory occupancy rate) is less than a specified threshold can be determined as an idle state, or 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 above specific methods for determining the instances to be updated may be executed independently or combined with each other to determine the instances to be updated in the actual application scenario.

[0184] Step 403: The plug-in center determines a target plug-in from a plurality of plug-ins included in the plug-in center according to the workload type of the instance to be updated.

[0185] Among them, different plug-ins among the multiple plug-ins are used to provide interfaces for updating microservice instances of different workload types, and the target plug-in is used to provide an interface for updating microservice instances of the workload type of the instance to be updated.

[0186] After determining the instance to be updated, the workload type of the instance to be updated can be obtained, so as to determine a target plug-in from multiple plug-ins, so as to provide the update capability of the microservice instance in the operating environment of the microservice cluster through the target plug-in.

[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, in the example shown in FIG3 , during the plug-in registration processing phase, the microservice cluster identifier and the workload type corresponding to the microservice cluster can be stored in the registration center. Then, in step 403, the update component can query the registration center for the workload type corresponding to the microservice cluster based on the microservice cluster identifier, and use the workload type corresponding to the microservice cluster as the workload type of the instance to be updated. Furthermore, in this scenario, since the workload types of the microservice instances in a microservice cluster are the same, in some examples, a query operation can be performed on the registration center for the update request, thereby determining the workload types of all instances to be updated in the microservice cluster based on the query operation; in other examples, a workload type query request can be performed on the registration center for each instance to be updated. Alternatively, the update component can directly query the plug-in center for the target plug-in corresponding to the workload type of the instance to be updated. The plug-in center determines the plug-in whose workload type matches the workload type of the instance to be updated among multiple plug-ins as the target plug-in.

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

[0190] In this way, when a microservice instance needs to be updated, it can be matched among multiple plug-ins according to the workload type, so that the appropriate plug-in can be adaptively selected through the plug-in center to access the corresponding operating environment, thereby performing the update operation of the microservice instance.

[0191] Step 404: The update component calls the target plug-in.

[0192] In an embodiment of the present application, the plug-in center or registration center can return information such as the identifier of the target plug-in to the update component, so that the update component can call the target plug-in through the information such as the identifier of the target plug-in.

[0193] As shown in FIG3 , the update component may call the target plug-in from the plug-in center.

[0194] Step 405: The target plug-in accesses the running environment of the instance to be updated to update the instance to be updated.

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

[0196] In the embodiment of the present application, since the target plug-in provides the ability to update the microservice instance in the operating environment of the microservice cluster, the target plug-in can be called to correspondingly access the operating environment of the microservice cluster to implement the update operation of the instance to be updated. The operating environment of the microservice cluster is the operating environment of the instance to be updated in the microservice cluster. There are many specific ways to implement the update operation of the instance to be updated by calling the target plug-in, which can be implemented according to the update method configured in the corresponding operating environment.

[0197] In the example shown in FIG3 , after the update component calls the target plug-in, the target plug-in can access the running environment of the instance to be updated to update the instance to be updated in the microservice cluster.

[0198] In addition, in the example shown in Figure 3, if the instances to be updated determined in step 402 are part of the instances to be updated in the microservice cluster, for example, due to quantity restrictions, each execution of step 402 can only determine no more than a specified number of instances to be updated. Then, after executing step 405, if there may still be required microservice instances in the microservice cluster, the above steps 402-405 can be executed cyclically through the update component and plug-in center to traverse all instances to be updated in the microservice cluster and implement the update operation of all instances to be updated. Of course, in some other examples, the instances to be updated in step 402 include all instances to be updated in the microservice cluster, and the above steps 402-405 may not need to be executed cyclically.

[0199] In addition, during the execution of the above steps, the update component can periodically return indication information to the configuration tool to indicate the current update progress, etc., or after the microservice cluster update is completed, the configuration tool can return indication information indicating that the update of the microservice cluster has been completed.

[0200] In the embodiment of the present application, multiple plug-ins provide the ability to update microservice instances in a variety of operating environments (such as cloud native, virtualization, serverless, etc.). Therefore, after determining the instance to be updated, the target plug-in adapted to the current operating environment can be dynamically determined according to the workload type of the instance to be updated to achieve the update of the instance to be updated in the microservice cluster. It can be seen that in the embodiment of the present application, microservice instances under different operating environments can be efficiently updated, the update efficiency of the microservice cluster can be improved, and it can adapt to the needs of various application scenarios. It 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 the present application.

[0202] 1. Microservice Cluster Update in Cloud Native Scenario

[0203] In this exemplary scenario, the operating environment of the microservice cluster is Kubernetes, and the workload type of the microservice cluster is a container type, specifically 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 the update policy set to update on delete) to Kubernetes to implement microservice deployment. The update policy provided in the Statefulset is update on delete, which means that the old version instance is deleted by deleting the instance to be updated, and then the new version instance is used to replace the deleted old version instance;

[0207] b. Kubernetes launches Statefulset based on YAML ("yet another markup language" ain't a markup language) content to launch a microservices cluster in Kubernetes;

[0208] c. The registration center monitors Kubernetes for new Statefulsets, obtains the registration information, records the address of the new Statefulset (namespace and object name), and matches the Statefulset workload type with the plug-in corresponding to the Statefulset workload type in the plug-in center;

[0209] d. During the operation of a microservice cluster, microservice instances are periodically labeled with their current status information. This status information can directly indicate that a microservice instance is pending for update. For example, if the status information indicates that a microservice instance is idle, it can be used as an instance to be updated. Alternatively, it can identify the microservice instance as a master or slave instance, or the region to which the microservice instance belongs.

[0210] e. The status update component monitors and reads the tags of the microservice instances and reads the status information;

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

[0212] 2) Update of the instance to be updated

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

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

[0215] b. The update component uses the microservice cluster information to find the actual location of the specific microservice cluster in the registration center;

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

[0217] d. After the update component determines the instance to be updated based on the status information, it can submit the workload type information of the instance to be updated to the plug-in center;

[0218] e. The plugin center returns the target plugin. The update component connects to Kubernetes through the target plugin and performs updates on the instances to be updated. In this example, the update function of the target plugin is implemented according to the update strategy provided by 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 example scenario, the microservice cluster runs in the third-party software OpenKruise in Kubernetes. The workload type of the microservice cluster is a container type, specifically the new workload AdvancedStatefulset provided by OpenKruise, which has a new instance update capability.

[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 YAML to Kubernetes where OpenKruise is deployed for microservice deployment.

[0224] b. Kubernetes receives a request to create a new AdvancedStatefulset and notifies OpenKruise to start the microservice cluster.

[0225] c. OpenKruise starts AdvancedStatefulset;

[0226] AdvancedStatefulset actively sends registration information to the registry, or the registry actively scans to obtain registration information;

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

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

[0229] 2) Update of the instance to be updated

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

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

[0232] b. The update component uses the microservice cluster information to find the actual location of the specific microservice cluster in the registration center;

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

[0234] d. After the update component determines the instance to be updated based on the status information, it can submit the workload type information of the instance to be updated to the plug-in center;

[0235] e. The plugin center returns the target plugin. The update component connects to OpenKruise through the target plugin and updates the label of the OpenKruise microservice instance and the priority definition of the label to mark the instance to be updated with the label.

[0236] f. After OpenKruise monitors and detects label changes on microservice instances, it performs the actual update operation.

[0237] 3. Microservice Cluster Update in Virtualization Scenario

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

[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 a virtualized cluster;

[0242] b. The virtualized cluster starts the microservice cluster;

[0243] c. The virtual machine type workload in the virtualization cluster registers information with the registration center;

[0244] d. During the operation of the microservice cluster, the status information of the microservice instance is reported to the state perception component;

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

[0246] 2) Update of the instance to be updated

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

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

[0249] b. The update component uses the microservice cluster information to find the actual location of the specific microservice cluster in the registration center;

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

[0251] d. After the update component determines the instance to be updated based on the status information, it can submit the workload type information of the instance to be updated to the plug-in center;

[0252] e. The plug-in center returns the target plug-in, and the update component accesses the virtualization cluster through the target plug-in to perform 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 embodiment of the present application from multiple aspects. The following describes the microservice instance update system provided by the embodiment of the present application in conjunction with the accompanying drawings.

[0254] As shown in FIG8 , an embodiment of the present application provides a microservice instance update system 80 , which includes a communication interface 801 , a plug-in center 802 , and an update component 803 ;

[0255] The communication interface 801 is used to obtain an update request, where the update request indicates that a microservice cluster is to be updated, and the microservice cluster includes multiple microservice instances;

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

[0257] The plug-in center 802 is used to determine a target plug-in from multiple plug-ins included in the plug-in center according to the workload type of the instance to be updated, wherein different plug-ins in the multiple plug-ins are used to provide interfaces for updating microservice instances of different workload types, and the target plug-in is used to provide an interface for updating microservice instances of the workload type of the instance to be updated;

[0258] The update component 803 is used to call the target plug-in so that the target plug-in can access the running environment of the instance to be updated to update the instance to be updated.

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

[0260] Optionally, the update component 803 is used to:

[0261] Get the status information of each microservice instance in multiple microservice instances;

[0262] According to the status information of each microservice instance, an instance to be updated is determined from multiple microservice instances.

[0263] Optionally, the multiple microservice instances in the microservice cluster include a microservice instance serving as a master instance and a microservice instance serving as a slave instance, and the state 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 and an update order of each instance to be updated from multiple microservice instances, wherein, among the multiple instances to be updated, the update order of the microservice instance serving as a slave instance precedes the update order of the microservice instance serving as a master instance.

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

[0266] The updating component 803 is used to determine, from multiple microservice instances, a microservice instance whose running state is idle as an instance to be updated.

[0267] Optionally, the state 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 quantity threshold.

[0269] In an embodiment of the present application, a module is used as an example of a software functional unit, and 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, and other computing devices. Furthermore, the above-mentioned 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 available zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0270] Similarly, the 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 located within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the 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 be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex PLD (CPLD), an off-the-shelf programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0272] The multiple computing devices included in the microservice instance update system can be distributed in the same region or in different regions. The multiple computing devices included in the microservice instance update system can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the microservice instance update system can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[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 plug-in center can be used to execute any step in the microservice instance update method. The steps that the communication interface, update component, and plug-in center are responsible for implementing can be specified as needed. The full functions of the microservice instance update system are realized by respectively implementing different steps in the microservice instance update method through the communication interface, update component, and plug-in center.

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

[0275] Bus 92 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG9 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 94 may include a pathway for transmitting information between various components of computing device 90 (e.g., memory 96, processor 94, and communication interface 98).

[0276] The 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, a hard disk drive (HDD), or a solid state drive (SSD).

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

[0279] The communication interface 98 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 90 and other devices or a communication network.

[0280] Embodiments of the present application also provide 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 in one or more computing devices 90 in the computing device cluster may store the same instructions for executing the microservice instance update method.

[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, the 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 in the computing device cluster can store different instructions, each for executing a portion of the functions of the microservice instance update method. In other words, the instructions stored in the memory 96 in different computing devices 90 can implement the functions of one or more modules in the communication interface, update component, and plug-in center.

[0284] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network or a local area network, etc. FIG11 shows a possible implementation. As shown in FIG11 , two computing devices 90A and 90B are connected via a network. Specifically, the connection to the network is made via a communication interface in each computing device. In this type of possible implementation, the memory 96 in the computing device 90A may store instructions for executing the functions of the update component. At the same time, the memory 96 in the computing device 90B may store instructions for executing the functions of the plug-in center. Alternatively, the memory 96 in the computing device 90A may store instructions for executing part of the functions of the update component. At the same time, the memory 96 in the computing device 90B may store instructions for executing another part of the functions of the update component.

[0285] It should be understood that the functionality of the computing device 90A shown in FIG11 may also be accomplished by multiple computing devices 90. Similarly, the functionality of the computing device 90B may also be accomplished by multiple computing devices 90.

[0286] The present application also provides another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similar to the connection methods of the computing device clusters shown in Figures 10 and 11. However, the memory 96 in 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, the 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 in the computing device cluster can store different instructions for executing part of the functions of the microservice instance update method. In other words, the instructions stored in the memory 96 in different computing devices 90 can implement the functions of one or more modules in the communication interface, update component, and plug-in center.

[0289] Embodiments of the present application also provide a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored on any available medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute a microservice instance update method.

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

[0291] The present application also provides a chip system, which includes a processor configured to implement the steps performed by the computing device cluster. In one possible design, the chip system may also include a memory configured to store necessary program instructions and data. The chip system may be composed solely of a chip or may include a chip and other discrete components.

[0292] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned 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, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0294] Units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0295] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0296] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, 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, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

Claims

1. A microservice instance update method, characterized in that: Applied to a microservice instance update system, the system is set in at least one data center, the system includes a communication interface, a plug-in center and an update component, and the method includes: The communication interface obtains an update request, where the update request indicates to update a microservice cluster, where the microservice cluster includes multiple microservice instances; The update component determines, according to the update request, an instance to be updated from multiple microservice instances in the microservice cluster; The plug-in center determines a target plug-in from a plurality of plug-ins included in the plug-in center according to the workload type of the instance to be updated, wherein different plug-ins among the plurality of plug-ins are used to provide interfaces for updating microservice instances of different workload types, and the target plug-in is used to provide an interface for updating the microservice instance of the workload type of the instance to be updated; The update component calls the target plug-in; The target plug-in accesses the running environment of the instance to be updated to update the instance to be updated.

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

3. The method according to claim 1 or 2, characterized in that The system further includes a state awareness component, wherein the update component determines, based on the update request, an instance to be updated from multiple microservice instances in the microservice cluster, including: The state perception component obtains state information of each microservice instance in the multiple microservice instances; The update component determines an instance to be updated from the multiple microservice instances according to 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 serving as a master instance and a microservice instance serving as a slave instance, and the state information includes information indicating whether the microservice instance is a master instance or a slave instance; The update component determines an 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 and an update order of each of the instances to be updated from the multiple microservice instances, wherein, among the multiple instances to be updated, the update order of the microservice instance serving as a slave instance precedes the update order of the microservice instance serving as a master instance.

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, where the running status is used to indicate whether the microservice instance is running; The update component determines an instance to be updated from the multiple microservice instances based on the status information of each microservice instance, including: The update component determines, from the multiple microservice instances, a microservice instance whose running state is idle as an instance to be updated.

6. The method according to any one of claims 3 to 5, characterized in that The state 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 an instance to be updated from the multiple microservice instances based on the status information of each microservice instance, including: The update component determines a plurality of instances to be updated from the plurality of microservice instances, wherein the plurality of instances to be updated belong to at least two regions, and the number of the 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 arranged in at least one data center, and the system includes a communication interface, a plug-in center, and an update component; The communication interface is used to: obtain an update request, where the update request indicates to update a microservice cluster, where the microservice cluster includes multiple microservice instances; The update component is used to: determine an instance to be updated from multiple microservice instances in the microservice cluster according to the update request; The plug-in center is used to: determine from the multiple plug-ins included in the plug-in center according to the workload type of the instance to be updated A target plug-in, wherein different plug-ins among the multiple plug-ins are used to provide interfaces for updating microservice instances of different workload types, and the target plug-in is used to provide an interface for updating the microservice instance of the workload type of the instance to be updated; The update component is used to call the target plug-in so that the target plug-in accesses the running 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, and function.

9. The system according to claim 7 or 8, characterized in that The update component is used to: Obtaining status information of each microservice instance in the multiple microservice instances; An instance to be updated is determined from the multiple microservice instances according to the status information of each microservice instance.

10. The system according to claim 9, characterized in that The multiple microservice instances in the microservice cluster include a microservice instance serving as a master instance and a microservice instance serving as a slave instance, and the state 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 an update order of each of the instances to be updated from the multiple microservice instances, wherein, among the multiple instances to be updated, the update order of the microservice instance serving as a slave instance precedes the update order of the microservice instance serving 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, where the running status is used to indicate whether the microservice instance is running; The update component is used to determine, from the multiple microservice instances, a microservice instance whose running state is an idle state as an instance to be updated.

12. The system according to any one of claims 9 to 11, characterized in that: The state 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 a plurality of instances to be updated from the plurality of microservice instances, wherein the plurality of 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.

13. A computing device cluster, characterized in that: comprising at least one computing device, the at least one computing device comprising a processor and a memory; The processor is configured to execute instructions stored in the memory, so that the computing device cluster executes the method according to any one of claims 1 to 6.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program runs on a processor, the processor is enabled to perform the method according to any one of claims 1 to 6.

15. A computer program product comprising instructions, characterized in that When the instructions are executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images