Complex service orchestration method based on service grid

Abstract

The invention provides a complex business arrangement method based on a service grid, which comprises the following steps that: a plurality of business services are deployed on a container management platform in a containerized application form, the service grid is operated on the platform, and the business services are associated with network agents; a declarative business process definition is obtained by an arrangement control module, and the definition describes an execution dependency relationship among business task nodes; the arrangement control module translates the business process definition into a group of network flow management rules and a group of declarative resource definitions; and issuing the network flow management rule to a control plane of the service grid to drive flow circulation, and issuing the declarative resource definition to a container management platform to execute a specific service task. According to the method and the system, process execution is sunk to infrastructures, thorough decoupling of service logic, process logic and resource scheduling is realized, a technical foundation is laid for constructing an elastic and robust distributed service system, and the development efficiency, reliability and maintainability of a complex service system are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of distributed systems, and in particular to microservice architecture, containerization technology, service mesh technology and complex business process management technology in cloud-native computing environment, and specifically relates to a complex business orchestration method based on a service mesh. BACKGROUND

[0002] In modern enterprises, such as large-scale equipment manufacturing, finance, telecommunications and other fields, complex business processes usually involve the cooperative work of multiple distributed systems or microservices. The complex business here refers to a process that contains one or more of the following characteristics: state-driven long-period tasks (such as manual approval that takes several days), high-concurrency transactional steps, logic containing conditional branching or parallel execution, and computationally intensive tasks that need to call heterogeneous environments (such as data analysis or scientific simulation).

[0003] Currently, the mainstream technology for implementing such business orchestration relies on centralized business process engines, such as Camunda or Activiti. Such engines are responsible for tracking and scheduling the state of each business process instance. In a distributed architecture that requires high availability and high elasticity, such centralized engines are extremely prone to becoming single points of failure and performance bottlenecks for the entire system, making them difficult to maintain and extend.

[0004] On the other hand, complex business processes, such as scientific computing, data analysis or simulation tasks, often rely on specific and complex runtime environments, such as specialized libraries, drivers or solvers. Under the traditional approach, the business system must be tightly integrated with the underlying heterogeneous computing resources (such as high-performance computing clusters), resulting in complex environment configuration, difficult resource scheduling, and inability to scale elastically.

[0005] If a centralized engine is not used, developers are forced to hardcode process logic in the code of business services, such as "Service A" completing task A, then explicitly calling "Service B". This approach results in a serious coupling of business function logic and process flow, network communication logic (such as service discovery, call retries, timeouts and security authentication). The business code is bloated, the process is difficult to change, and the system is extremely fragile.

[0006] To solve the above problems, two major improvement attempts have appeared in the prior art, but both have significant limitations: One approach is to use a dedicated distributed application runtime, such as Dapr. While this technology employs a network proxy (i.e., sidecar) pattern, it requires the use of its specific, non-standard proxy and introduces a completely new set of APIs to define workflows. This results in a strong binding between the business system and the specific runtime, making it incompatible with and unable to leverage the enterprise's existing, standardized service mesh (such as Istio or Linkerd) infrastructure, leading to a fragmentation of the technology stack and redundant construction.

[0007] Secondly, traditional centralized process engines (such as Temporal or Zeebe) are containerized and deployed on a container management platform. While this approach solves deployment and high availability issues, its execution model remains fundamentally centralized. Each state transition and decision in the process still needs to be handled centrally by the process engine instance, without leveraging the powerful traffic control capabilities of the service mesh itself to drive the process. This results in a separation between process execution (network routing) and service mesh governance (traffic rules), leading to architectural redundancy, and the process engine remains a potential logical bottleneck. Summary of the Invention

[0008] The present invention aims to solve the problems of centralized bottlenecks in business orchestration engines, strong coupling between business logic and network logic, strong coupling between business environment and underlying resource management, as well as the technology stack fragmentation and architectural redundancy caused by existing improvement solutions (such as dedicated runtime or containerized engines) in the prior art.

[0009] This invention proposes a complex business orchestration method based on service mesh. It natively leverages the existing, standardized service mesh and container management platform infrastructure capabilities to sink complex orchestration logic to the infrastructure, achieving a distributed, elastic, and non-intrusive complex business orchestration. The technical solution provided by this invention is as follows: A method for orchestrating complex business processes based on service mesh includes the following steps: S1. Deployment steps: Deploy one or more business services as containerized applications running on a container management platform, wherein a service mesh runs in the container management platform, and each containerized application is associated with a network proxy. S2. Acquisition Steps: An orchestration control module acquires a declarative business process definition, which includes multiple business task nodes and execution dependencies between nodes. S3. Translation Steps: The orchestration control module translates the business process definition into at least one set of network traffic governance rules. S4. Distribution Step: The orchestration control module distributes the network traffic governance rules to the control plane of the service mesh; S5. Execution steps: The network proxy intercepts and dynamically routes service calls between containerized applications according to the network traffic governance rules received from the control plane, so as to drive the jump between task nodes in the business process definition.

