Microservice orchestration method and apparatus, electronic device, and readable medium

Abstract

A microservice orchestration method and apparatus, electronic device, and readable medium, related to the technical field of data processing. The method includes: establishing (101) a first node in a first runtime for each microservice in a plurality of microservices, the first node being used to control execution of the microservice; receiving (102) a construction of a behavior tree by a user, the behavior tree including leaf nodes, the leaf nodes representing the microservices; parsing (103) the behavior tree, the leaf nodes being mapped to the first nodes; and generating an instance of the behavior tree.

Description

[Technical field]

[0001] TECHNICAL FIELD Embodiments of the present application mainly relate to the field of data processing technology, and in particular to a microservice orchestration method and apparatus, an electronic device, and a readable medium. [Background technology]

[0002] Microservices is an architecture and organization method for developing software, where the software is composed of small independent services that communicate through well-defined application programming interfaces (APIs). Microservices are a widely used architecture today. As the number of microservices increases, it becomes increasingly difficult to orchestrate microservices. Currently, microservices are orchestrated in a fixed order, and the execution of the corresponding workflow is performed within a service chain. However, when a service needs to be changed in the above manner or a new service needs to be introduced into the service chain, the related development and deployment become very cumbersome and complex.

[0003] Summary of the Invention The embodiments of the present application mainly provide a microservice orchestration method and apparatus, an electronic device, and a readable medium, for flexibly orchestrating different microservices.

[0004] A first aspect provides a microservice orchestration method comprising: establishing a first node in a first runtime for each of a plurality of microservices, the first node being configured to control execution of the microservice; receiving construction performed by a user on a behavior tree, the behavior tree including leaf nodes that represent the microservices; parsing the behavior tree, the leaf nodes being mapped to the first nodes; and generating an instance of the behavior tree.

[0005] A second aspect provides an electronic device comprising at least one memory configured to store computer readable code and at least one processor configured to invoke the computer readable code to perform steps of the method provided in the first aspect.

[0006] A third aspect provides a computer readable medium storing computer readable instructions which, when executed by a processor, cause the processor to perform the steps of the method provided in the first aspect.

[0007] A fourth aspect provides a microservice orchestration apparatus including components for performing the steps of the method provided in the first aspect.

[0008] The following drawings are intended merely to provide schematic illustrations and descriptions of embodiments of the present application and are not intended to limit the scope of the embodiments of the present application. [Brief description of the drawings]

[0009] [Figure 1] 1 is a flowchart of a microservice orchestration method according to an embodiment of the present application. [Diagram 2] FIG. 1 is a schematic diagram of a microservice orchestration method according to an embodiment of the present application. [Diagram 3] FIG. 2 is a schematic diagram of another microservice orchestration method according to an embodiment of the present application. [Figure 4] 1 is a schematic diagram of an electronic device according to an embodiment of the present application. [Diagram 5] FIG. 1 is a schematic diagram of a microservice orchestration apparatus according to an embodiment of the present application. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Next, the subject matter described herein will be discussed with reference to exemplary implementations. It should be understood that the discussion of the implementations is only intended to allow those skilled in the art to better understand and implement the subject matter described herein, and is not intended to limit the scope of protection of the claims, applicability, or examples. Changes may be made in the function and arrangement of the elements discussed without departing from the scope of protection of the contents of the embodiments of this application. Various processes or components may be omitted, replaced, or added in each example according to requirements. For example, the described method may be performed according to an order different from that described herein, and steps may be added, omitted, or combined. In addition, features described in some examples may be combined in other examples.

[0011] As used herein, the term "comprises" and variations thereof are open ended and mean "including, but not limited to." The term "based on" means "based at least in part on." The terms "one embodiment" and "an embodiment" mean "at least one embodiment." The term "another embodiment" means "at least one other embodiment." The terms "first," "second," etc. may refer to different objects or the same object. Other definitions may be included below, either explicitly or implicitly. Unless otherwise stated, the definition of a term is consistent throughout the specification.

[0012] Embodiments of the present application will be described below with reference to the drawings.

[0013] 1 is a flowchart of a microservice orchestration method according to an embodiment of the present application. As shown in FIG. 1, the microservice orchestration method 100 includes the following steps:

[0014] Step 101: Establish a first node within a first runtime for each of a plurality of microservices, where the first node is configured to control execution of the microservice.

