Multi-cluster service function chain closed-loop intelligent arrangement method and device

Abstract

The application discloses a multi-cluster service function chain closed-loop intelligent arrangement method and device, and belongs to the technical field of cloud computing, edge computing, network service arrangement and reliability guarantee. By constructing a closed-loop coupling structure of multi-cluster SFC arrangement, cross-layer operation can be verified, audited and replayed. A round evidence package is used as a cross-layer control and consistency anchor point, and shared evaluation events under budget constraints are evaluated through candidate action evaluation, network update is cooperatively supported, redundant strategy and redundant domain or shared backup domain selection are selected, cross-cluster consistency execution and rollback control are performed, and evidence package sealing and verification gating are performed, so that the multi-cluster closed-loop arrangement is verified, replayed and audited. The strategy version is consistent, repeated execution is avoided, and rollback to a consistent benchmark and forced reevaluation are realized when the strategy version is inconsistent. Under the condition that the evaluation budget is limited, multiple candidate feedbacks are generated at one time through shared evaluation events, the evaluation budget utilization rate is improved, and the closed-loop control cycle is shortened.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing, edge computing, network service orchestration and reliability assurance, specifically to a method and apparatus for closed-loop intelligent orchestration of multi-cluster service function chains. Background Technology

[0002] Multi-cluster deployment can improve business elasticity and disaster recovery capabilities. However, when orchestrating Service Function Chains (SFCs) in a multi-computing cluster environment, engineering implementation often faces contradictions such as: closed-loop operation is possible but difficult to verify; execution is possible but consistency is difficult; configuration is possible but verification is difficult; and evaluation is possible but uneconomical. Typical problems include: The closed-loop process is difficult to verify and audit: orchestration action generation, constraint checking, execution receipts, and operational observations are often scattered across different control plane / data plane systems and logs, resulting in inconsistent recording standards and incomplete fields, leading to the need for piecemeal traceability afterward. This approach makes it difficult to form a unified and verifiable chain of evidence, and it is particularly difficult to answer the key questions that engineering audits always ask: Why was this action chosen? Which constraints were checked and whether they passed? Was cross-cluster execution consistent? Was a rollback and reassessment performed according to rules after exceeding limits?

[0003] Cross-cluster consistency is weak and untraceable: Existing implementations typically rely on centralized distribution or the superposition of autonomous policies across clusters. When policy version drift, duplicate distribution, resource contention, and concurrent changes occur simultaneously, state splits can easily occur (the same SFC exhibits different placement / backup / routing states in different clusters). More critically, most engineering implementations lack traceable consistency anchors and recoverable consistency benchmarks. When conflicts occur, manual intervention or partial rollbacks are often the only options, making it difficult to guarantee that cross-cluster recovery to the same provable benchmark state is possible.

[0004] Reliability strategies lack verifiable closed-loop mechanisms: In engineering, redundancy strategies and shared backup configurations often adopt static rules, empirical thresholds, or local optimization results directly. When business SLAs (end-to-end latency thresholds) and reliability thresholds are constrained simultaneously, the above approaches often only appear reasonable but fail to provide calculable and verifiable check results. Furthermore, it is difficult to provide a closed-loop path that can be rolled back and re-evaluated after an observation goes out of bounds. This results in the risk that configurations have been issued but thresholds are unverifiable, and anomalies occur but the handling is unverifiable.

[0005] Low utilization of assessment budget: In the assessment of multi-entity collaborative relationships and action effects, the common practice is to conduct high-cost assessments such as simulation / sandbox / grayscale for each candidate action, resulting in the repeated consumption of calculation and assessment budgets. In actual engineering, an assessment event can often reuse intermediate results and generate feedback for multiple candidate actions. Existing implementations lack a systematic organization and recording mechanism for this assessment sharing capability, which slows down the closed-loop control cycle due to assessment costs, and the assessment conclusions are difficult to be used as a constraint basis for the next round.

[0006] Based on the above issues, the industry urgently needs an engineering closed-loop mechanism for multi-cluster SFC orchestration: it should not only connect key links such as telemetry, gating evaluation, candidate action evaluation, redundancy strategy and shared backup domain selection, cross-cluster consistent execution, and observation-triggered rollback / re-evaluation into an indispensable closed-loop causal chain, but also solidify the key inputs, decision basis, constraint conclusions, execution receipts and anomaly handling in each round of the closed loop into auditable records in a unified structure, so that the entire process of selection-execution-observation-rollback-re-evaluation is verifiable, replayable and engineering-implementable. Summary of the Invention

[0007] The purpose of this invention is to provide a closed-loop intelligent orchestration method and apparatus for multi-cluster service function chains to solve the problems mentioned in the background art.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution: A closed-loop intelligent orchestration method for multi-cluster service function chains, comprising the following steps: Collect telemetry data from each cluster to form a global status snapshot and feature vector; Generate a pre-commit record for the round evidence package, write and bind the policy version identifier, transaction identifier and previous hash; Based on the global state snapshot and feature vector, a set of candidate actions is constructed, and gating evaluation is performed to obtain the evaluation result. The target action is selected through the set of candidate actions, and the set of candidate actions, the evaluation result and the target action are written into the round evidence package. Each candidate action includes at least the action type, target, action parameters, effective scope and rollback pointer. Configure associated evaluation groups under the preset candidate action evaluation budget constraints; when a shared evaluation event is triggered, consume one unit budget to produce multiple candidate feedbacks and generate an evaluation event record to be written into the round evidence package; The collaborative support network is updated based on multiple candidate feedback, and the update results or summary of the collaborative support network, as well as the input summary, parameter version and output summary related to the update, are written into the round evidence package. The collaborative support network outputs an explicit constraint set to limit the candidate action space and guides the selection of redundant domains or shared backup domains, thus forming an executable orchestration action set; the explicit constraint set, redundancy strategy, domain selection results, and constraint verification results are written into the round evidence package; Based on the policy version identifier and transaction identifier, the executable orchestration action set is executed in a consistent manner across clusters. Before execution, the policy version identifier and transaction identifier are verified in each cluster, execution receipts are obtained, execution observations are collected and written into the round evidence package. If the observation goes out of bounds or conflicts, the system will roll back to the consensus benchmark and trigger a reassessment based on the rollback pointer. After the execution or rollback is completed, the round evidence package will be sealed and the previous hash, the current hash, and the signature or authentication field will be generated to form a hash chain. Before entering the next round, a verification gate will be executed. If the gate fails, the system will be prohibited from entering the next round.

[0009] Furthermore, the specific implementation process for forming the global state snapshot and feature vector includes: Collect telemetry data from each computing cluster. The telemetry data includes at least cluster or node resource utilization, end-to-end latency, throughput, error rate or packet loss rate, instance health, and workload characteristics. Telemetry data from different clusters are time-aligned, denoised or missing data is filled, and statistically aggregated according to a unified time window. The data is then organized into a global state snapshot according to the cluster dimension, node dimension, SFC or function dimension. The global state snapshot includes at least the resource capacity and usage, the current placement and link path of the SFC, the backup resource usage and sharing relationship, key thresholds and alarm status. The quantifiable fields in the global state snapshot are standardized or normalized, the discrete fields are encoded, and cross features for candidate action generation, gating evaluation and support network updates are added to form a feature vector.

[0010] Furthermore, the specific implementation process of writing and binding the policy version identifier, transaction identifier, and preceding hash into the pre-commit record of the generated round evidence package includes: Before any orchestration action is issued in this round, a pre-commit record of the round evidence package is generated, and the strategy version identifier and transaction identifier are bound to the pre-commit record; the pre-commit record includes at least the unique identifier of the round evidence package, the append write position before the record is sealed, the write timestamp, and the operator or device identifier; Calculate the hash values ​​of the current round's global state snapshot, feature vector, and candidate set summary to form the preceding hash; Write the strategy version identifier, transaction identifier, and preceding hash into the round evidence package.

[0011] Furthermore, the specific implementation process of constructing a candidate action set, performing gating evaluation to obtain evaluation results, selecting a target action through the candidate action set, and writing the candidate action set, evaluation results, and target action into the round evidence package includes: Establish an action primitive library and standardize the description of actions based on the mapping relationship between action primitives, parameters, and objects of action; Based on the current global state snapshot and feature vector, candidate parameter ranges are generated for each action primitive to form candidate actions, and action summaries of the candidate actions are calculated. The action summary is a unique index of the candidate action. Each candidate action carries at least the target SFC identifier, the set of affected nodes or links, resource increment or decrement, expected effective range, and a rollback pointer for rule-based rollback and re-evaluation after exceeding the limit. Each candidate action includes at least the action type, affected object, action parameters, effective range, and rollback pointer. Perform gating evaluation on each candidate action to determine whether it meets the SLA threshold constraint, cost boundary constraint, reliability threshold constraint, cross-cluster consistency constraint and action safety boundary constraint, and output the evaluation results, including Pass / Fail, failure reason, risk score and confidence level; The SLA threshold constraint, based on the SFC topology and link or node delay model, estimates the end-to-end delay jitter after the candidate action, determines whether it exceeds the SLA threshold, and outputs the delay default risk and confidence level. The cost boundary constraint is determined based on resource quotas, budget limits, and resource increments or reductions to estimate resource cost changes, and whether the boundary is exceeded, and the extent and reason for exceeding the boundary are output. The reliability threshold constraint is based on the redundancy strategy and the requirements of the shared backup domain or redundant domain. It estimates the availability improvement or failure rate change, determines whether the reliability threshold is met, and outputs the minimum gap when it is not met. The cross-cluster consistency constraint verifies whether the policy version on which the candidate action depends is consistent with the current policy version of each cluster, uses the transaction identifier or action digest as an idempotent key to detect duplicate issuance, and outputs risk conflicts and conflict types for conflict risks caused by concurrent changes or resource contention. The action safety boundary constraint checks whether it reaches the protected SFC or critical node, whether it exceeds the change range limit, and whether it violates the safety rules of the cooldown time or change window; if it does not meet the requirements, it will directly fail and output the safety boundary trigger item. Extract candidate actions that pass the gating evaluation from the candidate action set, construct a candidate action target set, and select target actions from the candidate action target set according to a preset objective function or sorting rule; The candidate action set, evaluation results, and target action are written into the round evidence package. Furthermore, the specific implementation process of configuring associated evaluation groups under the preset candidate action evaluation budget constraint, and consuming one unit budget to produce multiple candidate feedbacks and generating evaluation event records to be written into the round evidence package when a shared evaluation event is triggered includes: The target action is taken as a candidate action. Under the preset candidate action evaluation budget constraint, the candidate actions are organized into an associated evaluation group. The organization rule is to classify the candidate actions that are related to each other on the same batch of critical resources, the same SFC, the same shared backup pool, or the same set of candidate supply entities into the same associated evaluation group. When a shared evaluation event is triggered, one unit of budget is consumed to generate candidate feedback for multiple candidate actions in the associated evaluation group, generate an evaluation event record and write it into the round evidence package. The assessment budget represents the maximum number of high-cost assessments allowed to be triggered in this round; The triggering criteria for the shared evaluation event shall meet at least one of the following conditions: the number of candidate actions or uncertainty in the gating evaluation reaches a preset threshold; the key indicator is close to the threshold; insufficient samples or distribution drift detection required to support network updates are triggered; or the event is triggered periodically for calibrating the model or rules. The candidate feedback includes at least the prediction latency or throughput or error rate changes, reliability changes, cost changes, conflict or rollback risk scores and confidence levels; The evaluation event log shall include at least the event identifier, the associated evaluation group identifier, the list of candidate actions within the group, the budget consumption, the feedback of each candidate action, the timestamp, and a summary of the evaluation environment.