[0010] Furthermore, the translation step also includes: translating a specific task node in the business process definition into a declarative resource definition; the distribution step also includes: submitting the declarative resource definition to the container management platform; the execution step also includes: the container management platform automatically allocating resources and executing one or more containerized application instances to complete the specific task node based on the declarative resource definition.

[0011] Furthermore, the declarative resource definition specifies a container image and a set of resource requirements; the container image encapsulates the business tools, software libraries, and runtime environment required to execute the specific task node.

[0012] Furthermore, the network traffic governance rules include conditional routing rules; the orchestration control module is also used to monitor the current status of the business process; when the status changes, the orchestration control module automatically updates and issues the conditional routing rules, so that the network proxy routes subsequent network traffic to the next task node in the business process.

[0013] Furthermore, the network traffic governance rules include traffic replication rules; the execution steps also include: when the network proxy intercepts a call from an upstream business service, it automatically replicates and forwards the call to one or more predefined downstream business services according to the traffic replication rules.

[0014] Furthermore, the network proxy is also used to automatically provide a reliability mechanism for service calls to business services according to a preset strategy. The reliability mechanism includes retry, timeout, or circuit breaking.

[0015] Furthermore, it also includes: Acquiring telemetry data: The orchestration control module acquires telemetry data from the service mesh; Dynamic adjustment: The orchestration control module dynamically adjusts the network traffic governance rules based on the telemetry data to achieve load-aware scheduling of business processes.

[0016] Compared with the prior art, the beneficial effects achieved by the present invention are: 1. Complete decoupling and simplified business operations: Business services only need to focus on their own functions. How processes proceed, how networks retry, and how resources are allocated are all automatically handled by the underlying infrastructure (container platform and service mesh) under the configuration of the orchestration control module.

[0017] 2. Decentralized and highly available: It eliminates the bottleneck of traditional centralized process engines. Process execution is distributed across various network agents, and the orchestration and control module itself can also be deployed with high availability, greatly improving the robustness and elasticity of the system.

[0018] 3. Standardized and highly elastic environment: Containerization technology solves the environmental dependencies of complex business processes. Combined with the declarative scheduling capabilities of the container management platform, it enables elastic scaling and efficient resource utilization for compute-intensive tasks.

[0019] 4. Declarative and easy to maintain: Business processes are defined declaratively, making them easy to understand, version control, and change. Changes to the processes no longer require modifying and redeploying large amounts of business service code; only the configuration of the orchestration control module needs to be updated. Attached Figure Description

[0020] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is the overall flowchart of the method of the present invention. Figure 2 This is a schematic diagram of the system architecture of an embodiment of the present invention; Figure 3 This is a schematic diagram of an example of a collaborative approval-type business process. Figure 4 This is a schematic diagram of an orchestration implementation example for an asynchronous, computationally intensive service. Figure 5 This is a flowchart illustrating an example of an event-driven business process orchestration. Detailed Implementation

[0021] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] First, the general implementation methods of each step in the main process of the present invention will be described in detail: Regarding the specific implementation of the S1 deployment steps, this step aims to build a basic operating environment with traffic interception and governance capabilities.

[0023] S11. Image Building and Registration: Developers or CI / CD pipelines package business service code and its dependent environment into container images that conform to the OCI standard and push them to private or public container image repositories.

[0024] S12, Resource Inventory Definition: Compile the deployment inventory file for the container management platform. In this inventory, enable automatic service mesh injection via annotations or namespace labels.

[0025] S13, Instance Startup and Sidecar Injection: The container management platform schedules resources and starts business containers according to the inventory. During this process, the service mesh control plane uses the Admission Controller mechanism to automatically intercept Pod creation requests and inject network proxy containers (i.e., Sidecar Proxy) into the Pod.

[0026] S14. Proxy Initialization and Takeover: After the network proxy container starts, it uses iptables rules or eBPF technology to modify the network namespace configuration of the Pod, forcibly redirecting all TCP / HTTP traffic entering and leaving the business container to the port listened to by the network proxy, thus completing the traffic takeover.

