A computer-implemented method, system, and computer program for upgrading a sequence of microservices (upgrading a sequence of microservices in a cloud computing environment)
The method allows for seamless hot-upgrades of microservice sequences by determining the state of unexecuted components within a running sequence, addressing the inability of current cloud environments to handle such upgrades without disruption.
Patent Information
- Application Number
- JP2021208982
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2020-12-31
- Filing Date
- 2021-12-23
- Publication Date
- 2025-07-22
- Estimated Expiration
- 2041-12-23
AI Technical Summary
Current cloud computing environments lack the capability to support hot-upgrading sequences of microservices, leading to failures when attempting to upgrade sequences without stopping their execution.
A method and system for hot-upgrading microservice sequences by determining the state of unexecuted microservices or sub-sequences within a running sequence, allowing for seamless upgrades by ensuring only necessary components are upgraded in response to completion of upgrade states.
Enables seamless hot-upgrades of microservice sequences without disrupting ongoing operations, ensuring all microservices and sub-sequences are upgraded correctly and efficiently.
Smart Images

Figure 0007710798000007 
Figure 0007710798000008 
Figure 0007710798000009
Abstract
Description
Technical Field
[0001] The present invention generally relates to cloud computing, and more particularly to hot-upgrading a sequence of microservices in a cloud computing environment.
Background Art
[0002] Cloud computing is being used by many enterprises to deploy and host software applications. In a cloud computing environment, the functionality of an application may be separated and containerized or wrapped as microservices. A sequence of microservices provides a means of defining an ordered list of microservices or subsequences of microservices. One sequence can be invoked and a computing software solution can be performed.
Summary of the Invention
Problems to be Solved by the Invention
[0003] Current sequence processing units within existing cloud computing environments cannot support the functionality of hot-upgrading a sequence.
Means for Solving the Problems
[0004] The techniques presented in this specification enable hot upgrades of microservice sequences in a cloud computing environment. More specifically, the next microservice of a microservice sub-sequence within a running sequence is obtained in response to a message that calls the microservice or sub-sequence. The running microservice sequence includes at least one unexecuted microservice or sub-sequence to be hot-upgraded. The running microservice sequence is generated based on a sequence to be hot-upgraded that includes an ordered list of microservices or sub-sequences or both. This technique may include determining the state of the next microservice or sub-sequence. This technique may further include calling the next microservice or sub-sequence within the running sequence in response to the state of the next microservice or sub-sequence being upgrade complete.
[0005] One aspect of the present invention includes a computer-implemented method for upgrading a sequence of microservices, the method comprising: obtaining, by one or more processors, a next microservice or sub-sequence within a running sequence instance in response to a message for calling the next microservice or sub-sequence, wherein the running sequence instance includes at least one unexecuted microservice or sub-sequence to be hot-upgraded, and the running sequence instance is generated based on a sequence to be hot-upgraded that includes an ordered list of a plurality of microservices or sub-sequences; determining, by one or more processors, the state of the next microservice or sub-sequence within the running sequence instance; and calling, by one or more processors, the next microservice or sub-sequence within the running sequence instance in response to the state of the next microservice or sub-sequence being upgrade complete.
[0006] Another aspect of the present invention includes a computer system for upgrading a sequence of microservices, the system comprising a processing unit and a memory coupled to the processing unit for storing instructions, which when executed by the processing unit, obtain the next microservice or sub-sequence within the running sequence instance in response to a message calling the next microservice or sub-sequence, wherein the running sequence instance includes at least one unexecuted microservice or sub-sequence to be hot-upgraded, the running sequence instance is generated based on a sequence to be hot-upgraded that includes an ordered list of a plurality of microservices or sub-sequences, the obtaining, determining the state of the next microservice or sub-sequence within the running sequence instance, and in response to the state of the next microservice or sub-sequence being upgrade complete, performing operations including calling the next microservice or sub-sequence within the running sequence instance.
[0007] Yet another aspect of the present invention includes a computer program product for upgrading a sequence of microservices, the computer program product comprising a computer-readable storage medium having program instructions embodied thereon, the program instructions being to obtain a next microservice or subsequence within a running sequence instance in response to a message calling the next microservice or subsequence, wherein the running sequence instance includes at least one unexecuted microservice or subsequence to be hot-upgraded, the running sequence instance being generated based on a sequence to be hot-upgraded that includes an ordered list of a plurality of microservices or subsequences, the obtaining, determining a state of the next microservice or subsequence within the running sequence instance, and calling the next microservice or subsequence within the running sequence instance in response to the state of the next microservice or subsequence being upgrade complete, and being executable by a processor to cause the processor to perform operations including the above.
[0008] Furthermore, any of the components of the present invention can be deployed, managed, serviced, etc. by a service provider attempting to implement an upgrade of a sequence of microservices within a computer system.
[0009] Embodiments of the present invention also provide related systems, methods, or program products, or combinations thereof.
Brief Description of the Drawings
[0010] These and other features of the present invention will be more readily understood from the following detailed description of the various aspects of the present invention taken in conjunction with the accompanying drawings.
[0011]
Figure 1
[0012]
Figure 2
[0013]
Figure 3
[0014]
Figure 4a
Figure 4b
Figure 4c
Figure 4d
[0015]
Figure 5
[0016]
Figure 6a
Figure 6b
Figure 6c
[0017]
Figure 7
[0018]
Figure 8a
Figure 8b
Figure 8c
[0019]
Figure 8d
Figure 8e
Figure 8f
[0020]
Figure 9
[0021] The drawings are not necessarily to scale. The drawings are merely illustrative and are not intended to depict specific parameters of the present invention. The drawings are intended to depict only typical embodiments of the present invention and should not therefore be considered as limiting the scope. In the drawings, like numbers represent like elements.
Embodiments for Carrying Out the Invention
[0022] Here, embodiments of the present invention will be described in detail with reference to the accompanying drawings.
[0023] The following description, with reference to the accompanying drawings, is presented to assist in a comprehensive understanding of exemplary embodiments of the invention defined by the claims and their equivalents. For the purpose of aiding that understanding, the description includes various specific details, which should be regarded merely as examples. Accordingly, those skilled in the art will understand that various changes and modifications to the embodiments described herein can be made without departing from the scope and spirit of the invention. Further, descriptions of well-known functions and structures may be omitted for clarity and conciseness.
[0024] The terms and words used in the following description and claims are not limited to bibliographical meanings, but are used only to enable a clear and consistent understanding of the invention. Accordingly, it should be apparent to those skilled in the art that the following description of exemplary embodiments of the invention is presented for explanatory purposes only and not for the purpose of limiting the invention defined by the appended claims and their equivalents.
[0025] It is to be understood that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to "a component surface" includes reference to one or more such surfaces unless the context clearly dictates otherwise.
[0026] This disclosure includes a detailed description of cloud computing, but it should be understood that the implementation of the teachings recited herein is not limited to a cloud computing environment. Rather, embodiments of this disclosure can be implemented in conjunction with any other type of computing environment now known or later developed.
[0027] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.
[0028] The characteristics are as follows.
[0029] On-demand self-service: Cloud consumers can provision computing capabilities such as server time and network storage automatically, on their own, without the need for human interaction with the service provider.
[0030] Broad network access: The capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin-client platforms or thick-client platforms (e.g., mobile phones, laptops, and PDAs).
[0031] Resource pooling: Provider computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to demand. Consumers generally have no control or knowledge over the exact location of the provided resources, but there is location independence in that they can specify the location at a higher level of abstraction (e.g., country, state, or data center).
[0032] Rapid elasticity: The functionality is fast and elastic, and in some cases is automatically provisioned to scale out quickly and can also be quickly released to scale in quickly. To consumers, the available functionality often appears to be unlimited, and they can purchase any amount at any time.
[0033] Measured services: The cloud system automatically controls and optimizes resource usage by leveraging measurement capabilities at an abstraction level appropriate for the type of service (e.g., memory, processing, bandwidth, and active user accounts). It can monitor, control, and report resource usage to provide transparency to both providers and consumers of the services being utilized.
[0034] The service model is as follows.
[0035] Software as a Service (SaaS): The functionality provided to consumers is to use the provider's applications that run on the cloud infrastructure. These applications are accessible from various client devices via a thin-client interface such as a web browser (e.g., web-based email). With limited exceptions for user-specific application configuration settings, consumers do not manage or control the underlying cloud infrastructure, which includes the network, servers, operating systems, storage, or even individual application functionality.
[0036] Platform as a Service (PaaS): The function provided to consumers is to deploy the applications created or obtained by consumers in the cloud infrastructure, which are created using the programming languages and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage devices, but have control over the deployed applications and, in some cases, the applications that host the environment configuration.
[0037] Infrastructure as a Service (IaaS): The function provided to consumers is to provision other basic computing resources that allow consumers to deploy and run processing, storage devices, networks, and any software that may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but have control over the operating systems, storage devices, the right to control the deployed applications, and, in some cases, limited control over selected networking components (e.g., host firewalls).
[0038] The deployment models are as follows.
[0039] Private cloud: The cloud infrastructure operates only for a certain organization. The private cloud is managed by that organization or a third party and can exist on-premises or off-premises.
[0040] Community cloud: The cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). The community cloud is managed by those organizations or a third party and can exist on-premises or off-premises.
[0041] Public cloud: The cloud infrastructure is available for the general public or large industry groups and is owned by an organization that sells cloud services.
[0042] Hybrid cloud: The cloud infrastructure is a composition of two or more clouds (private, community, or public), and these clouds remain as distinct entities but are coupled by standard or proprietary technologies (such as cloud bursting for load balancing between clouds) that enable data and application portability.
[0043] The cloud computing environment is service-oriented, focusing on statelessness, low coupling, modularity, and semantic interoperability. At the center of cloud computing is an infrastructure that includes a network of interconnected nodes.
[0044] Referring now to FIG. 1, a schematic diagram of an example of a cloud computing node is shown. Cloud computing node 10 is only one example of a suitable cloud computing node and does not suggest any limitation as to the use or functionality scope of the disclosed embodiments described herein. In any case, cloud computing node 10 is capable of implementing or executing or both of the above functions.
[0045] The cloud computing node 10 includes a computer system / server 12, or a portable electronic device such as a communication device, which can operate in a number of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments or configurations or combinations thereof that may be suitable for use with the computer system / server 12 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices.
[0046] The computer system / server 12 can be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. Generally, program modules can include routines, programs, objects, components, logic circuits, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system / server 12 can be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can be located in both a local computer system storage medium including a memory storage device and a remote computer system storage medium.
[0047] As shown in FIG. 1, the computer system / server 12 of the cloud computing node 10 is shown in the form of a general-purpose computing device. The components of the computer system / server 12 may include, but are not limited to, one or more processors or processing units 16, a system memory 28, and a bus 18 that couples various system components including the system memory 28 to the processor unit 16.
[0048] Bus 18 represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor bus or local bus that uses any of a variety of bus architectures. By way of example and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Extended ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.
[0049] The computer system / server 12 typically includes various computer system readable media. Such media can be any available media that is accessible by the computer system / server 12 and includes both volatile and nonvolatile media, removable and non-removable media.
[0050] System memory 28 may include a computer system readable medium in the form of volatile memory such as, but not limited to, random access memory (RAM) 30 or cache memory 32, or both. The computer system / server 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 34 may be provided for reading from and writing to a fixed, non-volatile magnetic medium (not shown but typically called a “hard drive”). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media may be provided. In such instances, each disk drive may be connected to the bus 18 by one or more data media interfaces. As will be further depicted and described below, memory 28 may include at least one program product having a set (at least one) of program modules configured to carry out the functions of embodiments of the present disclosure.
[0051] A program / utility 40 having a set (at least one) of program modules 42 may store in memory 28, by way of example and not limitation, an operating system, one or more application programs, other program modules, and program data, as well. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. The program modules 42 generally carry out the functions or methodologies of embodiments of the present disclosure as described herein.
[0052] The computer system / server 12 can also communicate with one or more external devices 14 such as a keyboard, a pointing device, a display 24, one or more devices that enable a user to interact with the computer system / server 12, or any device (e.g., a network card, a modem, etc.) that enables the computer system / server 12 to communicate with one or more other computing devices, or a combination thereof. Such communication can be carried out via the input / output (I / O) interface 22. Further, the computer system / server 12 can communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet) or a combination thereof, via the network adapter 20. As shown in the figure, the network adapter 20 communicates with other components of the computer system / server 12 via the bus 18. Although not shown, it should be understood that other hardware components or software components or both can be used in combination with the computer system / server 12. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems.
[0053] Next, referring to FIG. 2, a cloud computing environment 50 for illustration is shown. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, and these nodes can communicate with local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or a cellular phone 54A, a desktop computer 54B, a laptop computer 54C, or an automotive computer system 54N, or a combination thereof. The nodes 10 can communicate with each other. These nodes can be physically or virtually grouped into one or more networks, such as the private cloud, community cloud, public cloud, or hybrid cloud described above, or a combination thereof (not shown). By doing so, the cloud computing environment 50 can provide infrastructure, platform, software, or a combination thereof as a service that does not require cloud consumers to maintain resources on local computing devices. The types of computing devices 54A - N shown in FIG. 2 are only for illustration, and it should be understood that the computer nodes 10 and the cloud computing environment 50 can communicate with any type of computerized device via any type of network or network-addressable connection, or both (e.g., using a web browser).
[0054] Next, referring to FIG. 3, a set of functional abstraction layers provided by the cloud computing environment 50 (FIG. 2) is shown. It should be understood in advance that the components, layers, and functions shown in FIG. 3 are only for illustration, and the embodiments of the present disclosure are not limited thereto. As shown, the following layers and corresponding functions are provided.
[0055] The hardware and software layer 60 includes hardware components and software components. Examples of hardware components include mainframe 61, RISC (Reduced Instruction Set Computer) architecture-based server 62, server 63, blade server 64, storage device 65, and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.
[0056] The virtualization layer 70 provides an abstraction layer that can result in examples of the following virtual entities: virtual server 71, virtual storage device 72, virtual network 73 including a virtual private network, virtual applications and operating systems 74, and virtual client 75.
[0057] In one example, the management layer 80 can provide the following functions. Resource provisioning 81 performs the dynamic procurement of computing resources and other resources used to execute tasks within a cloud computing environment. Metering and pricing 82 performs cost tracking when resources are utilized within a cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources can include application software licenses. Security performs verification of cloud consumer and task identification information and protection of data and other resources. The user portal 83 provides access to the cloud computing environment to consumers and system administrators. Service level management 84 performs cloud computing resource allocation and management such that the required service level is met. Service level agreement (SLA) planning and fulfillment 85 performs pre-configuration and procurement of cloud computing resources for which requirements are expected in the future according to the SLA.
[0058] In the workload layer 90, examples of functions that can utilize a cloud computing environment are provided. Examples of workloads and functions that can be provided from this layer include mapping and navigation 91, software development and life cycle management 92, virtual classroom education delivery 93, data analysis processing 94, transaction processing 95, and sequence hot upgrade 96.
[0059] As described above, a sequence can be used to process the business process of a solution because the sequence provides a way to define an ordered list of microservices or subsequences or both that can be called, such as Knative Eventing on Kubernetes. In an existing cloud computing environment, microservices can be hot-upgraded, and thus sequences that include microservices are also hot-upgraded in the same way. However, current sequence processing units within an existing cloud computing environment cannot support the function of hot-upgrading sequences.
[0060] Figure 4a shows an existing exemplary business process 400A that includes a sequence Mortgate (Version 1.0, hereinafter abbreviated as V1) 401. The sequence Mortgate (V1) 401 defines three ordered microservices / subsequences, namely, microservice Request (V1) 4011, microservice Verification (V1) 4012, and subsequence Underwriting (V1) 4013. The subsequence Underwriting (V1) 4013 also defines three ordered microservices, namely, microservice 1st Approval (V1) 40131, microservice 2nd Approval (V1) 40132, and microservice Final Approval (V1) 40133. Figure 4c shows the hot-upgraded process 400C of the business process 400A. As shown in Figure 4c, when the microservice Verification (V1) 4012 and the microservice 1st Approval (V1) 40131 are hot-upgraded to the microservice Verification (V2) 4022 and the microservice 1st Approval (V2) 40231, the business process 400A can be changed to the process 400C. In this case, the sequence Mortgate (V1) 401 and the subsequence Underwriting (V1) 4013 must be hot-upgraded to the sequence Mortgate (V2) 402 and the subsequence Underwriting (V2) 4023, respectively.
[0061] As shown above, in the current cloud computing environment, the function of hot upgrade of sequences cannot be supported. In other words, if a sequence is forcibly hot-upgraded in the current cloud computing environment, a failure will occur in the instance of the sequence. The sequence Mortgate (V1) 401 and the sub-sequence Underwriting (V1) 4013 must be stopped so that they can be hot-upgraded to the sequence Mortgate (V2) 402 and the sub-sequence Underwriting (V2) 4023. FIG. 4b shows the hot upgrade process 400B of the business process 400A. As shown in FIG. 4b, if the sub-sequence Underwriting (V1) 4013 is not stopped, all running sequence instances may encounter an error 409 during the hot upgrade indicated by the business process 400B.
[0062] As shown in FIG. 4d, the process 400 is used to abstract the above business processes 400A / 400B / 400C. The Subsequence X 403 and the Subsequence Y 4033 are used to represent the above sequence Mortgate and the sub-sequence Underwriting respectively. The microservices A, B, D, E, F are used to represent the above microservices Request, Verification, 1st Approval, 2nd Approval and Final Approval respectively. Hereinafter, the present invention will be described by taking the process 400 as an example.
[0063] FIG. 5 shows a schematic diagram of an exemplary existing cloud computing environment 500 for processing sequences, the cloud computing environment 500 including a cloud master 501, an event processing unit 502, and a plurality of deployed microservices such as microservice A 5031, microservice B 5032, microservice D 5033, microservice E 5034, and microservice F 5035, which respectively represent microservices A, B, D, E, and F of the process 400 shown in FIG. 4. The cloud master 501 includes a controller manager 5011 and a data storage device 5012. The event processing unit 702 includes a receiver 5021, a dispatcher 5022, and a controller 5023.
[0064] A user 505 can send a request to the cloud computing environment 500 to edit the process 400 as Sequence X 403 in a definition file and input the definition file into the data storage device 5012. FIG. 6a shows an exemplary definition of Sequence X 403 including microservice A 5031, microservice B 5032, and Subsequence Y 4033. FIG. 6b shows an exemplary definition of Subsequence Y 4033 including microservice D 5033, microservice E 5034, and microservice F 5035. FIG. 6c shows an exemplary definition of a microservice, with only two microservices shown for simplicity. The three definitions shown in FIGS. 6a, 6b, and 6c jointly constitute an exemplary definition file of Sequence X 403. Those skilled in the art will understand that the exemplary definition files of Sequence X 403 shown in FIGS. 6a, 6b, and 6c are presented for illustrative purposes without implying any limitation, and other data structures or file types can be used as alternatives.
[0065] When the controller manager 5011 receives a request asking to input a definition file into the data storage device 5012, it can notify the controller 5023 to input the definition file of Sequence X 403 into the data storage device 5012. Next, the controller 5023 can analyze the definition file of Sequence X 403 and, using the data structure required by the data storage device 5012, input information corresponding to the definition file of Sequence X 403 into the data storage device 5012, which stores all the data processed by the cloud computing environment 500. Table 1 shows information on an exemplary definition file of Sequence X 403, including an ordered list of multiple microservices or sub-sequences or both using the table structure required by the data storage device 5012. The data structure shown in Table 1 is presented for illustrative purposes without implying any limitation, and it should be understood that other data structures are also applicable.
Table 1
[0066] After inputting the information of the definition file of Sequence X 403 402 into the data storage device 5012, when the controller 5023 receives a call request for Sequence X 403, it can generate a sequence instance based on the definition file of Sequence X 403. Next, the receiver and dispatcher can call each microservice or sub-sequence together according to the sequence definition to execute the sequence instance. For example, in the sequence instance, the receiver 5021 receives a message that is the output of the original microservice and the input of the next microservice, obtains the next microservice or sub-sequence from the sequence definition, and enables the dispatcher 5022 to call the next microservice or sub-sequence by sending the message to the dispatcher 5022.
[0067] In the existing cloud computing environment 500, it can be seen that hot upgrades of sequences cannot be supported.
[0068] FIG. 7 shows a schematic diagram of an exemplary cloud computing environment 700 proposed for hot upgrades of sequences, according to some embodiments of the present disclosure. In both FIGS. 5 and 7, similar components and corresponding components are referred to by similar reference numerals. In both FIGS. 5 and 7, two components with the same component name but different reference numerals also represent the same component, but it should be noted that this component is improved in FIG. 7 compared to the component in FIG. 5. Referring now to FIG. 7, the proposed exemplary cloud computing environment 700 may include a cloud master 501, an event processing unit 702, and a plurality of deployed microservices such as microservice A 5031, microservice B 5032, microservice D 5033, microservice E 5034, and microservice F 5035 for the above process 400, similar to FIG. 5. The cloud master 501 includes a controller manager 5011 and a data storage device 5012, similar to FIG. 5. The event processing unit 702 includes a receiver 5021, a dispatcher 7022, and a controller 7023. The dispatcher 7022 includes an instance manager 70221, a version manager 70222, and a checker 70223. The proposed cloud computing environment 700 can support hot upgrades of sequences, and the details will be described later using Sequence X 403 in FIG. 4c as an example. The same components in both FIGS. 5 and 7 have the same functions. As is known to those skilled in the art, each component in FIG. 7 is connected to each other by a communication network.
[0069] The communication network of FIG. 7 can include various types of communication networks such as a wide area network (WAN), a local area network (LAN), a telecommunications network, a wireless network, a public switched network or a satellite network or a combination thereof. The communication network can include connections such as wired, wireless communication links, or fiber optic cables.
[0070] Each component within the cloud computing environment 700 can be, for example, a mobile device, a telephone, a personal digital assistant, a netbook, a laptop computer, a tablet computer, a desktop computer, or any type of computing device that can execute a program and access a network. The cloud computing environment 700 can operate in a cloud computing service model such as Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS). The cloud computing environment 700 can also be installed within a cloud computing deployment model such as a private cloud, a community cloud, a public cloud, or a hybrid cloud.
[0071] User 505 can edit Sequence X 403 as a definition file that supports both a sequence version and a microservice version, and request the cloud computing environment 700 to input this definition file into the data storage device 5012. FIG. 8a shows a proposed exemplary definition of Sequence X 403 according to some embodiments of the present disclosure, which supports both a sequence version and a microservice version (indicated by the underlined words), and includes microservice A (V1), microservice B (V1), and Subsequence Y (V1). FIG. 8b shows a proposed exemplary definition of Subsequence Y according to some embodiments of the present disclosure, which supports both a sequence version and a microservice version (indicated by the underlined words), and includes microservice D (V1), microservice E (V1), and microservice F (V1). FIG. 8c is a diagram showing a proposed exemplary definition of a microservice that supports a microservice version (indicated by the underlined words), and only microservice B and microservice D are shown as examples for simplicity. The three definitions shown in FIGS. 8a, 8b, and 8c jointly constitute an improved definition file of Sequence X 403. Those skilled in the art will understand that FIGS. 8a, 8b, and 8c only show a proposed exemplary definition file of Sequence X 403 without suggesting any limitation, and other data structures or file types can be used as alternatives.
[0072] When the controller manager 5011 receives a request asking to input a definition file into the data storage device 5012, it can notify the controller 7023 to input an improved definition file of Sequence X 403 into the data storage device 5012. The controller 7023 can analyze the improved definition file of Sequence X 403 and, using the data structure required by the data storage device 5012, input information corresponding to the definition file of Sequence X 403 into the data storage device 5012. Table 2 shows information on an exemplary improved definition file of Sequence X 403 that uses the table structure required by the data storage device 5012. When compared with the information shown in FIG. 5, the improved definition file of Sequence X 403 includes both a sequence version and a microservice version. The data structure shown in Table 2 is presented for illustrative purposes without implying any limitation, and it should be understood that other data structures are applicable.
Table 2
[0073] After inputting the information of the improved definition file of Sequence X 403 into the data storage device 5012, when the controller 7023 receives a call request for Sequence X 403, it can generate a sequence instance based on the improved definition file of Sequence X 403. Next, the receiver and dispatcher can call each microservice or sub-sequence together according to the sequence definition to execute the sequence instance. For example, in the sequence instance, the receiver 5021 receives a message that is the output of the original microservice and the input of the next microservice, obtains the next microservice or sub-sequence from the sequence definition, and enables the dispatcher 7022 to call the next microservice or sub-sequence.
[0074] When multiple requests are received asking to invoke Sequence X403, multiple sequence instances can optionally be generated by controller 7023. Information about the multiple sequence instances, including the sequence instance ID, sequence name, currently running service, and the state of the sequence instance, can be obtained by instance manager 70221 and input into data storage device 5012. Table 3 shows exemplary information about multiple sequence instances within data storage device 5012. It should be understood that the data structure of Table 3 above is for illustrative purposes without implying any limitation, and other data structures may also be applicable.
Table 3
[0075] In some cases, user 505 may need a hot upgrade of Sequence X 403 and Subsequence Y 4033, and hot upgrades of microservice B 5032 (or 4032) and microservice D 5033 (or 40331) will be applied. In this way, the user can edit the upgrade definition file that supports the sequence version, microservice version, and upgraded policies for both microservices and sequences, and send a command to hot upgrade the sequence (this command can be defined as "$ kubectl apply -f upgrade.yaml" for Kubernetes' Knative Eventing where the upgraded definition file is named upgrade.yaml, etc.), and request the cloud computing environment 700 to execute the upgrade definition file.
[0076] There are two types of hot upgrade policies for both the microservices and sub-sequences included in the sequence to be hot-upgraded. One of the hot upgrade policies for microservices is "secured", which means that due to no version update, messages for the microservices must still be sent to the current version of the microservices. It can be seen that the microservices included in the sequence with the "secured" policy do not need to be hot-upgraded. Another hot upgrade policy for microservices is "migrated", which means that messages for the microservices must be sent to the new version of the microservices. It can be seen that the microservices included in the sequence with the "migrated" policy need to be hot-upgraded.
[0077] In addition, the hot upgrade policy "secured" for sub-sequences means that the sub-sequences running in the current version continue to run in the current version. It can be seen that the sub-sequences included in the sequence with the "secured" policy do not need to be hot-upgraded. Another hot upgrade policy for sub-sequences is "migrated", which means that the sub-sequences running in the current version should migrate to the new version in the relevant running sequence instance. It can be seen that the sub-sequences included in the sequence with the "migrated" policy need to be hot-upgraded. The "secured" policy is the first type of policy, and the "migrated" policy is the second type of policy. It should be noted that the terms "secured" and "migrated" are for illustrative purposes, and those skilled in the art can also use other words or numbers to represent these two types of policies.
[0078] FIG. 8d shows a proposed exemplary definition of Sequence X 403 to be hot-upgraded, which supports sequence version, microservice version, and hot-upgraded policy (indicated by underlined words), and includes microservice A (V1), microservice B (V2), and Subsequence Y (V2). Since the upgraded policy of Sequence X 403 includes microservice B and Subsequence Y that both need to be hot-upgraded, it can be seen that it is "migrated". The upgraded policy of microservice A (V1) is "secured", which means that microservice A (V1) does not need to be hot-upgraded. Here, the "secured" policy is omitted in the sequence definition file. Those skilled in the art can understand that the "secured" policy can also be written in the description shown in FIG. 8d. The reason why the hot-upgraded policy of microservice B (V2) is "migrated" is that microservice B needs to be hot-upgraded from V1 to V2, and then messages to microservice B (V1) need to be sent to microservice B (V2) in any sequence to be executed later. The upgraded policy of Subsequence Y is "migrated" and is described in detail in FIG. 8e.
[0079] Figure 8e shows an exemplary definition of Subsequence Y that needs to be hot-upgraded, which supports sequence version, microservice version, and hot-upgraded policy (indicated by underlined words), and includes microservice D (V2), microservice E (V1), and microservice F (V1). It can be seen that the upgraded policy of Subsequence Y is "migrated" because Subsequence Y contains microservice D that needs to be hot-upgraded. The upgraded policy of microservice D is "migrated" because microservice D needs to be hot-upgraded from V1 to V2, and then messages to microservice D (V1) need to be sent to microservice D (V2) in any subsequent sequence that is executed. The upgraded policies of both microservice D (V1) and E (V1) are "secured", which means that neither microservice D (V1) nor E (V1) needs to be hot-upgraded. Here again, the "secured" policy is omitted in the sequence definition file. Those skilled in the art can understand that the "secured" policy can also be written in the description shown in Figure 8e. Figure 8f shows an exemplary definition of microservices according to some embodiments of the present disclosure, which supports microservice version and upgraded policy (indicated by underlined words). Here, for the sake of brevity, only microservice B and microservice D are shown as examples in Figure 8f. The three upgrade definitions shown in Figures 8d, 8e, and 8f jointly constitute the upgraded definition file of Sequence X 403, such as the aforementioned upgrade.yaml file. Those skilled in the art will understand that Figures 8d, 8e, and 8f only show an exemplary upgraded definition file of Sequence X without implication and limitation, and other data structures or file types can also be used as alternatives.Those skilled in the art can understand that FIGS. 8d, 8e, and 8f using the hot upgrade policy are one implementation for determining the state of the next microservice or sub-sequence of the running sequence instance in the following description. Other types of definitions can also be used.
[0080] When a command for hot-upgrading a sequence is received in the cloud computing environment 700, the controller manager 7011 can notify the controller 7023 to input the hot upgrade definition file of Sequence X 403. The controller 7023 can parse the hot upgrade definition file of Sequence X 403 (for example, the upgrade.yaml file included in the command) and input information about the hot upgrade definition of Sequence X 403 into the data storage device 5012. Table 4 shows exemplary information about the hot upgrade definition file of Sequence X 403. Comparing with the information shown in FIG. 2, it can be seen that the sequence version of Subsequence Y should be updated from V1 to V2, the versions of microservices B and D should be updated from V1 to V2, and the upgraded policies of Subsequence Y and microservices B and D are included in Table 4. The data structure of Table 4 above is for illustrative purposes without implying any limitation, and it should be understood that other data structures can also be applied. [Table 4]
[0081] After the controller 7023 inputs the hot-upgraded definition of Sequence X 403 into the data storage device 7012, the instance manager 70221 can obtain at least one running sequence instance from a plurality of sequence instances (such as Table 3) generated in the data storage device 7012, which includes at least one unexecuted microservice / subsequence to be hot-upgraded (that is, at least one unexecuted microservice / subsequence with the hot-upgraded policy "migrated"). It can be seen that the query result in Table 3 is shown in Table 5. This is because the unexecuted Subsequence Y of the running Sequence_instance_2 has the hot-upgraded policy "migrated", and both the unexecuted microservice B and the unexecuted Subsequence Y of the running Sequence_instance_2 have the hot-upgraded policy "migrated".
Table 5
[0082] In some embodiments, instead of querying the result from Table 2 in the data storage device 5012, the instance manager 70221 can directly obtain at least one running sequence instance that includes at least one of the unexecuted microservices / subsequences to be hot-upgraded shown in FIG. 5 (that is, at least one of the unexecuted microservices / subsequences with the hot-upgraded policy being "migrated"). In other words, the information in Table 2 in the data storage device 5012 is optional.
[0083] In some embodiments, in response to a message that calls the next microservice or sub-sequence within the running sequence instance from the receiver 5021, the checker 70223 can determine whether the running sequence instance includes at least one unexecuted microservice / sub-sequence to be hot-upgraded. In some embodiments, this determination can be made by checking whether the running sequence instance is included in Table 5. In some embodiments, this determination can be made by directly tracking the definition of the sequence. If the checker 70223 determines that the running sequence instance includes at least one unexecuted microservice / sub-sequence to be hot-upgraded, the checker 70223 can obtain the currently called running service from Table 5 or the like, and then obtain the next microservice / sequence from the hot-upgrade definition of Sequence X 403 that includes an ordered list of a plurality of microservices or sub-sequences or both in the data storage device 5012. Thereafter, the checker can check whether the state of the next microservice / sequence is "upgrade completed".
[0084] In some embodiments, when a microservice should not be hot-upgraded, that is, when the upgraded policy of the microservice is "secured", the state of the microservice is determined to be "upgrade completed". That is, the microservice does not need to be updated and can continue to be called. Also, when a microservice needs to be hot-upgraded, that is, when the upgraded policy of the microservice is "migrated", and when the current version of the microservice is different from the required version, the state of the microservice is determined to be "upgrade incomplete", and when the current version of the microservice is the same as the required version, the state of the microservice is determined to be "upgrade completed". That is, when the microservice has not been hot-upgraded to the required version, the microservice cannot be called (for example, the state is "upgrade incomplete"), but when it has been hot-upgraded to the required version, the microservice can be directly called (for example, the state is "upgrade completed").
[0085] In some embodiments, when a sub-sequence does not need to be hot-upgraded, that is, when the upgraded policy of the sequence is "secured", the state of the sequence is determined to be "upgrade completed". That is, the sub-sequences included in the current version of the sequence are deployed and can continue to be called. Also, when a sub-sequence needs to be hot-upgraded, that is, when the upgraded policy of the sequence is "migrated", there are two solutions. In one solution, if the current version of the sub-sequence is the same as the required version, the state of the microservice or sub-sequence is determined to be "upgrade completed", and if the current version of the sub-sequence is different from the required version, the state of the sub-sequence is determined to be "upgrade incomplete". That is, the state of each microservice included in the sub-sequence contributes to the state of the sub-sequence. In another solution, if the current version of the sub-sequence is the same as the required version, the state of the sub-sequence is determined to be "upgrade completed"; if the current version of the sub-sequence is different from the required version and the current version of the first microservice in the sub-sequence is the same as the required version, the state of the sub-sequence is determined to be "upgrade completed"; if the current version of the sub-sequence is different from the required version and the current version of the first microservice in the sub-sequence is different from the required version, the state of the sub-sequence is determined to be "upgrade incomplete". That is, only the state of the first microservice among all the microservices included in the sub-sequence contributes to the state of the sub-sequence.
[0086] In some embodiments, the version manager 70222 can always check the current version of the microservices / subsequences deployed in the cloud computing environment, obtain information about the current version, required version, hot upgrade policy, and the status of each microservice / sequence included in the upgraded Sequence X as shown in Table 6 from information such as Tables 4 and 5, and input the information shown in Table 6 into the data storage device 5015. The status of each microservice / sequence / subsequence can be determined using the above-described method by the version manager 70222. Also, the information about the current version and the status of each microservice / sequence / subsequence included in the upgraded Sequence X can be updated periodically, such as every 1 millisecond. Next, when checking whether the status of the next microservice / sequence for a certain sequence instance is "upgrade completed", the checker 70223 can check the information in Table 6 below in the data storage device 5012 to determine the status of the next microservice / sequence of that sequence instance. [Table 6]
[0087] In some embodiments, when checking whether the state of the next microservice or sub-sequence of a certain sequence instance is "upgrade completed", the checker 70223 can check with the version manager 70222 to determine the state of the next microservice / sub-sequence of that sequence instance. The version manager 70222 can obtain information about the current version, required version, and hot-upgraded policy from information such as Table 4 and Table 5 stored in the data storage device 5012, and use the method described above to determine the state of each microservice / sub-sequence included in the upgraded Sequence X, and can feedback to the checker 70223.
[0088] In some embodiments, when the checker 70223 determines that the state of the next microservice or sub-sequence of the sequence instance is "upgrade completed", the dispatcher 7022 can dispatch the sequence instance to call the next microservice / sequence. When the state of the next microservice / sequence of the sequence instance is "upgrade not completed", the dispatcher 7022 can substantially continuously determine the state of the next microservice / sub-sequence of that sequence instance until the state of the next microservice / sub-sequence becomes "upgrade completed" for dispatching to the next microservice / sub-sequence.
[0089] In some embodiments, when the checker 70223 determines that the running sequence instance does not include the unexecuted microservice or subsequence to be hot-upgraded, the dispatcher 7022 can dispatch a sequence instance to directly call the next microservice / sequence. At this time, it can be determined that the hot upgrade of the running sequence instance is completed. If the hot upgrade of all running sequence instances is completed, it can be determined that the hot upgrade of that sequence is completed. For the newly generated sequence instance after the hot upgrade of the sequence is completed, the hot-upgraded sequence can be directly applied.
[0090] FIG. 9 shows a flowchart of an exemplary method 900 for hot-upgrading a sequence in a cloud computing environment according to some embodiments of the present disclosure. The method 900 can be implemented by the dispatcher 7022 of the event processing unit in FIG. 7 or by other suitable computer / computing systems. For ease of understanding, the method 900 will be described with reference to FIG. 7.
[0091] At 910, in response to a message for calling the next microservice / subsequence, the dispatcher 7022 can obtain the next microservice or subsequence in the running sequence instance, the running sequence instance includes at least one unexecuted microservice / subsequence to be hot-upgraded, and the running sequence instance is generated based on the hot-upgraded sequence including an ordered list of a plurality of microservices or subsequences or both.
[0092] At 920, the dispatcher 7022 can determine the state of the next microservice / subsequence.
[0093] At 930, the dispatcher 7022 can determine whether the state of the next microservice or sub-sequence is "upgrade completed".
[0094] At 940, in response to the state of the next microservice or sub-sequence being "upgrade completed", the dispatcher 7022 can call the next microservice or sub-sequence within the running sequence instance. Then, method 900 ends. Also, in response to the state of the next microservice / sub-sequence being "upgrade not completed", the dispatcher 7022 returns to 920 and can substantially continue to determine the state of the next microservice or sub-sequence until the state of the next microservice or sub-sequence becomes "upgrade completed".
[0095] Upon receiving the next message for calling the next microservice / sub-sequence, the dispatcher 7022 can re-execute method 900 to end the hot upgrade for all microservices / sub-sequences and for all running sequence instances.
[0096] In some embodiments, the state of a microservice or sub-sequence included in a sequence is determined based on at least one of the following. That is, (1) if the microservice / sub-sequence does not need to be hot-upgraded within the sequence, the state of the microservice / sub-sequence is determined to be "upgrade completed"; (2) if the microservice / sub-sequence needs to be hot-upgraded within the sequence and the current version of the microservice / sub-sequence is different from the required version, the state of the microservice / sub-sequence is determined to be "upgrade incomplete"; (3) if the microservice / sub-sequence needs to be hot-upgraded within the sequence and the current version of the microservice / sub-sequence is the same as the required version, the state of the microservice / sub-sequence is determined to be "upgrade completed".
[0097] In some embodiments, the state of a sub-sequence included in a sequence is determined based on at least one of the following. That is, (1) if the sub-sequence does not need to be hot-upgraded within the sequence, the state of the sub-sequence is determined to be "upgrade completed"; (2) if the sub-sequence needs to be hot-upgraded within the sequence and the current version of the sub-sequence is the same as the required version, the state of the sub-sequence is determined to be "upgrade completed"; (3) if the sub-sequence needs to be hot-upgraded within the sequence, the current version of the sub-sequence is different from the required version, and the current version of the first microservice in the sub-sequence is the same as the required version, the state of the sub-sequence is determined to be "upgrade completed"; (4) if the sub-sequence needs to be hot-upgraded within the sequence, the current version of the sub-sequence is different from the required version, and the current version of the first microservice in the sub-sequence is different from the required version, the state of the sub-sequence is determined to be "upgrade incomplete".
[0098] In some embodiments, obtaining the next microservice or sub-sequence to be called for the running sequence instance involves the dispatcher 7022 being able to obtain an ordered list of a plurality of microservices or sub-sequences of the sequence, or both. In this case, the dispatcher 7022 can determine whether the running sequence instance includes at least one unexecuted microservice / sub-sequence to be hot-upgraded. If so, the dispatcher 7022 obtains the microservice / sub-sequence currently being called in the running sequence instance, and further, based on the currently called microservice / sub-sequence and the ordered list, can obtain the next microservice / sub-sequence to be called in the running sequence instance.
[0099] In some embodiments, when the running sequence instance does not include an unexecuted microservice or sub-sequence to be hot-upgraded, the dispatcher 7022 can call the next microservice / sub-sequence within the running sequence instance. At this time, it can be determined that the hot upgrade of the running sequence instance is complete. In some embodiments, when the hot upgrade of all running sequence instances is complete, it can be determined that the hot upgrade of that sequence is complete.
[0100] In the proposed method, it is possible to enable a sequence to be hot-upgraded.
[0101] Note that the process of managing conditional parallel cloud services according to the embodiments of the present disclosure can be implemented by the computer system / server 12 of FIG. 1.
[0102] The present disclosure can be a system, method, or computer program product, or any combination thereof, where the integration is at any possible technical detail level. The computer program product can include one or more computer-readable storage media having computer-readable program instructions for causing a processor to execute aspects of the present disclosure.
[0103] The computer-readable storage media can be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage media can be, by way of example and not limitation only, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a punch card, a mechanically encoded device such as a raised structure in the form of grooves in which instructions are recorded, and any suitable combination of the foregoing. As used herein, a computer-readable storage media is not construed to be a transitory signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission media (e.g., an optical pulse traveling through an optical fiber cable), or an electrical signal transmitted through a wire.
[0104] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing / processing devices, or to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof). The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. The network adapter card or network interface of each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each computing / processing device.
[0105] Computer-readable program instructions for carrying out the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk® and C++, and procedural programming languages such as the “C” programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to the external computer for this connection (e.g., through the Internet via an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit for performing aspects of this disclosure.
[0106] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.
[0107] These computer-readable program instructions are provided to a processor of a computer or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified within the block(s) of the flowchart and / or block diagram and / or both. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, or other devices to function in a particular manner, such that the computer-readable storage medium storing the instructions comprises an article of manufacture including instructions which implement the aspects of the function / act specified in one or more blocks of the flowchart and / or block diagram and / or both.
[0108] These computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices, thereby producing a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowchart and / or block diagram and / or both.
[0109] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this context, each block in the flowchart or block diagram can represent a module, segment, or portion of instructions, and can include one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions shown within the block may occur out of the order shown in the figures. For example, two blocks shown in succession may, in fact, be accomplished as one step, executed simultaneously, substantially simultaneously, partially or wholly overlapping in time, or in some cases, the blocks may be executed in the reverse order depending on the functions involved. It should also be understood that each block of the block diagrams or flowchart diagrams, or combinations of blocks in the block diagrams or flowchart diagrams, can be implemented by a dedicated hardware-based system that performs a particular function or operation, or by a combination of dedicated hardware and computer instructions.
[0110] The descriptions of the various embodiments of the present disclosure are presented for purposes of illustration, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein were chosen to best explain the principles of the embodiments, the practical application, or technical improvements found in the marketplace, or to enable other ordinary skill in the art to understand the embodiments disclosed herein.
Description of Reference Numerals
[0111] 10 Cloud computing node 12 Computer system / server 14 External device 16 Processor or processing unit, processor unit 18 Bus 20 Network adapter 22 Input / Output (I / O) Interface 28 System Memory 30 Random Access Memory (RAM) 32 Cache Memory 34 Memory System 50 Cloud Computing Environment 54A Personal Digital Assistant (PDA) or Cellular Phone 54B Desktop Computer 54C Laptop Computer 54N Automotive Computer System 60 Hardware and Software Layers 61 Mainframe 62 Server 63 Server 64 Blade Server 65 Memory Device 66 Network and Networking Components 67 Network Application Server Software 68 Database Software 70 Virtualization Layer 71 Virtual Server 72 Virtual Memory Device 73 Virtual Network 74 Virtual Applications and Operating Systems 75 Virtual Client 80 Management Layer 81 Resource Provisioning 82 Measurement and Pricing 83 User Portal 84 Service Level Management 85 Service Level Agreement (SLA) Planning and Fulfillment 90 Workload Layer 91 Mapping and Navigation 92 Software Development and Lifecycle Management 93 Virtual Classroom Education Delivery 94 Data Analysis Processing 95 Transaction Processing 96 Sequence Hot Upgrade 400A Business Process 400B Hot Upgrade Process, Business Process 400C Hot - Upgraded Process, Business Process 401 Sequence Mortgate(Version 1.0), Sequence Mortgate(V1) 4011 Micro - service Request(V1) 4012 Micro - service Verification(V1) 4013 Sub - sequence Underwriting(V1) 40131 Micro - service 1st Approval(V1) 40132 Micro - service 2nd Approval(V1) 40133 Micro - service Final Approval(V1) 402 Sequence Mortgate(V2) 4022 Micro - service Verification(V2) 4023 Sub - sequence Underwriting(V2) 40231 Micro - service 1st Approval(V2) 403 Subsequence X 4032 Micro - service B 4033 Subsequence Y 40331 Micro - service D 409 Error 500 Cloud Computing Environment 501 Cloud Master 5011 Controller Manager 5012 Data Storage Device 502 Event Processing Unit 5021 Receiver 5022 Dispatcher 5023 Controller 5031 Micro Service A 5032 Micro Service B 5033 Micro Service D 5034 Micro Service E 5035 Micro Service F 505 User 702 Event Processing Unit 7021 Dispatcher 70221 Instance Manager 70222 Version Manager 70223 Checker 7023 Controller
Claims
1. A computer-implemented method for upgrading a sequence of microservices, comprising: in response to a message for invoking a next microservice or sub-sequence, obtaining, by one or more processors, the next microservice or sub-sequence within a running sequence instance, wherein the running sequence instance includes at least one unexecuted microservice or sub-sequence to be hot-upgraded, and the running sequence instance is generated based on a sequence to be hot-upgraded that includes an ordered list of a plurality of microservices or sub-sequences; determining, by the one or more processors, a state of the next microservice or sub-sequence within the running sequence instance; and invoking, by the one or more processors, the next microservice or sub-sequence within the running sequence instance in response to the state of the next microservice or sub-sequence being upgrade complete A computer-implemented method comprising the above steps.
2. The computer-implemented method further comprises: in response to the state of the next microservice or sub-sequence being upgrade incomplete, continuously determining, by the one or more processors, the state of the next microservice or sub-sequence until the state of the next microservice or sub-sequence is upgrade complete. The computer-implemented method according to claim 1.
3. The state of the next microservice or sub-sequence is such that the next microservice or sub-sequence does not need to be hot-upgraded within the sequence, and the state of the next microservice or sub-sequence is determined to be upgrade complete. The next microservice or sub-sequence needs to be hot-upgraded within the sequence, the current version of the next microservice or sub-sequence is different from the required version, and the state of the next microservice or sub-sequence is determined to be upgrade incomplete, and, The next microservice or sub-sequence needs to be hot-upgraded within the sequence, the current version of the next microservice or sub-sequence is the required version, and the state of the next microservice or sub-sequence is determined to be upgrade complete, The computer-implemented method according to claim 2, determined based on at least one of the above.
4. The state of the next sub-sequence is The next sub-sequence does not need to be hot-upgraded within the sequence, and the state of the next sub-sequence is determined to be upgrade complete, The next sub-sequence needs to be hot-upgraded within the sequence, the current version of the next sub-sequence is the required version, and the state of the next sub-sequence is determined to be upgrade complete, The next sub-sequence needs to be hot-upgraded within the sequence, the current version of the next sub-sequence is different from the required version, the current version of the first microservice within the next sub-sequence is the required version, and the state of the next sub-sequence is determined to be upgrade complete, and, The next sub-sequence needs to be hot-upgraded within the sequence, the current version of the next sub-sequence is different from the required version, the current version of the first microservice within the next sub-sequence is different from the required version, and the state of the next sub-sequence is determined to be upgrade incomplete, The computer-implemented method according to claim 2 or 3, determined based on at least one of the above.
5. The step of obtaining the next microservice or sub-sequence to be called for the running sequence instance is obtaining, by the one or more processors, the ordered list of the plurality of microservices or sub-sequences of the sequence; determining, by the one or more processors, whether the running sequence instance includes at least one unexecuted microservice / sub-sequence to be hot-upgraded, and in response to the running sequence instance including at least one unexecuted microservice or sub-sequence to be hot-upgraded, obtaining, by the one or more processors, the microservice or sub-sequence currently being invoked within the running sequence instance, and obtaining, by the one or more processors, the next microservice or sub-sequence to be invoked within the running sequence instance based on the currently invoked microservice or sub-sequence and the ordered list The computer-implemented method according to any one of claims 1 to 4. **Claim 6** The computer-implemented method further includes invoking, by the one or more processors, the next microservice or sub-sequence within the running sequence instance in response to the running sequence instance not including an unexecuted microservice or sub-sequence to be hot-upgraded. The computer-implemented method according to claim 5. **Claim 7** A system for upgrading a sequence of microservices, comprising a processing unit, and a memory storing instructions coupled to the processing unit wherein when the instructions are executed by the processing unit In response to a message that invokes the next microservice or sub-sequence, obtaining, within the running sequence instance, the next microservice or sub-sequence, where the running sequence instance includes at least one unexecuted microservice or sub-sequence to be hot-upgraded, and the running sequence instance is generated based on a sequence to be hot-upgraded that includes an ordered list of a plurality of microservices or sub-sequences, the obtaining, determining the state of the next microservice or sub-sequence within the running sequence instance, and, invoking the next microservice or sub-sequence within the running sequence instance in response to the state of the next microservice or sub-sequence being upgrade complete A system that performs operations including these.
8. The operations further include in response to the state of the next microservice or sub-sequence being upgrade incomplete, substantially continuously determining the state of the next microservice or sub-sequence until the state of the next microservice or sub-sequence becomes upgrade complete, The system according to claim 7.
9. The state of the next microservice or sub-sequence is such that the next microservice or sub-sequence does not need to be hot-upgraded within the sequence, and the state of the next microservice or sub-sequence is determined to be upgrade complete, such that the next microservice or sub-sequence needs to be hot-upgraded within the sequence, the current version of the next microservice or sub-sequence is different from the required version, and the state of the next microservice or sub-sequence is determined to be upgrade incomplete, and, The next microservice or sub-sequence needs to be hot-upgraded within the sequence, the current version of the next microservice or sub-sequence is the required version, and the state of the next microservice or sub-sequence is determined to be upgrade complete, The system according to claim 8, which is determined based on at least one of the above.
10. The state of the next sub-sequence is, The next sub-sequence does not need to be hot-upgraded within the sequence, and the state of the next sub-sequence is determined to be upgrade complete, The next sub-sequence needs to be hot-upgraded within the sequence, the current version of the next sub-sequence is the required version, and the state of the next sub-sequence is determined to be upgrade complete, The next sub-sequence needs to be hot-upgraded within the sequence, the current version of the next sub-sequence is different from the required version, the current version of the first microservice within the next sub-sequence is the required version, and the state of the next sub-sequence is determined to be upgrade complete, and, The next sub-sequence needs to be hot-upgraded within the sequence, the current version of the next sub-sequence is different from the required version, the current version of the first microservice within the next sub-sequence is different from the required version, and the state of the next sub-sequence is determined to be upgrade incomplete, The system according to claim 8 or 9, which is determined based on at least one of the above.
11. Obtaining the next microservice or sub-sequence to be called for the running sequence instance is, Obtaining the ordered list of the plurality of microservices or sub-sequences of the sequence, Determining whether the running sequence instance includes at least one unexecuted microservice / sub-sequence to be hot-upgraded, and, In response to the running sequence instance including at least one unexecuted microservice or sub-sequence to be hot-upgraded, obtaining the microservice or sub-sequence currently being called within the running sequence instance, and obtaining the next microservice or sub-sequence to be called within the running sequence instance based on the currently called microservice or sub-sequence and the ordered list The system according to any one of claims 7 to 10, comprising.
12. The operation further In response to the running sequence instance not including an unexecuted microservice or sub-sequence to be hot-upgraded, calling, by the one or more processors, the next microservice or sub-sequence within the running sequence instance. The system according to claim 11.
13. A computer program for upgrading a sequence of microservices, the processor A procedure for obtaining the next microservice or sub-sequence within a running sequence instance in response to a message for calling the next microservice or sub-sequence, wherein the running sequence instance includes at least one unexecuted microservice or sub-sequence to be hot-upgraded, and the running sequence instance is generated based on a sequence to be hot-upgraded including an ordered list of a plurality of microservices or sub-sequences, the procedure; A procedure for determining the state of the next microservice or sub-sequence within the running sequence instance; A procedure for calling the next microservice or sub-sequence within the running sequence instance in response to the state of the next microservice or sub-sequence being upgrade complete A computer program for causing execution.
14. The processor In response to the state of the next microservice or sub-sequence being upgrade-incomplete, a procedure for substantially continuously determining the state of the next microservice or sub-sequence until the state of the next microservice or sub-sequence becomes upgrade-complete The computer program according to claim 13, further causing the above to be executed
15. The state of the next microservice or sub-sequence is the next microservice or sub-sequence does not need to be hot-upgraded within the sequence, and the state of the next microservice or sub-sequence is determined to be upgrade-complete the next microservice or sub-sequence needs to be hot-upgraded within the sequence, the current version of the next microservice or sub-sequence is different from the required version, and the state of the next microservice or sub-sequence is determined to be upgrade-incomplete, and the next microservice or sub-sequence needs to be hot-upgraded within the sequence, the current version of the next microservice or sub-sequence is the required version, and the state of the next microservice or sub-sequence is determined to be upgrade-complete The computer program according to claim 14, wherein the determination is based on at least one of the above
16. The state of the next sub-sequence is the next sub-sequence does not need to be hot-upgraded within the sequence, and the state of the next sub-sequence is determined to be upgrade-complete the next sub-sequence needs to be hot-upgraded within the sequence, the current version of the next sub-sequence is the required version, and the state of the next sub-sequence is determined to be upgrade-complete the next sub-sequence needs to be hot-upgraded within the sequence, the current version of the next sub-sequence is different from the required version, the current version of the first microservice in the next sub-sequence is the required version, and the state of the next sub-sequence is determined to be upgrade-complete, and The next subsequence needs to be hot-upgraded within the sequence, the current version of the next subsequence is different from the required version, the current version of the first microservice within the next subsequence is different from the required version, and the state of the next subsequence is determined to be incomplete for upgrade. The computer program according to claim 14 or 15, determined based on at least one of the above.
17. The procedure for obtaining the next microservice or subsequence to be called for the running sequence instance. The procedure for obtaining the ordered list of the plurality of microservices or subsequences of the sequence. The procedure for determining whether the running sequence instance includes at least one unexecuted microservice or subsequence to be hot-upgraded, and In response to the running sequence instance including at least one unexecuted microservice or subsequence to be hot-upgraded, The procedure for obtaining the microservice or subsequence currently being called within the running sequence instance, and The procedure for obtaining the next microservice or subsequence to be called within the running sequence instance based on the currently called microservice or subsequence and the ordered list. The computer program according to any one of claims 13 to 16, including the above.
18. To the processor, In response to the running sequence instance not including an unexecuted microservice or subsequence to be hot-upgraded, the procedure for calling the next microservice or subsequence within the running sequence instance by the one or more processors. The computer program according to claim 17, further causing the above to be executed.
Citation Information
Patent Citations
Cross-platform application device, terminal and storage medium
CN110874236A
Micro-service-based processing method and device, storage medium and electronic device
CN111917838A
Service Pool Architecture For Multitenant Services To Support Canary Release
US20200065086A1