Data processing system and method based on federal architecture interface and related equipment

Abstract

The invention discloses a data processing system and method based on a federated architecture interface and related equipment, and relates to the technical field of computer software, in particular to a federated architecture distributed system formed based on a central coordination node and a plurality of regional autonomous nodes. The central coordination node is used for performing global strategy making, metadata block chain evidence storage, conflict detection and federated monitoring and self-healing to realize global management and control, and the regional autonomous node adapts to a physical machine heterogeneous environment to perform local strategy execution, heterogeneous protocol conversion and resource autonomous regulation and control so as to realize flexible regulation of a regional strategy. According to the scheme, through a federated and intelligent treatment system, inherent contradictions between centralized management and control and department autonomy, standardization and rapid iteration and global safety and local flexibility are solved, technical support is provided for an enterprise to construct a standardized, high-reliability and easy-to-expand API ecological system, digital transformation is assisted, and the enterprise safety is improved. And global controllability and local autonomy of enterprise-level API ecology are realized.

Description

Technical Field

[0001] The present application relates to the field of computer software technology, and more specifically, to a data processing system, method, and related equipment based on a federated architecture interface. Background Art

[0002] As enterprises deepen their digital transformation, Application Programming Interfaces (APIs) have become the core link connecting internal systems, third-party services, and external customers. As the global API economy grows, the resulting governance adjustments are becoming increasingly prominent.

[0003] In the existing API governance model, internal API management is decentralized, and each department develops APIs independently. There is a lack of a global view, which leads to duplicate development and version confusion. This makes it impossible to keep the overall enterprise-level API ecosystem under control, and it is impossible to complete the local application of enterprise-level APIs.

[0004] Therefore, how to achieve global controllability and local autonomy of the enterprise-level API ecosystem is an urgent problem that needs to be solved in this application. Summary of the Invention

[0005] In view of this, the present application discloses a data processing system, method and related equipment based on a federated architecture interface, aiming to achieve global controllability and local autonomy of the enterprise-level API ecosystem.

[0006] In order to achieve the above purpose, the disclosed technical solutions are as follows:

[0007] In a first aspect, the present application discloses a data processing system based on a federated architecture interface, the system comprising a central coordination node and a plurality of regional autonomous nodes;

[0008] The central coordination node is deployed on the cloud platform of the enterprise headquarters; the multiple regional autonomous nodes are deployed in the private environment of the branch offices; the central coordination node communicates with the multiple regional autonomous nodes through a cross-layer communication protocol;

[0009] The central coordination node is used for global policy formulation, metadata blockchain storage, conflict detection, and federated monitoring and self-healing;

[0010] For multiple regional autonomous nodes, the regional autonomous nodes are used to adapt to the heterogeneous environment of physical machines to perform local policy execution, heterogeneous protocol conversion and resource autonomous regulation.

[0011] Preferably, the central coordination node includes at least a blockchain evidence storage submodule, a conflict detection engine, a policy federation engine, and a federation monitoring and analysis platform;

[0012] The blockchain evidence submodule is used to construct a unique hash fingerprint generated by each API registration request based on the blockchain platform, and write the unique hash fingerprint into the distributed ledger to complete the metadata blockchain evidence process;

[0013] The conflict detection engine is used to automatically intercept duplicate path registrations based on the namespace tree structure, and to identify overlapping interfaces by analyzing API interface semantics to complete the conflict detection process;

[0014] The policy federation engine is used to formulate global policies and perform policy changes and version rollbacks based on the incremental synchronization mechanism;

[0015] The federated monitoring and analysis platform is used to collect logs of the integrated observability architecture, detect anomalies of deep learning models, and automatically perform elastic scaling to complete the federated monitoring and self-healing process.

[0016] Preferably, the policy federation engine includes at least a conflict arbitrator;

[0017] The conflict arbitrator is used to generate an optimal solution based on a multi-objective optimization algorithm when a conflict occurs between a regional policy and a global baseline policy; wherein the optimal solution is used to balance security and business requirements.

[0018] Preferably, the federated monitoring and analysis platform includes at least a cross-domain log collector and a federated learning trainer;

[0019] The cross-domain log collector is used to standardize the log format of each region through the integrated observability architecture, and calculate global API health indicators in real time through the framework and distributed processing engine;

[0020] The federated learning trainer is used to obtain the anonymized statistical features uploaded by each region, perform aggregate training on the global anomaly detection model based on the anonymized statistical features, and send the received model increments to the regional autonomous nodes for updating.

[0021] Preferably, the regional autonomous node comprises at least a local policy executor, a dynamic protocol adapter and a regional autonomous controller;

[0022] The local policy executor is used to perform extended Berkeley packet filter traffic interception, policy execution and policy caching to complete the local policy execution process;

[0023] The dynamic protocol adapter is used to perform heterogeneous protocol conversion based on the protocol conversion matrix and dynamically select the optimal service instance through an intelligent routing strategy;

[0024] The regional autonomous controller is used to compile the global policy issued by the central coordination node to complete the local policy execution process, and dynamically adjust the parameter quota of the API instance to complete the resource autonomous regulation process.

[0025] Preferably, the regional autonomous controller includes at least a policy localization compiler and a resource quota manager;

[0026] The policy localization compiler is used to compile the global policy issued by the central coordination node into a global policy that complies with the preset regional technology stack rules;

[0027] The resource quota manager is used to dynamically adjust the CPU / memory quota of the API instance based on the PID controller to ensure that the resource utilization is greater than or equal to the preset utilization.

[0028] A second aspect of the present application discloses a data processing method based on a federated architecture interface, applicable to the system described in any one of the first aspects, wherein the system includes a central coordination node and multiple regional autonomous nodes, wherein the central coordination node is deployed on the cloud platform of the enterprise headquarters; and the multiple regional autonomous nodes are deployed in the private environment of the branch offices. The method includes:

[0029] enabling the central coordination node to communicate with the plurality of regional autonomous nodes through a cross-layer communication protocol;

[0030] When the central coordination node is in communication with the multiple regional autonomous nodes, global policy formulation, metadata blockchain storage, and federated monitoring and self-healing are performed through the central coordination node;

[0031] When the central coordination node is in communication with the multiple regional autonomous nodes, the multiple regional autonomous nodes adapt to the physical machine heterogeneous environment to perform local policy execution, heterogeneous protocol conversion and resource autonomous regulation.

[0032] Preferably, the cross-layer communication protocol is composed of a control plane and a data plane, and enabling the central coordination node to communicate with the multiple regional autonomous nodes through the cross-layer communication protocol includes:

