Cloud service bus-based resource cross-domain service orchestration system and method

Abstract

The application discloses a resource cross-domain service arrangement system and method based on a cloud service bus, relates to the technical field of cloud computing and service computing, and comprises an external interaction layer, a management control layer, an event-driven enhancement layer and an edge execution layer. The external interaction layer is connected with the management control layer and is used for receiving external service requests and forwarding the same to the inside. The management control layer is connected with the event-driven enhancement layer and is used for realizing service arrangement, policy control and network management. The event-driven enhancement layer is connected with the edge execution layer and is used for realizing scheduling optimization, service quality coordination and fault recovery based on an event stream. The application introduces the cloud service bus as a unified event communication mechanism, combines a policy engine, a hybrid scheduling mechanism and a cross-domain service quality coordination module, realizes dynamic management of service deployment, resource scheduling and system fault recovery, and thus improves the real-time performance, flexibility and reliability of the service arrangement system.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing and service computing technology, and further to the fields of cloud-native systems, microservice architecture, and distributed resource scheduling technology, especially a resource cross-domain service orchestration system and method based on cloud service bus. Background Technology

[0002] With the development of cloud computing, microservice architecture, and containerization technology, modern application systems typically consist of multiple loosely coupled service components. To achieve automated deployment, resource scheduling, and operational management of complex business systems, service orchestration technology is needed to uniformly manage the call relationships, execution order, and resource dependencies among multiple services. Service orchestration technology typically involves key functions such as service deployment, service lifecycle management, resource scheduling, and inter-service communication coordination, and is one of the important foundational technologies for cloud-native and distributed systems.

[0003] Currently, in cloud computing environments, service orchestration typically relies on container orchestration platforms or workflow orchestration systems. For example, container orchestration systems, such as Kubernetes, use schedulers and controllers to automate the deployment, scaling, and fault recovery of container instances, thereby enabling unified management of large-scale microservice applications. Furthermore, workflow-based service orchestration technologies define service execution flows or task pipelines to combine and invoke multiple services to complete complex business logic.

[0004] There are still some shortcomings in the existing technology: (1) The orchestration mechanism is mostly static, which makes it difficult to respond to changes in the system's operating status in real time. The existing technology usually generates a fixed process template or execution plan before service deployment or business process execution. When the system resource utilization, network status or service load changes, the orchestration system is difficult to dynamically adjust the service deployment strategy in a timely manner. (2) There is a lack of a unified event-driven communication mechanism. Many existing orchestration systems obtain information such as node resource utilization and service health status through periodic polling. This method not only increases the system communication and computing overhead, but also causes the system status perception to lag, thereby affecting the real-time performance of orchestration decisions. (3) The policy logic and execution mechanism are highly coupled. In traditional orchestration systems, the scheduling strategy is usually embedded in the system code or process template. When it is necessary to adapt to new business scenarios or deployment environments, the core logic of the system needs to be modified, resulting in poor system scalability and maintainability. (4) There is insufficient cross-domain service quality coordination capability. In multi-cloud or edge computing environments, service deployment nodes are usually distributed across different computing resource domains, with significant differences in network latency, resource load, and node performance. Existing orchestration systems typically lack a unified cross-domain Quality of Service (QoS) coordination mechanism. (5) Insufficient system self-healing capability. When service instances experience anomalies, node failures, or sudden increases in system load, existing orchestration systems typically only provide simple restart or rescheduling mechanisms, making it difficult to achieve automated fault detection and recovery. Summary of the Invention

[0005] To overcome the aforementioned problems in the existing technology, this invention proposes a resource cross-domain service orchestration system and method based on cloud service bus.

[0006] The technical solution adopted by this invention to solve its technical problem is: a cross-domain service orchestration system based on cloud service bus, comprising an external interaction layer, a management and control layer, an event-driven enhancement layer, and an edge execution layer. The external interaction layer is connected to the management and control layer and is used to receive external service requests and forward them internally. The management and control layer is connected to the event-driven enhancement layer and is used to implement service orchestration, policy control, and network management. The event-driven enhancement layer is connected to the edge execution layer and is used to implement scheduling optimization, service quality coordination, and fault recovery based on event flow.

