Service chain arrangement method

Abstract

The invention discloses a service chain arrangement method. The method comprises the following steps: completing unified modeling, generation, distribution and recovery of a service chain strategy in a dynamically configured logic control plane; service nodes are directly hooked to a network plane, and flow forwarding is realized through a unified virtual exchange network bridge; a flow table engine in the control plane converts service chain configuration into a directed acyclic graph, topological sorting and rule combination optimization are carried out, flow table rules are generated, and priorities are automatically distributed; the control plane adopts a Cookie collision detection and self-adaptive redistribution algorithm based on a Bloom filter and secondary hash to generate a unique Cookie prefix for the tenant; the control plane performs incremental updating on the service chain change by adopting an incremental difference calculation and minimum updating algorithm based on an editing distance; and the control plane performs service chain path selection and load balancing by adopting a service chain path optimization algorithm based on the shortest path and load awareness. According to the method, performance, isolation and high availability can be considered in a multi-tenant environment.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a service chain orchestration method. Background Technology

[0002] In cloud platforms, service chain orchestration is a key technology for achieving Network Functions Virtualization (NFV). Existing mainstream solutions lack sufficient orchestration and processing capabilities at the L2 / L3 layers, making it difficult to flexibly and efficiently control the forwarding of Layer 2 and Layer 3 traffic. This limits the diverse applications of network functions such as firewalls, intrusion detection, traffic mirroring, and load balancing. Meanwhile, service meshes commonly employ a sidecar pattern, requiring the deployment of proxy containers alongside each service instance, resulting in significant CPU / memory and network overhead. Service traffic must be forwarded via sidecars, further increasing latency and jitter, making it difficult to meet the requirements of large-scale multi-tenant and high-performance scenarios. As the number of tenants and service instances grows, achieving efficient isolation and fine-grained traffic management between tenants and service chains while ensuring performance has become a core challenge for cloud platform service chain orchestration. Summary of the Invention

[0003] To address the problems existing in the prior art, embodiments of this application provide a method, system, computing device, computer storage medium, and product containing computer programs for service chain orchestration, which can balance performance, isolation, and high availability in complex multi-tenant environments.

[0004] In a first aspect, embodiments of this application provide a service chain orchestration method, comprising: a control plane dynamically configuring a logical control plane for each tenant, and completing unified modeling, generation, distribution, and recycling of service chain policies within the logical control plane; a data plane adopting a sidecarless mode, directly connecting service nodes to the network plane, and achieving traffic forwarding through a unified virtual switching bridge; a flow table engine in the control plane converting the service chain configuration into a directed acyclic graph, performing topology sorting and rule merging optimization, generating flow table rules, and automatically assigning priorities; the control plane employing a cookie collision detection and adaptive reallocation algorithm based on Bloom filters and quadratic hashing to generate a unique cookie prefix for each tenant; the control plane employing an incremental difference calculation and minimization update algorithm based on edit distance to incrementally update service chain changes; and the control plane employing a service chain path optimization algorithm based on shortest path and load awareness to perform service chain path selection and load balancing.

[0005] In some possible implementations, the topology sorting and rule merging optimization includes: constructing a directed acyclic graph by treating service nodes in the service chain configuration as nodes of a graph and traffic paths and dependencies between nodes as edges; performing topology sorting using the Kahn algorithm or depth-first search to determine the logical order of rule execution; identifying rules with the same matching conditions and performing consecutive actions, and merging them into a single rule; and automatically assigning OpenFlow priorities based on the topology sorting results.

[0006] In some possible implementations, the cookie collision detection and adaptive reallocation algorithm based on Bloom filters and quadratic hashing specifically includes: pre-detecting the generated cookie prefix using a Bloom filter; if the Bloom filter indicates a possible collision, querying the global key-value store for precise confirmation; if a collision is confirmed, regenerating the cookie prefix using a quadratic hashing strategy, where the nonce is initially 0 and incremented by 1 after each collision; and performing atomic declaration-verification-occupancy operations in the global key-value store to ensure the global uniqueness of the tenant's cookie prefix.

[0007] In some possible implementations, the incremental difference calculation and minimum update algorithm based on edit distance specifically includes: converting the old and new rule sets into an ordered sequence sorted by priority; using the Wagner-Fischer algorithm to calculate the edit distance between the old and new rule sets, identifying the minimum edit path, including insertion, deletion, and modification operations; using matching domain hashing to quickly identify identical rules and avoid duplicate calculations; and merging multiple operations into a single OpenFlow transaction to ensure the atomicity and consistency of the update.

[0008] In some possible implementations, the service chain path optimization algorithm based on shortest path and load awareness includes: constructing a service chain topology graph, where nodes are service instances, and edge weights comprehensively consider latency, load, and bandwidth; calculating the shortest path using an improved Dijkstra algorithm, while also considering the real-time load of nodes; selecting K candidate paths as alternatives using the K-shortest path algorithm; and using a multi-dimensional comprehensive model for path scoring: Score(path) = α∙latency + β∙load + γ∙cost, where α, β, and γ are weight coefficients that are dynamically adjusted based on real-time monitoring data, latency is latency, load is load, and cost is resource cost.

[0009] In some possible implementations, the method also includes a multi-layer traffic processing and isolation mechanism, specifically: supporting pass-through and mirroring orchestration based on ports, MAC addresses, IP addresses, VLANs, and routes at the L2 / L3 layer; implementing application-level traffic redirection and extension actions at the L7 layer by cooperating with upper-layer policies and identifiers; and achieving multi-dimensional fine-grained isolation of tenants, namespaces, steps, and sessions through OpenFlowcookie and table entry layering.

[0010] In some possible implementations, the method also includes a high availability mechanism: selecting the primary node based on the earliest Ready and health probes, and automatically switching to the backup node when the primary node fails; and using incremental reordering and atomic replacement to ensure seamless link recovery.

[0011] In some possible implementations, the virtual switching bridge is br-servicechain, which is deployed on each compute node. All tenants' Pods on the same compute node are uniformly connected to br-servicechain, and strong isolation between tenants is achieved through OpenFlow Cookie prefixes.

[0012] In some possible implementations, the method also includes a cross-host orchestration mechanism: allocating independent VXLAN tunnels for services such as mirroring / bypassing to achieve cross-host orchestration and non-interference in concurrent service chain links.

[0013] In some possible implementations, the method also includes adaptive refactoring and incremental hot updates of the service chain: automatically executing bypass, switching, and rollback strategies for abnormal links, and supporting versioned management and on-demand recycling of policies and states.

[0014] In some possible implementations, the service chain configuration is received via a Kubernetes Custom Resource (CRD) or a RESTful API and includes tenant identifiers, a list of service nodes, traffic matching rules, and forwarding actions.

[0015] Secondly, embodiments of this application provide a computer-readable storage medium including computer-readable instructions that, when read and executed by a computer, cause the computer to perform the method described in any of the first aspects.

[0016] Thirdly, embodiments of this application provide a computing device, including a processor and a memory, wherein the memory stores computer program instructions, which, when executed by the processor, perform the method as described in any of the first aspects.

[0017] Fourthly, embodiments of this application provide a product comprising a computer program that, when the computer program product is run on a processor, causes the processor to perform the method as described in any of the first aspects. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. 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.

[0019] Figure 1 This is a schematic diagram of the structure of a service chain orchestration system provided in an embodiment of this application.

[0020] Figure 2 This is a schematic diagram of a service chain controller provided in an embodiment of this application.

[0021] Figure 3 This is a schematic diagram illustrating the implementation process of a cookie collision detection algorithm provided in an embodiment of this application.

