Service-oriented cloud-native workflow engine system and working method

Abstract

This invention discloses a service-centric cloud-native workflow engine system and its operating method. The service-centric cloud-native workflow engine system comprises: a portal layer for communication between users and the workflow engine, providing users with an interactive interface and interactive interfaces for user operation; a supporting business service layer for supporting upper-layer logic and allowing users to select services required for personalized business process customization; an abstract service layer for implementing and managing higher-level abstract business logic; an execution management layer for dynamically allocating tasks to corresponding microservice instances in the cloud platform infrastructure layer, completing task scheduling; and a cloud platform infrastructure layer for enabling on-demand allocation and rapid deployment of computing and storage resources. This invention achieves extended functionality by supporting business functions at the top and connecting resources at the bottom, achieving the goal of jointly optimizing both system business and resources.

Description

Technical Field

[0001] This invention relates to the technical field of workflow engine systems, and more particularly to a service-centric cloud-native workflow engine system and its operating method. Background Technology

[0002] In current workflow engine system architecture design, most mainstream workflow engine systems adopt a Service-Oriented Approach (SOA) architecture or a cloud-native architecture. In an SOA-based workflow engine architecture, workflow subtasks (activities) select different services at runtime to ensure activity implementation. It invokes services from the user's business needs perspective, without considering the specific implementation of task nodes, neglecting the rational use of system resources and the constantly changing cloud environment. Cloud computing, as a high-performance computing model, is becoming increasingly popular, and various cloud computing architectures or infrastructures are defined on it. Therefore, cloud-native engines have emerged, which can be directly deployed in the cloud environment and provided to users as cloud services, eliminating the need for users to build workflow engines locally. In a cloud-native workflow engine architecture, workflow activities directly select different service instance resources for execution, and workflow tasks are directly bound to specified types of microservice instances. This lack of consideration for users' personalized QoS preferences (such as preferences for price, response time, reliability, etc.) and business needs, coupled with the large number of heterogeneous services in the cloud environment providing the same functionality but with different QoS guarantees, makes it impossible to design reasonable business logic for them. These workflow engine architectures lack the ability to integrate system business and resources, and cannot conduct parallel research on the upper-layer business and lower-layer resources of the system. In other words, they cannot achieve the dual optimization goal of improving user satisfaction while ensuring that service providers obtain the maximum benefit. Summary of the Invention

[0003] The purpose of this section is to outline some aspects of embodiments of the present invention and to briefly describe some preferred embodiments. Simplifications or omissions may be made in this section, as well as in the abstract and title of this application, to avoid obscuring the purpose of these documents; however, such simplifications or omissions should not be construed as limiting the scope of the invention.

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a service-centric cloud-native workflow engine system that enables dynamic association between upper-layer business logic and lower-layer resources.

[0006] To address the aforementioned technical problems, this invention provides the following technical solution, comprising: a portal layer, used for communication between users and the workflow engine, providing users with an interactive interface and interactive interfaces for user operation; a supporting business service layer, connected to the portal layer, used to support upper-layer logic and allow users to select services required for personalized business process customization; an abstract service layer, connected to both the portal layer and the supporting business service layer, used to implement the description and management of higher-level abstract business logic; an execution management layer, connected to the supporting business service layer, used to dynamically allocate tasks to corresponding microservice instances in the cloud platform infrastructure layer, completing task scheduling; and a cloud platform infrastructure layer, connected to both the abstract service layer and the execution management layer, used to provide the upper layers with the necessary computing and storage resources, and to pool computing and storage resources through virtualization technology to achieve on-demand allocation and rapid deployment of computing and storage resources.

[0007] As a preferred embodiment of the service-centric cloud-native workflow engine system described in this invention, the supporting business service layer includes a service optimizer, a parser, a process manager, a task manager, a route controller, and an exception handler. The service optimizer is used to optimize services based on the personalized business requirements submitted by users from the portal layer and combined with the abstract services of the abstract service layer, obtaining a corresponding optimized service sequence. The parser is used to parse the business process model. The process manager is used to manage process instances, instantiate parsed process objects, control the start, suspension, resumption, and termination of process instances, and provide data information related to the operation of process instances. The task manager is used to manage task instances, constrain and track the operation of task instances, and update the status of task instances in real time. The route controller is used to parse routing rules and control process instances to run forward according to the data flow or control flow direction in the business process model. The exception handler is used to handle exceptions encountered by workflow instances during execution.

[0008] As a preferred embodiment of the service-centric cloud-native workflow engine system described in this invention, it includes: an abstract service layer composed of internal microservices and third-party services in the cloud system, wherein the internal microservices and third-party services are managed by the supporting business service layer to enable the construction of customized business processes.

[0009] As a preferred embodiment of the service-centric cloud-native workflow engine system described in this invention, the task scheduler in the execution management layer dynamically allocates tasks to corresponding microservice instances in the cloud platform infrastructure layer based on the corresponding service information and underlying resource information obtained from the supporting service layer, thereby completing task scheduling.