[0027] Regarding the S2 acquisition step, this step is executed by the orchestration control module, which is responsible for receiving and parsing the business logic.

[0028] S21. Receiving Definitions: The orchestration control module provides an API interface to receive business process definition files submitted by external systems. These files are typically in JSON, YAML, or DSL format.

[0029] S22. Syntax Validation and Parsing: The orchestration control module performs syntax validity checks on the received process definition to ensure that the task node definition is complete and the dependency relationship is closed.

[0030] S23. Dependency Graph Construction: The parser converts the declarative process definition into an in-memory directed acyclic graph (DAG) or state machine model. In this model, nodes represent business services or computational tasks, and edges represent flow conditions and data flow directions, thus structurally describing the flow logic.

[0031] Regarding the S3 translation step, this step is the core of the invention, responsible for mapping the process logic of the business layer to the network rules of the infrastructure layer.

[0032] S31. Routing Strategy Mapping: The orchestration control module traverses the dependency graph built in S2. For each "flow edge" in the graph (e.g., from service A to service B), a corresponding virtual service routing configuration is generated. The system identifies the unique identifier (FlowID) of the process instance and generates matching rules based on HTTP headers or cookies. For example, the generated rule semantics might be "When the source workload is service A, the request header contains a specific FlowID, and the processing result is Success, the next hop is routed to service B."

[0033] S32. Resource Definition Generation: For nodes marked as "compute-intensive" or "one-off task" in the dependency graph, the orchestration control module generates the corresponding container task resource definition according to the preset template, which includes the required image version, CPU / memory limits and mounted volume information.

[0034] S33. Fault Tolerance Strategy Generation: Generate corresponding timeout, retry, and circuit breaker configuration fragments based on the SLA requirements specified in the process definition.

[0035] Regarding the S4 deployment steps, this step is responsible for applying the generated configuration to the underlying platform.

[0036] S41. Configuration Consistency Check: Before deployment, the orchestration control module compares the existing rules in the current service mesh with the newly generated rules to calculate the incremental configuration in order to minimize the impact on the existing system.

[0037] S42. Rule Submission: For network traffic governance rules, the orchestration control module calls the API of the service mesh control plane to persistently store the routing and fault tolerance rules generated by S3. After the service mesh control plane detects a configuration change, it converts it into a protocol configuration that the underlying proxy can recognize and asynchronously pushes it to all relevant data plane proxies.

[0038] S43. Resource Submission: For declarative resource definitions, the orchestration control module calls the container management platform's API to submit the Job or Pod configuration, triggering the platform's scheduler to allocate resources.

[0039] Regarding the S5 execution steps, this step is automatically triggered in the network proxy of the data plane, without the need for business code intervention.

[0040] S51. Traffic Interception and Identification: When a business container initiates an external call, the traffic is redirected to the local network proxy. The proxy extracts key context information (such as the FlowID in the header) by parsing the request protocol.

[0041] S52, Rule Matching and Decision: The network agent searches the routing table issued by the control plane in its local memory. Based on the extracted context information, it matches the specific routing rule generated in step S3.

[0042] S53, Load Balancing and Forwarding: After determining the target service, the agent selects a healthy instance from the cluster load balancing pool and initiates a connection. During the forwarding process, the agent automatically executes configured policies (such as retry and timeout control).

[0043] S54. Telemetry Reporting: After the request is processed, the network agent asynchronously generates access logs and metrics, and reports them to the monitoring system for the orchestration and control module to perform subsequent status monitoring and decision-making loops.

[0044] The overall process of this invention is as follows: Figure 1 As shown, in order to make the above-mentioned objectives, features and effects of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0045] Example 1: Please refer to Figure 2 This illustrates a specific embodiment of the present invention. The system in this embodiment is deployed on a container management platform 100. The container management platform 100 is responsible for the abstraction and management of underlying computing, storage, and network resources, as well as the scheduling, execution, and lifecycle management of containerized applications.

[0046] A service mesh is deployed on top of the container management platform 100. The service mesh includes a control plane 110 and a data plane. The data plane consists of multiple network agents 121a, 122a, etc.

[0047] The system's business logic is carried by one or more business services (such as business service A 121, business service B 122). Each business service is encapsulated as a containerized application and runs as a containerized application instance (e.g., 120a, 120b) on the container management platform 100. Each containerized application instance contains a business service (e.g., 121) and an associated network proxy (e.g., 121a). The network proxy 121a intercepts all network traffic entering and leaving business service 121.