[0022] Figure 4 This is a schematic diagram illustrating the implementation process of a path optimization algorithm provided in an embodiment of this application.

[0023] Figure 5 This is a schematic diagram illustrating the implementation process of an incremental update algorithm provided in an embodiment of this application.

[0024] Figure 6 This is a schematic diagram of a virtual forwarding plane management component provided in an embodiment of this application.

[0025] Figure 7 This is a schematic diagram of a flow table engine provided in an embodiment of this application.

[0026] Figure 8 This is a schematic diagram illustrating the implementation process of a topological sorting algorithm provided in an embodiment of this application.

[0027] Figure 9 This is a schematic diagram illustrating the implementation process of a rule merging optimization algorithm provided in an embodiment of this application.

[0028] Figure 10 This is a schematic diagram of the implementation process of L2 / L3 layer traffic processing provided in an embodiment of this application.

[0029] Figure 11 This is a schematic diagram of the implementation process of L7 layer traffic processing provided in an embodiment of this application.

[0030] Figure 12 This is a schematic diagram illustrating the implementation process of a service chain isolation mechanism provided in an embodiment of this application.

[0031] Figure 13This is a schematic diagram illustrating the implementation process of a high availability mechanism provided in an embodiment of this application. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, 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.

[0033] In this article, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.

[0034] The terms "first" and "second," etc., used in the specification and claims herein are used to distinguish different objects, not to describe a specific order of objects. For example, "first response message" and "second response message," etc., are used to distinguish different response messages, not to describe a specific order of response messages.

[0035] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0036] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, for example, multiple processing units means two or more processing units, multiple elements means two or more elements, etc.

[0037] To facilitate understanding of the embodiments of this application, the following will provide further explanation and description with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of the present invention.

[0038] Cloud platform service chain orchestration includes multiple aspects such as flow table rule generation and optimization, tenant isolation and cookie management, service chain path selection and load balancing, incremental updates and differential calculations, etc.

[0039] In terms of flow table rule generation and optimization, existing solutions generally adopt sequential generation or simple rule distribution mechanisms, lacking in-depth analysis and optimization of the service chain topology. Traditional methods treat each service node in the service chain as an independent rule, generating and distributing them sequentially, resulting in a large number of rules and poor matching performance; rule priority allocation relies on manual configuration, which is prone to priority conflicts and execution order errors; rule updates use a full replacement method, resulting in high network overhead and high update latency, making it difficult to meet the dynamic orchestration requirements of large-scale service chains. In addition, existing solutions lack systematic algorithmic support for rule merging, deduplication, and topology optimization, failing to fully utilize the topological characteristics of the service chain for rule simplification and performance optimization.

[0040] In terms of tenant isolation and cookie management, existing solutions mostly employ simple hash generation or sequential allocation mechanisms, lacking efficient collision detection and redistribution strategies. As the number of tenants increases, the probability of cookie prefix collisions rises. Traditional solutions require frequent queries to the global storage for collision detection, resulting in significant performance overhead. Post-collision redistribution strategies are simple and lack adaptive mechanisms, potentially leading to redistribution failures or performance degradation. Existing solutions do not fully utilize efficient data structures such as Bloom filters for pre-detection, nor do they establish mathematical models for collision probabilities, making it difficult to achieve high-performance cookie generation and management while ensuring uniqueness.

[0041] In terms of service chain path selection and load balancing, existing solutions mostly adopt static path configuration or simple load balancing algorithms, lacking comprehensive consideration of network topology, node load, and link bandwidth. Traditional methods cannot dynamically adjust path weights based on real-time load, which can easily lead to some nodes being overloaded while other nodes are idle. Path selection only considers a single dimension (such as the shortest path or the lowest load), and cannot comprehensively optimize across multiple objectives (latency, load, cost). The lack of a multi-path alternative mechanism results in high switching latency when the primary path fails, affecting service availability.

[0042] Regarding incremental updates and difference calculations, existing solutions generally employ full replacement or simple rule comparison mechanisms, which cannot identify the minimum set of differences within the rule set. Traditional methods require redistributing all rules, resulting in high network overhead and update latency; simple rule comparisons cannot identify editing relationships (insertion, deletion, modification) between rules, leading to unnecessary rule operations; and the lack of a batch atomic update mechanism may result in brief inconsistencies during rule updates, affecting the reliability of the service chain.

[0043] The sidecar pattern was originally designed to achieve functional decoupling and flexible orchestration by deploying a proxy container next to the service instance. However, large-scale deployments have revealed three problems: first, high resource consumption and high cost of elastic scaling; second, high management complexity, with a lengthy upgrade, observation, and governance chain; and third, an extra hop in the data plane, leading to performance bottlenecks and stability risks, affecting overall service quality. Against this backdrop, the sidecarless pattern has gradually emerged.

[0044] The sidecarless mode integrates network functions directly into the network plane, with the network side uniformly carrying the service chain capabilities. This avoids injecting proxy containers into each service instance, significantly reducing system resource consumption and daily operational complexity. Since business traffic does not need to go through additional proxy forwarding, the network path is shortened and side-path loss is reduced, thereby effectively alleviating the performance bottleneck of the traditional sidecar mode and providing a more efficient and lightweight network service foundation for container clouds.

[0045] However, existing sidecarless solutions still have several shortcomings in service chain orchestration.

[0046] First, there is a lack of effective isolation mechanisms for multi-tenant environments. As the number of tenants and services increases, policy conflicts and resource competition easily arise between service chains, making it difficult to implement fine-grained quotas and controls. Second, the service chain is highly coupled with the main business network. Inserting, removing, and replacing service nodes requires extensive reconstruction of network objects, resulting in high change costs. Third, cross-host forwarding capabilities are limited, making it difficult to simultaneously meet enterprise-level high availability requirements such as multi-tunnel concurrency, master-slave failover, and link self-healing. Fourth, there is a lack of efficient flow table rule optimization algorithms. The large number of rules and poor matching performance make it difficult to support large-scale service chain orchestration. Fifth, there is a lack of intelligent path selection and load balancing algorithms, making it impossible to comprehensively optimize across multiple objectives, thus affecting the overall performance and resource utilization of the service chain.

[0047] In view of this, embodiments of this application provide a service chain orchestration method. By dynamically configuring a dedicated logical control plane (control domain) for tenants, the unified modeling, generation, distribution, and recycling of service chain policies are completed within an independent control plane, achieving strong isolation and non-interference concurrency of service chains at the tenant level. The data plane adopts a sidecarless architecture, directly connecting service nodes to the network plane. Combined with objects such as OpenFlow / ACL / logical switches and logical routes in OVS / OVN, it supports unified orchestration and fine-grained traffic control for L2 / L3 / L7. A topology sorting and rule merging optimization algorithm based on directed acyclic graphs (DAG) is introduced to convert service chain configuration into a topology structure. The rule execution order is determined through topology sorting, mergeable rules are identified and merged, and priorities are automatically assigned, significantly reducing the number of rules and improving matching performance. A cookie collision detection and adaptive reallocation algorithm based on Bloom filters and quadratic hashing is introduced to reduce the number of global storage queries through a pre-detection mechanism. The system employs a nonce increment strategy to ensure the uniqueness of cookie prefixes, significantly improving cookie generation performance. It introduces an incremental difference calculation and minimum update algorithm based on edit distance, using the Wagner-Fischer algorithm to calculate the minimum edit path for the rule set, updating only changed rules and merging multiple operations into a single atomic transaction, significantly reducing update overhead and latency. Furthermore, it introduces a service chain path optimization algorithm based on shortest path and load awareness, comprehensively considering multiple dimensions such as latency, load, and cost, using a K-shortest path mechanism to provide alternative paths and dynamically adjusting weights based on real-time load to achieve intelligent path selection and load balancing. It also introduces mechanisms such as multi-VXLAN concurrency, port naming optimization, and alias IP allocation to meet the requirements of cross-host multi-service concurrency, image bypass, and high-availability switching. Finally, it provides the ability to dynamically insert / remove service nodes, and combines health detection, status monitoring, and automatic fault switching to achieve adaptive link reconstruction and incremental hot updates, significantly improving system availability and maintainability.