[0012] Furthermore, the specific implementation process of updating the collaborative support network based on multiple candidate feedback and writing the update result or summary of the collaborative support network, along with the input summary, parameter version, and output summary related to the update, into the round evidence package includes: Construct a collaborative support network, taking into input global state snapshots, policies and constraints, evaluation and observation records, and version and transaction identifiers, and outputting entity sets, edge weight sets, and evidential digests; the evidential digests include network hashes, parameter versions, thresholds, and gating results; Extract resources and business objects from the global state snapshot, classify them according to supply entities and benefit entities, and assign them unique identifiers; For each beneficiary entity, candidate supporting edges are generated based on preset resource mapping relationships, reachability, sharing strategies, and isolation rules. If the isolation rules of an edge are not met, the edge is marked as a prohibited edge. The basic support strength of each edge is calculated by combining support capacity, availability, isolation or fault domain, stability and sharing degree, and the edge weight is obtained by normalizing the outgoing edges of the same supply entity. By using policy constraints as gating conditions, edges that do not meet the gating conditions are directly set to zero or removed, and the network hash, parameter version, and gating digest are written into the round evidence package to obtain the collaborative support network. Based on the multiple candidate feedbacks generated by shared evaluation events, the collaborative support network is updated. When a shared evaluation event is triggered, it generates candidate feedbacks for multiple candidate actions within the same associated evaluation group. For each candidate action, an input summary is extracted, including benefits, risks or costs, and confidence levels. The feedbacks at the action layer are mapped to an affected edge set, which includes the set of support edges actually used, changed, or depended upon by the candidate actions. The net contribution of this round of shared evaluation events to the support edges is obtained by aggregating each edge in the support edge set. : in, For return or risk weighting coefficients, To prevent zero items, For profit, For risk or cost, Confidence level; To support edge sets; For candidate actions; To support edges; The edge weights are then updated according to an incremental rule, which is as follows: in, The learning rate or step size is the event-level learning rate. For use in The contribution mapping function mapped to the target increment scale of [0,1]; This is the clipping function; After the update, normalization is performed again on the outgoing edges of the same supply entity, and a gating factor is introduced at the event level to gate the confidence update: in, Base step size; The gating coefficient; For edges whose duration exceeds the duration threshold and whose deviation from the current load / topology is greater than the deviation threshold, which are not covered by any shared evaluation events, apply attenuation according to the time window: in, The attenuation coefficient; The round evidence package records the event identifier, the set of candidate actions involved, the input summary for each action, the set of affected edges, the aggregated net contribution summary, and the gating parameters. The version and value of ) and a summary of the edge weights before and after the update.

[0013] Furthermore, the filtering process to form an executable set of orchestrated actions specifically includes: Based on the edge weights and gating results of the collaborative support network, the candidate action space for generation or selection is restricted by an explicit constraint set, the selection results of the redundant domain or shared backup domain are output, and the constraint relationship and basis summary are written into the evidence package. For each beneficiary entity, extract its supportable set from the collaborative support network. : in, For candidate actions, The edge weight threshold, For Top-K rule functions; A candidate space constraint set is constructed by constraining conditions, which include at least whitelist or blacklist constraints, shrinking of action range upper limit, restriction of applicable cluster domain for actions, restriction of available domain for shared backup, and consistency and security boundary gating. By constraining the supportable set with the candidate space constraint set, a set of candidate actions that satisfy the candidate space is obtained, and the edge weight threshold, Top-K rule function and constraint condition summary are written into the round evidence package; Candidate domains are selected based on the fault correlation matrix, isolation policy gating, and domain selection score. The domain with the highest score that meets the isolation gating is used as a redundant domain or a shared backup domain, and the output and output basis summary are written into the round evidence package. For each SFC, at least one of the four redundancy strategies—dedicated active backup, dedicated standby backup, shared active backup, and shared standby backup—is selected, and an executable orchestration action set is formed by combining the selection results of the redundancy domain or shared backup domain. The redundancy strategy identifier, the redundancy domain or shared backup domain result, and the constraint verification result are written into the round evidence package. The executable orchestration action set includes at least the placement action of each function in the service function chain, the backup resource allocation action, the shared backup pool configuration action, and the cross-cluster collaborative configuration action. Constraint verification includes at least the following: under the selected redundancy strategy and domain selection conditions, performing computable verification of end-to-end delay threshold and reliability threshold, recording a summary of the verification results, and obtaining constraint verification results.

[0014] Furthermore, the formation of an executable set of orchestrated actions includes: Obtain a snapshot of the global state in this round, and generate or update the feature vector based on the global state snapshot; Based on the global state snapshot and feature vector, a set of model parameters is extracted. The set of model parameters includes at least the resource capacity parameters of each computing cluster or node, the business requirement parameters of the service function chain, the end-to-end cutoff latency threshold, the reliability threshold, and the capacity or quota parameters of the shared backup pool. A joint orchestration optimization model is constructed based on the set of model parameters. The joint orchestration optimization model includes at least an objective function, decision variables, and model constraints. The decision variables include at least function placement variables, dedicated backup variables and shared backup pool variables, shared backup allocation variables, and cross-cluster collaborative configuration variables. The model constraints include at least resource capacity constraints, deadline latency constraints, and reliability threshold constraints. Solving the joint orchestration optimization model yields the target orchestration scheme that satisfies the model constraints; The target orchestration scheme is compared with the current orchestration state to obtain the set of variable changes; Based on the preset action primitive library, the variable change set is decoded into an executable orchestration action set. Each orchestration action includes at least an action type, an object of action, action parameters, and an effective scope. The action type includes at least one or more of the following: creation or release of functional instances, migration or reconstruction of instances, scaling up or down of shared backup pools, updating of shared backup allocation, and cross-cluster collaborative configuration distribution. When multiple candidate orchestration schemes are obtained, the target action set is determined from the action set corresponding to the candidate orchestration scheme set as the executable orchestration action set according to the objective function value or the preset risk or benefit ranking rule. When the joint orchestration optimization model generates multiple candidate orchestration schemes that meet the constraints, a comprehensive score is calculated for the action set corresponding to each candidate orchestration scheme, and the action set with the best comprehensive score is selected as the executable orchestration action set. The comprehensive score includes at least two or more of the following: deadline delay default risk, reliability gap, and cost increment. The decoding process is as follows: An instance creation action is generated when a function placement variable changes from unselected to selected; an instance release action is generated when a function placement variable changes from selected to unselected; an instance migration action is generated when the same function instance changes from selected to unselected between different nodes or different clusters; and an instance reconstruction action is generated when the same function instance changes from unselected to selected between different nodes or different clusters. When the dedicated backup variable changes, generate the creation or release action of the dedicated backup instance or the backup binding update action; When the shared backup pool variables change, a shared backup pool capacity adjustment action or a shared backup pool quota adjustment action is generated. When the shared backup allocation variable changes, a shared backup allocation update action is generated to update the allocation relationship between the beneficiary entity and the shared backup pool. When the cross-cluster collaborative configuration variables change, a cross-cluster collaborative configuration distribution action is generated.

[0015] Furthermore, if the execution observation goes out of bounds or conflicts, it will roll back to the consensus benchmark according to the rollback pointer and trigger a re-evaluation; after the execution or rollback is completed, the round evidence package is sealed and the previous hash, the current hash, and the signature or authentication field are generated to form a hash chain; before entering the next round, a verification gate is executed, and if it fails, it is prohibited from entering the next round. Specifically, this includes: When key performance indicators (KPIs) of the observed data exceed their limits or cross-cluster conflicts occur, the system rolls back to a consistent baseline state based on the rollback pointer and triggers a reassessment. The reassessment after rollback uses the state corresponding to the historical round evidence package pointed to by the rollback pointer as the consistent input baseline. After completing the current round of execution or rollback, the round evidence package is sealed, generating a previous hash, the current round hash, and a signature or authentication. Before entering the next round, the integrity of the sealed data and the continuity of the hash chain are verified. If the verification fails, the system is prohibited from entering the next round. The verification content includes at least hash chain continuity and signature or authentication validity. If the verification fails, the reason for failure is recorded, and the system is prohibited from entering the next round. The current round hash is calculated from at least the previous hash, policy version identifier, transaction identifier, target action, evaluation result, and summary of the executed observation, and satisfies the following conditions: ,in, For the preceding hash of the next round, This is the hash for this round; the signature or authentication is at least bound to the hash for this round and the policy version identifier, and enters the... Pre-round verification includes at least hash chain continuity verification and signature or authentication validity verification; The rollback pointer points to a certain historical round evidence package, and the re-evaluation after rollback must use the global state snapshot or its summary corresponding to the round evidence package as the cross-cluster consistency input benchmark. The triggering criteria for key indicators exceeding limits or cross-cluster conflicts include at least the following: SLA indicators exceeding thresholds, reliability indicators falling below thresholds, execution failures caused by resource conflicts, policy version conflicts, duplicate transaction conflicts, or resource contention conflicts.