[0033] The central coordination node communicates with the multiple regional autonomous nodes by adopting a control plane with bidirectional streaming and a data plane with HTTP / 2 with Protobuf encoding.

[0034] A third aspect of the present application discloses a storage medium, which includes stored instructions, wherein when the instructions are executed, the device where the storage medium is located is controlled to execute the data processing method based on the federal architecture interface as described in any one of the second aspects.

[0035] The fourth aspect of the present application discloses an electronic device comprising a memory and one or more instructions, wherein the one or more instructions are stored in the memory and configured to be executed by one or more processors to perform a data processing method based on a federal architecture interface as described in any one of the second aspects.

[0036] From the above technical solution, it can be seen that the present application discloses a data processing system, method and related equipment based on a federal architecture interface. The system includes a central coordination node and multiple regional autonomous nodes. The central coordination node is deployed on the enterprise headquarters cloud platform, and the regional autonomous nodes are deployed in the branch office private environment. The central coordination node communicates with multiple regional autonomous nodes through a cross-layer communication protocol. The central coordination node is used for global policy formulation, metadata blockchain notarization, conflict detection, federal monitoring and self-healing. For multiple regional autonomous nodes, the regional autonomous nodes are used to adapt to the heterogeneous environment of physical machines to perform local policy execution, heterogeneous protocol conversion and resource autonomous regulation.

[0037] The beneficial effects of this application are as follows: Based on a federated architecture distributed system consisting of a central coordination node and multiple regional autonomous nodes, the central coordination node is used for global policy formulation, metadata blockchain notarization, conflict detection, and federated monitoring and self-healing to achieve global control, and the regional autonomous nodes adapt to the heterogeneous environment of physical machines to perform local policy execution, heterogeneous protocol conversion, and resource autonomous regulation, thereby achieving flexible adjustment of regional policies. This solution solves the inherent contradictions between centralized control and departmental autonomy, standardization and rapid iteration, and global security and local flexibility through a federalized and intelligent governance system, providing technical support for enterprises to build a standardized, highly reliable, and easily scalable API ecosystem, helping with digital transformation and achieving global control and local autonomy of the enterprise-level API ecosystem. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.

[0039] Figure 1 This is a structural diagram of a data processing system based on a federated architecture interface disclosed in an embodiment of the present application;

[0040] Figure 2 A flowchart of a data processing method based on a federated architecture interface disclosed in an embodiment of the present application;

[0041] Figure 3A flowchart of another data processing method based on a federated architecture interface disclosed in an embodiment of the present application;

[0042] Figure 4 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of the present application. DETAILED DESCRIPTION

[0043] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0044] In this application, the terms "comprises," "comprising," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not preclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0045] As can be seen from the background technology, in the existing API governance model, internal enterprise API management is decentralized, and each department independently develops APIs, lacking a global view. This leads to repeated development, version confusion, etc., making it impossible to keep the overall enterprise-level API ecosystem in a controllable state and unable to complete the local application of enterprise-level APIs. Therefore, how to achieve global controllability and local autonomy of the enterprise-level API ecosystem is an urgent problem to be solved in this application.

[0046] In order to solve the above problems, the present application discloses a data processing system, method and related equipment based on a federal architecture interface, a federal architecture distributed system composed of a central coordination node and multiple regional autonomous nodes, the central coordination node is used for global policy formulation, metadata blockchain notarization, conflict detection and federal monitoring and self-healing to achieve global control, and the regional autonomous nodes adapt to the heterogeneous environment of physical machines to perform local policy execution, heterogeneous protocol conversion and resource autonomous regulation, so as to achieve flexible adjustment of regional policies. This solution solves the inherent contradictions between centralized control and departmental autonomy, standardization and rapid iteration, global security and local flexibility through a federalized and intelligent governance system, and provides technical support for enterprises to build a standardized, highly reliable and easily scalable API ecosystem, assist in digital transformation, and achieve global control and local autonomy of the enterprise-level API ecosystem. The specific implementation method is described in detail through the following embodiments.

[0047] It should be noted that the data processing system, method and related equipment based on the federal architecture interface provided by this application can be used in the field of computer software technology, and is particularly suitable for the unified governance and dynamic collaboration of API services among multiple departments and systems within large-scale group enterprises. The above is only an example and does not limit the application field of the data processing system, method and related equipment based on the federal architecture interface provided by this application.

[0048] refer to Figure 1 As shown, a data processing system based on a federal architecture interface disclosed in an embodiment of the present application includes a central coordination node (Central Coordinator) and multiple regional autonomy nodes (Regional Autonomy Node, RAN).

[0049] The connection relationship between the central coordination node and multiple regional autonomous nodes is as follows:

[0050] The central coordination node is deployed on the enterprise headquarters cloud platform; the regional autonomous nodes are deployed in the branch office private environment; the central coordination node communicates with multiple regional autonomous nodes through a cross-layer communication protocol.

[0051] It should be noted that the cross-layer communication protocol consists of a bidirectional flow control plane and a data plane encoded using HTTP / 2 with Protobuf to ensure low latency and high throughput.

[0052] The central coordination node is used for global policy formulation, metadata aggregation, metadata blockchain storage (Hyperledger Fabric), conflict detection, and federated monitoring and self-healing (integrated with OpenTelemetry).

[0053] For multiple regional autonomous nodes, regional autonomous nodes are used to adapt to Kubernetes / VM / physical machine heterogeneous environments to perform local policy execution, heterogeneous protocol conversion and resource autonomous regulation.

[0054] A heterogeneous Kubernetes / VM / physical machine environment refers to an environment in which Kubernetes, virtual machines (VMs), and physical machines are used simultaneously to deploy and manage applications within a data center or cloud environment. This environment combines different technology stacks and resource management methods to adapt to different application requirements and optimize resource utilization.

[0055] 1. The central coordination node module decomposes to obtain the metadata federation catalog (Metadata Catalog).

[0056] 1.1. Metadata Federation Catalog:

[0057] The metadata federation directory includes at least a blockchain evidence submodule, a conflict detection engine, a policy federation engine, and a federated monitoring and analysis platform. The functions of the blockchain evidence submodule, conflict detection engine, policy federation engine, and federated monitoring and analysis platform are as follows:

[0058] The blockchain evidence submodule is used to build a unique hash fingerprint generated by each API registration request based on the open source blockchain platform (Hyperledger Fabric), and write the unique hash fingerprint into the distributed ledger to complete the metadata blockchain evidence process, preventing malicious tampering and improving security.