[0007] The aforementioned cross-domain resource service orchestration system based on cloud service bus also includes a data support layer, which is connected to the management and control layer, the event-driven enhancement layer, and the edge execution layer, respectively, and is used to provide support for monitoring data caching, aggregation, and persistent storage.

[0008] The aforementioned cross-domain service orchestration system based on cloud service bus includes the following components: the management and control layer comprises a domain management module, an orchestration management module, a deployment management module, a policy engine module, a network management module, a service description storage module, a capability publishing module, and a monitoring module for authentication and permission verification; the event-driven enhancement layer comprises a cloud service bus, a hybrid scheduling module, a cross-domain service quality coordination module, a self-healing and rollback module, and a recovery policy library; and the edge execution layer comprises multiple edge nodes, each edge node comprising an edge orchestration module, a configuration reconciliation module, a service mesh management module, and a network function instance.

[0009] In the aforementioned cross-domain resource orchestration system based on cloud service bus, the policy engine module is used to receive events from the cloud service bus, generate corresponding orchestration decisions according to predefined policy rules, and send them to the orchestration management module.

[0010] In the aforementioned cross-domain service orchestration system based on cloud service bus, the hybrid scheduling module continuously receives real-time events from the cloud service bus and dynamically adjusts the task execution order and resource allocation strategy according to the system's operating status; when node resources are insufficient, the services to be deployed are migrated to other nodes; when the system load increases, the deployment priority of critical services is increased.

[0011] In the aforementioned cross-domain service orchestration system based on cloud service bus, the cross-domain service quality coordination module is used to collect system operation indicators and perform comprehensive analysis on the collected indicators to determine whether the current service meets the established service level agreement.

[0012] The resource cross-domain service orchestration method based on cloud service bus, based on the aforementioned resource cross-domain service orchestration system based on cloud service bus, specifically includes the following steps: Step 1, Receive Service Deployment Request: Receive service deployment requests from the external interaction layer. The domain management module performs identity authentication and permission verification on the request, and checks the legality of the service description information. Once the request is verified, the deployment request is forwarded to the orchestration management module. Step 2, execute deployment access control: The deployment management module executes access control and obtains the resource status information of each edge node through the monitoring module. If the system resources meet the service deployment requirements, proceed to step 3; otherwise, reject the deployment request or select a new deployment node. Step 3, Parse service descriptions and build dependency graphs: Parse service description information, extract dependencies between service components, and build service dependency graphs; Step 4, Generate Initial Service Deployment Plan: Execute a topology sorting algorithm based on the service dependency graph from Step 3 to generate the deployment order of service components, and publish deployment events through the cloud service bus; Step 5, Execute time-driven hybrid scheduling: After receiving a deployment event, the hybrid scheduling module uses a hybrid scheduling strategy of static planning and event-driven adjustment to execute service scheduling operations; Step 6, Service Deployment and Operation: After the scheduling decision is completed, the system sends deployment instructions to the edge stage. The local orchestration component on the edge node receives the deployment instructions and executes the creation of service instances, updating service configurations, and deleting service instances. The local orchestration component keeps the node's running state consistent with the system's expected state through a configuration reconciliation mechanism. After the service instance is deployed, it provides business services.

[0013] The aforementioned cross-domain service orchestration method based on cloud service bus involves the monitoring module continuously collecting service operation information and calculating service performance indicators based on the service quality assessment model during system operation. Simultaneously, the monitoring module continuously monitors the service instance operation status. When the system detects abnormal situations such as service instance crashes, node offline events, or abnormal service error rates, the system publishes the abnormal event to the cloud service bus. Upon receiving the abnormal event, the fault recovery module selects an appropriate recovery strategy from the recovery strategy library. After the recovery strategy is executed, the system updates the service operation status and restores normal operation.