[0016] A closed-loop intelligent orchestration device for multi-cluster service function chains, the device comprising a telemetry acquisition module, a feature construction module, a candidate action generation module, a strategy constraint evaluation module, a consistency execution module, an execution receipt acquisition module, an execution observation acquisition module, a feedback update module, and an evidence package management module: The telemetry acquisition module is used to collect telemetry data from each cluster. The feature construction module is used to generate a global state snapshot and feature vectors; The candidate action generation module is used to construct a set of candidate actions based on the global state snapshot and feature vectors; The strategy constraint evaluation module is used to perform gating evaluation on the candidate action set to obtain the evaluation result; select the target action from the candidate action set, and write the candidate action set, evaluation result and target action into the round evidence package; output an explicit constraint set based on the collaborative support network to limit the candidate action space, and guide the selection of redundant domains or shared backup domains to form an executable orchestration action set; write the explicit constraint set, redundancy strategy, domain selection result and constraint verification result into the round evidence package; The consistency execution module is used to perform cross-cluster consistency execution on executable orchestration action sets based on policy version identifiers and transaction identifiers. Before execution, policy version identifiers and transaction identifiers are verified in each cluster. The execution receipt collection module is used to obtain execution receipts; The observation and acquisition module is executed to collect and execute observations and write them into the round evidence package; The feedback update module is used to roll back to a consistent baseline and trigger a re-evaluation when an observation goes out of bounds or conflicts occur. After execution or rollback is completed, the round evidence package is sealed and the previous hash, the current hash, and the signature or authentication field are generated to form a hash chain. Before entering the next round, a verification gate is executed, and if it fails, the next round is prohibited. The evidence package management module is used to generate pre-commit records for round evidence packages and bind policy version identifiers and transaction identifiers. After obtaining execution receipts, execution observations and update results, it seals the round evidence packages and generates the previous hash, current hash and signature or authentication fields, and controls the entry into the next round with the seal verification gate.

[0017] Compared with the prior art, the beneficial effects achieved by the present invention are as follows: In the closed-loop intelligent orchestration method and device for multi-cluster service function chain provided by the present invention, the evidence for closed-loop control is elevated from scattered logs to a unified round evidence package as a cross-layer consistency anchor point. In each round of operation, the state snapshot summary, candidate actions, gating evaluation conclusions, execution receipts and observation results are written into the same evidence package in a structured manner, so that why the action is selected, whether the constraint is passed, whether the execution is consistent, how to roll back and re-evaluate after going out of bounds can be reviewed, replayed and audited in rounds. A pre-deployment mechanism for evidence package pre-commitment and version / transaction binding is introduced. By generating evidence package pre-commitment records before any orchestration action is implemented, and binding the strategy version identifier and transaction identifier to the record, a strong coupling between action deployment and evidence anchor points is achieved, avoiding the unverifiable and inconsistent statements caused by relying solely on post-event log splicing. By incorporating SLA thresholds, reliability thresholds, cost boundaries, cross-cluster consistency constraints, and action safety boundaries into the engineering constraint assessment, only candidates passing through the gating set are allowed to enter the execution path, and the summary of the assessment conclusions and input conditions are simultaneously solidified into the evidence package to form auditable constraint evidence; To address the issue of wasted assessment budgets, assessment budget constraints, associated assessment groups, and shared assessment events are introduced. Under budget constraints, candidates are grouped and organized. When a shared assessment event is triggered, multiple candidates within the group simultaneously generate their respective feedback with a single budget expenditure. The event identifier, the candidate list within the group, the budget expenditure, and the feedback results are written into an evidence package, thereby improving the efficiency of assessment reuse and closed-loop cycle from a mechanism perspective. To address cross-cluster state splitting, cross-cluster consistent execution and idempotency verification are introduced. Before execution, the policy version and transaction identifier are verified in each cluster. If duplicate transactions are detected, the duplicate execution is rejected and the reason for the conflict is recorded. During the execution phase, a consistent commit protocol, such as two-phase commit, consensus commit, or equivalence mechanism, is adopted to ensure that all commits or consistent aborts and rollbacks, thereby providing a traceable consistency benchmark. The handling of anomalies is upgraded from manual remediation to observation-triggered rollback, re-evaluation, and sealing verification gating. When the observed indicators go out of bounds or cross-cluster conflicts occur, the rollback is rolled back to the consistency benchmark according to the rollback pointer and a re-evaluation is forcibly triggered. At the end of each round, the evidence package is sealed to generate a hash chain and signature or authentication information. Before entering the next round, integrity and continuity verification is performed. If the verification fails, the next round is prohibited. The gating method ensures the credibility and auditability of the cross-round closed loop. Attached Figure Description

[0018] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.

[0019] Figure 1 This is a schematic diagram of the overall framework for closed-loop intelligent orchestration of multi-cluster service function chains in an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the data structure, pre-submission, sealing and hash chain, rollback pointer and verification gating relationship of the round evidence package in this embodiment of the invention; Figure 3 This is a schematic diagram of the associated evaluation group and shared evaluation event generating multiple candidate feedback and updating the collaborative support network under the budget constraint of candidate action evaluation in this embodiment of the invention; Figure 4 This is a schematic diagram of the process of triggering a shared evaluation event, generating an evaluation event record, and writing it into an evidence package in an embodiment of the present invention; Figure 5 This is a schematic diagram of four types of redundancy strategies in an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating the formation of an executable orchestration set and its consistent execution in an embodiment of the present invention; Figure 7 This is a schematic diagram of the three-layer closed-loop feedback relationship of observation-driven gating evaluation, collaborative support network, and redundancy strategy / domain selection in an embodiment of the present invention. Detailed Implementation

[0020] 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, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] It should be explained that the terms and symbols defined in the embodiments of this invention include: round : The identifier of the discrete control cycle in closed-loop operation; : No. Round global state snapshot; : No. Wheel feature vector; : Set of candidate actions; Gating assessment results; Select the target action; : Execution receipt; : Perform observation; Update results; Strategy version identifier; Transaction identifier / idempotency identifier; : Rollback pointer, pointing to the historical round evidence package As a benchmark for consistency; , , Previous hash, current hash, and signature / authentication fields; Candidate Action Evaluation Budget : The maximum number of times a shared evaluation event can be triggered (configurable by round or time window); Associated evaluation groups: used to share a set of candidates for evaluation event triggering, allowing for partial overlap; Shared evaluation event: An evaluation trigger event that consumes 1 unit of budget and generates individual candidate feedback for multiple candidates within an associated evaluation group; Collaborative Support Network: A structural output that characterizes the support relationship between supplying entities and benefiting entities, used to limit the candidate action space and guide the selection of redundant domains / shared backup domains.

[0022] Please see Figure 1-7In this first embodiment: a closed-loop intelligent orchestration framework for multi-cluster service function chain is provided, which includes at least: an orchestration control device and multiple computing clusters.

[0023] The orchestration control device includes at least the following modules: telemetry acquisition module, feature construction module, candidate action generation module, strategy constraint evaluation module, consistency execution module, execution receipt acquisition module, execution observation acquisition module, feedback update module, and evidence package management module. The telemetry acquisition module is used to collect telemetry data from each cluster. The feature construction module is used to generate a global state snapshot and feature vectors; The candidate action generation module is used to construct a set of candidate actions based on the global state snapshot and feature vectors; The strategy constraint evaluation module is used to perform gating evaluation on the candidate action set to obtain the evaluation result; select the target action from the candidate action set, and write the candidate action set, evaluation result and target action into the round evidence package; output an explicit constraint set based on the collaborative support network to limit the candidate action space, and guide the selection of redundant domains or shared backup domains to form an executable orchestration action set; write the explicit constraint set, redundancy strategy, domain selection result and constraint verification result into the round evidence package; The consistency execution module is used to perform cross-cluster consistency execution on executable orchestration action sets based on policy version identifiers and transaction identifiers. Before execution, policy version identifiers and transaction identifiers are verified in each cluster. The execution receipt collection module is used to obtain execution receipts; The observation and acquisition module is executed to collect and execute observations and write them into the round evidence package; The feedback update module is used to roll back to a consistent baseline and trigger a re-evaluation when an observation goes out of bounds or conflicts occur. After execution or rollback is completed, the round evidence package is sealed and the previous hash, the current hash, and the signature or authentication field are generated to form a hash chain. Before entering the next round, a verification gate is executed, and if it fails, the next round is prohibited. The evidence package management module is used to generate pre-commit records for round evidence packages and bind policy version identifiers and transaction identifiers. After obtaining execution receipts, execution observations and update results, it seals the round evidence packages and generates the previous hash, current hash and signature or authentication fields, and controls the entry into the next round with the seal verification gate.

[0024] Multiple computing clusters provide resource pools and execution terminals respectively. The execution terminals are used to verify the policy version and transaction identifier and perform orchestration actions.

[0025] This embodiment provides a closed-loop intelligent orchestration method for multi-cluster service function chains, which includes the following steps: Step 1: Collect telemetry data from each cluster to create a global state snapshot. With feature vectors ; Step 2: Generate round evidence packages Write and bind the policy version identifier to the pre-commit record. Transaction identifier and preceding hash ; The data structure of the round evidence package must contain at least the following fields: Status Snapshot With feature vectors Candidate actions Gating assessment results Target action Strategy Version Transaction identifier Evaluation event logs, collaborative support network summaries; redundancy policies and redundancy domain / shared backup domain logs; execution receipts. , Perform observation Update results ; Rollback pointer Preorder hash This round of hashing Signature / Authentication ; Exception and conflict records, audit storage, and archived timestamps and sequence numbers; Pre-commit involves generating and writing a pre-commit record before the action is issued. , , .