[0048] For example, Figure 1 This diagram illustrates the structure of a service chain orchestration system provided in an embodiment of this application. This system is used on a Kubernetes container cloud platform and can achieve high-performance, strongly isolated, flexibly orchestrated, and hot-update service chain functionality without the need for traditional sidecar proxies. Figure 1As shown, the service chain orchestration system 100 includes a control plane 101 and a data plane 102, adopting a design pattern that separates the control plane 101 and the data plane 102. The control plane 101 includes a Service Chain Controller 1011, a Virtual Forwarding Plane Management Component (VFPM) 1012, and a FlowRule Engine 1013, responsible for the full lifecycle management of service chain configurations, rule compilation and optimization, and incremental deployment per node. The data plane 102 includes multiple data nodes, each containing a service chain bridge br-servicechain 1021, a pod network interface card 1022, and a VXLAN tunnel 1023. Data transmission between different nodes occurs through the VXLAN tunnel 1023. Data plane 102 is centered around a unified service chain bridge br-servicechain across all nodes. This is combined with cross-host transport tunnels (VXLAN, supporting multiple VNI concurrency and isolation) and Pod service chain network interfaces mounted via MultusCNI to achieve a service chain data path characterized by centralized orchestration, distributed execution, strong isolation, and hot updates. Tenant isolation no longer relies on independent bridges for each tenant; instead, strong isolation is achieved through a hierarchical namespace architecture using OpenFlow Cookie (high-level tenant domain, mid-level namespace, low-level step / session). The control plane implements declarative management of ServiceChainCRD and ConfigMap to ensure policy traceability and rollback capability. The data plane uses programmable switching and OpenFlow rules to guarantee forwarding performance and consistency.

[0049] Figure 2 This is a schematic diagram of a service chain controller provided in an embodiment of this application. The service chain controller can be as follows: Figure 1 The service chain controller 1011 is shown. (As shown...) Figure 2As shown, the service chain controller is implemented based on the Kubernetes controller framework, using a ReconcileLoop to drive a closed loop of "expected state - actual state - difference". Its core functions include service chain lifecycle management, network interface orchestration, and runtime governance. When a ServiceChain configuration is created or updated, the controller listens for CRD events and aggregates the context (Pod / Deployment / Namespace / Node topology and tags / taints, CNI annotations, bound network interfaces and SR-IOV / VF resources, existing tunnels and OVS status, VNI resource pool) through the Kubernetes API. It first performs configuration validation and normalization (Schema validation, default value completion, unit and protocol stack normalization, loop / conflict detection, and quota constraints). Based on the link steps and cross-host requirements, it determines the logical tenant view of the br-servicechain to be connected and whether it is cross-host. Subsequently, MultusCNI is used to dynamically create and mount a dedicated network interface card (supporting veth / SR-IOV / VF) for the target Pod. This completes the network interface card naming, NetNS binding, MTU / txqueuelen / qdisc configuration, and offload policy (GRO / GSO / TSO / LRO) settings. VFPM is then called to connect the interface to the br-servicechain: creating / confirming bridges and patching ports as needed, configuring bridge MAC / MTU / storm suppression, selecting or reusing a unique VNI VXLAN tunnel for cross-host scenarios (local_ip / remote_ip pairing, PMTU detection, checksum / offload switch, port name short prefix + hash abbreviation to prevent truncation), and performing connectivity verification.

[0050] The service chain controller expands high-level link steps into executable matching actions (passthrough, mirroring, rate limiting / marking, redirection / QoS), which are then handed over to the flow table engine to generate hierarchical OpenFlow and OVSDB configurations. This includes priority ordering, topology sorting, and cookie namespace encoding (high-order tenants, mid-order namespaces, low-order steps / session fragments). Differences are calculated based on cache snapshots, and the least disruptive update is selected under an "incremental priority" strategy. Specifically, incremental paths only insert / update affected table entries and apply them atomically using barriers / txn (add first, then delete). Full paths support shadow table pre-installation and atomic switching. Configuration is performed per node, with traces and rollback points recorded by writing to the ConfigMap. The runtime controller continuously monitors the health and performance metrics (throughput, error count, RTT / packet loss, rule hits) of Pods / nodes / interfaces / tunnels / rules. When anomalies such as Pod migration, interface flapping, tunnel failure, or rule drift occur, it automatically rebuilds the binding relationship between the Pod and the logical tenant view of br-servicechain, repairs or rebuilds tunnels and ports, recalculates differences, and triggers incremental rule re-deployment. If the risk increases, it rolls back to the previous stable version and writes back the status (Ready / Degraded / Failure). Combined with backoff retries and self-healing processes, it ensures that the service chain is continuously available, strongly isolated, and has low jitter in multi-tenant and cross-host scenarios.

[0051] During the tenant registration / service chain creation initialization phase, to ensure that cross-tenant cookie spaces do not overlap, the control face adopts 64-bit hierarchical encoding for the tenant's high-order prefix: the high 48 bits of SipHash(secret, tenantId|clusterId|createUnix|nonce) are used as the tenant prefix, and the low bits are used for step / action / session fragmentation; and atomic deduplication and persistence are performed in the global KV, and the nonce is changed and retried when necessary to eliminate the extremely low probability of conflict.

[0052] In this embodiment, cookie collision detection employs an adaptive redistribution algorithm based on a Bloom filter and quadratic hashing, significantly improving cookie generation performance and uniqueness guarantee. Specifically, a Bloom filter is used (parameter k = 3 hash functions, bit array size m = 2). 20 A quick pre-detection check is performed to determine if the cookie prefix already exists in the global hash space. If the Bloom filter indicates a potential collision, a global key-value pair (such as etcd) is queried for precise confirmation. If a collision is confirmed, a second hashing strategy is used to regenerate: SipHash-2-4(secretKey, tenantId|nonce|timestamp), where the nonce is initially 0 and incremented by 1 after each collision, with a maximum of 16 retries. The collision probability is calculated based on the birthday paradox model, and its formula is: When the number of tenants n < 1000, the collision probability P < 0.001%, ensuring sufficient uniqueness of the 48-bit prefix space. The controller executes an atomic "declare-verify-occupy" process in the global key-value pair. If a conflict occurs, a nonce retry is introduced until uniqueness is achieved, ensuring stability across restarts and preventing overlap between tenant spaces. This algorithm reduces etcd query counts by 90%, improves cookie generation performance by 10 times, and simultaneously guarantees the global uniqueness of the tenant prefix and cross-cluster stability.

[0053] In one specific embodiment Figure 3 A schematic diagram illustrating the implementation flow of the cookie collision detection algorithm is shown. Figure 3 As shown, the cookie collision detection algorithm may include the following steps:

[0054] S31: Initialize the Bloom filter. Create a bit array of size m=2. 20 (Approximately 1MB), using k=3 independent hash functions (a combination of MurmurHash3, CityHash, and SipHash).

[0055] S32: Load existing cookie prefixes. Read all allocated tenant cookie prefixes from the global key-value store (etcd) and add them to the Bloom filter.