[0015] The first node communicates with the corresponding microservice via a RESTful application programming interface (API) or a remote procedure call (RPC) API. Optionally, as shown in Figure 2, the first node I, the first node II, and the first node III in the first runtime are configured to control the execution of the corresponding microservices, respectively. The first node I controls the execution of microservice I, the first node II controls the execution of microservice II, and the first node III controls the execution of microservice III.

[0016] Step 102: Receive a construction performed by a user on a behavior tree, where the behavior tree includes a first leaf node, the first leaf node representing a corresponding microservice, the first leaf node being a behavior node.

[0017] A behavior tree is a formalized graphical modeling language that explicitly represents hundreds or thousands of natural language requirements by well-defined symbols. The requirements are usually used to express the demands of users of large-scale software integration systems. The execution order of each node is usually defined in the behavior tree. As shown in FIG. 2, a user may create a corresponding behavior tree according to the demands for the actual control logic. Optionally, the first leaf node may include a name or identifier of the function of the corresponding microservice. Optionally, multiple leaf nodes may be created in the behavior tree according to specific requirements corresponding to different functions of the same microservice or corresponding to different microservices. Optionally, when a configuration operation performed by a user on the first leaf node is received or according to a pre-setting configuration operation of the system, if the configuration includes a parameter related to the execution of the corresponding microservice, the execution of the corresponding microservice may be controlled via the corresponding first node according to the specific configuration when the first leaf node is checked. In one embodiment, it is assumed that the function of the microservice is to grasp component A. In detail, according to the calling rules defined for the microservice, including the types and parameters of the allowable request messages, such as gripping strength, moving speed, and moving position, the user inputs the specific configuration requirements into the corresponding leaf node. When the first leaf node is checked, the corresponding first node establishes the corresponding request information. The request information includes the parameters for gripping the component A after the microservice receives the corresponding request information. In one embodiment, for example, in the field of industrial control, an associated operation technology (OT) device connected to the first runtime may be controlled to perform a specific operation in response to the configuration operation performed by the user. In one embodiment, the microservice includes a runtime. The corresponding OT device may be directly controlled via the runtime in the microservice to perform a specific operation in response to the configuration operation performed by the user.

[0018] Step 103: Parse the behavior tree, where the first leaf node is mapped to the first node.

[0019] In particular, the control logic in the behavior tree may be sent to a first runtime to analyze the control logic in the behavior tree. Optionally, the destination address of the first leaf node, i.e., the address and configuration information of the target device, may be mapped to the first node in the first runtime according to the name or identifier of the function of the corresponding microservice contained in the leaf node.

[0020] Step 104: An instance of the behavior tree is generated.

[0021] The behavior tree may be instantiated via a first runtime, the first runtime being configured to deploy control logic in the behavior tree. Optionally, the first runtime deploys the control logic of an associated leaf node to a corresponding target device according to a destination address of the associated leaf node in the behavior tree.

[0022] In this embodiment of the present application, corresponding nodes are established to control the execution of different microservices, and then the established nodes are mapped to corresponding leaf nodes in the behavior tree, so that the definition of the control logic in the behavior tree is fully used to orchestrate different microservices. The coupling degree between different microservices is greatly reduced, and the logical coupling relationship is decoupled for the behavior tree. Because the logical processing of the behavior tree follows its checking algorithm, the business coupling degree between the product designer and the developer is greatly reduced. During the construction of a new service, the product designer realizes the maximum re-orchestration of the microservice by building different behavior trees that do not require secondary development of the microservice. The rapid development and deployment of the new service can be realized only by the visual definition and construction of the behavior tree. The product developer only needs to develop abundant related nodes such as code blocks or classes according to the interface of the microservice without needing to pay attention to the specific service coupling logic. During the service upgrade, if no new microservices and API changes or new API introductions are involved, the product designer only needs to upgrade the logic of the behavior tree. When only the optimization of a microservice is involved and no API changes are involved, only a single-point upgrade needs to be performed on the corresponding microservice. When API changes are involved, the microservice and orchestration policy may be upgraded separately. Therefore, the embodiment of the present application can greatly reduce labor costs.