[0026] Seal for acquisition , , Post-calculation ,generate Mark and archive; after archiving, persist to audit storage by appending (219), and prohibit overwrite updates.

[0027] Step 3: Based on global state snapshot With feature vectors Construct a set of candidate actions And perform gating evaluation to obtain evaluation results. Select the target action from the candidate action set. and the candidate action set Evaluation results and target action Write the round evidence package Each candidate action must include at least the action type, target, action parameters, scope of effect, and rollback pointer. ; Hash chain At least with , , Select action summary, gating evaluation summary, and execution observation summary binding; and satisfy the following conditions: . At least binding and Used for integrity verification.

[0028] Before proceeding to the next round, at least the following checks must be performed: hash chain continuity and... Validity; if the validation fails, the process is prohibited from proceeding to the next round and the reason for the failure is recorded.

[0029] Auditable playback based on sealed evidence packages: review gating assessment basis, share assessment events and multiple candidate feedback, support network updates and constraint results, redundant strategies and domain selection records, consistent execution receipts and observations, rollback benchmarks and reassessment input binding, etc.

[0030] Step 4: Evaluate the preset candidate actions within the budget. Configure associated evaluation groups under constraints; when a shared evaluation event is triggered, consume one unit of budget output for multiple candidate feedbacks and generate an evaluation event record, which is then written into the round evidence package. ; The associated assessment group is used to organize candidates and can allow for partial overlap; it shares an assessment event, which consumes 1 unit of budget and generates candidate feedback for multiple candidates within the group; the assessment event record includes at least: event identifier, associated assessment group identifier, candidate list, budget consumption, feedback for each candidate, timestamp, and is written into the evidence package; The collaborative support network is updated based on feedback from multiple candidates and is used to: limit the candidate action space (whitelist / blacklist / amplitude limit / applicable cluster domain limitation, etc.); guide the selection of redundant domains or shared backup domains and limit the scope of sharing; all of the above-mentioned limiting relationships are written into the evidence package.

[0031] Step 5: Update the collaborative support network based on multiple candidate feedback, and write the updated results or summary of the collaborative support network, along with the related input summaries, parameter versions, and output summaries, into the round evidence package. ; Step 6: Based on the output of the collaborative support network, an explicit constraint set is used to limit the candidate action space and guide the selection of redundant domains or shared backup domains, thus forming an executable orchestration action set; the explicit constraint set, redundancy strategy, domain selection results, and constraint verification results are written into the round evidence package. ); Redundancy strategies are strictly enumerated into four categories: dedicated active backup, dedicated standby backup, shared active backup, and shared standby backup.

[0032] Based on the output of the collaborative support network, the redundant domain / shared backup domain is determined, and the redundancy strategy, domain selection results and their constraint verification results are written into the evidence package to form an executable orchestration action set (including placement, backup allocation, shared backup pool configuration, cross-cluster collaborative configuration, etc.) for consistent execution.

[0033] Step 7: Based on the policy version identifier and transaction identifier S7 performs cross-cluster consistent execution of executable orchestration sets and obtains execution receipts. And collect and execute observations. And write it into the round evidence package ( Before execution, the policy version is identified in each cluster. and transaction identifier S7 verification is used to prevent version drift or duplicate execution; execution receipts and observations are obtained and written into the round evidence package. Among these: The consistency execution mechanism can adopt two-phase commit, consensus commit, or an equivalent consistency commit protocol; it must at least guarantee that either all clusters commit successfully, or the process is aborted / rolled back in a consistent manner.

[0034] Idempotency check: If a transaction flag is detected as already executed, the transaction is rejected from being executed again, and the reason for rejection and the cluster flag of the conflict source are written into the evidence package.

[0035] Step 8: If observation is performed Out of bounds or conflicts will be handled according to the rollback pointer. Rollback to a consistent baseline and trigger a reassessment; seal the round evidence package after execution or rollback is complete. It generates a previous hash, a current hash, and a signature or authentication field to form a hash chain; before entering the next round, it performs a verification gate, and if it fails, it is prohibited from entering the next round.

[0036] Pre-execution verification and Detected If an action has already been executed, it should be rejected from being executed again and recorded; if a policy version conflict, duplicate transaction conflict, or resource contention conflict occurs, the current round of actions should be aborted or rolled back, depending on... Roll back to a consistent baseline and trigger a reassessment; the reassessment after rollback must use the state corresponding to the round evidence package pointed to by the rollback pointer as a consistent input baseline to ensure consistent recovery across clusters.

[0037] The three-layer closed-loop feedback relationship of observation-driven gating evaluation, collaborative support network, and redundancy strategy / domain selection is as follows: Figure 7 Perform observation Update results driven by archive verification results Used to update: gating evaluation threshold / penalty weight / disabled action list; cooperative support network; redundancy policy and domain selection preference; and Write it into the evidence package as one of the input constraints for the next round.

[0038] The steps for constructing and implementing the joint orchestration optimization model include: Index set and input parameter determination: Based on the global state snapshot S_t, determine the computing cluster set, node set, service function chain set, virtual network function set, and shared backup pool set; and extract model parameters such as resource capacity (CPU / GPU / memory / storage / bandwidth), link latency and packet loss rate, instance processing latency, instance availability / failure rate, and service arrival rate from S_t / X_t, while reading the SLA deadline latency threshold and reliability threshold.

[0039] Decision variable definition: At least define the function placement variable (representing which node / cluster each function instance is placed on), the dedicated backup number variable (representing the scale of dedicated backups used by each SFC or each function), and the shared backup pool number variable (representing the scale of shared backup pool configuration); in some implementations, further define the shared backup allocation variable (representing which shared backup pool a certain function / SFC is mapped to) and the cross-cluster collaborative configuration variable.

[0040] Objective function construction: Construct an objective function to measure orchestration performance. The objective function should reflect at least one of resource cost, latency risk, and change risk. In some implementations, the objective function is a weighted combination of the above indicators.

[0041] Constraint Construction: 1) Resource capacity constraint: The resource consumption introduced by placement and backup on each node / cluster shall not exceed its capacity; 2) Deadline delay constraint: Calculate the upper bound or quantile estimate of the end-to-end delay based on "link transmission delay + function processing delay (and necessary queuing item estimation)", and require it not to exceed the cutoff delay threshold; 3) Reliability threshold constraint: Calculate the SFC reliability index based on the functional instance availability parameters and the selected redundancy strategy (dedicated active backup / dedicated standby backup / shared active backup / shared standby backup, etc.), and require it to be no less than the reliability threshold. 4) In some implementations, constraints on shared backup pool capacity and shareable domain, as well as cross-cluster consistency and action security boundary constraints, are further added.

[0042] Solution and feasibility verification: Solve the joint orchestration optimization model. The solution method can be integer programming, heuristic search, decomposition coordination or a combination thereof. If the solution result is not feasible, adjust the constraint relaxation parameters or candidate domain and solve again until an orchestration scheme that satisfies the constraints is obtained.

[0043] The orchestration scheme is decoded into an action set: the orchestration scheme is converted into an executable orchestration action set, which includes at least function placement actions, backup resource allocation actions, shared backup pool configuration actions, and cross-cluster collaborative configuration actions. The model parameter summary, solution result summary, and constraint verification summary are written into the round evidence package E_t to support review and playback.

[0044] Specifically, the implementation process for forming a global state snapshot and feature vector includes: Collect telemetry data from each computing cluster. The telemetry data includes at least the cluster or node resource utilization rate. The telemetry data sources include at least: cluster or node resource utilization rate (CPU / GPU / memory / storage / bandwidth, etc.), end-to-end latency (including queuing / processing / link), throughput, error rate / packet loss rate, instance health, and workload characteristics (arrival rate, concurrency, traffic distribution, request size distribution, SFC business priority, etc.). Telemetry data from different clusters are time-aligned, denoised or missing data are filled, and statistically aggregated (mean / quantile / peak / slope, etc.) according to a unified time window. The data are then organized into a global state snapshot according to cluster dimension, node dimension, SFC or function dimension. The global state snapshot includes at least resource capacity and usage, current SFC placement and link path, backup resource usage and sharing relationship, key thresholds and alarm status. The quantifiable fields in the global state snapshot are standardized or normalized, and the discrete fields are encoded, such as one-hot / indexed encoding. Cross features used for candidate action generation, gating evaluation and supporting network updates are added to form a feature vector.

[0045] Specifically, the process of generating pre-commit records for round evidence packages, writing and binding policy version identifiers, transaction identifiers, and preceding hashes includes: Before any orchestration action is issued in this round, a pre-commit record of the round evidence package is generated, and the strategy version identifier and transaction identifier are bound to the pre-commit record for cross-cluster consistency and idempotency control. The pre-commit record includes at least the unique identifier of the round evidence package, the append write position before the record is sealed, the write timestamp, and the operator or device identifier. Calculate the hash values ​​of the current round's global state snapshot, feature vector, and candidate set summary to form the preceding hash; The policy version identifier, transaction identifier, and preceding hash are written into the round evidence package. The transaction identifier is used as an idempotent key and can be generated from the round identifier, target SFC identifier, hash of action digest, or generated from a globally unique ID, ensuring that duplicate distributions across clusters can be identified and rejected.

[0046] Specifically, the process of constructing a candidate action set and performing gating evaluation to obtain the evaluation results; selecting the target action from the candidate action set, and writing the candidate action set, evaluation results, and target action into the round evidence package includes: Establish an action primitive library to standardize the description of actions based on the mapping relationship between action primitives, parameters, and objects. Action primitives should include at least: function placement / migration, instance scaling up / down, link path / routing adjustment, backup instance creation / release, shared backup pool capacity adjustment, cross-cluster collaborative configuration change, etc. Candidate actions can be obtained by rule enumeration, heuristic search, or optimization, but they must be bound to a global state snapshot and be replayable for verification.