[0010] As a preferred embodiment of the service-centric cloud-native workflow engine working method described in this invention, the method includes: designing task definitions and workflow definitions based on JSON DSL according to prior knowledge and business service information provided in the cloud-native workflow engine system, and storing them in a business process library; upon receiving a user's workflow task request, searching the business process library for the required workflow template; if not found, returning an error message to the user; otherwise, parsing the workflow definition, combining the predefined service composition with the workflow blueprint and the actual service instance execution status to identify the next service and implement service composition. The process involves tracking, managing, and correctly executing the flow, followed by the workflow execution phase. This phase involves selecting suitable microservices for workflow instance subtasks to form a candidate service list. A predefined service composition algorithm generates a service execution sequence that meets the requirements of a customized business process. A service optimizer then transmits the workflow subtasks in the service execution sequence to the task scheduler in the data center where the corresponding microservice resides. During data center execution, the task scheduler schedules tasks to microservice instance workers. Based on the management services in the execution layer, automatic elastic scaling of microservice instance workers is achieved according to the needs of upper-layer business logic and information about underlying resources.

[0011] As a preferred embodiment of the service-centric cloud-native workflow engine working method described in this invention, the process of selecting suitable microservices to form a candidate service list includes: starting a service selector to perform service selection; the service selector separates the task definition from the workflow definition and searches for services within the system / existing cloud services in the cloud / services deployed from image files submitted by the user based on the user's business needs to obtain a microservice set S. i Combining the calculation methods of global QoS constraints to local subtask QoS constraints for different workflow structures, the refined QoS constraints of each subtask in the workflow instance are obtained; the service optimizer is based on the refined QoS constraints and the microservice set S. i The QoS attribute information of the service is used to select suitable microservices for the workflow instance subtasks to form a candidate service list; among them, different workflow structures include sequential structure workflow, selection structure workflow, parallel structure workflow, loop structure workflow and hybrid structure workflow; the hybrid structure includes "sequential + selection" and "sequential + parallel" structures.

[0012] As a preferred embodiment of the service-centric cloud-native workflow engine working method described in this invention, the calculation method includes: the calculation method for a sequential structured workflow is: calculating the difference Δ between the user's global QoS constraint on the workflow QoS attribute k and the average value of the QoS attribute k of all candidate services in the workflow's subtasks. k :

[0013]

[0014] In the formula, cs represents workflow, c k (cs) represents the user's global constraint value on the workflow QoS attribute k. Represents workflow subtask t i Candidate microservice set S i The mean of QoS attribute k for all microservices in N i Represents workflow subtask t i The number of candidate services;

[0015] After refining the workflow instance, the workflow sub-activities t i QoS constraint value c Seq k (S i )for:

[0016]

[0017] In the formula, Represents workflow activity t i The candidate microservice set S i The standard deviation of the QoS attribute k value of microservices, qos k (ms j ) indicates the service is in milliseconds (ms). j The value of the QoS attribute k, c Seq k (S i ) represents the workflow sub-activities t after refining the sequential workflow instance. i QoS constraint values;

[0018] The calculation method for selecting the structured workflow is as follows:

[0019]

[0020] In the formula, qos k (cs) must satisfy QoS k (cs)≤c k (cs), qos k (cs) represents the aggregated value of the QoS attribute k of all services following the preferred service sequence of the workflow instance, therefore, each structure cb in the structure is selected. i Both need to satisfy c k (cb i )≤c k (cs), therefore, as long as the maximum value of the average value of the candidate service for the task among all selectable execution paths satisfies That's it, S rThis represents the set of candidate services corresponding to the critical execution paths within the workflow, prob i This represents the probability of executing the chosen execution path i;

[0021] The calculation method for parallel workflow is as follows:

[0022] qos k (cs) = qos k (S r )

[0023]

[0024] In the formula, to satisfy qos k (cs)≤c k (cs), only the critical path needs to satisfy c. k (S r )≤c k (cs);

[0025] The calculation method for a cyclic workflow is as follows:

[0026]

[0027] In the formula, the loop operation is expanded into a set of sequential operations, which must satisfy qos. k (cs)≤c k (cs), c Loop k (S i )≤c k (cs); The calculation method for hybrid structure workflow is as follows:

[0028] Assume there are l executable paths, each execution path ER j For j∈[1,m], the constraint qos must be satisfied. k (ER j )≤c k (cs) As long as the execution path with the largest aggregate average satisfies the constraints, the global constraints required by the user are very likely to be satisfied, i.e. Workflow sub-activities based on hybrid structure t i The refined QoS attribute k constraint values ​​are shown below:

[0029]

[0030] in,

[0031] As a preferred embodiment of the service-centric cloud-native workflow engine working method described in this invention, the hybrid workflow further includes: for a "sequential + selection" hybrid structure: if Si ∈ER r Er(S) i ,ER r ) = 1, otherwise Er(S) i ,ER r ) = 0; For a hybrid "sequential + parallel" structure: if the QoS attribute k is an additive or multiplicative attribute, Er(S) = 0; i ,ER r ) = 1; If the QoS attribute k is a maximum value attribute, when S i ∈ER r Er(S) i ,ER r ) = 1, otherwise Er(S) i ,ER r ) = 0.