[0014] The service quality assessment model in the above-mentioned cross-domain service orchestration method based on cloud service bus is as follows: QoS_score=w1×ResponseTime+w2×ErrorRate+w3×ResourceUsage Wherein, ResponseTime represents the service response time, ErrorRate represents the service error rate, ResourceUsage represents the resource utilization rate, and w1, w2, and w3 are weight parameters; when the QoS_score exceeds the preset threshold, the system determines that the service quality has deteriorated and triggers resource adjustment operations.

[0015] The beneficial effects of this invention are that by introducing a cloud service bus as a unified event communication mechanism, and combining it with a policy engine, a hybrid scheduling mechanism, and a cross-domain QoS coordination module, it achieves dynamic management of service deployment, resource scheduling, and system fault recovery, thereby improving the real-time performance, flexibility, and reliability of the service orchestration system. This invention implements an event-driven service orchestration mechanism, improving system response speed. A pluggable policy engine decouples policies from execution logic, improving system scalability. A hybrid scheduling mechanism enhances the flexibility of deploying complex services. The introduction of a cross-domain QoS coordination mechanism improves service quality assurance capabilities. Self-healing and fallback mechanisms improve system reliability and fault tolerance. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the system of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the technical solution of the present invention, the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] This embodiment discloses a cross-domain resource service orchestration system based on a cloud service bus, such as... Figure 1 As shown, the blue section represents service orchestration across management and edge domains, the orange section represents monitoring and telemetry data acquisition, the green section represents network and quality of service management, and the red section represents self-healing control paths. It includes an external interaction layer, a management control layer, an event-driven enhancement layer, an edge execution layer, and a data support layer. The external interaction layer is connected to the management control layer and is used to receive external service requests and forward them internally. The management control layer is connected to the event-driven enhancement layer and is used to implement service orchestration, policy control, and network management. The event-driven enhancement layer is connected to the edge execution layer and is used to implement scheduling optimization, quality of service coordination, and fault recovery based on event flows. The data support layer is connected to the management control layer, the event-driven enhancement layer, and the edge execution layer respectively, and is used to provide monitoring data caching, aggregation, and persistent storage support.

[0019] The management and control layer includes a domain management module, an orchestration management module, a deployment management module, a policy engine module, a network management module, a service description storage module, a capability publishing module, and a monitoring module for authentication and permission verification; the event-driven enhancement layer includes a cloud service bus, a hybrid scheduling module, a cross-domain service quality coordination module, a self-healing and rollback module, and a recovery policy library; the edge execution layer includes multiple edge nodes, each edge node including an edge orchestration module, a configuration reconciliation module, a service mesh management module, and a network function instance.

[0020] A Cloud Service Bus (CSB) is introduced into the system architecture to achieve unified communication and event distribution among system modules. The CSB employs a publish / subscribe communication mechanism, allowing each system component to participate in system operation as either an event publisher or subscriber. During system operation, the monitoring module continuously collects system status information, such as node resource utilization, service response time, network latency, service instance health status, and system fault alarms. This information is encapsulated as system events and published to the CSB. The service orchestration engine subscribes to relevant events to achieve real-time awareness of the system status. This mechanism avoids the performance overhead of traditional polling monitoring and improves system response speed.

[0021] To enable flexible expansion of orchestration policies, this embodiment designs a pluggable policy engine module. The policy engine receives events from the cloud service bus and generates corresponding orchestration decisions based on predefined policy rules. The policy engine supports multiple rule execution frameworks, such as Drools, OpenPolicyAgent (OPA), and the Rego rule language. The policy engine executes corresponding policies based on system state changes; for example, it triggers scaling operations when node CPU utilization exceeds a threshold; it triggers service migration when service response time exceeds SLA requirements; and it triggers service instance redeployment when a node fails. The policy engine converts the generated decision results into specific orchestration operations and sends them to the orchestration execution module. This design decouples orchestration policies from execution logic, improving system scalability.