[0023] In one embodiment, an operating interface is provided that allows a user to create and update a corresponding behavior tree. During the execution of a workflow, the nodes of the currently executing behavior tree are displayed on the operating interface in a pre-configured annotation manner, allowing the user to learn the execution progress and status.

[0024] In one embodiment, FIG. 3 is a schematic diagram of another microservice orchestration method in which at least one behavior subtree may be connected to a primary behavior tree before an instance of the behavior tree is generated, as shown in FIG. 3. The distributed deployment is executed in a second runtime connected to the at least one behavior subtree and a first runtime connected to the primary behavior tree. The first runtime is connected to the second runtime such that the first runtime controls the execution of the second runtime. A corresponding second node is established in the second runtime for each of all behavior nodes in the behavior subtree of the at least one behavior subtree. The behavior node defines the behavior of the OT device such that when a behavior node in the behavior subtree is checked, the corresponding OT device is controlled by the second node. Optionally, the communication between the primary behavior tree and the behavior subtree may be established via an RPC standard.

[0025] In one embodiment, in a scenario of monitoring objects on a conveyor belt, a first behavior subtree for image recognition may be communicated with a runtime installed on computing device A to control an associated OT device to complete an image recognition operation. A second behavior subtree for object detection is communicated with a runtime installed on computing device B to control an associated OT device to complete object detection.

[0026] Optionally, at least one second node may be connected to the microservices in a second runtime, whereby the second node controls the execution of the microservices, i.e., the microservices may be invoked in either the primary behavior tree or the behavior subtree.

[0027] Optionally, the leaf nodes may be determined from the primary behavior tree, where the leaf nodes are configured to control the execution of the behavior subtrees. A root node of each of the at least one behavior subtree is connected to a corresponding leaf node in the primary behavior tree. The root node of each of the at least one behavior subtree may be communicated with the corresponding leaf node in the primary behavior tree via a RESTful API or an RPC API.

[0028] With the emergence of open distributed industrial control systems, more and more complex control logics are deployed on distributed systems and divided into different function blocks that communicate with IP network technology. This embodiment of the present application is consistent with current distributed development. Since the behavior subtrees are connected to the primary behavior tree and are respectively connected to different runtimes in distributed deployment, there is no need to fully develop the existing software, and only the newly added behavior tree design part needs to be deployed. In this embodiment of the present application, program design is separated from development. When a new behavior subtree needs to be added to the original behavior tree, the new behavior tree is deployed at runtime without the need to stop the execution of other original programs. The reconfiguration or reconstruction of the control logic is more efficient and flexible, saving enormous capital and human resources. In addition, distributed deployment also reduces the requirements for the computing power of the device. A user may deploy a control logic with high timeliness requirements on the site and a control logic with low timeliness requirements on the cloud.

[0029] An embodiment of the present application further provides an electronic device 400. FIG. 4 is a schematic diagram of the electronic device 400 according to an embodiment of the present application. As shown in FIG. 4, the electronic device 400 includes a processor 401 and a memory 402. The memory 402 stores instructions. The instructions, when executed by the processor 401, perform the above-mentioned method 100. The at least one processor 401 may include a microprocessor, an application specific integrated circuit (ASIC), a digital signal processor (DSP), a central processing unit (CPU), a graphic processing unit (GPU), a state machine, etc. An embodiment of a computer readable medium includes, but is not limited to, a floppy disk, a CD-ROM, a disk, a memory chip, a ROM, a RAM, an ASIC, a configured processor, all optical media, all tape or other magnetic media, or any other medium from which a computer processor can read instructions. In addition, various other forms of computer readable media may transmit or carry instructions to a computer, including a router, a private or public network, or other wired and wireless transmission device or channel. The instructions may include code from any computer programming language, including C, C++, C++, Visual Basic, Java, and JavaScript.

[0030] 5 is a schematic diagram of a microservice orchestration apparatus 50 according to an embodiment of the present application. As shown in FIG. 5, the microservice orchestration apparatus 50 includes: an establishment module 51 configured to establish a first node in a first runtime for each of a plurality of microservices, the first node being configured to control execution of the microservice; a receiving module 52 configured to receive a construction performed by a user on a behavior tree, the behavior tree including leaf nodes, the leaf nodes representing corresponding microservices; a parsing module 53 configured to parse the behavior tree, where a leaf node is mapped to a first node; and an instantiation module 54 configured to generate an instance of the behavior tree.