[0032] As a preferred embodiment of the service-centric cloud-native workflow engine working method described in this invention, it further includes: the cloud-native workflow engine system navigating workflow instances, transmitting data and control information between associated microservices, and controlling the direction of the workflow during task execution.

[0033] As a preferred embodiment of the service-centric cloud-native workflow engine working method described in this invention, the method includes: if there are Worker instances under the service in the service execution sequence that can satisfy the QoS constraints of the workflow subtask, the task scheduler schedules the workflow subtask to the microservice instance Worker with the lowest cost for execution; when all microservice instance Workers under the service in the service execution sequence cannot meet the user's QoS requirements, a higher-performance microservice instance Worker is obtained through an elastic scaling strategy, so that the workflow task can be executed normally and the user does not perceive any task abnormality; when all microservice instance Workers under the service in the service execution sequence can meet the user's QoS requirements, and the amount of idle resources is detected to frequently exceed the threshold set by the system, the cloud-native workflow engine system will reclaim the corresponding idle resources.

[0034] The beneficial effects of this invention are as follows: This invention dynamically and organically links three types of objects through two-layer system technical services. At the same time, by introducing an abstract service layer, it decouples user-personalized task requests from underlying resource instances, thus breaking the strong coupling between the two. Furthermore, through two-layer system technical services, it performs two-stage scheduling of the three execution objects in the workflow, ultimately realizing the extended function of supporting business at the top and connecting resources at the bottom, achieving the goal of jointly optimizing both system business and resources. Attached Figure Description

[0035] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein:

[0036] Figure 1 This is a schematic diagram of the overall structure of the service-centric cloud-native workflow engine system described in the first embodiment of the present invention;

[0037] Figure 2 This is a schematic diagram of the architecture of the service-centric cloud-native workflow engine system described in the first embodiment of the present invention;

[0038] Figure 3 This is a schematic diagram of the service-centric cloud-native workflow engine architecture described in the first embodiment of the present invention.

[0039] Figure 4 This is a schematic diagram illustrating the heterogeneous workflow request execution of the service-centric cloud-native workflow engine architecture described in the third embodiment of the present invention.

[0040] Figure 5 This is a schematic diagram illustrating the workflow execution success rate according to the third embodiment of the present invention. Detailed Implementation

[0041] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0042] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0043] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0044] This invention is described in detail with reference to the schematic diagrams. When detailing the embodiments of this invention, for ease of explanation, the cross-sectional views illustrating the device structure may be partially enlarged, not adhering to the usual scale. Furthermore, the schematic diagrams are merely examples and should not be construed as limiting the scope of protection of this invention. In actual fabrication, the three-dimensional spatial dimensions of length, width, and depth should be included.

[0045] Furthermore, in the description of this invention, it should be noted that the terms "upper," "lower," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are used solely for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. In addition, the terms "first," "second," or "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0046] Unless otherwise explicitly specified and limited, the terms "installation," "connection," and "joining" in this invention should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections; similarly, they can refer to mechanical connections, electrical connections, or direct connections, or indirect connections through an intermediate medium, or internal connections between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0047] Example 1

[0048] Reference Figures 1-3 This is the first embodiment of the present invention, which provides a service-centric cloud-native workflow engine system, see reference. Figures 1-2 The system consists of a portal layer 100, a supporting business service layer 200, an abstract service layer 300, an execution management layer 400, and a cloud platform infrastructure layer 500, specifically including:

[0049] Portal layer 100 is used for communication between users and the workflow engine, providing users with an interactive interface and interactive interfaces for user operation.

[0050] Specifically, the portal layer interacts directly with the user, is responsible for the connection between the user and the workflow engine, provides the user with an interactive interface, and triggers the workflow engine to manage task requests after the portal layer receives user requests.

[0051] Preferably, the portal layer 100, through the supporting business services of the upper layer of the cloud-native workflow engine system and the operation management services in the lower layer of the execution management layer, realizes the optimization of service customization business processes based on the user's task requirements and preferences, and then combines the underlying resources to perform specific task execution, realizing the dynamic association between the user's request and the abstract service of the abstract service layer 300 and the system resources.

[0052] The business service layer 200 is connected to the portal layer 100 to support the upper-layer logic and provide users with the services required for personalized business process customization.

[0053] The business service layer 200 includes a service optimizer 201, a parser 202, a process manager 203, a task manager 204, a route controller 205, and an exception handler 206.

[0054] Supports the coordination between various service components in the business service layer 200, specifically:

[0055] Service optimizer 201 is used to optimize services based on the personalized business requirements submitted by users from portal layer 100 and the abstract services of abstract service layer 300, and obtain a corresponding optimized service sequence.

[0056] Parser 202 is used to parse the business process model.

[0057] Process Manager 203 is used to manage process instances, instantiate and resolve process objects, control the start, suspension, resumption and termination of process instances, and provide data information related to the operation of process instances.

