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 relate mainly 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 are 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, orchestrating them becomes increasingly difficult. Currently, microservices are orchestrated in a fixed order, and the execution of the corresponding workflow is carried out 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, for each of a plurality of microservices, a first node within a first runtime, the first node configured to control execution of the microservice; receiving constructions 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 the steps of the method provided in the first aspect.

[0006] A third aspect provides a computer-readable medium storing computer-readable instructions that, 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 a schematic illustration and description of embodiments of the present application and are not intended to limit the scope of the embodiments of the present application. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a flowchart of a microservice orchestration method according to an embodiment of the present application. [Figure 2] FIG. 1 is a schematic diagram of a microservice orchestration method according to an embodiment of the present application. [Figure 3] FIG. 1 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. [Figure 5] FIG. 1 is a schematic diagram of a microservice orchestration apparatus according to an embodiment of the present application. DETAILED DESCRIPTION OF THE INVENTION

[0010] Next, the subject matter described in this specification will be discussed with reference to exemplary implementations. It should be understood that the discussion of the implementations is intended merely to enable those skilled in the art to better understand and practice the subject matter described herein, and is not intended to limit the scope of the claims, applicability, or protection of the examples. Changes may be made to the function and arrangement of the discussed elements without departing from the scope of protection of the content 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 in 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 expressly or implicitly included below. Unless otherwise stated, the definition of a term will be 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 nodes communicate with the corresponding microservices via RESTful application programming interfaces (APIs) or remote procedure call (RPC) APIs. 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, and the first leaf node represents a corresponding microservice. The first leaf node is a behavior node.

[0017] A behavior tree is a formalized graphical modeling language that explicitly represents hundreds or thousands of natural language requirements with clearly defined symbols. Requirements are typically used to express user demands for large-scale software integration systems. The execution order of each node is typically defined in the behavior tree. As shown in FIG. 2, a user may create a corresponding behavior tree according to their requirements for the actual control logic. Optionally, a first leaf node may include the 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 different microservices. Optionally, when a configuration operation performed by a user on the first leaf node is received or according to a system pre-configuration operation, if the configuration includes parameters relevant to the execution of the corresponding microservice, the execution of the corresponding microservice may be controlled through the corresponding first node according to the specific configuration when the first leaf node is checked. In one embodiment, the function of the microservice is assumed to be to grasp component A. In particular, a user inputs specific configuration requirements into a corresponding leaf node according to a calling convention defined for the microservice, including allowable request message types and parameters such as grip strength, movement speed, and movement position. When a first leaf node is checked, the corresponding first node establishes corresponding request information. The request information includes parameters for gripping component A after the microservice receives the corresponding request information. In one embodiment, for example, in the field of industrial control, an associated operational technology (OT) device connected to the first runtime can be controlled to perform specific operations in response to the configuration operations performed by the user. In one embodiment, the microservice includes a runtime. The corresponding OT device can be directly controlled via the runtime within the microservice to perform specific operations in response to the configuration operations 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 for analyzing 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 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 control logic definition in the behavior tree is fully used to orchestrate different microservices. The degree of coupling between different microservices is greatly reduced, and logical coupling relationships are decoupled with respect to the behavior tree. The logical processing of the behavior tree follows its checking algorithm, significantly reducing the business coupling between product designers and developers. During the construction of new services, product designers can realize maximum re-orchestration of microservices by building different behavior trees that do not require secondary development of microservices. Rapid development and deployment of new services can be achieved solely through the visual definition and construction of behavior trees. Product developers need only develop abundant related nodes, such as code blocks or classes, according to the interfaces of microservices without paying attention to specific service coupling logic. During service upgrades, if new microservices and API changes or new API introductions are not involved, product designers only need to upgrade the logic of the behavior tree. When only microservice optimization 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 embodiments of the present application can significantly 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-defined annotation manner, allowing the user to learn the progress and status of the execution.

[0024] In one embodiment, FIG. 3 is a schematic diagram of another microservice orchestration method in which at least one behavior subtree can be connected to a primary behavior tree before an instance of the behavior tree is generated, as shown in FIG. 3. Distributed deployment is performed 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. Corresponding second nodes are established in the second runtime for each of all behavior nodes in the behavior subtree of the at least one behavior subtree. The behavior nodes define 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, communication between the primary behavior tree and the behavior subtrees 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, leaf nodes may be determined from the primary behavior tree, where the leaf nodes are configured to control the execution of 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, increasingly complex control logic is deployed on distributed systems and divided into different functional blocks that communicate over IP network technology. This embodiment of the present application is consistent with current distributed development. Because behavior subtrees are connected to the primary behavior tree and are connected to different runtimes in distributed deployment, there is no need to completely redevelop existing software; only the newly added behavior tree design portion 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 stopping the execution of the other original programs. Reconfiguring or rebuilding control logic is more efficient and flexible, saving enormous capital and human resources. In addition, distributed deployment also reduces the requirements for device computing power. Users may deploy control logic with high timeliness requirements on-site and 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. When executed by the processor 401, the instructions perform the above-described 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 graphics 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 within the 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 corresponding microservices; a parsing module 53 configured to parse the behavior tree, wherein leaf nodes are mapped to first nodes; and an instantiation module 54 configured to generate an instance of the behavior tree.

[0031] Additionally, an embodiment of the present application further provides a computer-readable medium storing computer-readable instructions that, when executed by a processor, cause the processor to perform the above-described 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 needed. The system structure described in the embodiments 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 Receiver Module 53 Parsing Module 54 Instantiation Module

Claims

1. A microservice orchestration method performed by a computer under the control of software, comprising: Establishing (101), by the computer, 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, by the computer, constructions performed by a user on a behavior tree (102), the behavior tree including leaf nodes, the leaf nodes representing the microservices; parsing (103) the behavior tree by the computer, wherein the leaf nodes are mapped to the first nodes; generating an instance of the behavior tree by the computer (104); Including, Prior to the step of instantiating the behavior tree (104), the method further comprises: connecting, by the computer, at least one behavior subtree to the behavior tree; performing, by the computer, 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, by the computer, the first runtime to the second runtime such that the first runtime controls execution of the second runtime; establishing, by the computer, for each of all behavior nodes in a behavior subtree of the at least one behavior subtree, a corresponding second node in the second runtime, the behavior node defining the behavior 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; further comprising: Microservice orchestration methodology.

2. 10. 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, by the computer, 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. After the step of establishing a corresponding second node in the second runtime, the method further comprises: connecting, by the computer, 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 1 further comprising:

5. said step of connecting said at least one behavior subtree to said behavior tree comprises: determining, by the computer, a leaf node from the behavior tree, the leaf node configured to control execution of a behavior subtree; connecting, by the computer, 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 1 , comprising:

6. 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 comprises: 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 5 , comprising:

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

8. A computer readable storage medium storing computer readable instructions that, when executed, perform the method of any one of claims 1 to 6.

9. A microservice orchestration device, an establishment module (51) configured to establish 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; 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, wherein the leaf nodes are mapped to the first nodes; an instantiation module (54) configured to generate an instance of the behavior tree; Equipped with Before generating the instance of the behavior tree, the microservice orchestration apparatus 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; establishing a corresponding second node in the second runtime for each of all behavior nodes in a behavior subtree of the at least one behavior subtree, the behavior node defining a behavior 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; It is configured as follows: A microservice orchestration appliance.

Images