[0047] Based on the current global state snapshot and feature vector, candidate parameter ranges are generated for each action primitive to form candidate actions, and action summaries of the candidate actions are calculated. The action summary is a unique index of the candidate action. Each candidate action carries at least the target SFC identifier, the set of affected nodes or links, resource increment or decrement, expected effective range, and a rollback pointer for rule-based rollback and re-evaluation after exceeding the limit. Each candidate action includes at least the action type, affected object, action parameters, effective range, and rollback pointer. Perform gating evaluation on each candidate action to determine whether it meets the SLA threshold constraint, cost boundary constraint, reliability threshold constraint, cross-cluster consistency constraint and action safety boundary constraint, and output the evaluation results, including Pass / Fail, failure reason, risk score and confidence level; The SLA threshold constraint, based on the SFC topology and link or node delay model, estimates the end-to-end delay jitter after the candidate action, determines whether it exceeds the SLA threshold, and outputs the delay default risk and confidence level. The cost boundary constraint is determined based on resource quotas, budget limits, and resource increments or reductions to estimate resource cost changes, and whether the boundary is exceeded, and the extent and reason for exceeding the boundary are output. The reliability threshold constraint is based on the redundancy strategy and the requirements of the shared backup domain or redundant domain. It estimates the availability improvement or failure rate change, determines whether the reliability threshold is met, and outputs the minimum gap when it is not met (e.g., insufficient number of backups, failure domain isolation, etc.). The cross-cluster consistency constraints (version consistency, transaction idempotency, conflict risk check) verify whether the policy version on which the candidate action depends is consistent with the current policy version of each cluster, detect duplicate issuance by using the transaction identifier or action digest as the idempotency key, and output risk conflict and conflict type for conflict risks caused by concurrent changes or resource contention. The action safety boundary constraint checks whether it reaches the protected SFC or critical node, whether it exceeds the change range limit, and whether it violates the safety rules of the cooldown time or change window; if it does not meet the requirements, it will directly fail and output the safety boundary trigger item. Extract candidate actions that pass the gating evaluation from the candidate action set, construct a candidate action target set, and select target actions from the candidate action target set according to a preset objective function or sorting rule; The candidate action set, evaluation results, and target action are written into the round evidence package. .

[0048] The technical contribution of this step goes beyond simply generating generalized descriptions of candidate actions and constraint checks. It lies in binding the standardized expressions of candidate actions (action summaries and rollback pointers), the constraint evidence output of gating evaluation (item-by-item constraint conclusions, failure reasons, risk / confidence levels), and the consistency / idempotency control of the round's evidence package's pre-commit anchor points, strategy version identifiers, and transaction / idempotency identifiers into a closed-loop evidence chain for the same round. This allows for the review and auditing of "why this action was selected, how constraints are passed, cross-cluster consistency, and how out-of-bounds rollbacks and re-evaluations are performed round by round. The algorithm implementation can employ rules, heuristics, or models, but the output fields, binding relationships, and gating / rollback mechanisms are essential technical features of this invention.

[0049] Specifically, under the preset candidate action evaluation budget constraint, the associated evaluation group is configured; when a shared evaluation event is triggered, the process of consuming one unit budget to produce multiple candidate feedbacks and generating evaluation event records written into the round evidence package includes: The target action is taken as a candidate action. Under the preset candidate action evaluation budget constraint, the candidate actions are organized into an associated evaluation group. The organization rule is to classify the candidate actions that are related to each other on the same batch of critical resources, the same SFC, the same shared backup pool, or the same set of candidate supply entities into the same associated evaluation group. When a shared evaluation event is triggered, one unit of budget is consumed to generate candidate feedback for multiple candidate actions in the associated evaluation group, generate an evaluation event record and write it into the round evidence package. The assessment budget represents the maximum number of high-cost assessments allowed to be triggered in this round; The triggering criteria for the shared evaluation event shall meet at least one of the following conditions: the number of candidate actions or uncertainty in the gating evaluation reaches a preset threshold; the key indicator is close to the threshold; insufficient samples or distribution drift detection required to support network updates are triggered; or the event is triggered periodically for calibrating the model or rules. The candidate feedback includes at least the prediction latency or throughput or error rate changes, reliability changes, cost changes, conflict or rollback risk scores and confidence levels; The evaluation event log shall include at least the event identifier, the associated evaluation group identifier, the list of candidate actions within the group, the budget consumption, the feedback of each candidate action, the timestamp, and a summary of the evaluation environment.

[0050] Specifically, the implementation process of updating the collaborative support network based on multiple candidate feedback and writing the updated results or summary of the collaborative support network, along with the related input summary, parameter version, and output summary, into the round evidence package includes: Construct a collaborative support network, taking into input global state snapshots, policies and constraints, evaluation and observation records, and version and transaction identifiers, and outputting entity sets, edge weight sets, and evidential digests; the evidential digests include network hashes, parameter versions, thresholds, and gating results; Extract resources and business objects from the global state snapshot, classify them according to supply entities and benefit entities, and assign them unique identifiers; For each beneficiary entity, candidate supporting edges are generated based on preset resource mapping relationships, reachability, sharing strategies, and isolation rules. If the isolation rules of an edge are not met, the edge is marked as a prohibited edge. The basic support strength of each edge is calculated by combining support capacity, availability, isolation or fault domain, stability and sharing degree, and the edge weight is obtained by normalizing the outgoing edges of the same supply entity. By using policy constraints as gating conditions, edges that do not meet the gating conditions are directly set to zero or removed, and the network hash, parameter version, and gating digest are written into the round evidence package to obtain the collaborative support network. Based on the multiple candidate feedbacks generated from shared evaluation events, the collaborative support network is updated, and the updated input and output summaries are written into the round evidence package. The collaborative support network is used to characterize the support relationships from supply entities to benefit entities, and can be represented using a directed graph, weighted graph, or structure with hyperedges, denoted as: Where V is the set of entities, the supply entities can be resource objects such as clusters, nodes, links, shared backup pools, and fault domains, and the beneficiary entities can be SFC, VNF instances, business flows or combinations thereof; E is the set of supporting edges; Let the set of edge weights be defined. This represents a comprehensive measure of the support strength, shareability, and marginal benefit contribution of the supply entity u to the benefit entity v under given load and constraints. The larger the value, the more worthwhile it is to prioritize the use of this support relationship in the subsequent candidate action generation and selection stage. For each support edge ( First, calculate the foundation support strength. Then normalize to obtain the edge weights: in, Indicates the same supply entity Normalize all outgoing edges of the ) (e.g., normalize to sum to 1 or max-min normalize) to ensure comparability between different beneficiary entities.