[0022] This invention proposes a hybrid scheduling mechanism combining static planning and real-time scheduling. During the service deployment phase, the system first constructs a service dependency model based on the application blueprint and uses a directed acyclic graph (DAG) to describe the dependencies between services. An initial execution order for service deployment is generated using a topology sorting algorithm, forming a basic orchestration plan. During system operation, the hybrid scheduling module continuously receives real-time events from the cloud service bus and dynamically adjusts the task execution order and resource allocation strategy according to the system's operating status. When node resources are insufficient, services to be deployed are migrated to other nodes; when system load increases, the deployment priority of critical services is increased. Through this mechanism, the system can achieve dynamic optimization scheduling while maintaining the correctness of service dependencies.

[0023] To ensure service quality in multi-cloud or multi-edge environments, this invention designs a cross-domain service quality coordination module. This module is responsible for collecting system operation metrics, including service response time, throughput, network latency, packet loss rate, and error rate. The system comprehensively analyzes these metrics using a QoS evaluation model and determines whether the current service meets the established Service Level Agreement (SLA). When a service quality degradation is detected, the system triggers corresponding optimization measures: adjusting the deployment location of service instances; adjusting network routing policies; and increasing the number of service instances. In specific implementations, the QoS coordination module can be combined with service mesh technologies (such as Istio) to achieve fine-grained traffic management.

[0024] To improve system stability, this invention incorporates self-healing and rollback mechanisms. When the system detects abnormal events such as service instance crashes, node disconnections, or increased service error rates, it selects an appropriate recovery strategy from a predefined recovery strategy library. Recovery strategies include: automatic service instance restart, service instance migration, service version rollback, and service traffic degradation. After recovery is complete, the system feeds back the execution results to the cloud service bus, thus forming a closed-loop control mechanism.

[0025] Figure 1 In this context, the service orchestration control flow is used to implement deployment request distribution and configuration control, the monitoring data flow is used to implement node status reporting and decision support, and the rollback / failover action flow is used to implement service recovery and migration control in abnormal situations.

[0026] Based on the above system, this embodiment also proposes an event-driven service orchestration method based on a cloud service bus, which is suitable for distributed service deployment and management in multi-cloud or edge computing environments. The system mainly includes an external interface module, a management and control module, an event scheduling module, and an edge execution module, and realizes closed-loop control of service deployment, resource scheduling, and system recovery through a unified event communication mechanism.

[0027] The overall operation process of this method includes the following steps: Step S1: Receive service deployment request The system first receives service deployment requests from external systems via the northbound interface. These external callers can be business systems, management portals, or cross-domain service orchestration systems.

[0028] Service deployment requests typically include the following information: service description file, service resource requirements, service dependencies, network communication requirements, and deployment strategy parameters. Upon receiving a service request, the system forwards it to the domain management module for parsing.

[0029] The domain management module is responsible for authenticating and verifying the permissions of requests, as well as checking the validity of service description information. Once the request is verified, it is forwarded to the orchestration management module.

[0030] Step S2: Implement deployment access control After receiving a service deployment request, the orchestration management module calls the deployment management module to execute admission control. Admission control is used to determine whether the current system resources meet the service deployment requirements. The system obtains resource status information of each edge node through the monitoring module, including: CPU utilization, memory usage, network bandwidth, and storage resources. If the system resources meet the service deployment requirements, it proceeds to the next stage; otherwise, the system can reject the deployment request or select a new deployment node.

[0031] Step S3: Parse the service description and build the dependency graph After admission control is passed, the system parses the service description file and extracts the dependencies between service components. Based on the parsing results, the system constructs a service dependency graph, represented by a directed acyclic graph (DAG): each node represents a service component; each edge represents a dependency between services. For example, when service B depends on service A, a directed edge from A to B is created in the dependency graph. Using this dependency graph, the system can determine the deployment order between service components.

[0032] Step S4: Generate initial service deployment plan The system executes a topological sorting algorithm based on the service dependency graph to generate the deployment order of service components. Let the service dependency graph be G=(V,E), where V represents the set of service components and E represents the set of service dependencies. The system calculates the deployment sequence through topological sorting: DeployOrder=TopologicalSort(G). This deployment sequence guides the service deployment order, thereby ensuring that service dependencies are satisfied.