[0056] S33: Generate candidate cookie prefixes. For new tenants, use SipHash-2-4(secretKey, tenantId|clusterId|createUnix|nonce) to calculate the hash value, take the high 48 bits as the candidate prefix, and initialize the nonce value to 0.

[0057] S34: Bloom filter pre-detection. Map the candidate prefixes to k positions in a bit array using k hash functions, and check if all these positions are 1. If all are 1, a collision (false positive) may exist, proceed to S35. If not all are 1, there is definitely no collision, proceed to S36.

[0058] S35: Precise Collision Detection. Query the global key-value pair to check if the candidate prefix actually exists. If a collision exists, increment the nonce by 1 and re-execute step S33 (maximum 16 retries). If no collision exists (false positive), proceed to S36.

[0059] S36: Atomic prefix occupancy. Perform an atomic "declare-verify-occupy" operation in the global key-value pair: Use etcd's Compare-And-Swap (CAS) mechanism to check if the candidate prefix is ​​already occupied. If it is not occupied, write it and mark it as occupied; if the CAS fails (it is already occupied), return to step S33 to regenerate.

[0060] S37: Persistence and Caching. Successfully allocated prefixes are written to etcd and a TTL (e.g., 30 days) is set. Simultaneously, they are recorded in the local cache to improve subsequent query performance.

[0061] S38: Regular maintenance and cleanup. Regularly (e.g., daily) scan etcd, clean up expired prefix allocation records, and update the Bloom filter synchronously.

[0062] In the service chain instantiation and scheduling phase, this embodiment employs a service chain path optimization algorithm. Tenants create service chain configurations via the API provided by the service chain controller. These configurations include service node types, link order, traffic matching and actions, QoS requirements, and cross-host policies. The flow table engine performs legality and logical consistency verification on the configurations and uses the aforementioned topology sorting algorithm to generate unique service chain identifiers and optimized orchestration plans. The service chain controller formulates scheduling strategies based on current resources and network conditions, and uses a shortest path and load-aware service chain path optimization algorithm for node selection and path allocation.