[0051] Basic support strength Derived from a combination of five factors—capability, availability, isolation, stability, and sharing—an engineering-implementable definition is given below, allowing for product or weighted forms, but fields and gating logic are essential technical features: This refers to the available resources, bandwidth, and backup capabilities that the supplying entity can provide. To meet the current needs of the beneficiary entities (traffic, computing power, backup share, etc.); To provide information such as the health status, failure rate, and available windows of the supply entity; For the isolation and fault domain constraints to be satisfied; when the isolation requirement is not satisfied, let ( This side is banned in this round (and will not be included in the candidate guide). For stability indicators (congestion, jitter, frequent changes, cooling-off period, etc.); To ensure the feasibility of sharing (shared backup pool quota, shared link policy, cross-cluster permission / domain policy allowance, etc.).

[0052] To ensure verifiability, the following calculations must be recorded in each round of evidence packages: The key input summaries (index values ​​and time windows), the normalization method used, the function / parameter version number, and the generated edge weight summaries (such as Top-K changes, mean / variance, etc.).

[0053] When a shared evaluation event is triggered, it generates candidate feedback for multiple candidate actions within the same associated evaluation group. For each candidate action, an input summary is extracted, including benefits, risks or costs, and confidence levels. The feedback from the action layer is mapped to an affected edge set, which includes a set of supporting edges that the candidate actions actually use, change, or depend on. The net contribution of this round of shared evaluation events to the supporting edges is then aggregated for each edge in the supporting edge set. : in, For return or risk weighting coefficients, To prevent zero items, For profit, For risk or cost, Confidence level; To support edge sets; For candidate actions; To support edges; Benefits include improved reliability, increased throughput, and reduced default risk; Risks / costs, such as SLA default risk, conflict risk, change risk, and incremental costs; Confidence level, such as assessment of credibility (simulation / sandbox / grayscale quality, sample size, observation noise, etc.). The edge weights are then updated according to an incremental rule, which is as follows: in, The learning rate or step size is the event-level learning rate. For use in The contribution mapping function mapped to the target increment scale of [0,1]; This is the clipping function; After the update, normalization is performed again on the outgoing edges of the same supply entity, and a gating factor is introduced at the event level to gate the confidence update: in, Base step size; The gating coefficient can be determined jointly by the overall confidence level of the event and the conflict risk. For example, if the overall confidence level of the event is less than the confidence threshold or the conflict risk is greater than the conflict risk threshold, then let... Lowering the value or setting it to 0 freezes the update process; recording only has no effect. Otherwise, scale up / down proportionally. To achieve the principle of learning only when it is credible, suppressing when there is conflict, and stopping when there is noise; For edges whose duration exceeds the duration threshold and whose deviation from the current load / topology is greater than the deviation threshold, which are not covered by any shared evaluation events, apply attenuation according to the time window: in, The attenuation coefficient; The round evidence package records the event identifier, the set of candidate actions involved, the input summary for each action, the set of affected edges, the aggregated net contribution summary, and the gating parameters. The version and value of the edge weights before and after the update (e.g., changes in Top-K edges and distribution of change magnitude).

[0054] Compared to methods that rely solely on static weighting based on empirical rules or make local adjustments after independent evaluation of a single candidate, the improvements made by this invention in the collaborative support network update process are reflected in the following aspects: Shared evaluation event-driven multi-candidate linkage update: A single high-cost evaluation event simultaneously generates feedback on multiple candidate actions within the associated evaluation group, which are then aggregated into incremental updates on multiple supporting edges. This achieves a closed-loop gain of evaluation sharing, weight linkage, and guidance for the next round of candidates, thereby improving the utilization rate of the evaluation budget and shortening the closed-loop cycle.

[0055] Confidence Gating and Conflict Risk Suppression: Explicitly Incorporating Assessment Confidence and Cross-Cluster Conflict Risk into the Update Step The gating supports freeze / decrease step size updates, suppresses weight drift caused by noise and concurrency conflicts, and improves cross-wheel stability.

[0056] The evidence package is verifiable and updatable: The updated input summary, parameter version, event aggregation results, and weight summaries before and after the update are written into the round evidence package, making the weight changes traceable, auditable, and replayable, avoiding the problem of black-box self-updates that cannot be verified.

[0057] Edge weight semantics and gating constraints are of the same origin: edge weights are defined by factors such as capacity, availability, isolation, stability, and sharing, and are of the same origin as gating evaluation constraints. This enables the collaborative support network to not only be updated, but also to effectively shrink the candidate space and improve feasibility and consistency in subsequent candidate action generation and optimization.

[0058] Specifically, the process of filtering to form an executable set of orchestrated actions includes: Based on the edge weights and gating results of the collaborative support network, the candidate action space for generation or selection is restricted by an explicit constraint set, the selection results of the redundant domain or shared backup domain are output, and the constraint relationship and basis summary are written into the evidence package. For each beneficiary entity, extract its supportable set from the collaborative support network. : in, For candidate actions, The edge weight threshold, For Top-K rule functions; A candidate space constraint set is constructed by constraining conditions, which include at least whitelist or blacklist constraints, shrinking of action range upper limit, restriction of applicable cluster domain for actions, restriction of available domain for shared backup, and consistency and security boundary gating. Whitelist or blacklist constraints include whitelists that only allow... Clusters / nodes / backup pools are added to the candidate list; blacklists remove prohibited objects (maintenance nodes, protected SFC critical nodes, risk domains, etc.).

[0059] Limitation of the upper limit of the range of motion This includes setting upper limits on actions involving resource changes (migration / scaling / rerouting, etc.) based on the level of support. The lower the level of support, the stricter the upper limit, in order to suppress the risks brought about by large-scale changes.

[0060] Actions are subject to cluster domain restrictions and are only permitted within the set of clusters involved in the action. Shared backup availability is limited to a specific domain, allowing only shared backup actions to select a set of backup pools. This set of backup pools is projected from provisioning entities in the supporting network that meet shared gating (quota / permission / policy permission).

[0061] Consistency and security boundary gating uses cross-cluster version consistency, transaction idempotency, cooldown time, change window, etc. as hard gates. Violations will result in the candidate being removed and not entering the subsequent gating evaluation.

[0062] By constraining the supportable set with the candidate space constraint set, a set of candidate actions that satisfy the candidate space is obtained, and the edge weight threshold, Top-K rule function and constraint condition summary are written into the round evidence package; Candidate domains are selected based on the fault correlation matrix, isolation policy gating, and domain selection score. The domain with the highest score that meets the isolation gating is used as a redundant domain or a shared backup domain, and the output and output basis summary are written into the round evidence package. The fault correlation matrix is ​​constructed based on information such as data center / fault domain / same power network / same uplink; isolation policy gating directly eliminates combinations that do not meet the priority policies of different data centers / different fault domains; domain selection scoring, such as calculating the domain selection score for candidate domain D (which can be a set of clusters / node categories / backup pools). : in, These are weight parameters (fixed with the strategy version). For cost items such as shared backup usage / cross-domain communication overhead, C Correlation; Output: Select the domain with the highest score and that meets the isolation gating as the redundant domain / shared backup domain; The redundant domain / shared backup domain and its underlying summary (Top-K supporting edge, correlation penalty item, cost item, and gate trigger item) are written into the round evidence package.

[0063] To ensure audit review, this round of evidence packages At least the following should be recorded: Supported network baseline summary: current round hash, parameter version number; Candidate space constraints: threshold, Top-K rules, supported set, only allowed cluster set involved in the action, only allowed backup pool set selected by shared backup actions, whitelist and blacklist hit items, calculation method and value of action amplitude upper limit shrinkage; Domain selection criteria: size of candidate domain set, components of domain selection score, reasons for gating elimination, and final redundant / shared backup domain; Information bound to consistency: policy version identifier, policy version identifier, and idempotent key summary.

[0064] Through the aforementioned constraints and recording mechanisms, this step clarifies and provides evidence for how candidate spaces are generated / shrinked, how redundant domains and shared backup domains are determined, and how the basis for verification is established, thus avoiding unforeseen and unverifiable risks caused by relying solely on experience or verbal rules.

[0065] For each SFC, at least one of the four redundancy strategies—dedicated active backup, dedicated standby backup, shared active backup, and shared standby backup—is selected, and an executable orchestration action set is formed by combining the selection results of the redundancy domain or shared backup domain. The redundancy strategy identifier, the redundancy domain or shared backup domain result, and the constraint verification result are written into the round evidence package. The executable orchestration action set includes at least the placement action of each function in the service function chain, the backup resource allocation action, the shared backup pool configuration action, and the cross-cluster collaborative configuration action. Constraint verification includes at least the following: under the selected redundancy strategy and domain selection conditions, performing computable verification of end-to-end delay thresholds and reliability thresholds (using estimation / simulation / proof verification, etc.), recording a summary of the verification results, and obtaining constraint verification results.

[0066] Specifically, the formation of an executable set of orchestrated actions includes: Obtain a snapshot of the global state in this round, and generate or update the feature vector based on the global state snapshot; Based on the global state snapshot and feature vector, a set of model parameters is extracted. The set of model parameters includes at least the resource capacity parameters of each computing cluster or node, the business requirement parameters of the service function chain, the end-to-end cutoff latency threshold, the reliability threshold, and the capacity or quota parameters of the shared backup pool. A joint orchestration optimization model is constructed based on the set of model parameters. The joint orchestration optimization model includes at least an objective function, decision variables, and model constraints. The decision variables include at least function placement variables, dedicated backup variables and shared backup pool variables, shared backup allocation variables, and cross-cluster collaborative configuration variables. The model constraints include at least resource capacity constraints, deadline latency constraints, and reliability threshold constraints. Solving the joint orchestration optimization model yields the target orchestration scheme that satisfies the model constraints; The target orchestration scheme is compared with the current orchestration state to obtain the set of variable changes; Based on the preset action primitive library, the variable change set is decoded into an executable orchestration action set. Each orchestration action includes at least an action type, an object of action, action parameters, and an effective scope. The action type includes at least one or more of the following: creation or release of functional instances, migration or reconstruction of instances, scaling up or down of shared backup pools, updating of shared backup allocation, and cross-cluster collaborative configuration distribution. When multiple candidate orchestration schemes are obtained, the target action set is determined from the action set corresponding to the candidate orchestration scheme set as the executable orchestration action set according to the objective function value or the preset risk or benefit ranking rule. When the joint orchestration optimization model generates multiple candidate orchestration schemes that meet the constraints, a comprehensive score is calculated for the action set corresponding to each candidate orchestration scheme, and the action set with the best comprehensive score is selected as the executable orchestration action set. The comprehensive score includes at least two or more of the following: deadline delay default risk, reliability gap, and cost increment. The decoding process is as follows: An instance creation action is generated when a function placement variable changes from unselected to selected; an instance release action is generated when a function placement variable changes from selected to unselected; an instance migration action is generated when the same function instance changes from selected to unselected between different nodes or different clusters; and an instance reconstruction action is generated when the same function instance changes from unselected to selected between different nodes or different clusters. When the dedicated backup variable changes, generate the creation or release action of the dedicated backup instance or the backup binding update action; When the shared backup pool variables change, a shared backup pool capacity adjustment action or a shared backup pool quota adjustment action is generated. When the shared backup allocation variable changes, a shared backup allocation update action is generated to update the allocation relationship between the beneficiary entity and the shared backup pool. When the cross-cluster collaborative configuration variables change, a cross-cluster collaborative configuration distribution action is generated.

[0067] Specifically, if an observation goes out of bounds or conflicts, the process rolls back to a consistent baseline based on the rollback pointer and triggers a re-evaluation. After execution or rollback, the round evidence package is sealed and a previous hash, current hash, and signature or authentication field are generated to form a hash chain. Before entering the next round, a verification gate is executed; if it fails, entry into the next round is prohibited. This includes: When key performance indicators (KPIs) of the observed data exceed their limits or cross-cluster conflicts occur, the system rolls back to a consistent baseline state based on the rollback pointer and triggers a reassessment. The reassessment after rollback uses the state corresponding to the historical round evidence package pointed to by the rollback pointer as the consistent input baseline. After completing the current round of execution or rollback, the round evidence package is sealed, generating a previous hash, the current round hash, and a signature or authentication. Before entering the next round, the integrity of the sealed data and the continuity of the hash chain are verified. If the verification fails, the system is prohibited from entering the next round. The verification content includes at least hash chain continuity and signature or authentication validity. If the verification fails, the reason for failure is recorded, and the system is prohibited from entering the next round. The current round hash is calculated from at least the previous hash, policy version identifier, transaction identifier, target action, evaluation result, and summary of the executed observation, and satisfies the following conditions: ,in, For the preceding hash of the next round, This is the hash for this round; the signature or authentication is at least bound to the hash for this round and the policy version identifier, and enters the... Pre-round verification includes at least hash chain continuity verification and signature or authentication validity verification; The rollback pointer points to a certain historical round evidence package, and the re-evaluation after rollback must use the global state snapshot or its summary corresponding to the round evidence package as the cross-cluster consistency input benchmark. The triggering criteria for key indicators exceeding limits or cross-cluster conflicts include at least the following: SLA indicators exceeding thresholds, reliability indicators falling below thresholds, execution failures caused by resource conflicts, policy version conflicts, duplicate transaction conflicts, or resource contention conflicts.

[0068] A closed-loop intelligent orchestration device for multi-cluster service function chains, the device comprising: The telemetry acquisition module is used to collect telemetry data from each cluster and generate a global status snapshot and feature vector. The evidence package management module is used to generate pre-commit records for round evidence packages and bind policy version identifiers and transaction identifiers. After obtaining execution receipts, execution observations and update results, it seals the round evidence packages and generates the previous hash, current hash and signature or authentication fields, and uses the sealing verification gate to control the entry into the next round. The candidate action generation module and the gating evaluation module are used to generate a set of candidate actions, form gating evaluation results and select target actions, and write relevant fields into the round evidence package; The assessment budget and shared assessment event module is used to configure associated assessment groups and trigger shared assessment events under the candidate action assessment budget, generate multiple candidate feedbacks and form assessment event records to be written into the round evidence package; The collaborative support network module is used to update the collaborative support network based on multi-candidate feedback, and output constraints to limit the candidate action space and guide the selection of redundant domains or shared backup domains, and write them into the round evidence package. The redundancy strategy selection and action set generation module is used to select a redundancy strategy from four types of redundancy strategies and generate an executable orchestration action set, and write the redundancy strategy and the selection results of the redundancy domain or shared backup domain into the round evidence package. The cross-cluster consistency execution module is used to implement cross-cluster consistency execution based on policy version identifier and transaction identifier, and collect execution receipts and execution observations. In case of out-of-bounds or conflicts, it triggers rollback and re-evaluation based on the rollback pointer.

[0069] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0070] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A closed-loop intelligent orchestration method for multi-cluster service function chains, characterized in that, The method includes: Collect telemetry data from each cluster to form a global status snapshot and feature vector; Generate a pre-commit record for the round evidence package, write and bind the policy version identifier, transaction identifier and previous hash; Based on the global state snapshot and feature vector, a set of candidate actions is constructed, and gating evaluation is performed to obtain the evaluation result. The target action is selected through the set of candidate actions, and the set of candidate actions, the evaluation result and the target action are written into the round evidence package. Each candidate action includes at least the action type, target, action parameters, effective scope and rollback pointer. Configure associated evaluation groups under the preset candidate action evaluation budget constraints; when a shared evaluation event is triggered, consume one unit budget to produce multiple candidate feedbacks and generate an evaluation event record to be written into the round evidence package; The collaborative support network is updated based on multiple candidate feedback, and the update results or summary of the collaborative support network, as well as the input summary, parameter version and output summary related to the update, are written into the round evidence package. The collaborative support network outputs an explicit constraint set to limit the candidate action space and guides the selection of redundant domains or shared backup domains, thus forming an executable orchestration action set; the explicit constraint set, redundancy strategy, domain selection results, and constraint verification results are written into the round evidence package; Based on the policy version identifier and transaction identifier, the executable orchestration action set is executed in a consistent manner across clusters. Before execution, the policy version identifier and transaction identifier are verified in each cluster, execution receipts are obtained, execution observations are collected and written into the round evidence package. If the observation goes out of bounds or conflicts, the system will roll back to the consensus benchmark and trigger a reassessment based on the rollback pointer. After the execution or rollback is completed, the round evidence package will be sealed and the previous hash, the current hash, and the signature or authentication field will be generated to form a hash chain. Before entering the next round, a verification gate will be executed. If the gate fails, the system will be prohibited from entering the next round.