[0059] The conflict detection engine is used to automatically intercept duplicate path registrations based on the namespace tree structure (e.g., / department ID / service name / version) to determine whether there is a naming conflict. It also analyzes the API interface semantics to identify overlapping interfaces to determine whether there is a semantic conflict, thereby completing the conflict detection process. Conflict detection includes naming conflict detection and semantic conflict detection. The specific conflict detection implementation process is as follows:

[0060] Conflict Detection Engine:

[0061] Naming conflict detection: Based on the namespace tree structure (such as department ID / service name / version), duplicate path registrations are automatically blocked. The specific implementation process is as follows:

[0062] (1) Predefined rules for the namespace tree structure and hierarchical path specifications:

[0063] Use the three-level mandatory namespace format: / department ID / service name / version, for example:

[0064] Finance Department Payment Service V1.0: / finance / payment / 1.0;

[0065] Technical Department User Center V2.0: / tech / user / 2.0;

[0066] Department ID uniqueness: Uniformly assigned by a central node (such as using a universally unique identifier (UUID) or enterprise organizational structure code) to ensure cross-departmental path isolation.

[0067] Path element constraints:

[0068] Service names: Use CamelCase naming conventions (e.g., userManagement) and do not use reserved words (e.g., system, admin, etc.);

[0069] Version number: Follow the SemVer specification (major version, minor version, revision number, etc.), such as major version 2.1.0.

[0070] (2) Real-time conflict detection process during API registration:

[0071] When receiving a registration request, automatically convert the input path (such as / finance / payment / v1) to the canonical format / finance / payment / 1.0;

[0072] Verify that the path elements comply with the rules (for example, if the version number format is incorrect, intercept it in advance).

[0073] Tree index fast query:

[0074] The global namespace is stored in a Trie tree (prefix tree), and the query time complexity is O(k), where k is the number of path levels.

[0075] Example: When querying / finance / payment / 1.0, quickly locate the node along the path finance→payment→1.0 in the Trie tree. If the node exists, a conflict is determined.

[0076] (3) Conflict interception and automatic processing mechanism:

[0077] Hard collision interception strategy:

[0078] If the path to be registered is exactly the same as the existing path (e.g., / finance / payment / 1.0 is registered repeatedly), a 409 Conflict error is returned and the registration is rejected.

[0079] Blockchain evidence linkage:

[0080] Conflict information is synchronously written to the open-source enterprise-level blockchain platform (Hyperledger Fabric), recording the conflict path, applicant, and timestamp to prevent malicious duplicate registrations. Conflict information includes at least hard conflict information and / or soft conflict information.

[0081] Soft conflict prompt mechanism:

[0082] If the path prefix conflicts (e.g. / finance / payment already exists, and / finance / paymentV2 is newly registered), the system will automatically prompt.

[0083] Semantic conflict detection:

[0084] Use the BERT model to analyze API interface semantics (input / output fields), identify overlapping interfaces, and generate alerts. The specific implementation is as follows:

[0085] (1) API field semantic conversion:

[0086] Decode API documentation, convert input / output fields (such as userID, user unique identifier) ​​into natural language text, and weight them according to business importance (such as primary key fields have a higher weight).

[0087] (2) BERT model analysis:

[0088] The pre-trained BERT model is used to process text and generate interface semantic vectors, which are then fine-tuned to adapt to the API field (such as learning business semantics such as "user query" and "order creation").

[0089] (3) Similarity calculation:

[0090] Compare the semantic vectors of the new interface with the existing interface: Calculate the semantic similarity of the input / output fields (e.g., the matching degree between userID and userId). If the overall interface similarity exceeds a threshold (e.g., 0.85), functional overlap is determined. This application does not specify the threshold.

[0091] (4) Intelligent alarm generation:

[0092] When there is a conflict, similar fields are output for highlighting and comparison (such as overlapping parts of input parameters).

[0093] Global Service Catalog API: Provides a GraphQL interface for regions to query the full API metadata, supporting filtering by department, protocol type, data tag, etc.

[0094] 1.2 Policy Federator

[0095] The policy federation engine includes a policy template library, an incremental synchronization mechanism, and a conflict arbitrator.

[0096] Policy template library: Pre-installed machine-readable policy templates (Rego language) for compliance frameworks such as ISO 27001 and GDPR, supporting one-click delivery.

[0097] Incremental synchronization mechanism:

[0098] When the policy changes, only the difference is pushed to the regional autonomous node (Delta Encoding), reducing bandwidth usage by at least 75%.

[0099] Versioned rollback: Each policy is accompanied by a version number, and regional autonomous nodes can quickly roll back to historical versions.

[0100] The policy federation engine is used to formulate global policies and perform policy changes and version rollbacks based on the incremental synchronization mechanism.

[0101] The conflict arbiter is used to generate an optimal solution (Pareto) based on a multi-objective optimization algorithm (NSGA-II) when a conflict between the regional policy and the global baseline policy is detected. The optimal solution is used to balance security and business requirements.

[0102] Specific scenarios and implementation examples of the policy federation engine are as follows:

[0103] Global baseline policy: All financial APIs must enable two-factor authentication (2FA), and the throttling threshold can be 200 queries per second (QPS) (security goal: authentication strength ≥ 90%, risk level ≤ medium). This application does not specify the throttling threshold.

[0104] Regional policy requirements: During e-commerce promotions, the / finance / promotion / sale interfaces need to temporarily disable 2FA and increase the throttling threshold to 500 QPS. Business objectives: request success rate ≥ 95% and user complaint rate ≤ 1%.

[0105] Conflict point: Regional policies directly violate the global security baseline;

[0106] The NSGA-II algorithm is used to generate a compromise solution that balances security and business needs. The specific process is as follows:

[0107] (1) Define the conflicting objectives:

[0108] Security goals (such as authentication strength) and business goals (such as interface success rate) are quantitatively opposed.

[0109] (2) Algorithm-generated compromise solution:

[0110] A genetic algorithm is used to mix global and regional policy parameters (such as authentication switches and current limiting values) to screen out the Pareto optimal solution in which "one cannot be optimized without sacrificing the other."

[0111] (3) Automatically issuing balancing strategies:

[0112] For example, if the global requirement is "API must be limited to 200 QPS" and the regional application requires "500 QPS for e-commerce promotions", the algorithm generates a compromise solution of "350 QPS + temporary relaxation during peak periods".

[0113] Therefore, multi-objective optimization is used to replace the "black or white" policy decision to achieve a quantitative balance between security and business.

[0114] 1.3. Federated Monitoring and Analysis Platform (Federated Monitor):

[0115] The federated monitoring and analysis platform is used to collect logs for the integrated observability architecture (OpenTelemetry), detect anomalies for the deep learning model (LSTM-Autoencoder), and automatically scale out capacity to complete the federated monitoring and self-healing process.