[0058] Task Manager 204 is used to manage task instances, constrain and track the execution process of task instances, and update the status of task instances in real time.

[0059] The routing controller 205 is used to parse routing rules and control flow instances to run forward according to the data flow or control flow direction in the business process model.

[0060] Exception handler 206 is used to handle exceptions encountered by workflow instances during execution.

[0061] Preferably, the business service layer 200 performs tasks such as service optimization based on the personalized business needs submitted by users from the portal layer and the abstract services of the abstract service layer 300 to obtain the corresponding optimized service sequence.

[0062] The abstract service layer 300, connected to both the portal layer 100 and the supporting business service layer 200, is used to describe and manage higher-level abstract business logic and can operate across organizations. The abstract service layer 300 consists of internal microservices and third-party services within the cloud system. These internal microservices and third-party services are managed by the supporting business services of the supporting business service layer 200 to enable the construction of customized business processes. Specific abstract services do not directly execute any user-requested tasks; their implementation is transparent to the service components of the supporting business service layer. Different service providers offer standardized service descriptions, enabling workflow instances to flexibly select the most valuable service based on user business needs and QoS constraints.

[0063] The execution management layer 400, connected to the supporting business service layer 200, is used to dynamically allocate tasks to the corresponding microservice instances in the cloud platform infrastructure layer 500, completing task scheduling. Specifically, the task scheduler in the execution management layer 400 dynamically allocates tasks to the corresponding microservice instances in the cloud platform infrastructure layer 500 based on the corresponding service information and underlying resource information obtained from the supporting service layer 200. That is, the execution management layer 400 implements a two-layer scheduling mechanism through two layers of technical service layers, thereby supporting the dynamic association of user task requests, abstract services, and service instance resources, and finally sending workflow subtasks to the Worker microservice instances deployed on the cloud platform infrastructure layer 500 for execution.

[0064] Reference Figure 3 This is the engine diagram of the system, which includes the core components of the workflow engine and some interaction interfaces. The core components of the workflow engine are divided into two modules: the process engine and the task engine. The process engine module includes a parser 202, a process manager 203, a task manager 204, a route controller 205, an execution engine, and an exception handler 206. The task engine module includes a task store, a service optimizer 201, and a task scheduler.

[0065] Ideally, the business management service supporting the business service layer 200 and the underlying operation technology management service supporting the execution layer 400 each perform their respective duties at different levels, with division of labor and cooperation between them. This supports the dynamic association between upper-level business logic and lower-level resources, enabling joint research on customizing business processes for users' personalized business needs and optimizing system resource allocation.

[0066] The cloud platform infrastructure layer 500 connects to the abstract service layer 300 and the execution management layer 400, respectively, to provide the upper layers with the computing and storage resources they need, and to pool computing and storage resources through virtualization technology to achieve on-demand allocation and rapid deployment of computing and storage resources.

[0067] Ideally, automatic elastic scaling of service instances is achieved in the cloud platform infrastructure layer 500 through the runtime technology service in the workflow engine.

[0068] Preferably, to achieve dynamic association of execution objects, this system also extends to two layers of system technical services: a support business service layer 200 that supports upper-level logic, and an execution management layer 400 that controls lower-level resources. This system dynamically and organically associates the three types of objects through these two layers of system technical services. The business management technical service of the support business service layer 200 supports the analysis of users' personalized business needs and QoS preferences, thereby enabling users to select the services required for personalized business process customization. The operation management technical service of the execution management layer 400 realizes the optimized configuration of enterprise lower-level resources, ultimately achieving comprehensive management of the system. Furthermore, by introducing an abstract service layer 300, the system decouples user-personalized task requests from lower-level resource instances, removing the strong coupling between the two. Then, through the two layers of system technical services, two-stage scheduling of the three types of execution objects in the workflow is performed, ultimately achieving the extended function of supporting business at the top and connecting resources at the bottom, achieving the goal of jointly optimizing both system business and resources.

[0069] Example 2

[0070] This embodiment differs from the first embodiment in that it provides a service-centric cloud-native workflow engine working method, including:

[0071] S1: Based on prior knowledge and business service information provided by the cloud-native workflow engine system, design task definitions and workflow definitions using JSON-based DSL and store them in the business process library.

[0072] Based on prior knowledge and the business service information provided by the cloud-native workflow engine system in Example 1, the process designer designs task definitions and workflow definitions based on JSON DSL and stores them in the business process library. Users submit the name of the requested business process, input data, and information on the global QoS requirements parameters of the business process (i.e., user constraints) at the portal layer to start the corresponding workflow.

[0073] S2: Upon receiving a user's workflow task request, check if the business process library contains the workflow template required by the user; if not, return an error message to the user.

[0074] S3: Otherwise, the workflow definition is parsed, and the predefined service composition is combined with the workflow blueprint and the actual service instance execution status to identify the next service and realize the tracking, management and correct execution of the service composition workflow. Then, the workflow operation phase is entered, and suitable microservices are selected for the workflow instance subtasks to form a candidate service list.