[0031] In addition, an embodiment of the present application further provides a computer-readable medium, which stores computer-readable instructions. When executed by a processor, the computer-readable instructions cause the processor to execute the above-mentioned microservice orchestration method. An embodiment of the computer-readable medium includes a floppy disk, a hard disk, a magneto-optical disk, an optical disk (CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, or DVD+RW), a magnetic tape, a non-volatile memory card, and a ROM. Optionally, the computer-readable instructions may be downloaded from a server computer or a cloud via a communication network.

[0032] It should be noted that not all steps and modules in the above process and system structure diagrams are necessary, and some steps or modules may be omitted according to actual requirements. The execution order of the steps is not fixed and may be adjusted as necessary. The system structure described in the embodiment may be a physical structure or a logical structure. That is, some modules may be implemented by the same physical entity, or some modules may be implemented by multiple physical entities, or may be jointly implemented by several components in multiple independent devices. [Explanation of symbols]

[0033] 100 Microservice Orchestration Methods 101~104 Method steps 400 Electronic Devices 401 Processor 402 Memory 50 Microservice Orchestration Device 51 Establishment Module 52 Receiving module 53 Syntax Analysis Module 54 Instantiation Module

Claims

1. A microservice orchestration method, comprising: Establishing (101) a first node within a first runtime for each of a plurality of microservices, the first node being configured to control execution of the microservice; receiving (102) a construction performed by a user on a behavior tree, the behavior tree including leaf nodes, the leaf nodes representing the microservices; parsing (103) the behavior tree, wherein the leaf nodes are mapped to the first nodes; creating an instance of the behavior tree (104); Microservices orchestration methods, including:

2. 2. The method of claim 1, wherein the first node communicates with the corresponding microservice via a RESTful application programming interface (API) or a remote procedure call (RPC) API.

3. After the step (102) of receiving a construction performed on a behavior tree by a user, the method further comprises: configuring the leaf node such that the execution of the corresponding microservice is controlled via the first node according to the configuration when the leaf node is checked; The method of claim 1 further comprising:

4. Prior to the step of instantiating (104) the behavior tree, the method further comprises: connecting at least one behavior subtree to the behavior tree; performing a distributed deployment on a second runtime connected to the at least one behavior subtree and on the first runtime connected to the behavior tree; connecting the first runtime to the second runtime such that the first runtime controls execution of the second runtime; 2. The method of claim 1, further comprising: for each of all behavior nodes in a behavior subtree of the at least one behavior subtree, establishing a corresponding second node in the second runtime, the behavior node defining an operation of an operation technology (OT) device, whereby the corresponding OT device is controlled via the second node when the behavior node in the behavior subtree is checked.

5. After the step of establishing a corresponding second node in the second runtime, the method further comprises: Connecting at least one second node to the microservice within the second runtime, whereby the second node controls execution of the microservice. The method of claim 4 further comprising:

6. said step of connecting said at least one behavior subtree to said behavior tree further comprising: determining a leaf node from the behavior tree, the leaf node configured to control execution of a behavior subtree; connecting a root node of each of the at least one behavior subtree to a corresponding leaf node in the behavior tree; The method of claim 4 , comprising:

7. said step of connecting a root node of each of said at least one behavior subtree to a corresponding leaf node in said behavior tree, communicating the root node of each of the at least one behavior subtree with the corresponding leaf node in the behavior tree via a RESTful API or an RPC API; The method of claim 6, comprising:

8. 8. An electronic device comprising a processor (401) and a memory (402), the memory (402) storing computer readable instructions which, when executed by the processor (401), perform a method according to any one of claims 1 to 7.

9. A computer readable storage medium storing computer readable instructions which, when executed, perform a method according to any one of claims 1 to 7.

10. A microservice orchestration device, an establishment module (51) configured to establish a first node in a first runtime for each of a plurality of microservices, the first node being configured to control execution of the microservice; a receiving module (52) configured to receive constructions performed by a user on a behavior tree, the behavior tree including leaf nodes, the leaf nodes representing the microservices; a parsing module (53) configured to parse the behavior tree, the leaf nodes being mapped to the first nodes; an instantiation module (54) configured to generate an instance of the behavior tree; A microservice orchestration device comprising:

Images