[0048] The orchestration control module 130 is configured to perform the following functions: Listening and fetching: Provide an API or listening mechanism to fetch business process definitions defined by the user in a declarative (e.g., YAML, JSON, or domain-specific language) format.

[0049] Translation and Communication: Communicating with the control plane 110 of the service mesh via the first communication link 131. This is used to translate and distribute the flow logic in the business process, such as conditional branches and sequential execution, into network traffic governance rules. Communicating with the API of the container management platform 100 via the second communication link 132. This is used to translate and distribute the task execution logic in the business process, especially computationally intensive tasks, into declarative resource definitions.

[0050] Monitoring: Communicates with the monitoring components of the service mesh (e.g., telemetry data collectors) via the third communication link 133 to obtain service telemetry data reported by the network agent, such as latency and error rate, for the purpose of enabling dynamic, load-aware orchestration and scheduling.

[0051] Example 2: Please refer to Figure 3 This embodiment is a collaborative approval business implementation, illustrating how the present invention distributes network traffic governance rules to the control plane of the service mesh. Taking a general multi-level document review and approval process as an example, the process includes three task nodes: compilation, proofreading, and review.

[0052] 1. Process Initiation and Parsing (corresponding to step S2): The user submits a document to initiate the approval process. The orchestration control module 130 receives the process instance creation request. Based on the predefined JSON process file, it uses the DAG construction algorithm to parse the current status as "Completed" and the next hop as "Proofreading Service", and generates a unique process tracking ID (e.g., instance-abc).

[0053] 2. Rule Translation (corresponding to step S3): For this process instance, the orchestration control module 130 translates the "flow to verification service" logic into a VirtualService routing rule. This rule explicitly specifies that when the request header contains x-flow-id:instance-abc, the traffic weight is 100% directed to the verification service (corresponding to...). Figure 2 Business service B 122 in the middle.

[0054] 3. Incremental Distribution (corresponding to step S4): The orchestration control module 130 first compares the current mesh configuration to confirm that the rule is a new item, and then submits the configuration through the control plane API. The service mesh control plane 110 automatically converts this configuration into the xDS protocol and pushes it to the relevant network agents.

[0055] 4. Proxy Execution (corresponding to step S5): Service 121 issues a call request (e.g., accessing http: / / workflow / next). Its associated network proxy 121a intercepts the traffic through iptables, extracts the x-flow-id from the request header, matches it to the local cached routing table, and transparently forwards the request to the verification service 122.

[0056] 5. Closed-loop process: When the proofreading service is completed, the orchestration control module 130 repeats the above steps, updates the routing rules, and directs the traffic of the next stage to the audit service, so as to achieve a seamless transition of process status.

[0057] The beneficial effect of this embodiment is that it achieves complete decoupling between process logic and business logic. Specifically, compared with traditional hard-coded calls, this embodiment adopts dynamic routing technology based on HTTP headers. The orchestration module translates the flow logic into grid rules, completely decoupling the routing decision-making power from the business code. This allows the orchestration service to be unaware of the existence of the proofreading service, greatly simplifying the business code.

[0058] Example 3: Please refer to Figure 4 This embodiment is an asynchronous computing-intensive business implementation example, illustrating how to handle non-service computing tasks, taking a general data analysis batch processing task as an example.

[0059] 1. Task Node Identification (corresponding to step S2): When the business process flows to the "Data Analysis" node, the orchestration control module 130 parses the DAG node attributes and identifies the node as kind: Job (computation-intensive task), rather than a normal RPC service call.

[0060] 2. Declarative resource mapping (corresponding to step S3): The orchestration control module 130 calls the built-in template engine, reads the parameters in the process definition (image my-analytics-tool:v1.2, resource CPU: 8, Memory: 64Gi, input data volume data-volume-abc), and fills them into the Job resource template to generate a complete YAML resource definition file.

[0061] 3. Issuance of scheduling instructions (corresponding to step S4): The orchestration control module 130 submits the generated JobYAML to the container management platform 100 through link 132.

[0062] 4. Platform Execution and Feedback (corresponding to step S5): The scheduler of the container management platform 100 automatically starts the Pod to execute the analysis task based on resource requirements. The orchestration control module 130 monitors the Job status through the Watch mechanism. Once the task is completed (Success), it triggers the process DAG to enter the next node.