2. The multi-cluster service function chain closed-loop intelligent orchestration method according to claim 1, characterized in that, The specific implementation process for forming the global state snapshot and feature vector includes: Collect telemetry data from each computing cluster. The telemetry data includes at least cluster or node resource utilization, end-to-end latency, throughput, error rate or packet loss rate, instance health, and workload characteristics. Telemetry data from different clusters are time-aligned, denoised or missing data is filled, and statistically aggregated according to a unified time window. The data is then organized into a global state snapshot according to the cluster dimension, node dimension, SFC or function dimension. The global state snapshot includes at least the resource capacity and usage, the current placement and link path of the SFC, the backup resource usage and sharing relationship, key thresholds and alarm status. The quantifiable fields in the global state snapshot are standardized or normalized, the discrete fields are encoded, and cross features for candidate action generation, gating evaluation and support network updates are added to form a feature vector.

3. The multi-cluster service function chain closed-loop intelligent orchestration method according to claim 2, characterized in that, The specific implementation process of writing and binding the policy version identifier, transaction identifier, and previous hash to the pre-commit record of the generated round evidence package includes: Before any orchestration action is issued in this round, a pre-commit record of the round evidence package is generated, and the strategy version identifier and transaction identifier are bound to the pre-commit record; the pre-commit record includes at least the unique identifier of the round evidence package, the append write position before the record is sealed, the write timestamp, and the operator or device identifier; Calculate the hash values ​​of the current round's global state snapshot, feature vector, and candidate set summary to form the preceding hash; Write the strategy version identifier, transaction identifier, and preceding hash into the round evidence package.

4. The intelligent orchestration method for closed-loop multi-cluster service function chain according to claim 3, characterized in that, The specific implementation process of constructing a candidate action set, performing gating evaluation to obtain evaluation results, selecting a target action from the candidate action set, and writing the candidate action set, evaluation results, and target action into the round evidence package includes: Establish an action primitive library and standardize the description of actions based on the mapping relationship between action primitives, parameters, and objects of action; Based on the current global state snapshot and feature vector, candidate parameter ranges are generated for each action primitive to form candidate actions. Action summaries of the candidate actions are calculated to construct a set of candidate actions. The action summary is a unique index of the candidate action. Each candidate action carries at least the target SFC identifier, the set of affected nodes or links, resource increment or decrement, expected effective range, and a rollback pointer for rule-based rollback and re-evaluation after exceeding the limit. Each candidate action includes at least the action type, affected object, action parameters, effective range, and rollback pointer. Perform gating evaluation on each candidate action to determine whether it meets the SLA threshold constraint, cost boundary constraint, reliability threshold constraint, cross-cluster consistency constraint and action safety boundary constraint, and output the evaluation results, including Pass / Fail, failure reason, risk score and confidence level; The SLA threshold constraint, based on the SFC topology and link or node delay model, estimates the end-to-end delay jitter after the candidate action, determines whether it exceeds the SLA threshold, and outputs the delay default risk and confidence level. The cost boundary constraint is determined based on resource quotas, budget limits, and resource increments or reductions to estimate resource cost changes, and whether the boundary is exceeded, and the extent and reason for exceeding the boundary are output. The reliability threshold constraint is based on the redundancy strategy and the requirements of the shared backup domain or redundant domain. It estimates the availability improvement or failure rate change, determines whether the reliability threshold is met, and outputs the minimum gap when it is not met. The cross-cluster consistency constraint verifies whether the policy version on which the candidate action depends is consistent with the current policy version of each cluster, uses the transaction identifier or action digest as an idempotent key to detect duplicate issuance, and outputs risk conflicts and conflict types for conflict risks caused by concurrent changes or resource contention. The action safety boundary constraint checks whether it reaches the protected SFC or critical node, whether it exceeds the change range limit, and whether it violates the safety rules of the cooldown time or change window; if it does not meet the requirements, it will directly fail and output the safety boundary trigger item. Extract candidate actions that pass the gating evaluation from the candidate action set, construct a candidate action target set, and select target actions from the candidate action target set according to a preset objective function or sorting rule; Write the candidate action set, evaluation results, and target action into the round evidence package.

5. The intelligent orchestration method for closed-loop multi-cluster service function chain according to claim 4, characterized in that, The specific implementation process of configuring associated evaluation groups under the preset candidate action evaluation budget constraint, and consuming one unit budget to produce multiple candidate feedbacks and generating evaluation event records to be written into the round evidence package when a shared evaluation event is triggered includes: The target action is taken as a candidate action. Under the preset candidate action evaluation budget constraint, the candidate actions are organized into an associated evaluation group. The organization rule is to classify the candidate actions that are related to each other on the same batch of critical resources, the same SFC, the same shared backup pool, or the same set of candidate supply entities into the same associated evaluation group. When a shared evaluation event is triggered, one unit of budget is consumed to generate candidate feedback for multiple candidate actions in the associated evaluation group, generate an evaluation event record and write it into the round evidence package. The assessment budget represents the maximum number of high-cost assessments allowed to be triggered in this round; The triggering criteria for the shared evaluation event shall meet at least one of the following conditions: the number of candidate actions or uncertainty in the gating evaluation reaches a preset threshold; the key indicator is close to the threshold; insufficient samples or distribution drift detection required to support network updates are triggered; or the event is triggered periodically for calibrating the model or rules. The candidate feedback includes at least the prediction latency or throughput or error rate changes, reliability changes, cost changes, conflict or rollback risk scores and confidence levels; The evaluation event log shall include at least the event identifier, the associated evaluation group identifier, the list of candidate actions within the group, the budget consumption, the feedback of each candidate action, the timestamp, and a summary of the evaluation environment.