[0063] In this path optimization algorithm, a service chain topology graph is constructed, where nodes are service instances, and edge weights comprehensively consider latency, load, and bandwidth. An improved Dijkstra algorithm is used to calculate the shortest path, while also considering real-time node load (CPU, memory, network utilization). The K-shortest path algorithm (Yen's algorithm) is employed to select K candidate paths. Path scoring uses a multi-dimensional comprehensive model: Score(path) = α∙latency + β∙load + γ∙cost, where α, β, and γ are weight coefficients dynamically adjusted based on real-time monitoring data, latency is the time delay, load is the load factor, and cost is the resource cost. Load weights are updated using an exponential moving average: load_avg = 0.7∙load_old + 0.3∙load_current. When a node's load exceeds 80%, a path weight penalty is increased to prevent overloaded nodes.

[0064] For example, Figure 4 This diagram illustrates the implementation flow of a path optimization algorithm provided in an embodiment of this application. Figure 4 As shown, the path optimization algorithm includes:

[0065] S41: Construct the service chain topology graph. Traverse all multi-tenant service instances in the cluster, and create graph nodes for each instance. Based on the link order in the service chain configuration and the reachability between nodes, establish edges between relevant nodes, and initialize the edge weight as the base latency value.

[0066] S42: Collect real-time load information. Collect metrics such as CPU usage, memory usage, and network bandwidth utilization of each node through the Kubernetes Metrics API or Prometheus.

[0067] S43: Calculate the edge weight, that is, the comprehensive weight of the link. For each edge (u, v), calculate the comprehensive weight, weight(u, v) = base_latency + load_penalty(u) + load_penalty(v) + bandwidth_cost(u, v), where base_latency is the base latency, load_penalty is the load penalty function, and bandwidth_cost is the bandwidth cost.

[0068] S44: Calculate the optimal service chain path. Execute the improved Dijkstra's algorithm. Initialize the distance array dist[] and the path array path[], set the distance of the source node to 0, and the distances of other nodes to infinity. Use a priority queue (min heap) to maintain the nodes to be processed. Each time, take out the node u with the minimum distance, traverse all adjacent nodes v of u. If dist[u] + weight(u, v) < dist[v], then update dist[v] and path[v]. Repeat this process until all nodes are processed.

[0069] S45: Generate multiple candidate paths. Generate the K-shortest paths. Use Yen's algorithm. Based on the shortest path, generate the second-shortest path, the third-shortest path, etc. by removing edges or nodes until K candidate paths are generated.

[0070] S46: Score and select paths. Calculate the comprehensive score Score(path) for each candidate path, and select the path with the lowest score as the optimal path.

[0071] S47: Dynamically adjust and recalculate paths. Periodically (such as every 30 seconds, etc.) re-collect load information and update the edge weights. If the score of the current path deteriorates significantly (such as exceeding the threshold of 20%), then trigger path recalculation and switching.

[0072] After the service chain controller completes orchestration, it sends the orchestration results to the virtual forwarding plane management component and incrementally updates existing rules. Once the configuration takes effect, tenants can dynamically change the service chain (e.g., add / delete service nodes, adjust traffic policies, switch between primary and backup servers) through the same API. The controller uses an incremental difference calculation and minimum update algorithm based on edit distance to calculate the differences and trigger online hot updates to the data plane. In this embodiment, the incremental update algorithm uses the Wagner-Fischer algorithm to calculate the edit distance (Levenshtein distance) between the old and new rule sets, converting them into an ordered sequence sorted by priority; it identifies the minimum edit path, including insertion, deletion, and modification operations; it uses matching domain hashing to quickly identify identical rules, avoiding redundant calculations; and it merges multiple operations into a single OpenFlow transaction, ensuring the atomicity and consistency of the update. This algorithm reduces the number of rules that need updating by 60-80%, reduces network overhead by 70%, and ensures the reliability of rule updates and the consistency of the data plane through a batch atomic update mechanism.

[0073] In one specific embodiment Figure 5 A schematic diagram illustrating the implementation flow of the incremental update algorithm is shown. For example... Figure 5 As shown, the implementation process of this incremental update may include the following steps:

[0074] S51: Rule Serialization. Convert the old and new rule sets into ordered sequences sorted by priority. Each rule contains attributes such as matching domain, action domain, priority, and cookie.

[0075] S52: Difference Calculation Model Construction. Calculate the edit distance matrix: Using dynamic programming, construct a two-dimensional matrix dp[i][j], representing the minimum number of edit operations required to transform the first i rules of the old rule sequence into the first j rules of the new rule sequence. Initialize dp[0][j] = j (representing inserting j rules), dp[i][0] = i (representing deleting i rules). Recursive formula dp[i][j] = min(dp[i-1][j] + 1 (representing deleting old rule i), dp[i][j-1] + 1 (representing inserting new rule j), dp[i-1][j-1] + cost (representing modifying a rule; if the rule is the same, cost = 0; otherwise, cost = 1)).

[0076] S53: Determine the minimum edit operation sequence. Backtrack the minimum edit path: Starting from dp[m][n] (where m and n are the lengths of the old and new rule sequences, respectively), trace backward according to the recursive formula to determine the optimal edit operation sequence.

[0077] S54: Rule matching optimization. For modification operations, calculate the matching field hash value (using SHA-256) of the old and new rules. If the hash values ​​are the same, skip the rule to avoid unnecessary updates.

[0078] S55: Operation Grouping and Transactional Processing. Editing operations are grouped by type (insert group, delete group, modify group). For each group of operations, a corresponding OpenFlow command sequence is generated. OpenFlow transaction mechanisms (such as barrierrequest / response) are used to ensure that all operations are executed atomically.

[0079] S56: Execute incremental update rules. Perform operations in the order of "insert first, modify then delete," sending a barrier request after each operation to await confirmation, ensuring data plane consistency.

[0080] S57: Update Verification and Rollback Processing. After the update is complete, the actual rule status is obtained using the dump-flows command and compared with the expected status. If there is a difference, the rollback mechanism is triggered to restore the state to the state before the update.

[0081] Figure 6 This is a schematic diagram of a virtual forwarding plane management component provided in an embodiment of this application. The virtual forwarding plane management component can be, for example: Figure 1 The virtual forwarding plane management component 1012 is shown. Figure 6 As shown, the Virtual Forwarding Plane Management Component (VFPM) is responsible for the creation and maintenance of the node-level service chain bridge br-servicechain and its dependent objects.

[0082] In a specific embodiment, VFPM first performs capability self-checks and state recovery when the process starts: it checks the OVS / kernel and OpenFlow versions of the local node, the DPDK / TCoffload support matrix, reads the previous version's successful configuration and the list of existing ports, and if no bridge is found, it creates a br-servicechain in an idempotent manner and sets basic attributes (bridge MAC, MTU, stormcontrol, datapath-id, OpenFlow version). Then, it creates or verifies internal patch ports to achieve connection and partitioning with other bridges on the node. After completion, it reports the node's initial snapshot to the control plane.

[0083] In another specific embodiment, VFPM provides a logical service chain view for each tenant on a unified bridge, uses the cookie namespace for high-order tenant prefix, mid-order namespace encoding and low-order step / fragmentation domain division, and assigns table entry priority ranges and queue / rate limiting policies to this view, thereby achieving strong isolation and observability without building new physical independent bridges.

[0084] In terms of port management, VFPM maintains the entire lifecycle of physical ports, virtual ports, and tunnel ports. Physical ports include system / dpdk types, supporting parameter pushdown for MTU, txqueuelen, qdisc, and offload parameters such as GRO / GSO / TSO / LRO. Virtual ports include container veth and SR-IOV / VF. When VFPM detects a container network interface card or receives control plane commands, it executes naming conventions and access (port names use a short prefix + hash abbreviation to avoid truncation), completes NetNS binding verification, and ensures MTU / queue / offload consistency before adding it to the br-servicechain. Taking VXLAN as an example, VFPM uses the (local_ip, remote_ip, vni) triple to remove duplicates, ensuring the uniqueness of each VNI on the node. It can optionally enable BFD probing and PMTU policies, and configure checksums and destination ports when necessary. The creation, parameter modification, and deletion of the aforementioned ports are all combined in a transactional manner, following an atomic sequence of "add first, delete later + barrier verification," and supporting shadow table or prefix switching to achieve seamless migration.

[0085] In terms of rule enforcement, VFPM receives configurations from the control plane and compares them with local snapshots to generate differences. It prioritizes incremental paths, only inserting / modifying / deleting affected entries. It switches to full paths (shadow table pre-installation, insertion redirection, barrier confirmation, and old table reclamation) when critical entry tables or tenant masks change. VFPM's entry pipeline includes entry domain segmentation, Layer 2 / 3 matching, service chain scheduling, and action / observation layers. All matching and actions are constrained by cookie masks, prohibiting cross-tenant matching. Queues and meters are configured at the entry or action layer to achieve bandwidth and priority governance. To ensure consistency, VFPM persists the hash and cookie mask of the most recently successful version locally. Any failure automatically rolls back to the most recent stable version and records audit information.

[0086] In terms of runtime governance, VFPM collects port, tunnel, and rule health data at multiple granular cycles. Fast cycles (approximately 1 second) report link up / down times and basic transmission / reception; regular cycles (approximately 10 seconds) aggregate throughput, packet loss, error count, RTT, BFD status, dpifdrops, and rule hits; slow cycles (approximately 60 seconds) perform full consistency checks and drift hash comparisons. Anomaly detection rules include, but are not limited to: port flap thresholds (e.g., ≥3 status jitters within 60 seconds or short-term no transmission / reception after carrierup), tunnel unreachability (BFDDown or multiple failed RTT probes, encap / decap errors exceeding thresholds), rule drift (dump-flows generated by Cookie namespaces differing from the expected hash by more than a preset ratio), abnormal entry aging (abnormal increase in critical rule idle time with a still high hit rate), and session anomalies (frequent OVS session reconnections or abnormal CPU / memory usage). Upon triggering an anomaly, VFPM enters an automatic recovery process and employs an exponential backoff strategy: For the port, it performs a down process → parameter reset → up process → reconnection → barrier verification and rapid connectivity detection. For the tunnel, it refreshes parameters (local / remote_ip, csum, PMTU) or rebuilds the port name, switching the alternative local_ip if necessary. Rules are incrementally re-deployed only within the corresponding cookie namespace; if the ingress mask is corrupted, it enables atomic switching of the shadow prefix and rolls back the old prefix. If multiple attempts still fail, the tenant or namespace is placed in a degraded state and a control plane re-orchestration is requested.

[0087] Regarding multi-tenant deployment and cross-node consistency, VFPM executes the same cookie mask and table entry layering strategy on each node's br-servicechain based on the tenant prefix allocated by the control plane, ensuring that the logical view, priority segment, and queue / rate-limiting configuration of the same tenant are consistent across different nodes. For each successful application, VFPM generates a version number and hash and reports the node status (including bridge parameters, port and tunnel lists, number and hit rate of rules aggregated by tenant, recent anomalies, and recovery results). The control plane updates the desired state and scheduling strategy accordingly, thus forming a closed-loop self-healing process of "deployment—execution—observation—repair—reporting." Therefore, this embodiment of VFPM achieves strong multi-tenant isolation, parameter consistency, minimal disturbance changes, and rapid self-healing without creating multiple bridges, ensuring the stability and maintainability of the node-level service chain in cross-host and large-scale scenarios.

[0088] Figure 7 This is a schematic diagram of a flow table engine provided in an embodiment of this application. The flow table engine can be as follows: Figure 1 The flow table engine 1013 is shown. For example... Figure 4As shown, the flow table engine is responsible for the generation, optimization, and distribution of service chain rules. The flow table engine parses the service chain configuration, extracts service nodes, matching conditions (port / MAC / IP / VLAN / DSCP / identifier), actions (forwarding / mirroring / rate limiting / marking), and QoS constraints, generating executable OpenFlow / OVSDB combined rules. During the generation process, rule merging, priority reordering, path pruning, dependency topology sorting, and cookie encoding (high-order tenant, mid-order namespace, low-order step / session fragmentation) are performed to improve matching efficiency and multi-dimensional isolation capabilities. The flow table engine generates incremental difference packets with "minimal perturbation" by node, distributes them to the node agent atomic application through the control plane, maintains rule caching and usage statistics, periodically cleans up expired or low-frequency rules, and supports syntax validation, conflict detection, and simulation verification to ensure rule correctness and maintainability.

[0089] In this embodiment, the flow table engine employs a topology sorting and rule merging optimization algorithm based on a directed acyclic graph (DAG), significantly improving rule generation efficiency and matching performance. Specifically, the flow table engine converts the service chain configuration into a DAG structure, where nodes represent service nodes and edges represent traffic paths and dependencies. It uses the Kahn algorithm or depth-first search (DFS) for topology sorting to determine the logical order of rule execution. It identifies mergeable rule patterns—rules with the same matching conditions and consecutive actions—and merges them into a single rule to reduce the number of rules. It deduplicates rules by using the hash values ​​of the matching and action domains to avoid duplicate rule distribution. It automatically assigns OpenFlow priorities based on the topology sorting results, ensuring rules are executed in the correct order and avoiding priority conflicts. This algorithm reduces the time complexity of rule generation from O(n^2) to O(n+m), where n is the number of service nodes and m is the number of edges, reducing the number of rules by 30-50% and significantly improving rule matching performance and system throughput.

[0090] In one specific embodiment Figure 8 A schematic diagram illustrating the implementation flow of the topological sorting algorithm is shown. Figure 8 As shown, the implementation process of the topology sorting algorithm may include the following steps:

[0091] S81: Construct a service dependency graph. Traverse each service node in the service chain configuration and create a graph node for each node. Based on the link order and dependencies of the service chain, establish directed edges between related nodes to form a DAG.

[0092] S82: Calculate the in-degree of each node. Initialize the in-degree counter of each node, traverse all edges, and for each edge (u,v), increment the in-degree of node v by 1.

[0093] S83: Perform topological sorting. Execute Kahn's algorithm, initialize queue Q, and add all nodes with an in-degree of 0 to the queue. When the queue is not empty, remove the head node u and add it to the topological sequence. Traverse all outgoing edges (u, v) of u, decrementing the in-degree of node v by 1. If the in-degree of v becomes 0, add v to the queue. Repeat this process until the queue is empty.

[0094] S84: Detect cyclic dependencies. If the length of the topological sequence is less than the total number of nodes, a cyclic dependency exists, the algorithm terminates and returns an error.

[0095] S85: Assign rule priorities. Assign increasing OpenFlow priorities to the rules corresponding to each service node according to the topology sequence, ensuring that rules are executed in the order of dependency.

[0096] In another specific embodiment, Figure 9 A schematic diagram illustrating the implementation flow of the rule merging optimization algorithm is shown. Figure 9 As shown, the implementation process of the rule merging optimization algorithm may include the following steps:

[0097] S91: Rule Grouping. Groups rules with the same matching criteria together. Matching criteria include combinations of fields such as source / destination MAC, IP, port, VLAN, and DSCP.

[0098] S92: Action Sequence Merging. For rules within the same group, if their action sequences are consecutive (i.e., the output of the previous rule is the input of the next rule), multiple actions are merged into the action sequence of a single rule.

[0099] S93: Hash Deduplication. Calculate the hash value of the matching field and action field for each rule (using the SHA-256 algorithm), maintain a hash table to record existing rules, and skip any duplicate rules found.

[0100] S94: Rule simplification. For rules containing redundant actions (such as marking the same field multiple times consecutively), only the last action is retained.

[0101] S95: Generate an optimized rule set. Output the merged rule list and update the rule priority mapping.

[0102] The flow table engine provided in this application supports multi-layer traffic processing: at the L2 / L3 layer, it supports passthrough and mirror orchestration based on port / MAC / IP / VLAN / routing; at the L7 layer, it enables application-level traffic redirection and extension actions by cooperating with upper-layer policies and identifiers; it achieves multi-dimensional fine-grained isolation such as tenant / namespace / step / session through OpenFlowcookie and table entry layering; in terms of master / slave switchover, it supports selecting the master node by "earliest Ready" and health detection, automatic failover, incremental re-orchestration and atomic replacement, ensuring seamless link recovery and high availability.

[0103] In one specific embodiment Figure 10 A schematic diagram illustrating the implementation flow of L2 / L3 layer traffic processing is shown. Figure 10 As shown, the implementation process of this traffic processing includes:

[0104] S1001: Traffic Classification. Traffic is classified based on fields such as source / destination MAC address, IP address, port number, and VLAN tag, and matched against traffic matching conditions in the service chain configuration.

[0105] S1002: Straight-through processing. For traffic matching the straight-through rule, the flow table engine generates OpenFlow rules and forwards the traffic directly to the target service node without any modification.

[0106] S1003: Mirroring. For traffic that matches the mirroring rules, the flow table engine generates OpenFlow rules, copies the traffic, and sends it to the mirror target (such as monitoring services or security auditing services), while the original traffic continues to be forwarded along the normal path.

[0107] S1004: Route Orchestration. For traffic that needs to cross subnets, the flow table engine generates OpenFlow rules that include routing actions, specifying the next-hop gateway or routing table entry.

[0108] S1005: VLAN Pre-processing. For traffic requiring VLAN isolation, the flow table engine generates OpenFlow rules containing push_vlan / pop_vlan / modify_vlan actions to add, remove, or modify VLAN tags.

[0109] In another specific embodiment, Figure 11 A schematic diagram illustrating the implementation flow of L7 layer traffic processing is shown. Figure 11 As shown, the implementation process of this traffic processing includes:

[0110] S1111: Application Identifier Extraction. Application identifiers (such as HTTPHost, URI, User-Agent, etc.) are extracted through Deep Packet Inspection (DPI) or application layer protocol parsing.

[0111] S1112: Policy Matching. Based on the application identifier, match the application-level policy in the service chain configuration to determine the sequence of service nodes to be executed.

[0112] S1113: Traffic Marking. Mark the application identifier in the DSCP, ToS, or custom fields of the data packet to facilitate identification by subsequent service nodes.

[0113] S1114: Service chain orchestration. Generate corresponding OpenFlow rules according to the service node order defined in the policy to achieve sequential traffic forwarding.

[0114] S1115: Extended Action Execution. For traffic that requires extended actions (such as rate limiting, QoS marking, redirection, etc.), the flow table engine generates OpenFlow rules containing the corresponding actions.

[0115] During the entire service chain orchestration system runtime and fault handling phases, embodiments of this application also provide a service chain isolation and high availability mechanism that combines the functions of control plane decision-making and data plane execution.

[0116] Service chain isolation in this embodiment is achieved through a single br-servicechain and a VXLAN tunnel: tenants share the same data plane bridge, but strong isolation is achieved through non-overlapping cookie prefixes. Cross-host paths are distinguished by a unique VNI and REMOTE_IP, avoiding tunnel conflicts and resource contention between different tenants. The controller and data plane work together to provide state observation and adaptive reconfiguration capabilities, automatically executing bypass / switchover / rollback policies for abnormal links, and supporting versioned management and on-demand reclamation of policies and states.

[0117] In one specific embodiment Figure 12 A schematic diagram illustrating the implementation process of the service chain isolation mechanism is shown. For example... Figure 12 As shown, the implementation process of this service chain isolation mechanism includes:

[0118] S1221: Cookie prefix allocation. Assign a unique 48-bit cookie prefix to each tenant, ensuring that the prefixes of different tenants do not overlap.

[0119] S1222: Rule Matching Isolation. All OpenFlow rules are filtered using a cookie mask (cookie=TenantPrefix / 0xFFFFFFFFFFFF0000) during matching to ensure that rules only match the traffic of the corresponding tenant.

[0120] S1223: Hierarchical Isolation of Table Entries. In br-servicechain, each tenant is assigned an independent priority range for table entries to avoid interference between rules of different tenants.

[0121] S1224: Queuing and Rate Limiting Isolation. Assign independent queues and rate limiting policies to each tenant to ensure resource isolation between tenants.

[0122] S1225: VXLAN Tunnel Isolation. Assigns a unique VNI to each tenant's cross-host traffic, combined with local_ip / remote_ip pairing, to achieve tunnel-level isolation.

[0123] In another specific embodiment, Figure 13 A schematic diagram illustrating the implementation process of a high availability mechanism is shown. For example... Figure 13 As shown, the implementation process of this high availability mechanism includes:

[0124] S1331: Primary / Backup Node Selection. Based on the nodes' Ready status and health probe results, the controller selects the node that is "earliest Ready" as the primary node, and the other nodes as backup nodes.

[0125] S1332: Health Probe. The controller periodically (e.g., every 5 seconds) performs health probes on the master node (e.g., ICMPping, TCP connection tests, application layer health checks). If consecutive failures exceed the threshold (e.g., 3 times), a failover is triggered.

[0126] S1333: Automatic failover. When the primary node fails, the controller automatically selects a backup node as the new primary node and triggers incremental re-orchestration to update relevant rules.

[0127] S1334: Atomic Replacement. Utilizes OpenFlow transaction mechanisms to ensure the atomicity of rule updates and avoid traffic interruptions during the switchover process.

[0128] S1335: State Synchronization. After the switchover is complete, the controller synchronizes the states of the primary and backup nodes to ensure consistency.

[0129] S1336: Automatic recovery. After the original master node recovers, the controller decides, based on the policy, whether to switch back to the original master node or maintain the current master node.

[0130] The above describes the service chain orchestration method provided in this application embodiment. This method aims to address the technical challenges of current container cloud platforms in service chain orchestration, multi-tenant isolation, and network performance. Existing service mesh solutions mainly support L7 layer traffic processing and deploy proxy containers in a sidecar mode, resulting in high system resource consumption and management complexity, making it difficult to meet the network performance and reliability requirements of enterprise applications. This solution introduces a tenant-level logical control plane and a sidecarless data plane, constructing a core architecture composed of a service chain controller and a virtual forwarding plane management component, achieving high-performance, strong isolation, and hot-updateable dynamic orchestration capabilities for service chains.

[0131] The core architecture of this solution comprises a service chain controller and a virtual forwarding plane management component. The service chain controller, as the core component of the platform, is responsible for global service chain policy management and resource scheduling. It generates unified orchestration rules covering L2 / L3 / L7 through a built-in flow table engine and performs policy verification, versioning, and isolation management within the tenant-level logical control plane. The virtual forwarding plane management component is responsible for implementing policies in the data plane. It adopts a sidecarless mode to directly integrate network functions into the network plane, combining virtual switching instances and multi-VXLAN tunnel technology to complete service chain forwarding, cross-host orchestration, and high availability control. The flow table engine in this solution employs a topology sorting and rule merging optimization algorithm based on a directed acyclic graph (DAG), significantly improving rule generation efficiency and matching performance. Specifically, the flow table engine converts the service chain configuration into a DAG structure, where nodes represent service nodes and edges represent traffic paths and dependencies. It uses the Kahn algorithm or Depth-First Search (DFS) for topology sorting to determine the logical order of rule execution. It identifies mergeable rule patterns—rules with the same matching conditions and consecutive actions—and merges them into a single rule to reduce the number of rules. It deduplicates rules by using the hash values ​​of the matching and action domains to avoid duplicate rule distribution. Based on the topology sorting results, it automatically assigns OpenFlow priorities to ensure rules are executed in the correct order and avoid priority conflicts. This algorithm reduces the time complexity of rule generation from O(n^2) to O(n+m), where n is the number of service nodes and m is the number of edges, reducing the number of rules by 30-50% and significantly improving rule matching performance and system throughput.

[0132] Tenants create service chain configurations through the API provided by the service chain controller. The configurations include service node types, link order, traffic matching and actions, QoS requirements, and cross-host policies. The flow table engine performs legality verification and logical consistency verification on the configurations, and uses the aforementioned topology sorting algorithm to generate unique service chain identifiers and optimized orchestration plans. The service chain controller formulates scheduling policies based on current resource and network status, and uses a service chain path optimization algorithm based on shortest path and load awareness to select nodes and allocate paths. This path optimization algorithm constructs a service chain topology graph, where nodes are service instances, and edge weights comprehensively consider latency, load, and bandwidth. An improved Dijkstra algorithm is used to calculate the shortest path, while also considering real-time node load (CPU, memory, network utilization). The K-shortest path algorithm (Yen's algorithm) is employed to select K candidate paths. Path scoring uses a multi-dimensional comprehensive model: Score(path) = α∙latency + β∙load + γ∙cost, where α, β, and γ are weight coefficients dynamically adjusted based on real-time monitoring data. Load weights are updated using an exponential moving average: load_avg = 0.7∙load_old + 0.3∙load_current. When a node's load exceeds 80%, a path weight penalty is added to prevent overloaded nodes. The orchestration results are distributed to the virtual forwarding plane management component, and existing rules are incrementally updated. After the configuration takes effect, tenants can dynamically change the service chain through the same API (such as adding / deleting service nodes, adjusting traffic policies, switching between primary and backup, etc.). The controller uses an incremental difference calculation and minimization update algorithm based on edit distance to calculate the difference of the changes and trigger online hot updates of the data plane.

[0133] This incremental update algorithm uses the Wagner-Fischer algorithm to calculate the edit distance (Levenshtein distance) between the old and new rule sets, transforming them into an ordered sequence sorted by priority. It identifies the minimum edit path, including insertion, deletion, and modification operations. Matching field hashing is used to quickly identify identical rules, avoiding redundant calculations. Multiple operations are merged into a single OpenFlow transaction, ensuring the atomicity and consistency of the update. This algorithm reduces the number of rules requiring updates by 60-80%, reduces network overhead by 70%, and ensures the reliability of rule updates and the consistency of the data plane through a batch atomic update mechanism.

[0134] The data plane implementation of this solution is as follows: all tenant Pods are uniformly connected to a dedicated bridge br-servicechain, and strong isolation is achieved between tenants through OpenFlow Cookie prefixes. Independent VXLAN tunnels (with unique VNI and local / remote IP pairs) are allocated for services such as images / bypasses to achieve cross-host orchestration and interference-free concurrent service chain links; short prefixes and hash abbreviations are used for port naming to avoid OVS port name truncation and ensure stable rule matching.

[0135] This solution avoids injecting proxy containers into each service instance, significantly reducing CPU / memory and network overhead, shortening data paths, and improving latency and throughput performance. Cookies employ a 64-bit hierarchical structure: the high 48 bits are the "tenant prefix," obtained by taking the high bits of SipHash-2-4(secretKey, tenantId|tenantCreateUnix|clusterId) and persisting it in the control plane; the low 16 bits encode the link dimension (such as steps / actions / session fragments). Data plane matching uses a mask cookie=TenantPrefix / 0xFFFFFFFFFFFF0000 to achieve tenant-level filtering and observation.

[0136] This solution employs an adaptive redistribution algorithm based on Bloom filters and quadratic hashing for cookie collision detection, which significantly improves cookie generation performance and uniqueness guarantee. Specifically, a Bloom filter (parameter k = 3 hash functions, bit array size m = 2^20) is used to quickly pre-detect whether the cookie prefix already exists in the global space. If the Bloom filter indicates a possible collision, the global key-value pair (such as etcd) is queried for precise confirmation. If a collision is confirmed, a secondary hashing strategy is used to regenerate: SipHash-2-4(secretKey, tenantId|nonce|timestamp), where the nonce is initially 0 and incremented by 1 after each collision, with a maximum of 16 retries. The collision probability is calculated based on the birthday paradox model: P(collision) = 1 - (1 - 1 / 2^48)^n. When the number of tenants n < 1000, the collision probability P < 0.001%, ensuring that the 48-bit prefix space has sufficient uniqueness. The controller executes the "declare-verify-occupy" atomic process in the global key-value pair. If a conflict occurs, the nonce is retried until it is unique and written to disk, ensuring that it remains stable across restarts and does not overlap with the tenant space. This algorithm reduces the number of etcd queries by 90%, improves cookie generation performance by 10 times, and ensures the global uniqueness of tenant prefixes and cross-cluster stability.

[0137] This solution's flow table engine supports multi-layered traffic processing: at L2 / L3 layers, it supports passthrough and mirror orchestration based on ports / MAC / IP / VLANs / routes; at L7 layer, it enables application-level traffic redirection and expansion actions by cooperating with upper-layer policies and identifiers; it achieves fine-grained isolation of tenants / namespaces / steps / sessions through OpenFlowcookie and table layering; in terms of master / slave failover, it supports selecting the master node by "earliest Ready" and health probes, automatic failover, incremental re-orchestration, and atomic replacement, ensuring seamless link recovery and high availability.

[0138] Service chain isolation in this solution is achieved through a single br-servicechain and VXLAN tunnels: tenants share the same data plane bridge, but strong isolation is achieved through non-overlapping cookie prefixes; cross-host paths are distinguished by unique VNIs and REMOTE_IPs, avoiding tunnel conflicts and resource contention between different tenants. The controller and data plane work together to provide state observation and adaptive reconfiguration capabilities, automatically executing bypass / switchover / rollback policies for abnormal links, and supporting versioned management and on-demand reclamation of policies and states.

[0139] Through the design of the solution provided in this application embodiment, this solution significantly outperforms existing solutions in terms of service chain orchestration capabilities, performance, and isolation: Compared to the limitation of service mesh only supporting L7 traffic processing, this solution can simultaneously cover L2 / L3 and L7 multi-layer orchestration, greatly expanding application scenarios; Compared to solutions such as NSM, this solution directly integrates network functions into the network plane, avoiding additional forwarding and assembly overhead, and achieving better performance; Through topology sorting and rule merging algorithms, the number of rules is reduced by 30-50%, and rule matching performance is improved by more than 40%; Through incremental update algorithms, update overhead is reduced by 70%, and hot update response time is shortened by 60%; Through path optimization algorithms, service chain latency is reduced by 20-30%, and load balancing effect is improved by 35%; Through the Bloom filter-optimized cookie generation algorithm, system initialization performance is improved by 3 times, while supporting dynamic insertion and removal of service nodes, compatible with the Kubernetes network model, providing fine-grained traffic control and online hot update capabilities, making service chain orchestration more flexible and efficient. This solution effectively addresses the performance, isolation, and maintainability challenges of container cloud platforms in service chain orchestration, meets the needs of enterprise-level multi-tenancy and high-reliability scenarios, enhances the elasticity and scalability of network services, and provides enterprises with a more economical and efficient network service solution.

[0140] It is understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. Furthermore, in some possible implementations, each step in the above embodiments may be selectively executed according to actual circumstances; it may be partially or fully executed, without limitation here. All or part of any feature of any embodiment of this application can be freely and arbitrarily combined without contradiction. The combined technical solutions are also within the scope of this application.

[0141] Based on the methods in the above embodiments, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to execute the methods in the above embodiments.

[0142] Based on the methods in the above embodiments, this application provides a computer program product that, when run on a processor, causes the processor to execute the methods in the above embodiments.

[0143] It is understood that the processor in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.

[0144] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.

[0145] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0146] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

Claims

1. A service chain orchestration method, characterized in that, The method includes: The control plane dynamically configures the logical control plane for each tenant, and completes the unified modeling, generation, distribution and recycling of service chain policies within the logical control plane; The data plane adopts a sidecarless mode, directly connecting service nodes to the network plane and using a unified virtual switching bridge to achieve traffic forwarding; The flow table engine in the control plane converts the service chain configuration into a directed acyclic graph, performs topology sorting and rule merging optimization, generates flow table rules, and automatically assigns priorities. The control plane employs a Cookie collision detection and adaptive reallocation algorithm based on Bloom filters and quadratic hashing to generate a unique Cookie prefix for each tenant. The control plane uses an incremental difference calculation and minimization update algorithm based on edit distance to incrementally update service chain changes; The control plane employs a service chain path optimization algorithm based on the shortest path and load awareness to select service chain paths and balance load.

2. The method according to claim 1, characterized in that, The topology sorting and rule merging optimization includes: The service nodes in the service chain configuration are used as nodes in the graph, and the traffic paths and dependencies between nodes are used as edges to construct a directed acyclic graph. Use Kahn's algorithm or depth-first search to perform topological sorting and determine the logical order of rule execution; Identify rules that have the same matching conditions and perform consecutive actions, and merge them into a single rule; OpenFlow priorities are automatically assigned based on the topology sorting results.

3. The method according to claim 1, characterized in that, The cookie collision detection and adaptive reallocation algorithm based on Bloom filters and quadratic hashing specifically includes: Use a Bloom filter to pre-detect the generated cookie prefix; If the Bloom filter indicates a potential collision, query the global key-value store for precise confirmation; If a collision is confirmed, the cookie prefix is ​​regenerated using a double hashing strategy, where the nonce is initially 0 and incremented by 1 after each collision. Perform atomic operations of declaration-verification-occupancy in the global key-value store to ensure the global uniqueness of tenant cookie prefixes.

4. The method according to claim 1, characterized in that, The incremental difference calculation and minimization update algorithm based on edit distance specifically includes: Convert the old and new rule sets into ordered sequences sorted by priority; The Wagner-Fischer algorithm is used to calculate the edit distance between the old and new rule sets and identify the minimum edit path, including insertion, deletion and modification operations; Use matching domain hashes to quickly identify identical rules and avoid duplicate calculations; Multiple operations are combined into a single OpenFlow transaction, ensuring the atomicity and consistency of updates.

5. The method according to claim 1, characterized in that, The service chain path optimization algorithm based on shortest path and load awareness includes: Construct a service chain topology graph, where nodes are service instances, and edge weights comprehensively consider latency, load, and bandwidth. The shortest path is calculated using an improved Dijkstra algorithm, while taking into account the real-time load of nodes. The K-shortest path algorithm is used to select K candidate paths as alternatives; The path scoring adopts a multi-dimensional comprehensive model: Score(path) = α∙latency + β∙load + γ∙cost, where α, β, and γ are weight coefficients that are dynamically adjusted based on real-time monitoring data, latency is the time delay, load is the load, and cost is the resource cost.

6. The method according to claim 1, characterized in that, The method also includes a multi-layer traffic processing and isolation mechanism, specifically: Supports pass-through and mirroring orchestration based on ports, MAC addresses, IP addresses, VLANs, and routes at L2 / L3 layers; At layer L7, application-level traffic redirection and expansion actions are achieved by cooperating with upper-layer strategies and identifiers. OpenFlow cookies and table entry layering enable multi-dimensional, fine-grained isolation of tenants, namespaces, steps, and sessions.

7. The method according to claim 1, characterized in that, The method also includes a high availability mechanism: The primary node is selected based on the earliest Ready and health detection, and the system automatically switches to the backup node when the primary node fails. Incremental reordering and atomic replacement are used to ensure seamless link recovery.

8. The method according to claim 1, characterized in that, The virtual switching bridge is br-servicechain, which is deployed on each compute node. All tenants' Pods on the same compute node are uniformly connected to br-servicechain, and strong isolation is achieved between different tenants through OpenFlow Cookie prefix.

9. The method according to claim 1, characterized in that, The method also includes a cross-host orchestration mechanism: allocating independent VXLAN tunnels for services such as mirroring / bypassing to achieve cross-host orchestration and interference-free concurrent service chain links.

10. The method according to claim 1, characterized in that, The method also includes adaptive reconstruction and incremental hot update of the service chain: automatically execute bypass, switching and rollback strategies for abnormal links, and support versioned management and on-demand recycling of policies and states.

Images