[0116] Among them, the federated monitoring and analysis platform includes at least a cross-domain log collector and a federated learning trainer.

[0117] Cross-domain log collector:

[0118] The cross-domain log collector is used to standardize the log format of each region through the integrated observability framework (OpenTelemetry) and calculate global API health indicators in real time through the framework and distributed processing engine (Apache Flink);

[0119] Federated Learning Trainer:

[0120] The federated learning trainer is used to obtain anonymized statistical features uploaded by each region (such as API call frequency and error code distribution), aggregate training of the global anomaly detection model based on the anonymized statistical features, and send the received model increments to the regional autonomous nodes for updating.

[0121] Incremental model update:

[0122] New models are issued to regional autonomous nodes every day.

[0123] 2. Regional autonomous node module decomposition:

[0124] A regional autonomous node includes at least a local policy enforcer (LPE), a dynamic protocol adapter, and a regional autonomous controller.

[0125] 2.1. Local Policy Executor:

[0126] The local policy enforcer is used to perform extended Berkeley Packet Filter (eBPF) traffic interception, policy enforcement, and policy caching to complete the local policy enforcement process.

[0127] eBPF traffic interception:

[0128] Intercept API requests / responses in kernel mode, bypassing user-mode proxies, and reducing latency to 1 / 6 of traditional solutions.

[0129] Policy execution chain:

[0130] The policy execution chain includes chain execution authentication, current limiting, data desensitization and other policies, and supports dynamic plug-in loading (WebAssembly module).

[0131] Policy Cache:

[0132] The local LRU cache hot strategy can still run independently for at least 24 hours when the network is disconnected.

[0133] 2.2 Dynamic Protocol Adapter (DPA):

[0134] Protocol conversion matrix:

[0135] Built-in RESTful gRPC, SOAP 15 conversion logics, including GraphQL, are generated based on the Large Language Model (LLM) (CodeGen model fine-tuning).

[0136] Performance optimization: Through static code analysis + JIT compilation, the conversion logic execution efficiency is improved by at least 5 times compared to general frameworks.

[0137] Intelligent routing decisions: Dynamically select the optimal service instance based on the caller's geographic location, network quality (such as BGP data), and API SLA requirements.

[0138] The dynamic protocol adapter is used to convert heterogeneous protocols based on the protocol conversion matrix and dynamically select the optimal service instance through intelligent routing strategies.

[0139] 2.3 Regional Autonomy Controller (RAC):

[0140] The regional autonomous controller is used to compile the global policy issued by the central coordination node to complete the local policy execution process, and dynamically adjust the CPU / memory quota of the API instance in the region to ensure resource utilization ≥ 85% to complete the resource autonomous regulation process.

[0141] The regional autonomous controller includes at least a policy localization compiler and a resource quota manager.

[0142] The policy localization compiler is used to compile global policies (such as "all APIs must be authenticated") issued by the central coordination node into global policies (such as Kubernetes NetworkPolicy and IstioAuthorizationPolicy) that comply with the rules of the preset regional technology stack. For example, the policy localization compiler compiles global policies (such as "all APIs must be authenticated") issued by the central coordination node into specific rules (such as Kubernetes NetworkPolicy and IstioAuthorizationPolicy) that apply to the regional technology stack.

[0143] The resource quota manager dynamically adjusts the CPU and memory quotas of API instances based on the PID controller to ensure resource utilization is greater than or equal to the preset utilization rate. The preset utilization rate includes, but is not limited to, 85%. For example, the resource quota manager dynamically adjusts the CPU and memory quotas of API instances in the region based on the PID controller to ensure resource utilization is ≥85%.

[0144] 3. The key data flows of the central coordination node and multiple regional autonomous nodes are described as follows:

[0145] 3.1 Metadata registration flow:

[0146] Regional autonomous node A submits API metadata (Swagger JSON) to the central node;

[0147] The blockchain evidence storage module generates a transaction (TxID = 0x3a5f…) and writes the transaction into the distributed ledger;

[0148] After the conflict detection engine passes verification, the global service catalog is updated and broadcast to other regions.

[0149] 3.2 Cross-domain API call flow:

[0150] The caller's LPE (region A) intercepts the request, verifies the local policy, and then queries the global directory to obtain the target API location;

[0151] DPA converts HTTP / JSON to the gRPC / Protobuf format required by target region B;

[0152] The request is sent to the best instance in region B via dynamic routing, and the response data is returned with the reverse protocol conversion.

[0153] 3.3, Policy Federation Synchronization Flow:

[0154] The central node publishes new policies (such as "enabling two-factor authentication for all APIs");

[0155] After the regional autonomous node receives the policy issued by the central node, RAC compiles it into Envoy Filter and hot loads it to Sidecar.

[0156] The execution results of each region are aggregated to the federal monitoring platform, triggering automatic repair of non-compliant areas.

[0157] (1) The criteria for determining non-compliant areas are as follows:

[0158] Inadequate policy implementation: For example, a global requirement for APIs to enable two-factor authentication may result in an actual activation rate of less than 90% in a region.

[0159] Performance substandard: Policy execution delay exceeds 10ms, or resource utilization deviates from the target range, such as 75%-85%.

[0160] Detecting anomalies: The federated learning model detects that regional API call data (such as error rate) deviates from the global baseline by more than three standard deviations.

[0161] (2) Core process of automatic repair:

[0162] Problem location: Determine the cause through log analysis (such as policy configuration errors, insufficient resources);

[0163] Graded repair:

[0164] Emergency issues (such as authentication not enabled): Re-issue policies and hot-load in real time;

[0165] Performance issues: Automatically adjust the CPU / memory quotas of regional autonomous nodes (such as scaling instances);

[0166] Effect verification: Send a test request to confirm that the strategy is effective. The repair is completed after the indicators return to normal.

[0167] The following are some examples:

[0168] Scenario: The payment interface rate limit policy in region C is not set to 200 QPS as required globally. The actual rate is 500 QPS, which is considered substandard.

[0169] Repair steps:

[0170] The system discovered an abnormal current limit value and located it as a regional policy configuration error;

[0171] Automatically issue the correct current limiting policy (only update the differences), and reload the regional autonomous nodes;

[0172] The test request verifies that the current limit is effective and the repair is complete.

[0173] In order to facilitate the understanding of the data processing process based on the federated architecture interface, combined with Figure 2 To explain, Figure 2 A schematic diagram showing data processing based on a federated architecture interface.

[0174] Figure 2 Phase 1: Federation Metadata Registration and Synchronization:

[0175] Step 1.1: Standardize department-level API definitions:

[0176] The Regional Autonomous Node (RAN) automatically extracts metadata (endpoints, parameters, data schema) of the local API through the OpenAPI specification scanner and generates a standardized description file (YAML format).

[0177] Step 1.2: Blockchain evidence storage and conflict detection:

[0178] RAN encrypts the API metadata (AES-256) and submits it to the central node, triggering smart contract verification:

[0179] Check for naming conflicts: If the same path already exists in the global directory, the department hash suffix is ​​automatically appended.

[0180] Semantic similarity analysis: Use the Siamese network to calculate the similarity between the new API and the existing interface. If it is >85%, manual review is triggered.

[0181] After verification, the metadata hash value is written to the Hyperledger Fabric blockchain, and the evidence storage delay is <200ms.

[0182] Step 1.3, Federal Directory Broadcast:

[0183] The central node updates the global service catalog and pushes the changes to other RANs through an incremental synchronization protocol, transmitting only differential data (Delta encoding), reducing bandwidth usage by 70%.

[0184] Phase 2: Dynamic orchestration of cross-domain API calls:

[0185] Step 2.1: Local policy pre-execution;

[0186] The edge policy enforcer (EPE) of RAN-A, the caller, intercepts the API request and executes the localized policy chain:

[0187] Identity authentication: Verify the legitimacy of the JWT token and compare it with the central node synchronization revocation list (CRL) to prevent token reuse.

[0188] Attribute-based access control (ABAC): Dynamic authentication based on user roles (such as role=finance) and API tags (such as data_class=secret).

[0189] Policy execution takes ≤10ms, which is 8 times faster than traditional gateways.

[0190] Step 2.2, Federal Routing Decision:

[0191] EPE queries the federated service catalog to obtain a list of available instances of the target API.

[0192] The dynamic routing engine selects the optimal instance based on a multi-objective optimization algorithm:

[0193] Network metrics: Real-time RTT (50ms vs. 120ms) and packet loss rate (0.1% vs. 2.3%) for each instance.

[0194] Compliance constraints: If the request contains EU user data (GEO=EU), only local EDGE nodes are selected.

[0195] Load balancing: Dynamically assigns weights based on instance CPU usage (30% vs. 85%).

[0196] Step 2.3: Protocol conversion and request forwarding:

[0197] The Heterogeneous Protocol Conversion Layer (HPC) converts HTTP / JSON requests into the gRPC / Protobuf format supported by the target instance: calling the LLM to generate conversion code (for example, mapping {"id":123} to message ShipmentReq{int32 id=1;}).

[0198] The conversion logic is optimized through JIT compilation, and the single conversion delay is less than 5ms.

[0199] The request is sent to the target instance through the mTLS encrypted channel, and the connection reuse rate is ≥ 95%.

[0200] Phase 3: Real-time coordination of federated strategies:

[0201] Step 3.1: Global policy issuance:

[0202] The central node publishes new policies and pushes them to each RAN through a priority queue:

[0203] High-priority policies, such as security patches, take effect immediately (preemptive updates).

[0204] Low-priority policies (such as log format changes) take effect during off-peak hours.

[0205] Step 3.2: Local strategy compilation and hot loading:

[0206] After the RAN receives the policy, the Regional Autonomous Controller (RAC) compiles it into rules that can be recognized by the execution engine: the policy takes effect within 100ms and service interruption is zero.

[0207] Step 3.3, conflict feedback and adaptive adjustment:

[0208] If local policies conflict with business requirements (e.g., a promotional API cannot withstand the global throttling threshold), the RAN submits a policy exemption request to the central node:

[0209] The federation engine assesses risk based on historical data (such as the API's stability over the past 30 days) and dynamically adjusts the limit (±20%). The limit can be 20%, 22%, etc., and is set based on actual conditions. This application does not impose specific restrictions.

[0210] Adjustment results are synchronized to other regions to prevent policy fragmentation.

[0211] Phase 4: Federal Monitoring and Self-Healing:

[0212] Step 4.1: Aggregate distributed tracing data:

[0213] Each RAN collects API call chain logs (TraceID, SpanID, and duration) through the OpenTelemetry SDK and reports them to the federated monitoring platform at the central node.

[0214] The real-time correlation analysis engine detects cross-domain anomalies and triggers root cause analysis.

[0215] Step 4.2: Federated Learning Model Update

[0216] The central node aggregates anonymous statistical features of each region (such as error code distribution and peak QPS) and trains a global anomaly detection model:

[0217] Use LSTM to predict the API traffic baseline, and trigger an alarm when the deviation is greater than 3σ.

[0218] The model parameters are encrypted and sent to each RAN, and the incremental update takes less than 2 minutes.

[0219] Step 4.3: Automatic elastic expansion and contraction:

[0220] Regional autonomous nodes automatically scale up and down through the Kubernetes Operator API based on prediction models and real-time load.

[0221] The specific process of regional autonomous nodes automatically scaling up and down the API through the Kubernetes Operator based on the prediction model and real-time load is as follows:

[0222] Resource utilization is stabilized at 75%-85%, avoiding over-configuration.

[0223] The automation of Kubernetes Operator is as follows:

[0224] (1) Custom Resource Definition (CRD) and Controller:

[0225] Scenario example:

[0226] CRD definition:

[0227] Define the scaling policy CRD for the API service:

[0228] yaml

[0229] apiVersion: apigovernance.faga.io / v1

[0230] kind: APIScalingPolicy

[0231] metadata:

[0232] name: payment-api-policy

[0233] spec:

[0234] minReplicas: 2

[0235] maxReplicas: 20

[0236] predictFactor: 1.5 #predicted flow amplification factor

[0237] metrics:

[0238] - type: CPU

[0239] target: 75%

[0240] - type: QPS

[0241] target: 800.

[0242] Controller loop logic:

[0243] The Operator continuously monitors the CRD and API instance status, and automatically updates the Deployment's replicas field when the prediction model or real-time load triggers a threshold.

[0244] (2) Optimization of scaling execution:

[0245] Gradual scaling:

[0246] When expanding, increase the capacity in multiples of 1 → 2 → 4 → 8 to avoid resource fluctuations caused by a one-time expansion. When reducing the capacity, wait for 10 minutes, such as observing stability, before reducing the number of replicas.

[0247] Taint and tolerance configuration:

[0248] Newly expanded Pods are automatically tainted with api-type=hot and are preferentially scheduled to idle nodes to avoid competing for resources with other services.

[0249] Step 4.4: Cross-domain circuit breaker and service degradation:

[0250] When the API failure rate in a region exceeds 5%, the federation engine activates the cross-region circuit breaker mechanism:

[0251] Traffic is automatically switched to the backup region (for example, European user requests are switched from the failed eu-west-1 region to eu-central-1).

[0252] If the entire region is unavailable, a preset degraded response (such as cached data) is returned, and the SLA compliance rate is ≥ 99.95%.

[0253] Figure 2 In [1], the metadata module uses “standardized API information, blockchain evidence storage, and global service directory” as a “map” for cross-domain calls:

[0254] After Region A registers an API, the central node writes its protocol format (such as Swagger), deployment location (such as the cluster IP address in Region B), and basic policies (such as authentication requirements) into the global directory.

[0255] When making cross-domain calls, the caller in region C first checks the global directory to determine "where the target API is, what protocol it uses, and what policy verification is required," paving the way for subsequent calls.

[0256] (2) During the call process, "strategy conflict + execution indicator" triggers the intervention of the strategy module:

[0257] When executing a local policy (for example, when the Sidecar in region C performs throttling), a conflict is detected with the global policy (for example, a local throttling of 500 QPS versus a global requirement of 200 QPS).

[0258] At the same time, real-time indicators generated by the call (such as a sudden increase in QPS and a high authentication failure rate) will also be reported to let the policy module know that "there is a problem with the execution effect."

[0259] (3) The policy module outputs “compromise policy instructions” to directly control the calling behavior:

[0260] The center uses the NSGA-II algorithm to generate compromise strategies (e.g., limiting traffic to 300 QPS, temporarily effective during e-commerce promotions).

[0261] Compile the policy into locally executable rules (such as Envoy Filter) and send it to the Sidecar in region C. When called, the new rules are directly executed (for example, the rate limit value is changed from 500 QPS to 300 QPS).

[0262] (4) The strategy module synchronizes the "strategy execution status" for the monitoring module to determine whether it has "met the standard":

[0263] After implementing the new policy, Region C reports data (e.g., 2FA activation rate of 92% and rate limiting compliance rate of 85%).

[0264] The monitoring module compares global standards (such as 2FA ≥ 90%, current limiting deviation ≤ 20%), identifies areas that do not meet the standards (such as current limiting compliance rate 85% < 90%), and forms a closed-loop strategy of dependence → conflict → regulation → feedback.

[0265] This application solves the inherent contradictions between centralized control and departmental autonomy, standardization and rapid iteration, global security and local flexibility through a federalized and intelligent governance system. It provides technical support for enterprises to build a standardized, highly reliable, and easily scalable API ecosystem, and helps digital transformation move from "local controllability" to "global trustworthiness."

[0266] 1. Balance between hierarchical governance and flexible autonomy:

[0267] The federal architecture achieves the dual goals of centralized global policy control and flexible regional policy adjustment, ensuring consistency in enterprise-level security and compliance baselines while empowering business departments with autonomy over their technology stacks, thus avoiding the constraints of a "one-size-fits-all" governance model on business agility.

[0268] 2. Systematic improvement of security and compliance:

[0269] The cross-domain authentication mechanism based on dynamic tokens, fine-grained attribute control, and data sovereignty-sensitive routing capabilities significantly reduce the risks of unauthorized access and data violations, meet the compliance requirements of multiple jurisdictions, and support dynamic delegation of permissions under complex organizational structures.

[0270] 3. Performance optimization for large-scale distributed scenarios:

[0271] Through decentralized traffic proxy and kernel-level policy execution technology, the performance bottleneck of traditional centralized gateways can be effectively avoided, high-throughput, low-latency cross-domain API collaboration can be achieved, and the real-time interaction needs of massive service nodes within the enterprise can be adapted.

[0272] 4. Enhanced full life cycle governance capabilities:

[0273] It covers the entire process of intelligent governance of API design, development, deployment, and monitoring, automatically identifies technical debt issues such as non-standard interface definitions and version conflicts, and provides repair suggestions, significantly improving the maintainability and long-term evolution capabilities of API assets.

[0274] 5. Heterogeneous environment compatibility and ecological scalability:

[0275] It supports seamless integration of multiple protocols and multiple infrastructures, reducing the complexity of enterprise hybrid cloud and legacy system transformation. At the same time, through open architecture design, it is compatible with mainstream cloud-native tool chains to reduce the risk of technology lock-in.

[0276] 6. Dynamic adaptive fault recovery mechanism:

[0277] Based on the collaboration of federated monitoring and intelligent strategies, rapid perception, root cause location, and automatic circuit breaking / downgrading of cross-domain faults can be achieved, thereby improving the overall fault tolerance of distributed systems and ensuring the continuity of critical businesses.

[0278] This application aims to build a Federated API Governance Architecture (FAGA) to break through the technical opposition between traditional centralized control and fragmented autonomy, and achieve "globally controllable, locally autonomous" collaborative governance of the enterprise-level API ecosystem.

[0279] (1) Solve the contradiction between scale and elastic expansion:

[0280] Decentralized traffic control: By deploying lightweight edge policy enforcers locally in the business domain, policies such as authentication and rate limiting are decentralized to the caller for execution, eliminating traffic bottlenecks at centralized gateways. See the Local Policy Enforcer section for details.

[0281] Protocol-free adaptation: Design a heterogeneous protocol conversion layer to automatically generate bidirectional conversion logic for protocols such as gRPC / RESTful / GraphQL based on LLM, eliminating the cost of multi-technology stack collaboration.

[0282] (2) Reconciling the conflict between centralized control and departmental autonomy:

[0283] Federated Policy Learning: This mechanism builds a global-local two-tier policy engine. Headquarters defines security baselines, and departments can overlay business-domain-specific rules. For example, blockchain-based evidence storage ensures auditability of policy changes, resolving a historical issue for an e-commerce company where global authentication failed due to regional policy overlays.

[0284] Dynamic compliance routing: Automatically dispatch requests to compliant infrastructure based on API metadata tags (such as data sovereignty region and privacy level).

[0285] (3) Build a sustainable API governance system:

[0286] Intelligent Technical Debt Governance: This introduces a full API lifecycle graph, automatically identifying interfaces that do not conform to the OpenAPI specification (such as missing version numbers or undefined error codes) through static code analysis, and integrating it with GitOps pipelines to enforce remediation. This shortens the technical debt discovery and remediation cycle and improves operational continuity.

[0287] Federated Metadata Catalog: uses a decentralized Schema registry to support decentralized registration and conflict detection of API definitions in multiple autonomous domains.

[0288] (4) Filling the gap between academic research and industrial practice:

[0289] Proof of cross-domain policy consistency: Applying federated learning theory to API governance policy collaboration, we propose an ε-consistency convergence algorithm. While ensuring the independence of each domain's policies, we mathematically prove the convergence of the global security baseline.

[0290] Vendor-neutral architecture design: Through the abstract cloud native control plane interface (CNCPI), it is compatible with the policy import and export of mainstream engines such as AWS API Gateway and Kong to reduce cross-cloud migration costs.

[0291] The beneficial effects of the embodiments of the present application are as follows: a distributed system based on a federated architecture consisting of a central coordination node and multiple regional autonomous nodes, wherein the central coordination node is used for global policy formulation, metadata blockchain notarization, conflict detection, and federated monitoring and self-healing to achieve global control, and regional autonomous nodes adapt to the heterogeneous environment of physical machines to perform local policy execution, heterogeneous protocol conversion, and resource autonomous regulation, thereby achieving flexible adjustment of regional policies. This solution solves the inherent contradictions between centralized control and departmental autonomy, standardization and rapid iteration, and global security and local flexibility through a federalized and intelligent governance system, providing technical support for enterprises to build a standardized, highly reliable, and easily scalable API ecosystem, assisting in digital transformation and achieving global control and local autonomy of the enterprise-level API ecosystem.

[0292] Based on the above embodiment Figure 1 A data processing system based on a federated architecture interface is disclosed. The embodiment of the present application also discloses a data processing method based on a federated architecture interface. Figure 3 As shown, the data processing method based on the federated architecture interface mainly includes the following steps:

[0293] S301: The central coordination node communicates with multiple regional autonomous nodes through a cross-layer communication protocol.

[0294] In S301 , a central coordination node communicates with multiple regional autonomous nodes by adopting a bidirectional flow control plane and a data plane encoded with HTTP / 2 with Protobuf.

[0295] Among them, the central coordination node is responsible for global policy formulation, metadata blockchain notarization (Hyperledger Fabric), federal monitoring (integrated with OpenTelemetry) and other operations.

[0296] Central coordination node:

[0297] Metadata directory: Detect naming conflicts through hierarchical namespace ( / department / service / version) + Trie tree, analyze API semantic conflicts based on the BERT model, and use blockchain to store evidence to prevent tampering;

[0298] Policy Engine: Supports one-click delivery of Rego policy templates, Delta encoding for incremental synchronization of policies, NSGA-II algorithm for adjudicating conflicts between regional and global policies, and provides versioned rollback.

[0299] Monitoring platform: Aggregate regional anonymous features to train the LSTM-Autoencoder anomaly detection model, supporting cross-domain call chain tracing.

[0300] Regional autonomous nodes adapt to Kubernetes / VM / physical machine heterogeneous environments to achieve local policy execution, heterogeneous protocol conversion, and autonomous resource regulation.

[0301] Regional autonomous nodes:

[0302] Local Policy Executor (LPE): intercepts traffic through eBPF kernel mode, supports policy chain dynamic plug-ins (WebAssembly) and local LRU cache (network disconnection autonomy ≥ 24 hours);

[0303] Dynamic Protocol Adapter (DPA): Generates 15 protocol conversion logics based on LLM (such as REST gRPC), JIT compilation optimizes conversion efficiency, and multi-target routing selects the best instance;

[0304] Regional Autonomous Controller (RAC): compiles global policies into Kubernetes / Istio rules, and the PID controller dynamically adjusts resource quotas.

[0305] S302: When the central coordination node is in communication with multiple regional autonomous nodes, global policy formulation, metadata blockchain notarization, federal monitoring and self-healing are performed through the central coordination node.

[0306] S303: When the central coordination node is in communication with multiple regional autonomous nodes, the regional autonomous nodes are used to adapt to the Kubernetes / VM / physical machine heterogeneous environment to perform local policy execution, heterogeneous protocol conversion, and resource autonomous regulation.

[0307] The process of the data processing method based on the federated architecture interface is as follows:

[0308] Metadata registration: Regions submit AES encrypted metadata, which is then stored on the blockchain and subjected to naming and semantic conflict detection, and then incrementally broadcast to update the global catalog.

[0309] Cross-domain call: LPE pre-execution of local policy → multi-destination routing instance → DPA conversion protocol → mTLS encrypted forwarding;

[0310] Policy collaboration: The center issues policies based on priority, and regions hot-load compiled rules. In the event of conflicts, NSGA-II generates compromise solutions and supports version rollback.

[0311] Monitoring and self-healing: OpenTelemetry data is collected for root cause analysis, the federated learning model warns of anomalies, and K8s Operator implements automatic API scaling and triggers cross-domain circuit breaking / degradation.

[0312] This application discloses a data processing method based on a federated architecture interface, using a "central coordination node + regional autonomous nodes" architecture. This method addresses cross-domain API management and policy coordination issues in heterogeneous infrastructure. The system includes a central coordination node deployed on the enterprise headquarters cloud platform, responsible for global policy formulation, metadata aggregation, and federated monitoring; and regional autonomous nodes deployed in branch offices' private environments, supporting heterogeneous environments such as Kubernetes, VMs, and physical machines. The control plane uses gRPC persistent connections and the data plane uses HTTP / 2 with Protobuf encoding to achieve low-latency, high-throughput communication. The central node implements global control through a metadata federation directory (including Hyperledger Fabric blockchain evidence storage and BERT semantic conflict detection), a policy federation engine (supporting one-click Rego template delivery and NSGA-II conflict resolution), and a federated monitoring platform (integrated with OpenTelemetry log collection and LSTM-Autoencoder anomaly detection). Regional autonomous nodes support efficient policy execution and heterogeneous protocol conversion through eBPF kernel-mode traffic interception, LLM-driven dynamic protocol adapters, and a policy localization compiler. The method and process include federated metadata registration (including AES encrypted transmission and Siamese network semantic verification), dynamic cross-domain call orchestration (integrating multi-objective optimized routing and JIT compilation protocol conversion), real-time policy collaboration (supporting incremental synchronization, versioned rollback, and adaptive adjustment), and federated monitoring and self-healing (using a federated learning model to achieve automatic scaling and cross-domain circuit breaking). This application significantly improves resource utilization to over 85%, reduces policy execution latency to 10ms, and achieves an SLA compliance rate of ≥99.95%, making it suitable for enterprise distributed API governance scenarios.

[0313] The beneficial effects of the embodiments of the present application are as follows: a distributed system based on a federated architecture consisting of a central coordination node and multiple regional autonomous nodes, wherein the central coordination node is used for global policy formulation, metadata blockchain notarization, conflict detection, and federated monitoring and self-healing to achieve global control, and regional autonomous nodes adapt to the heterogeneous environment of physical machines to perform local policy execution, heterogeneous protocol conversion, and resource autonomous regulation, thereby achieving flexible adjustment of regional policies. This solution solves the inherent contradictions between centralized control and departmental autonomy, standardization and rapid iteration, and global security and local flexibility through a federalized and intelligent governance system, providing technical support for enterprises to build a standardized, highly reliable, and easily scalable API ecosystem, assisting in digital transformation and achieving global control and local autonomy of the enterprise-level API ecosystem.

[0314] An embodiment of the present application further provides a storage medium, which includes stored instructions, wherein when the instructions are executed, the device where the storage medium is located is controlled to execute the above-mentioned data processing method based on the federal architecture interface.

[0315] The present application also provides an electronic device, the structure of which is shown in FIG. Figure 4 As shown, it specifically includes a memory 401 and one or more instructions 402, wherein the one or more instructions 402 are stored in the memory 401 and are configured to be executed by one or more processors 403 to execute the one or more instructions 402 to perform the above-mentioned data processing method based on the federal architecture interface.

[0316] For the sake of simplicity, the aforementioned method embodiments are described as a series of action combinations. However, those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this application.

[0317] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similarities between the various embodiments can be referred to in conjunction with each other. For device embodiments, since they are generally similar to method embodiments, their description is relatively simple, and for relevant details, reference can be made to the description of the method embodiments.

[0318] The steps in the methods of the various embodiments of the present application can be adjusted in sequence, combined, and deleted according to actual needs.

[0319] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are merely used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations.

[0320] The above description of the disclosed embodiments will enable those skilled in the art to implement or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

[0321] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A data processing system based on a federated architecture interface, characterized in that: The system includes a central coordination node and multiple regional autonomous nodes; The central coordination node is deployed on the cloud platform of the enterprise headquarters; the multiple regional autonomous nodes are deployed in the private environment of the branch offices; the central coordination node communicates with the multiple regional autonomous nodes through a cross-layer communication protocol; The central coordination node is used for global policy formulation, metadata blockchain storage, conflict detection, and federated monitoring and self-healing; For multiple regional autonomous nodes, the regional autonomous nodes are used to adapt to the heterogeneous environment of physical machines to perform local policy execution, heterogeneous protocol conversion and resource autonomous regulation.

2. The system according to claim 1, wherein: The central coordination node includes at least a blockchain evidence storage submodule, a conflict detection engine, a policy federation engine, and a federation monitoring and analysis platform; The blockchain evidence submodule is used to construct a unique hash fingerprint generated by each API registration request based on the blockchain platform, and write the unique hash fingerprint into the distributed ledger to complete the metadata blockchain evidence process; The conflict detection engine is used to automatically intercept duplicate path registrations based on the namespace tree structure, and to identify overlapping interfaces by analyzing API interface semantics to complete the conflict detection process; The policy federation engine is used to formulate global policies and perform policy changes and version rollbacks based on the incremental synchronization mechanism; The federated monitoring and analysis platform is used to collect logs of the integrated observability architecture, detect anomalies of deep learning models, and automatically perform elastic scaling to complete the federated monitoring and self-healing process.

3. The system according to claim 2, characterized in that The policy federation engine includes at least a conflict arbitrator; The conflict arbitrator is used to generate an optimal solution based on a multi-objective optimization algorithm when a conflict occurs between a regional policy and a global baseline policy; wherein the optimal solution is used to balance security and business requirements.

4. The system according to claim 2, wherein: The federated monitoring and analysis platform includes at least a cross-domain log collector and a federated learning trainer; The cross-domain log collector is used to standardize the log format of each region through the integrated observability architecture, and calculate global API health indicators in real time through the framework and distributed processing engine; The federated learning trainer is used to obtain the anonymized statistical features uploaded by each region, perform aggregate training on the global anomaly detection model based on the anonymized statistical features, and send the received model increments to the regional autonomous nodes for updating.

5. The system according to claim 1, wherein: The regional autonomous node includes at least a local policy executor, a dynamic protocol adapter and a regional autonomous controller; The local policy executor is used to perform extended Berkeley packet filter traffic interception, policy execution and policy caching to complete the local policy execution process; The dynamic protocol adapter is used to perform heterogeneous protocol conversion based on the protocol conversion matrix and dynamically select the optimal service instance through an intelligent routing strategy; The regional autonomous controller is used to compile the global policy issued by the central coordination node to complete the local policy execution process, and dynamically adjust the parameter quota of the API instance to complete the resource autonomous regulation process.

6. The system according to claim 5, characterized in that The regional autonomous controller includes at least a policy localization compiler and a resource quota manager; The policy localization compiler is used to compile the global policy issued by the central coordination node into a global policy that complies with the preset regional technology stack rules; The resource quota manager is used to dynamically adjust the CPU / memory quota of the API instance based on the PID controller to ensure that the resource utilization is greater than or equal to the preset utilization.

7. A data processing method based on a federated architecture interface, characterized in that: The system according to any one of claims 1 to 6, wherein the system comprises a central coordination node and a plurality of regional autonomous nodes, and the central coordination node is deployed on the enterprise headquarters cloud platform; The multiple regional autonomous nodes are deployed in a private environment of a branch office, and the method includes: enabling the central coordination node to communicate with the plurality of regional autonomous nodes through a cross-layer communication protocol; When the central coordination node is in communication with the multiple regional autonomous nodes, global policy formulation, metadata blockchain storage, and federated monitoring and self-healing are performed through the central coordination node; When the central coordination node is in communication with the multiple regional autonomous nodes, the multiple regional autonomous nodes adapt to the physical machine heterogeneous environment to perform local policy execution, heterogeneous protocol conversion and resource autonomous regulation.

8. The method according to claim 7, characterized in that The cross-layer communication protocol is composed of a control plane and a data plane, and enabling the central coordination node to communicate with the multiple regional autonomous nodes through the cross-layer communication protocol includes: The central coordination node communicates with the multiple regional autonomous nodes by adopting a control plane with bidirectional streaming and a data plane with HTTP / 2 with Protobuf encoding.

9. A storage medium, characterized in that: The storage medium includes stored instructions, wherein when the instructions are executed, the device where the storage medium is located is controlled to execute the data processing method based on the federated architecture interface according to any one of claims 7 to 8.

10. An electronic device, characterized in that: It includes a memory and one or more instructions, wherein the one or more instructions are stored in the memory and are configured to be executed by one or more processors to perform the data processing method based on the federated architecture interface as described in any one of claims 7 to 8.

Images