[0075] The specific steps for selecting suitable microservices to form a candidate service list are as follows:

[0076] (1) Start the service selector to perform service selection. The service selector separates the task definition in the workflow definition and searches for services within the system / existing cloud services in the cloud / services deployed by the image file submitted by the user based on the user's business needs to obtain the microservice set S. i ;

[0077] (2) By combining the calculation methods of global QoS constraints to local subtask QoS constraints of different workflow structures, the refined QoS constraints of each subtask in the workflow instance are obtained.

[0078] Different workflow structures include sequential workflow, selection workflow, parallel workflow, loop workflow, and hybrid workflow; hybrid structures include "sequential + selection" and "sequential + parallel" structures.

[0079] Based on the optimization objective, QoS attributes can be divided into positive attributes that need to be maximized (such as A (availability) and R (reliability), denoted as QoS). + And the negative attributes that need to be minimized (such as RT (response time) and cost (price), denoted as QoS). - In this embodiment, only negative attributes are considered. For positive attributes, they can be converted into negative attributes by calculating the negative value (multiplying by -1).

[0080] ① The calculation method for sequential workflow is as follows:

[0081] Calculate the difference Δ between the user's global QoS constraint on workflow QoS attribute k and the average QoS attribute k of all candidate services in the workflow's subtasks. k :

[0082]

[0083] In the formula, cs represents workflow, c k (cs) represents the user's global constraint value on the workflow QoS attribute k. Represents workflow subtask t i Candidate microservice set S i The mean of QoS attribute k for all microservices in N i Represents workflow subtask t i The number of candidate services;

[0084] After refining the workflow instance, the workflow sub-activities t i QoS constraint value c Seqk (S i )for:

[0085]

[0086] In the formula, Represents workflow activity t i The candidate microservice set S i The standard deviation of the QoS attribute k value of microservices, qos k (ms j ) indicates the service is in milliseconds (ms). j The value of the QoS attribute k, c Seq k (S i ) represents the workflow sub-activity t after the workflow instance is refined. i QoS constraint values.

[0087] ② The calculation method for the selected structured workflow is as follows:

[0088]

[0089] In this formula, regardless of which service is selected, QoS... k (cs) must satisfy QoS k (cs)≤c k (cs), qos k (cs) represents the aggregated value of the QoS attribute k of all services following the preferred service sequence of the workflow instance, therefore, each structure cb in the structure is selected. i Both need to satisfy c k (cb i )≤c k (cs), therefore, as long as the maximum value of the average value of the candidate service for the task among all selectable execution paths satisfies That's it, S r This represents the set of candidate services corresponding to the critical execution paths within the workflow, prob i This represents the probability of executing the chosen execution path i;

[0090] ③ The calculation method for parallel workflow is as follows:

[0091] qos k (cs) = qos k (S r )

[0092]

[0093] In the formula, since the aggregate value is determined by the critical path, in order to satisfy QoS... k (cs)≤c k(cs), only the critical path needs to satisfy c. k (S r )≤c k (cs);

[0094] ④ The calculation method for a cyclic workflow is as follows:

[0095]

[0096] In the formula, since the loop structure is defined using the loop number MNI, the loop operation is expanded into a set of sequential operations that must satisfy qos. k (cs)≤c k (cs), c Loop k (S i )≤c k (cs);

[0097] ⑤ The calculation method for hybrid workflow is as follows:

[0098] Assume there are l executable paths, each execution path ER j j∈[1,m] must satisfy the constraint qos k (ER j )≤c k (cs) As long as the execution path with the largest aggregate average satisfies the constraints, the global constraints required by the user are very likely to be satisfied, i.e. Workflow sub-activities based on hybrid structure t i The refined QoS attribute k constraint values ​​are shown below:

[0099]

[0100] in,

[0101] For a "sequence + selection" hybrid structure: if S i ∈ER r Then Er(S) i ,ER r ) = 1, otherwise Er(S) i ,ER r ) = 0.

[0102] For a hybrid "sequential + parallel" structure: if the QoS attribute k is an additive or multiplicative attribute, then Er(S i ,ER r ) = 1; If the QoS attribute k is a maximum value attribute, when S i ∈ER r At that time, Er(S) i ,ER r) = 1, otherwise Er(S) i ,ER r ) = 0.

[0103] (3) The service optimizer is based on the refined QoS constraints and the microservice set S. i The QoS attribute information of the service is used to select suitable microservices for the workflow instance subtasks to form a candidate service list;

[0104] S4: Generate a service execution sequence that meets the requirements of a customized business process through a predefined service composition algorithm, and then send the workflow subtasks in the service execution sequence to the task scheduler of the data center where the corresponding microservice is located through a service optimizer.

[0105] Ideally, the cloud-native workflow engine system navigates workflow instances, transmits data and control information between related microservices, and controls the direction of the workflow during task execution, thereby promoting the effective operation of the entire workflow.

[0106] S5: When running in the data center, the task scheduler is used to schedule tasks to microservice instance Workers.