6. The multi-cluster service function chain closed-loop intelligent orchestration method according to claim 5, characterized in that, The specific implementation process of updating the collaborative support network based on multiple candidate feedback and writing the update result or summary of the collaborative support network, as well as the input summary, parameter version and output summary related to the update into the round evidence package includes: Construct a collaborative support network, taking into input global state snapshots, policies and constraints, evaluation and observation records, and version and transaction identifiers, and outputting entity sets, edge weight sets, and evidential digests; the evidential digests include network hashes, parameter versions, thresholds, and gating results; Extract resources and business objects from the global state snapshot, classify them according to supply entities and benefit entities, and assign them unique identifiers; For each beneficiary entity, candidate supporting edges are generated based on preset resource mapping relationships, reachability, sharing strategies, and isolation rules. If the isolation rules of an edge are not met, the edge is marked as a prohibited edge. The basic support strength of each edge is calculated by combining support capacity, availability, isolation or fault domain, stability and sharing degree, and the edge weight is obtained by normalizing the outgoing edges of the same supply entity. By using policy constraints as gating conditions, edges that do not meet the gating conditions are directly set to zero or removed, and the network hash, parameter version, and gating digest are written into the round evidence package to obtain the collaborative support network. Based on the multiple candidate feedbacks generated by shared evaluation events, the collaborative support network is updated. When a shared evaluation event is triggered, it generates candidate feedbacks for multiple candidate actions within the same associated evaluation group. For each candidate action, an input summary is extracted, including benefits, risks or costs, and confidence levels. The feedbacks at the action layer are mapped to an affected edge set, which includes the set of support edges actually used, changed, or depended upon by the candidate actions. The net contribution of this round of shared evaluation events to the support edges is obtained by aggregating each edge in the support edge set. : in, For return or risk weighting coefficients, To prevent zero items, For profit, For risk or cost, Confidence level; To support edge sets; For candidate actions; To support edges; The edge weights are then updated according to an incremental rule, which is as follows: in, The learning rate or step size is the event-level learning rate. For use in The contribution mapping function mapped to the target increment scale of [0,1]; This is the clipping function; After the update, normalization is performed again on the outgoing edges of the same supply entity, and a gating factor is introduced at the event level to gate the confidence update: in, Base step size; The gating factor; For edges whose duration exceeds the duration threshold and whose deviation from the current load / topology is greater than the deviation threshold, which are not covered by any shared evaluation events, apply attenuation according to the time window: in, The attenuation coefficient; The round evidence package records the event identifier, the set of candidate actions involved, the input summary for each action, the set of affected edges, the aggregated net contribution summary, and the gating parameters. The version and value of ) and a summary of the edge weights before and after the update.

7. The intelligent orchestration method for closed-loop multi-cluster service function chain according to claim 6, characterized in that: The filtering process to form an executable set of orchestration actions specifically includes: Based on the edge weights and gating results of the collaborative support network, the candidate action space for generation or selection is restricted by an explicit constraint set, the selection results of the redundant domain or shared backup domain are output, and the constraint relationship and basis summary are written into the evidence package. For each beneficiary entity, extract its supportable set from the collaborative support network. : in, For candidate actions, The edge weight threshold, For Top-K rule functions; A candidate space constraint set is constructed by constraining conditions, which include at least whitelist or blacklist constraints, shrinking of action range upper limit, restriction of applicable cluster domain for actions, restriction of available domain for shared backup, and consistency and security boundary gating. By constraining the supportable set with the candidate space constraint set, a set of candidate actions that satisfy the candidate space is obtained, and the edge weight threshold, Top-K rule function and constraint condition summary are written into the round evidence package; Candidate domains are selected based on the fault correlation matrix, isolation policy gating, and domain selection score. The domain with the highest score that meets the isolation gating is used as a redundant domain or a shared backup domain, and the output and output basis summary are written into the round evidence package. For each SFC, at least one of the four redundancy strategies—dedicated active backup, dedicated standby backup, shared active backup, and shared standby backup—is selected, and an executable orchestration action set is formed by combining the selection results of the redundancy domain or shared backup domain. The redundancy strategy identifier, the redundancy domain or shared backup domain result, and the constraint verification result are written into the round evidence package. The executable orchestration action set includes at least the placement action of each function in the service function chain, the backup resource allocation action, the shared backup pool configuration action, and the cross-cluster collaborative configuration action. Constraint verification includes at least the following: under the selected redundancy strategy and domain selection conditions, performing computable verification of end-to-end delay threshold and reliability threshold, recording a summary of the verification results, and obtaining constraint verification results.

8. The multi-cluster service function chain closed-loop intelligent orchestration method according to claim 7, characterized in that, The formation of an executable set of orchestrated actions includes: Obtain a snapshot of the global state in this round, and generate or update the feature vector based on the global state snapshot; Based on the global state snapshot and feature vector, a set of model parameters is extracted. The set of model parameters includes at least the resource capacity parameters of each computing cluster or node, the business requirement parameters of the service function chain, the end-to-end cutoff latency threshold, the reliability threshold, and the capacity or quota parameters of the shared backup pool. A joint orchestration optimization model is constructed based on the set of model parameters. The joint orchestration optimization model includes at least an objective function, decision variables, and model constraints. The decision variables include at least function placement variables, dedicated backup variables and shared backup pool variables, shared backup allocation variables, and cross-cluster collaborative configuration variables. The model constraints include at least resource capacity constraints, deadline latency constraints, and reliability threshold constraints. Solving the joint orchestration optimization model yields the target orchestration scheme that satisfies the model constraints; The target orchestration scheme is compared with the current orchestration state to obtain the set of variable changes; Based on the preset action primitive library, the variable change set is decoded into an executable orchestration action set. Each orchestration action includes at least an action type, an object of action, action parameters, and an effective scope. The action type includes at least one or more of the following: creation or release of functional instances, migration or reconstruction of instances, scaling up or down of shared backup pools, updating of shared backup allocation, and cross-cluster collaborative configuration distribution. When multiple candidate orchestration schemes are obtained, the target action set is determined from the action set corresponding to the candidate orchestration scheme set as the executable orchestration action set according to the objective function value or the preset risk or benefit ranking rule. When the joint orchestration optimization model generates multiple candidate orchestration schemes that meet the constraints, a comprehensive score is calculated for the action set corresponding to each candidate orchestration scheme, and the action set with the best comprehensive score is selected as the executable orchestration action set. The comprehensive score includes at least two or more of the following: deadline delay default risk, reliability gap, and cost increment. The decoding process is as follows: An instance creation action is generated when a function placement variable changes from unselected to selected; an instance release action is generated when a function placement variable changes from selected to unselected; an instance migration action is generated when the same function instance changes from selected to unselected between different nodes or different clusters; and an instance reconstruction action is generated when the same function instance changes from unselected to selected between different nodes or different clusters. When the dedicated backup variable changes, generate the creation or release action of the dedicated backup instance or the backup binding update action; When the shared backup pool variables change, a shared backup pool capacity adjustment action or a shared backup pool quota adjustment action is generated. When the shared backup allocation variable changes, a shared backup allocation update action is generated to update the allocation relationship between the beneficiary entity and the shared backup pool. When the cross-cluster collaborative configuration variables change, a cross-cluster collaborative configuration distribution action is generated.

9. The intelligent orchestration method for closed-loop multi-cluster service function chain according to claim 8, characterized in that, If the execution observation goes out of bounds or conflicts, it will be rolled back to the consistency benchmark according to the rollback pointer and a re-evaluation will be triggered; after the execution or rollback is completed, the round evidence package will be sealed and the previous hash, the current hash and the signature or authentication field will be generated to form a hash chain; Before proceeding to the next round, a verification gate is executed; failure to pass the gate prevents entry into the next round. Specifically, this includes: When key performance indicators (KPIs) of the observed data exceed their limits or cross-cluster conflicts occur, the system rolls back to a consistent baseline state based on the rollback pointer and triggers a reassessment. The reassessment after rollback uses the state corresponding to the historical round evidence package pointed to by the rollback pointer as the consistent input baseline. After completing the current round of execution or rollback, the round evidence package is sealed, generating a previous hash, the current round hash, and a signature or authentication. Before entering the next round, the integrity of the sealed data and the continuity of the hash chain are verified. If the verification fails, the system is prohibited from entering the next round. The verification content includes at least hash chain continuity and signature or authentication validity. If the verification fails, the reason for failure is recorded, and the system is prohibited from entering the next round. The current round hash is calculated from at least the previous hash, policy version identifier, transaction identifier, target action, evaluation result, and summary of the executed observation, and satisfies the following conditions: ,in, For the preceding hash of the next round, This is the hash for this round; the signature or authentication is at least bound to the hash for this round and the policy version identifier, and enters the... Pre-round verification includes at least hash chain continuity verification and signature or authentication validity verification; The rollback pointer points to a certain historical round evidence package, and the re-evaluation after rollback must use the global state snapshot or its summary corresponding to the round evidence package as the cross-cluster consistency input benchmark. The triggering criteria for key indicators exceeding limits or cross-cluster conflicts include at least the following: SLA indicators exceeding thresholds, reliability indicators falling below thresholds, execution failures caused by resource conflicts, policy version conflicts, duplicate transaction conflicts, or resource contention conflicts.

10. A closed-loop intelligent orchestration device for multi-cluster service function chains, characterized in that, The device includes a telemetry acquisition module, a feature construction module, a candidate action generation module, a strategy constraint evaluation module, a consistency execution module, an execution receipt acquisition module, an execution observation acquisition module, a feedback update module, and an evidence package management module. The telemetry acquisition module is used to collect telemetry data from each cluster. The feature construction module is used to generate a global state snapshot and feature vectors; The candidate action generation module is used to construct a set of candidate actions based on the global state snapshot and feature vectors; The strategy constraint evaluation module is used to perform gating evaluation on the candidate action set to obtain the evaluation result; the target action is selected from the candidate action set, and the candidate action set, evaluation result and target action are written into the round evidence package; The collaborative support network outputs an explicit constraint set to limit the candidate action space and guides the selection of redundant domains or shared backup domains, thus forming an executable orchestration action set; the explicit constraint set, redundancy strategy, domain selection results, and constraint verification results are written into the round evidence package; The consistency execution module is used to perform cross-cluster consistency execution on executable orchestration action sets based on policy version identifiers and transaction identifiers. Before execution, policy version identifiers and transaction identifiers are verified in each cluster. The execution receipt collection module is used to obtain execution receipts; The observation and acquisition module is executed to collect and execute observations and write them into the round evidence package; The feedback update module is used to roll back to a consistent baseline and trigger a re-evaluation based on the rollback pointer when an observation goes out of bounds or conflicts occur. After the execution or rollback is completed, the round evidence package is sealed and the previous hash, the current hash, and the signature or authentication field are generated to form a hash chain. Before proceeding to the next round, a verification gate is executed; if the verification fails, the user is prohibited from proceeding to the next round. The evidence package management module is used to generate pre-commit records for round evidence packages and bind policy version identifiers and transaction identifiers. After obtaining execution receipts, execution observations and update results, it seals the round evidence packages and generates the previous hash, current hash and signature or authentication fields, and controls the entry into the next round with the seal verification gate.

Images