[0033] Step S5: Publish deployment events via cloud service bus After generating the service deployment plan, the system publishes service deployment events through the cloud service bus. The cloud service bus is built on a publish-subscribe communication mechanism, allowing modules within the system to collaborate by subscribing to events. For example, the scheduling module subscribes to deployment events, the QoS coordination module subscribes to performance monitoring events, and the fault recovery module subscribes to exception events. In this way, the system achieves decoupled communication between modules.

[0034] Step S6: Execute event-driven hybrid scheduling The hybrid scheduling module executes service scheduling operations upon receiving a deployment event. It employs a hybrid scheduling strategy combining static planning and event-driven adjustments. During the initial service deployment phase, the system generates a static deployment plan based on the service dependency graph. During system operation, the scheduling module continuously monitors the event stream in the cloud service bus. When the system detects events such as changes in node resources, network latency, or service performance degradation, the scheduling module recalculates the scheduling strategy based on real-time events. For example, when a node's resource load is too high, the system can execute a service migration operation: `TargetNode = argmin(ResourceLoad)`, thereby migrating the service instance to the node with the lowest resource utilization.

[0035] Step S7: Perform service quality assessment and optimization The system continuously collects service operation status information through the monitoring module and calculates service performance indicators based on the service quality assessment model. The service quality assessment model can be expressed as: QoS_score=w1×ResponseTime+w2×ErrorRate+w3×ResourceUsage Where: ResponseTime represents the service response time, ErrorRate represents the service error rate, ResourceUsage represents the resource utilization rate, and w1, w2, and w3 are weight parameters.

[0036] When the QoS_score exceeds the preset threshold, the system determines that the service quality has deteriorated and triggers resource adjustment operations, such as: expanding the number of service instances, adjusting service deployment nodes, and modifying service traffic routing policies.

[0037] This mechanism enables the system to manage service quality across domains.

[0038] Step S8: Perform service deployment and operation After the scheduling decision is made, the system sends deployment instructions to the edge nodes. The local orchestration component on the edge node receives the deployment instructions and performs the following operations: creating a service instance, updating the service configuration, and deleting the service instance. Simultaneously, the local orchestration component maintains the node's running state consistent with the system's expected state through a configuration reconciliation mechanism. Once the service instance is deployed, it begins providing business services.

[0039] Step S9: Perform fault detection and automatic recovery During system operation, the monitoring module continuously monitors the running status of service instances. When the system detects abnormal situations such as service instance crashes, node offline events, or abnormal service error rates, it publishes the abnormal event to the cloud service bus. Upon receiving the abnormal event, the fault recovery module selects an appropriate recovery strategy from the recovery strategy library, such as restarting the service instance, migrating the service to another node, or rolling back to a stable version. After the recovery strategy is executed, the system updates the service running status and resumes normal operation. Through the above implementation method, this invention constructs an event-driven service orchestration method based on a cloud service bus.

[0040] This method decouples system modules through a unified event communication mechanism and combines a hybrid scheduling strategy, a quality of service coordination mechanism, and an automatic recovery mechanism to achieve closed-loop control of service deployment, resource scheduling, and system recovery.

[0041] The above embodiments are merely exemplary embodiments of the present invention and are not intended to limit the present invention. Those skilled in the art can make various modifications or equivalent substitutions to the present invention within its scope and spirit, and such modifications or equivalent substitutions should also be considered to fall within the scope of protection of the present invention.

Claims