[0107] The task scheduler is responsible for scheduling runtime tasks in this data center to microservice instance workers. It can read performance information such as workload of worker instances monitored in the system, and map tasks to resources based on information of all workflow instances that call microservices in this data center.

[0108] S6: Based on the management services in the execution management layer, it enables automatic elastic scaling of microservice instance Workers according to the needs of upper-layer business logic and information of lower-layer resources.

[0109] If there is a Worker instance under the service in the service execution sequence that can meet the QoS constraints of the workflow subtask (i.e., meet the user's QoS parameter requirements, such as the user requiring a workflow service within 1000 yuan and within 100 seconds), the task scheduler will schedule the workflow subtask to the microservice instance Worker with the lowest cost for execution.

[0110] When all microservice instance workers under a service in the service execution sequence cannot meet the user's QoS requirements, a higher-performance microservice instance worker is obtained through an elastic scaling strategy, so that the workflow task can be executed normally and the user will not feel any task abnormality.

[0111] When all microservice instances (Workers) in the service execution sequence can meet the user's QoS requirements, and the amount of idle resources is detected to frequently exceed the threshold set by the system, the cloud-native workflow engine system will reclaim the corresponding idle resources.

[0112] Example 3

[0113] To verify the effectiveness of the techniques used in this method, this implementation example includes an experimental analysis to verify the actual effect of the method.

[0114] This implementation example conducted three series of experiments, including (1) testing the effectiveness and usability of the method; (2) verifying the key functions of personalized service customization and task scheduling in the method; and (3) analyzing the flexibility of the system.

[0115] (1) Test the effectiveness and usability of this method.

[0116] This method supports the execution of heterogeneous workflows. A series of simulation experiments were conducted on heterogeneous workflow requests with different QoS levels. The experimental results are as follows: Figure 4 The images shown are for reference only.

[0117] (2) Verify the key functions of personalized service customization and task scheduling in this method.

[0118] Based on the above heterogeneous workflow model, personalized service customization tests were conducted on heterogeneous workflow requests with different QoS levels. The service execution sequence of the workflow instance was customized according to user requirements, and the service optimization results are shown in Table 1, for reference only. This system performs QoS management based on the global constraints submitted by the user, obtaining the refined QoS constraints for each subtask, and then performs service optimization to obtain personalized service optimization results that satisfy both global and local constraints.

[0119] Table 1: Service optimization results in heterogeneous workflow requests (I represents internal services, E represents third-party services).

[0120]

[0121] Based on the service optimization results above, further verification of task scheduling is conducted. If the workflow subtasks are executed by external services, the underlying instance information is not considered because the execution of third-party services is invisible. Conversely, if the workflow subtasks are executed by internal services in the cloud environment where the system resides, the mapping from tasks to service instance resources is optimized based on the global resource information and task information of the cloud data center. The experimental results are shown in Table 2, which are for reference only.

[0122] Table 2: Task scheduling results in heterogeneous workflow requests.

[0123]

[0124] (3) Analyze the flexibility of this system.

[0125] Due to the instability of the cloud environment, the QoS of participating internal or third-party services may change dynamically, potentially leading to service failures. This study verifies the system's exception handling capabilities by simulating queryable but non-executable abnormal services. Since any workflow structure can be converted into a sequential structure using certain methods, a sequential workflow is used as an example to verify the system's flexibility in handling exceptions. The verification results are as follows: Figure 5 The images shown are for reference only.

[0126] The above verification and analysis results show that the proposed method can handle heterogeneous workflow task requests. On the business side, it can customize services based on users' personalized business needs, thereby improving user satisfaction. On the underlying execution side, it can perform reasonable task scheduling based on system resource conditions and task requests, thereby improving cloud resource utilization. At the same time, the system can flexibly handle abnormal situations during workflow operation, ensuring that the workflow is completed normally. These results verify the rationality and effectiveness of the proposed method.

[0127] It should be recognized that embodiments of the present invention can be implemented or carried out by computer hardware, a combination of hardware and software, or by computer instructions stored in a non-transitory computer-readable storage medium. The method can be implemented using standard programming techniques—including a non-transitory computer-readable storage medium configured with a computer program, wherein such a storage medium causes the computer to operate in a specific and predefined manner—according to the methods and drawings described in the specific embodiments. Each program can be implemented in a high-level procedural or object-oriented programming language to communicate with the computer system. However, if desired, the program can be implemented in assembly or machine language. In any case, the language can be a compiled or interpreted language. Furthermore, for this purpose, the program can run on a programmed application-specific integrated circuit (ASIC).

[0128] Furthermore, the procedures described herein may be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by the context. The procedures described herein (or variations and / or combinations thereof) may be executed under the control of one or more computer systems configured with executable instructions, and may be implemented by hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more applications) that commonly executes on one or more processors. The computer program comprises a plurality of instructions executable by one or more processors.