[0063] The beneficial effects of this embodiment are: it achieves environment standardization and resource isolation for complex computing tasks. Unlike synchronous service calls (RPC), this embodiment maps task nodes to Jobs (declarative one-time tasks). This allows the system to allocate independent, isolated computing resources (such as 8 cores / 64GB) to the task and automatically release them after the task is completed. Compared with ordinary service calls, this avoids blocking and resource contention, significantly improving stability and elasticity.

[0064] Example 4: Please refer to Figure 5 This embodiment is a data synchronization type business implementation example, illustrating how to use traffic governance rules to achieve business decoupling, taking the scenario where multiple downstream systems need to be notified after an order is completed as an example.

[0065] 1. Policy Pre-configuration (corresponding to steps S3 and S4): During the process deployment phase, the orchestration control module 130 has generated a traffic mirroring rule based on the "notify downstream" logic in the process definition and distributed it to the control plane. This rule specifies that the response traffic of the order service specific interface (POST / api / order / complete) will be 100% mirrored.

[0066] 2. Interception and Context Matching (corresponding to step S5): The order service (upstream) completes processing and returns a response. Its network proxy (Sidecar) intercepts the outbound traffic and matches it to the aforementioned mirroring rules based on the request's metadata (Path, Method).

[0067] 3. Asynchronous fan-out (corresponding to step S5): Without blocking the main business response (return to the caller), the network proxy automatically creates a traffic copy and sends it asynchronously to the inventory service and logistics service.

[0068] 4. Telemetry Feedback: The network agent collects metrics such as latency and success rate of main calls and mirror calls, and asynchronously reports them to the monitoring center. By analyzing this telemetry data, the orchestration control module 130 can dynamically issue rate limiting or circuit breaker rules if downstream service congestion is detected, thereby achieving load-aware adaptive orchestration.

[0069] The beneficial effects of this embodiment are: it achieves complete decoupling from downstream consumers and zero latency in the main process. The order service only needs to return a response once, and the Sidecar agent is responsible for silently copying and forwarding the data to downstream systems (inventory, logistics) in the background. The main business process is unaware of zero latency, and downstream failures will not block upstream processes. Adding or removing downstream systems only requires updating the rules, without modifying the business code.

[0070] The above embodiments provide a detailed description of the present invention, using specific examples to illustrate the principles and implementation methods. The descriptions of these embodiments are merely for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A service mesh based complex business orchestration method, characterized in that, The method comprises the following steps: S1, a deployment step: deploying one or more business services as containerized applications running on a container management platform, the container management platform running a service mesh, and the containerized applications each being associated with a network proxy; S2, an acquisition step: acquiring, by an orchestration control module, a declarative business process definition, the business process definition including multiple business task nodes and execution dependency relationships between the nodes; S3, a translation step: the orchestration control module translating the business process definition into at least one set of network traffic governance rules; S4, a delivery step: the orchestration control module delivering the network traffic governance rules to a control plane of the service mesh; S5, an execution step: the network proxy intercepting and dynamically routing service calls between the containerized applications according to the network traffic governance rules received from the control plane, to drive the jumping between task nodes in the business process definition.

2. The method of claim 1, wherein, The translation step further comprises: translating a specific task node in the business process definition into a declarative resource definition; the delivery step further comprises: submitting the declarative resource definition to the container management platform; and the execution step further comprises: the container management platform automatically allocating resources and executing one or more containerized application instances to complete the specific task node according to the declarative resource definition.

3. The method of claim 2, wherein, The declarative resource definition specifies a container image and a set of resource requirements; the container image encapsulates business tools, software libraries, and runtime environments required to execute the specific task node.

4. The method of claim 1, wherein, The network traffic governance rules include conditional routing rules; the orchestration control module is further configured to monitor the current state of the business process; when the state changes, the orchestration control module automatically updates and delivers the conditional routing rules, so that the network proxy routes subsequent network traffic to the next task node in the business process.

5. The method of claim 1, wherein, The network traffic governance rules include traffic replication rules; the execution step further comprises: when the network proxy intercepts a call from a certain upstream business service, the network proxy automatically replicates and forwards the call to one or more predefined downstream business services according to the traffic replication rules.

6. The method of claim 1, wherein, The network proxy is further configured to automatically provide a reliability mechanism for business service calls according to a preset policy, the reliability mechanism including retry, timeout, or circuit breaking.

7. The method of claim 1-6, wherein, Further comprising: Acquiring telemetry data: the orchestration control module acquires telemetry data from the service mesh; Dynamic adjustment: the orchestration control module dynamically adjusts the network traffic governance rules according to the telemetry data, to achieve load-aware scheduling of the business process.

Images