1. A resource cross-domain service orchestration system based on cloud service bus, characterized in that, It includes an external interaction layer, a management and control layer, an event-driven enhancement layer, an edge execution layer, and a data support layer. The external interaction layer is connected to the management and control layer and is used to receive external service requests and forward them internally. The management and control layer is connected to the event-driven enhancement layer and is used to implement service orchestration, policy control, and network management. The event-driven enhancement layer is connected to the edge execution layer and is used to implement scheduling optimization, service quality coordination, and fault recovery based on event streams. The data support layer is connected to the management and control layer, the event-driven enhancement layer, and the edge execution layer respectively and is used to provide monitoring data caching, aggregation, and persistent storage support. The management and control layer includes a domain management module, an orchestration management module, a deployment management module, a policy engine module, a network management module, a service description storage module, a capability publishing module, and a monitoring module for authentication and permission verification; the event-driven enhancement layer includes a cloud service bus, a hybrid scheduling module, a cross-domain service quality coordination module, a self-healing and rollback module, and a recovery policy library; the edge execution layer includes multiple edge nodes, each edge node including an edge orchestration module, a configuration reconciliation module, a service mesh management module, and a network function instance; The policy engine module is used to receive events from the cloud service bus, generate corresponding orchestration decisions according to predefined policy rules, and send them to the orchestration management module. The hybrid scheduling module continuously receives real-time events from the cloud service bus and dynamically adjusts the task execution order and resource allocation strategy according to the system operating status. When node resources are insufficient, migrate the services to be deployed to other nodes; when system load increases, increase the deployment priority of critical services. The cloud service bus adopts a publish-subscribe communication mechanism, and each system component participates in the system operation as an event publisher or event subscriber. The monitoring module encapsulates the collected system operation status information into system events and publishes them to the cloud service bus. During system operation, the monitoring module continuously collects service operation status information and calculates service performance indicators based on the service quality assessment model. At the same time, the monitoring module continuously monitors the operation status of service instances. When the system detects service instance crashes, nodes going offline, or abnormal service error rates, the system publishes the abnormal events to the cloud service bus. After receiving an abnormal event, the self-healing and rollback module selects an appropriate recovery strategy from the recovery strategy library. After the recovery strategy is executed, the system updates the service running status and restores normal operation. The service quality assessment model is as follows: QoS_score=w1×ResponseTime+w2×ErrorRate+w3×ResourceUsage Wherein, ResponseTime represents the service response time, ErrorRate represents the service error rate, ResourceUsage represents the resource utilization rate, and w1, w2, and w3 are weight parameters; when the QoS_score exceeds the preset threshold, the system determines that the service quality has deteriorated and triggers resource adjustment operations.

2. The resource cross-domain service orchestration system based on cloud service bus according to claim 1, characterized in that, The cross-domain service quality coordination module is used to collect system operation indicators and perform comprehensive analysis on the collected indicators to determine whether the current service meets the established service level agreement.

3. A method for orchestrating cross-domain resource services based on a cloud service bus, characterized in that, The resource cross-domain service orchestration system based on cloud service bus as described in any one of claims 1-2 specifically includes the following steps: Step 1, Receive Service Deployment Request: Receive service deployment requests from the external interaction layer. The domain management module performs identity authentication and permission verification on the request, and checks the legality of the service description information. Once the request is verified, the deployment request is forwarded to the orchestration management module. Step 2, execute deployment access control: The deployment management module executes access control and obtains the resource status information of each edge node through the monitoring module. If the system resources meet the service deployment requirements, proceed to step 3; otherwise, reject the deployment request or select a new deployment node. Step 3, Parse service descriptions and build dependency graphs: Parse service description information, extract dependencies between service components, and build service dependency graphs; Step 4, Generate Initial Service Deployment Plan: Execute a topology sorting algorithm based on the service dependency graph from Step 3 to generate the deployment order of service components, and publish deployment events through the cloud service bus; Step 5, execute a hybrid scheduling strategy that combines static planning and event-driven adjustment: After receiving a deployment event, the hybrid scheduling module executes service scheduling operations using a hybrid scheduling strategy that combines static planning and event-driven adjustment. Step 6, Service Deployment and Operation: After the scheduling decision is completed, the system sends deployment instructions to the edge nodes. The local orchestration component on the edge nodes receives the deployment instructions and executes the creation of service instances, updating service configurations, and deleting service instances. The local orchestration component maintains the node's running state consistent with the system's expected state through a configuration reconciliation mechanism. After the service instance is deployed, it provides business services.

Images