[0129] Furthermore, the method can be implemented in any suitable type of computing platform, including but not limited to personal computers, minicomputers, mainframes, workstations, networked or distributed computing environments, standalone or integrated computer platforms, or in communication with charged particle tools or other imaging devices, etc. Aspects of the invention can be implemented as machine-readable code stored on a non-transitory storage medium or device, whether removable or integrated into a computing platform, such as a hard disk, optical read and / or write storage medium, RAM, ROM, etc., such that it is readable by a programmable computer, and when the storage medium or device is read by the computer, it can be used to configure and operate the computer to perform the processes described herein. Furthermore, the machine-readable code, or portions thereof, can be transmitted via wired or wireless networks. The invention described herein includes these and other different types of non-transitory computer-readable storage media when such media comprises instructions or programs that implement the steps described above in conjunction with a microprocessor or other data processor. When programmed according to the methods and techniques described herein, the invention also includes the computer itself. A computer program can be applied to input data to perform the functions described herein, thereby transforming the input data to generate output data stored in non-volatile memory. The output information can also be applied to one or more output devices such as a display. In a preferred embodiment of the invention, the converted data represents physical and tangible objects, including specific visual depictions of physical and tangible objects generated on a display.

[0130] As used herein, the terms “component,” “module,” “system,” etc., are intended to refer to a computer-related entity, which may be hardware, firmware, a combination of hardware and software, software, or running software. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a running thread, a program, and / or a computer. As an example, an application running on a computing device and the computing device itself can both be components. One or more components may reside in a running process and / or thread, and components may be located in a single computer and / or distributed among two or more computers. Furthermore, these components are capable of execution from various computer-readable media having various data structures thereon. These components may communicate locally and / or remotely via signals, such as based on one or more data packets (e.g., data from a component that interacts with a local system, another component in a distributed system, and / or signals that interact with other systems via a network such as the Internet).

[0131] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A service-centric cloud-native workflow engine system, characterized in that, include: The portal layer (100) is used for communication between users and the workflow engine, providing users with an interactive interface and interactive interfaces for user operation; The business service layer (200) is connected to the portal layer (100) and is used to support the upper-layer logic and provide users with the services required for personalized business process customization. The abstract service layer (300) is connected to the portal layer (100) and the supporting business service layer (200) respectively, and is used to implement the description and management of higher abstract business logic; The execution management layer (400) is connected to the supporting business service layer (200) and is used to dynamically allocate tasks to the corresponding microservice instances in the cloud platform infrastructure layer (500) to complete task scheduling; The cloud platform infrastructure layer (500) is connected to the abstract service layer (300) and the execution management layer (400) respectively, and is used to provide the upper layer with the computing and storage resources it needs, and to pool the computing and storage resources through virtualization technology to realize on-demand allocation and rapid deployment of computing and storage resources; The supporting business service layer (200) includes a service optimizer (201), a parser (202), a process manager (203), a task manager (204), a route controller (205), and an exception handler (206); The service optimizer (201) is used to optimize services based on the personalized business requirements submitted by users from the portal layer (100) and the abstract services of the abstract service layer (300) to obtain the corresponding optimized service sequence. Parser (202) is used to parse the business process model; The process manager (203) is used to manage process instances, instantiate and resolve process objects, control the start, suspension, resumption and termination of process instances, and provide data information related to the operation of process instances. Task Manager (204) is used to manage task instances, constrain and track the running process of task instances, and update the status of task instances in real time; The routing controller (205) is used to parse routing rules and control flow instances to run forward according to the data flow or control flow direction in the business process model; An exception handler (206) is used to handle exceptions encountered by a workflow instance during execution; The abstract service layer (300) consists of internal microservices and third-party services in the cloud system. The internal microservices and third-party services are managed by the supporting business service layer (200) to realize the construction of customized business processes. The task scheduler in the execution management layer (400) dynamically allocates tasks to the corresponding microservice instances in the cloud platform infrastructure layer (500) based on the corresponding service information and underlying resource information obtained by the support service layer (200), thereby completing task scheduling. The task scheduler in the execution management layer (400) dynamically allocates tasks to the corresponding microservice instances in the cloud platform infrastructure layer (500) based on the corresponding service information and underlying resource information obtained from the support service layer (200), thereby completing task scheduling.

2. A service-centric cloud-native workflow engine working method, applying the service-centric cloud-native workflow engine system as described in claim 1, characterized in that, include: Based on prior knowledge and business service information provided by the cloud-native workflow engine system, task definitions and workflow definitions are designed based on JSON DSL and stored in the business process library. Upon receiving a user's workflow task request, the system searches the business process library to see if it contains the workflow template required by the user. If not, return an error message to the user; Otherwise, the workflow definition is parsed, and the predefined service composition is combined with the workflow blueprint and the actual service instance execution status to identify the next service and realize the tracking, management and correct execution of the service composition workflow. Then, the workflow operation phase is entered, and suitable microservices are selected for the workflow instance subtasks to form a candidate service list. A service execution sequence that meets the requirements of a customized business process is generated through a predefined service composition algorithm. Then, the workflow subtasks in the service execution sequence are sent to the task scheduler of the data center where the corresponding microservice is located through a service optimizer. When running in the data center, the task scheduler is used to schedule tasks to microservice instance Workers; Based on the management services in the execution layer, the automatic elastic scaling of microservice instance Workers is achieved according to the needs of upper-layer business logic and the information of lower-layer resources.

3. The service-centric cloud-native workflow engine working method as described in claim 2, characterized in that, Selecting suitable microservices to form a candidate service list includes: The service selector is initiated to perform service selection. It separates the task definitions from the workflow definition and searches for services within the system, existing cloud services, or services deployed from user-submitted image files based on the user's business requirements to obtain a microservice set S. i ; By combining the calculation methods of global QoS constraints to local subtask QoS constraints for different workflow structures, the refined QoS constraints of each subtask in the workflow instance are obtained. The service optimizer is based on the refined QoS constraints and the microservice set S i The QoS attribute information of the service is used to select suitable microservices for the workflow instance subtasks to form a candidate service list; The different workflow structures include sequential workflow, selection workflow, parallel workflow, loop workflow, and hybrid workflow; the hybrid structure includes "sequential + selection" and "sequential + parallel" structures.

4. The service-centric cloud-native workflow engine working method as described in claim 3, characterized in that, The calculation methods include: The calculation method for sequential workflow is as follows: Calculate the difference Δ between the user's global QoS constraint on workflow QoS attribute k and the average QoS attribute k of all candidate services in the workflow's subtasks. k : In the formula, cs represents the workflow, c k (cs) represents the user's global constraint value on the workflow QoS attribute k. Represents workflow subtask t i Candidate microservice set S i The mean of QoS attribute k for all microservices in N i Represents workflow subtask t i The number of candidate services; After refining the workflow instance, the workflow sub-activities t i QoS constraint value c Seq k (S i )for: In the formula, Represents workflow activity t i The candidate microservice set S i The standard deviation of the QoS attribute k value of microservices, qos k (ms j ) indicates the service is in milliseconds (ms). j The value of the QoS attribute k, c Seq k (S i ) represents the workflow sub-activities t after refining the sequential workflow instance. i QoS constraint values; The calculation method for selecting the structured workflow is as follows: In the formula, qos k (cs) must satisfy QoS k (cs)≤c k (cs), qos k (cs) represents the aggregated value of the QoS attribute k of all services following the preferred service sequence of the workflow instance, therefore, each structure cb in the structure is selected. i Both need to satisfy c k (cb i )≤c k (cs), therefore, as long as the maximum value of the average value of the candidate service for the task among all selectable execution paths satisfies That's it, S r This represents the set of candidate services corresponding to the critical execution paths within the workflow, prob i This represents the probability of executing the selectable execution path i; The calculation method for parallel workflow is as follows: qos k (cs)=qos k (S r ) In the formula, to satisfy qos k (cs)≤c k (cs), only the critical path needs to satisfy c. k (S r )≤c k (cs); The calculation method for a cyclic workflow is as follows: In the formula, the loop operation is expanded into a set of sequential operations, which must satisfy qos. k (cs)≤c k (cs), c Loop k (S i )≤c k (cs); The calculation method for hybrid workflow is as follows: Assume there are l executable paths, each execution path ER j For j∈[1,m], the constraint qos must be satisfied. k (ER j )≤c k (cs) As long as the execution path with the largest aggregate average satisfies the constraints, the global constraints required by the user are very likely to be satisfied, i.e. Workflow sub-activities based on hybrid structure t i The refined QoS attribute k constraint values ​​are shown below: in, 5. The service-centric cloud-native workflow engine working method as described in claim 4, characterized in that, Hybrid workflows also include: For a "sequence + selection" mixed structure: if S i ∈ER r Er(S) i ,ER r ) = 1, otherwise Er(S) i ,ER r ) = 0, For a hybrid "sequential + parallel" structure: if the QoS attribute k is an additive or multiplicative attribute, Er(S i ,ER r ) = 1; If the QoS attribute k is a maximum value attribute, when S i ∈ER r Er(S) i ,ER r ) = 1, otherwise Er(S) i ,ER r ) = 0.

6. The service-centric cloud-native workflow engine working method as described in claim 5, characterized in that, Also includes: The cloud-native workflow engine system navigates workflow instances, transmits data and control information between related microservices, and controls the direction of the workflow during task execution.

7. The service-centric cloud-native workflow engine working method as described in claim 6, characterized in that, include: If there is a Worker instance under the service in the service execution sequence that can satisfy the QoS constraints of the workflow subtask, the task scheduler will schedule the workflow subtask to the microservice instance Worker with the lowest cost for execution. When all microservice instance workers under a service in the service execution sequence cannot meet the user's QoS requirements, a higher-performance microservice instance worker is obtained through an elastic scaling strategy, so that the workflow task can be executed normally and the user will not feel any task abnormality. When all microservice instances (Workers) in the service execution sequence can meet the user's QoS requirements, and the amount of idle resources is detected to frequently exceed the threshold set by the system, the cloud-native workflow engine system will reclaim the corresponding idle resources.

Images