A method, gateway and system for preserving order in a federated gateway topology configuration

Abstract

The application discloses a method for maintaining order and idempotent synchronization of a federal gateway topology configuration, a gateway and a system, and belongs to the technical field of distributed system configuration management. Each participant deploys a gateway and saves a business configuration file containing a participant topology block and a local configuration in a configuration center. After synchronization triggering, an initiator gateway executes an aggregation-broadcast process: first, the initiator gateway pulls a full multi-party view from a peer and merges a non-partner topology block to form a topology union; and then, the initiator gateway broadcasts the union to each peer, and each peer merges according to the same rule. During the merging process, the topology block of the receiving party is always skipped, and the local configuration is not extracted, sent or covered, so that the topology authority of each participant is maintained, and safe, ordered and idempotent convergence of topology information in heterogeneous multi-format configuration files is realized.

Description

Technical Field

[0001] This invention belongs to the field of distributed system configuration management technology, specifically relating to a method for order-preserving idempotent synchronization of federated gateway topology configuration, the gateway, and the system. Background Technology

[0002] In a privacy-preserving computing platform, multiple distrustful parties from different organizations form a federation to jointly perform tasks such as cross-party modeling, joint queries, secure intersection, multi-party secure computation, or federated learning. Each party typically deploys its business service stack, gateway, and configuration center locally. Cross-party requests need to be addressed, forwarded, and authenticated through the gateways of each party. Therefore, each party needs to store federated topology information such as the addresses, ports, public keys, routing tables, or cross-party trust materials of other parties locally.

[0003] In actual systems, the aforementioned topology information is typically not stored in a single standardized file, but rather dispersed across multiple business configuration files, with different business components employing different file formats and organizational structures. For example, some configuration files are JSON array structures, some are JSON object structures, and others are YAML structures. A single business configuration file may also contain both topology configuration and local configuration. Local configuration includes database connection information, cache configuration, message queue account passwords, local permission switches, and other runtime parameters used only by that party. This type of local configuration is sensitive and environment-dependent; it should not be transmitted between participating parties, nor should it be overwritten by configuration content provided by other participating parties.

[0004] In existing technologies, federated topology configuration typically relies on manual maintenance on a per-party basis, centralized configuration distribution, template rendering, full file synchronization, or a general distributed merging mechanism. Manual maintenance experiences a rapid increase in configuration modifications as the number of participants increases, easily leading to omissions, errors, and inconsistencies across nodes. Centralized configuration distribution or template rendering requires the central node to rewrite the configuration files of each participant, posing risks of single-point dependencies and unauthorized rewriting, and potentially disrupting comments, key order, and local configurations in the original files. Full file synchronization or overall serialization write-back methods are prone to leaking or accidentally overwriting sensitive local configurations, and it is particularly difficult to guarantee the stability of comments, indentation, and manual auditing formats in YAML and other files.

[0005] Furthermore, in multi-party federations, each participant typically only has authority over its own corresponding topology information. For example, a participant's gateway address, public key, routing entry, or access materials should be declared and updated by that participant itself, while other participants only hold copies of this information. If a generic gossip, CRDT, or other merging mechanism that does not distinguish between owner authority is used, it is possible that outdated copies held by other participants could overwrite the owner participant's latest topology information, leading to topology information rollback, contamination, or inconsistency.

[0006] Therefore, existing technologies struggle to simultaneously meet the following requirements in multi-party federated computing scenarios for privacy-preserving computation: synchronizing cross-party topology information across heterogeneous business configuration files such as JSON and YAML; synchronizing only topology configuration fragments indexed by participant identifiers, without extracting, transmitting, or overwriting sensitive local configurations; preserving comments, key order, and local structure of the original configuration file during the write process; ensuring each participant maintains authority over its own topology block, preventing stale copies from overwriting the owner's latest value; and making the synchronization process repeatable and idempotent. Therefore, it is necessary to propose a pre-ordered and idempotent synchronization method, gateway, and system for federated gateway topology configuration to achieve secure, pre-ordered, and idempotent synchronization of topology blocks in heterogeneous configuration files. Summary of the Invention

[0007] The purpose of this invention is to provide a method, gateway, and system for order-preserving and idempotent synchronization of topology configuration in a federated gateway, in order to solve the problem of secure, order-preserving, and idempotent synchronization of topology information in heterogeneous configuration files in multi-participant federated scenarios.

[0008] To achieve the above objectives, this invention provides a method for order-preserving idempotent synchronization of federated gateway topology configuration, applicable to a federated system with multiple participants. Each participant has a participant identifier and deploys a gateway and a configuration center. The configuration center stores business configuration files in at least two formats, including JSON arrays, JSON objects, or YAML files. The business configuration files contain participant topology blocks indexed by participant identifiers and local configurations. The initiating gateway executes the following steps:

[0009] Read the member file to determine the peer gateway;

[0010] Request a full multi-party view organized by configuration identifier and participant identifier from each peer gateway;

[0011] The configuration processing module with topology path description information is invoked according to the configuration identifier, and the topology blocks in which the participant identifier is not equal to the local identifier are merged into the local configuration center;

[0012] Export the merged full multi-party view from the local configuration center, which contains the topology block union of reachable participants in this round, and broadcast it to each peer gateway so that each peer gateway merges according to the same rules, so that the reachable participants in this round form the same topology union view;

[0013] The topology path description information includes the topology parent path, the participant primary key field, and the prohibited local configuration path. The configuration processing module only extracts, inserts, or replaces topology blocks within the topology parent path. When writing, the participant primary key field is filled back with the identifier of the participant to be written, and the content corresponding to the prohibited local configuration path is not extracted, sent, or overwritten.

[0014] Furthermore, when reading the member file, the initiating gateway reads the participant identifier, gateway access endpoint, and identity verification materials, and generates a peer gateway list after removing its own participant identifier; the member file is only used to discover peer gateways and the source of verification requests, and is not used to save or write back the participant topology block.

[0015] Furthermore, the topology path description information includes configuration identifier, file content type, topology parent path, participant primary key field, set of allowed write fields, set of prohibited local configuration paths, insertion order strategy, and rendering strategy; the configuration processing module only identifies topology blocks indexed by the participant primary key field within the topology parent path.

[0016] Furthermore, when generating a full multi-party view, the peer gateway reads the registered service configuration file and searches for the configuration processing module according to the configuration identifier. If the search is successful, the configuration processing module extracts the participant topology block. If the search fails, the corresponding configuration identifier is skipped, and the extraction result is assembled into a mapping of configuration identifier, participant identifier, and topology block.

[0017] Furthermore, when merging all multi-party views, the topology blocks to be written are grouped according to the configuration identifier; the current content of the same business configuration file is read only once, and multiple participating party topology blocks are written continuously; after writing, the content summary of the business configuration file is calculated and compared with the content summary of the business configuration file before writing. If the summaries are consistent, it is not published. When the configuration center supports version numbers, it carries the read version for conditional publishing.

[0018] Furthermore, for JSON array-type files, the configuration processing module searches for elements in the array whose participant primary key field is equal to the participant identifier to be written. If the element exists, it is replaced in its original position; otherwise, it is inserted according to the insertion order strategy. For JSON object-type files, only the child objects corresponding to the participant identifier to be written are added or replaced under the parent path of the topology.

[0019] Furthermore, for YAML files, the configuration processing module reads the file content line by line, locates the topology parent path and the sub-block line interval corresponding to the participant identifier to be written according to the indentation level; if the sub-block line interval exists, it is replaced; if it does not exist, it is inserted in the topology parent block. The line sequence outside the topology parent path remains unchanged line by line, and the relative order of non-target participant topology blocks in the topology parent block remains unchanged.

[0020] Furthermore, when topology blocks with the same configuration identifier and participant identifier come from multiple sources, the topology block whose source identifier is equal to the participant identifier is preferentially used as the owner's directly derived block; if no owner's directly derived block is obtained, the third-party copy is used for missing padding only if the owner participant identifier of the third-party copy is consistent with the participant identifier, the owner version number is higher than the local record, the digest calculated based on the third-party copy is consistent with the digest it carries, and the signature verification is successful; the local record includes the highest received owner version number and the corresponding digest, and copies with the same version but different digests are rejected from being overwritten.

[0021] The present invention also provides a pre-order idempotent synchronization gateway for federated gateway topology configuration, comprising a processor, a memory, a network communication unit, and a configuration center access unit. The memory stores computer program instructions, and when the processor executes the computer program instructions, it causes the federated gateway to perform a pre-order idempotent synchronization method for federated gateway topology configuration.

[0022] This invention also provides an order-preserving idempotent synchronization system for federated gateway topology configuration. Each federated gateway is bound to a participant identifier and communicates with other federated gateways through the gateway access endpoint recorded in the member file. Any federated gateway can trigger synchronization as the initiating gateway, so that the topology blocks of the initiating gateway and the peer participants who successfully returned the full multi-party view and successfully received the broadcast in this round converge to the same topology union, and the local configuration in each configuration center is not overwritten by other federated gateways.

[0023] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0024] 1. This invention achieves isolated synchronization between topology configuration and local configuration. During the synchronization process, only topology blocks indexed by participant identifiers are extracted, transmitted, and written. Local configurations such as database passwords, cache configurations, message queue credentials, and local permissions are retained in place, without being transmitted or overwritten, thereby reducing the risk of sensitive configuration leakage and accidental modification.

[0025] 2. This invention achieves owner authority and idempotent convergence. During merging, the receiver's own topology block is always skipped, ensuring that the topology information of each participant is declared solely by its own authority, preventing outdated copies from overwriting the owner's latest value; repeating the synchronization operation when the input remains unchanged will not alter the existing result, facilitating maintenance retry and fault recovery.

[0026] 3. This invention achieves topology convergence within the range of connectable participants in the current round. Through a two-stage aggregation-broadcast process, the initiator first aggregates the topology union of connectable participants, and then broadcasts the topology union to reachable peers, enabling the connectable participants in the current round to converge to a consistent topology view within a single synchronization operation; for participants that are temporarily unreachable, failure information is recorded and convergence continues in subsequent synchronization rounds;

[0027] 4. This invention preserves comments in comment-supported formats and maintains the order of non-target content. For different configuration file formats such as JSON and YAML, a separate configuration processing module performs local extraction and writing, avoiding the loss of comments, changes in key order, or damage to the file structure caused by overall deserialization and full file overwriting; when adding a new configuration format, only the corresponding processing module needs to be added and registered, without affecting the existing synchronous orchestration logic;

[0028] 5. This invention reduces invalid deployments in the configuration center and redundant hot reloading of business components. For the same business configuration file, the gateway reads the current content only once and writes it continuously to multiple participating party topology blocks; if the content digests before and after writing are consistent, the configuration is not published, thereby avoiding repeated synchronization triggering of unchanged configuration deployments. Attached Figure Description

[0029] Figure 1 A schematic diagram of the overall process of the order-preserving idempotent synchronization method for the federal gateway topology configuration of the present invention;

[0030] Figure 2 A schematic diagram of the order-preserving idempotent synchronization system configured for the federal gateway topology of this invention;

[0031] Figure 3 This is a flowchart illustrating the two-stage synchronization process of aggregation and broadcasting in this invention;

[0032] Figure 4 This is a schematic diagram of the isolation structure between the topology block and the local configuration of the business configuration file in this invention;

[0033] Figure 5 This is a schematic diagram illustrating the process of the configuration processing module extracting and writing business configuration files of different formats in this invention.

[0034] Figure 6 This is a schematic diagram of the functional module structure of the federated gateway in this invention. Detailed Implementation

[0035] 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.

[0036] The federation described in this invention refers to a privacy computing network composed of two or more participants. Each participant has a globally unique participant identifier (party_id) and deploys at least one gateway and one configuration center locally. The gateway is used for control plane communication and topology configuration synchronization with other participant gateways, and the configuration center is used to store multiple service configuration files required for the operation of its own service components. Each service configuration file has a unique configuration identifier (data_id). The topology configuration fragment in the service configuration file that is indexed by the participant identifier and can be independently extracted and written back is called a participant topology block. The content in the service configuration file other than the participant topology block is called local configuration. Local configuration includes, but is not limited to, database connection information, cache configuration, message queue account password, local permission switches, and operating parameters that are only used by the participant's own service components.

[0037] Example 1:

[0038] like Figure 1 As shown, this embodiment provides a method for order-preserving idempotent synchronization of federated gateway topology configuration. This method is triggered by a synchronization response from any participating gateway. Taking gateway G1000 of participant 1000 as the initiator as an example, the method includes the following steps:

[0039] In step S101, the initiating gateway receives a synchronization trigger request. The synchronization trigger request can be generated by the operation and maintenance personnel calling the POST / federation / sync interface, or it can be triggered by a new participant joining the federation, a change in the participant topology, a scheduled task, or a configuration center listening event. The initiating gateway reads its own member file to obtain the identifiers of the peer participants in the current federation other than itself and their gateway access endpoints.

[0040] In step S102, the initiating gateway enters the aggregation phase. The initiating gateway sequentially sends a full multi-party view export request to each peer gateway, for example, by calling the peer gateway's GET / federation / setup / export interface. After receiving the request, the peer gateway reads multiple registered business configuration files from its local configuration center, and calls the configuration processing module corresponding to each business configuration file to extract all identifiable participant topology blocks from the file content, assembles them into a full multi-party view, and returns it to the initiating gateway.

[0041] In step S103, the initiating gateway merges the full multi-party view obtained from the peer gateway into its own configuration center. During the merging process, the initiating gateway searches for the corresponding configuration processing module for each data_id in the full multi-party view; if no corresponding configuration processing module exists, an alarm is recorded and the data_id is skipped; for business configuration files with corresponding configuration processing modules, the initiating gateway reads the current content of the file from its own configuration center; if the configuration center returns that the file is not found, the file content is treated as empty, and the configuration processing module is allowed to generate the initial file content based on the topology block to be written.

[0042] For each participant topology block under the same business configuration file, the initiating gateway determines whether the participant identifier corresponding to the topology block is equal to the initiator's own identifier. If they are equal, the topology block is skipped, and no write operation is performed. If they are not equal, the write interface of the corresponding configuration processing module is called to insert or replace the participant topology block in the file content. For the same business configuration file, the initiating gateway preferably adopts a read-once, modify-multiple-blocks, and publish-once approach: that is, the file content is read once, multiple topology blocks to be synchronized in the file are continuously written, and finally, when the file content changes, it is published back to the configuration center all at once. This reduces the number of read and write operations in the configuration center and avoids repeatedly triggering hot reloading of downstream business components in the same round of synchronization.

[0043] In step S104, after the initiating gateway completes the aggregation of all reachable peers, it re-exports the full multi-party view from its local configuration center. At this time, the initiating gateway's local configuration center already holds the union of the topology blocks of each participant in its set of connectable participants. If a peer is unreachable, the initiating gateway records the aggregation failure information but does not block the aggregation processing of other peers. The unreachable peer can re-participate in convergence in the next round of synchronization.

[0044] Step S105: The initiating gateway enters the broadcast phase. For example... Figure 3 As shown, the initiating gateway encapsulates the aggregated full multi-party view into a broadcast payload and sends the broadcast payload to each peer gateway, for example, by calling the peer gateway's POST / federation / sync / receive interface; the broadcast payload may include the initiator identifier source, the latest member metadata party_info of this party, and the aggregated full topology bundle topo; the purpose of carrying party_info is to enable the peer to refresh the initiator's member metadata while receiving topology synchronization, reducing additional member information queries.

[0045] In step S106, after receiving the broadcast payload, the peer gateway first confirms the request source based on the shared token, member file, or other authentication methods, and then writes or updates the member metadata in the broadcast payload to its own member file. Subsequently, the peer gateway performs a merging process on the topology. The merging rules are the same as those in the initiator's aggregation phase, that is, for each business configuration file, the current content is read, and for each participating topology block, it is determined whether its participating identifier is equal to the receiver's own identifier. If they are equal, it is skipped; if they are not equal, the write interface is called to perform insertion or in-situ replacement. After the merging is completed, it is only published back to its own configuration center when the file content changes.

[0046] When topology blocks with the same data_id and the same participant identifier pid come from multiple sources, the initiator or receiver processes them according to the owner priority rule: if the topology block directly exported by the gateway corresponding to the pid has been obtained, then third-party copies from other participants must not overwrite the topology block; if the topology block directly exported by the gateway corresponding to the pid has not yet been obtained, then third-party copies with verified signatures and version numbers higher than the local record are allowed to be used as fillers for missing data. Thus, topology integrity can still be improved when some nodes are temporarily unreachable, while avoiding outdated copies from overwriting the latest owner declaration.

[0047] In step S107, after the aggregation and broadcast phases described above, all connectable participants in the federation hold the same full topology union. Since each receiver skips the topology block corresponding to its own participant identifier during merging, each participant maintains authority over its own topology block and will not be overwritten by copies held by other participants. Furthermore, if the input topology block remains unchanged, repeatedly executing the above synchronization method will not alter the already converged topology results in each configuration center; therefore, this synchronization method is idempotent.

[0048] Within the same synchronization round, the initiating gateway first aggregates the topology blocks returned by reachable peers in this round and forms a topology block union with the topology blocks in its own configuration center. This topology block union is then broadcast to all reachable peer gateways. During merging, each receiving gateway skips topology blocks with the same participant identifier as itself and only writes topology blocks from other participants. Therefore, each reachable participant ultimately holds the same cross-party topology union, while its own topology block remains locally authoritative. For topology blocks whose version number and digest remain unchanged, repeated synchronization does not trigger writes or publications, thus achieving idempotent convergence.

[0049] In this embodiment, the initiator does not generate the entire configuration file as a centralized template rendering node, but only performs aggregation and broadcasting at the topology block granularity; the receiver does not accept the entire file overwrite indiscriminately, but skips its own topology block and only writes the topology blocks of other participants locally during merging; thus, topology convergence within one operation is achieved in an environment where multiple participants do not trust each other, configuration files are heterogeneous and contain local sensitive configurations.

[0050] Example 2:

[0051] like Figure 2 As shown, this embodiment provides an order-preserving idempotent synchronization system for federated gateway topology configuration. The system includes multiple participants, each deploying a gateway, a configuration center, and several service components. Taking three participants as an example, their participant identifiers are 1000, 2000, and 3000, respectively. Participant 1000 deploys gateway G1000 and configuration center C1000, participant 2000 deploys gateway G2000 and configuration center C2000, and participant 3000 deploys gateway G3000 and configuration center C3000.

[0052] In one specific implementation, the gateway is implemented using OpenResty / Lua and provides a federated control plane interface on the management port; the configuration center is implemented using Nacos and isolates configurations in different federations or different environments through namespaces and groups; the above implementation is only an example, and the gateway can also be implemented using Java, Go, Rust or other languages, and the configuration center can also be other configuration management systems with read, publish and version management capabilities.

[0053] Each participating party stores multiple business configuration files in its local configuration center. These business configuration files include party-info.json, route-table.json, service-conf.yaml, mq-route.json, and auth-config.json. party-info.json can be a JSON array, where each element corresponds to a participating party entry, which serves as the topology block for that participating party. route-table.json can be a JSON object, containing the route topology block corresponding to the participating party's PID under the cross-participating party routing topology configuration table route_table, while fields such as permission are local configurations. service-conf.yaml can be a YAML file, containing the proxy address topology block corresponding to the participating party's PID under the proxy address configuration item proxy_addr, while fields such as database, cache, and message queue are local configurations. mq-route.json and auth-config.json respectively store message routing blocks indexed by participating party and authentication configuration blocks.

[0054] like Figure 4As shown, the participant topology block is the smallest data unit synchronized in this invention. This topology block uses the participant identifier `party_id`, participant code `party_code`, or other fields that uniquely identify the participant as the primary key. Internal fields are determined by the business configuration file to which it belongs, and may include address, port, public key, routing table, access key identifier, trust materials required for cross-party calls, etc. Database passwords, cache accounts, message queue account passwords, and other content only related to the current operating environment, even if they are located in the same business configuration file, are not extracted, transmitted, or written as part of the participant topology block.

[0055] The system also includes member files; member files are used to store member metadata such as participant identifiers, gateway access endpoints (gateway_endpoint), host addresses, and internal access addresses. Member files are only used to determine the access location of peer gateways and do not carry business topology blocks; thus, the member plane and the topology plane are decoupled: member files are used to discover participants and access gateways, while business configuration files are used to carry the actual cross-party topology, and the two will not interfere with each other.

[0056] During synchronization, the gateway temporarily assembles a full multi-party view; this full multi-party view is a bundled structure organized according to the configuration identifier data_id, the participant identifier party_id, and the topology block, and is only used as transient data for network transmission and merging processing, and is not written to the member file.

[0057] Example 3:

[0058] like Figure 5 As shown in the figure, this embodiment further illustrates the extraction and writing methods of business configuration files; each business configuration file corresponds to an independent configuration processing module; the configuration processing module declares the configuration identifier data_id and file content type content_type it processes, and implements the extraction interface extract_all(content) and the writing interface write_peer(content,pid,block).

[0059] The extraction interface is used to identify all participant topology blocks from the business configuration file content and return the participant identifier and the mapping of topology blocks; the writing interface is used to insert or replace the topology block corresponding to the participant pid into the file content while keeping the rest of the file content unchanged; different configuration processing modules do not call each other or share file structure assumptions, and the orchestration module only dispatches the file content to the corresponding configuration processing module for processing based on the data_id.

[0060] For JSON array-type files, such as party-info.json, the configuration processing module reads the participants array, identifies primary key fields such as party_code or party_id, and extracts each array element as a topology block for the corresponding participant. During writing, the configuration processing module searches for an element in the array whose primary key field is equal to the target pid. If it exists, the element is replaced in its original position in the array. If it does not exist, the new element is appended to the array or inserted into the corresponding position according to the participant order in the member file. During writing, the configuration processing module forces the party_code or party_id in the element to be set to the target pid to prevent inbound payloads from polluting the topology of other participants by forging primary key fields.

[0061] For JSON object files, such as route-table.json, the configuration processing module only processes the sub-objects corresponding to route_table. When writing, if a sub-object corresponding to the target pid already exists under route_table, it is replaced; otherwise, it is added. For fields such as permission, local, database, and mq that are not declared as topology paths, the configuration processing module does not extract or write them, and these fields in the file remain unchanged. For configuration files indexed by participants, such as mq-route.json and auth-config.json, the same principle applies: only the topology sub-blocks corresponding to the target pid are located and updated.

[0062] For YAML-type mixed files, such as service-conf.yaml, the configuration processing module uses line-level positioning and editing. Taking proxy_addr as the parent key of the topology block carrying the proxy address of the participant as an example, the write interface scans the file content line by line, determines the line containing proxy_addr and its parent indentation based on the indentation. Then, it searches for the starting line of the sub-block under the proxy_addr parent key, where the indentation level corresponds to the participant sub-block and the key name is equal to the target pid, and determines the ending position of the sub-block based on the indentation of subsequent lines. If an existing sub-block of the target pid is found, the atomic block line interval is replaced with a new sub-block line generated based on the block. If no sub-block of the target pid is found, a new sub-block is inserted before the ending position of the proxy_addr parent block. Except for the line interval containing the target pid sub-block, all other line sequences are retained line by line, including comments, blank lines, key order, local database configuration, local cache configuration, and message queue configuration.

[0063] During YAML line-level positioning, the configuration processing module first reads the file content line by line, recording the indentation level, key name, and whether each line is empty or a comment line. When a line's key name corresponds to the topology parent path and the indentation level satisfies the parent-child relationship, that line is determined as the starting line of the topology parent block. The module then scans forward until it reaches a line with an indentation level less than or equal to that of the topology parent block that is neither empty nor a comment, thus determining the end position of the topology parent block. Within this topology parent block, the configuration processing module searches for a child block whose key name equals the identifier of the participant to be written. If found, the module determines the line range of that child block based on the indentation of subsequent lines and replaces it. If not found, a child block line generated by the topology block is inserted before the end position of the topology parent block. Except for the replaced or inserted target participant child block, the remaining lines are not reserialized or rearranged.

[0064] For example, in service-conf.yaml, the configuration processing module only replaces or inserts the proxy address sub-block corresponding to the target party_id, while the database configuration, cache configuration, message queue configuration, comment lines and blank lines in the file remain unchanged.

[0065] In a preferred embodiment, each configuration processing module also corresponds to a topology path description information, which includes at least data_id, content_type, topology_parent_path, participant primary key field owner_key, set of fields allowed to be written, set of local configuration paths that are prohibited from extraction and writing, insertion order strategy, and rendering strategy. The extraction interface only identifies participant topology blocks with owner_key as the primary key within the structure pointed to by topology_parent_path. The writing interface only performs insertion or replacement on the topology block corresponding to the target pid within the same structure. For fields not declared as topology paths in the topology path description information, even if they are located in the same business configuration file as the topology block, they are not extracted, transmitted, or written.

[0066] By using the above-described line-level positioning and editing method, this embodiment avoids performing overall deserialization and reserialization on the YAML file, thus preventing the loss of comments, changes in key order, or accidental modification of local configuration blocks due to differences in parser output; for configuration files that require manual auditing, the original file layout can also remain stable.

[0067] In a preferred embodiment, the configuration processing module compares the file content before and after the write operation. The orchestration module only publishes the new content back to the configuration center if the content has actually changed. If the write interface of a certain business configuration file fails, the orchestration module records the error information of that file and continues to process other business configuration files. If the write of a participant's topology block fails, the orchestration module records the data_id and pid corresponding to that topology block and continues to process other topology blocks in the same business configuration file. Therefore, an anomaly in a single file or a single topology block will not cause the entire synchronization round to fail.

[0068] Example 4:

[0069] This embodiment further illustrates the methods for maintaining owner authority and ensuring security during the synchronization process.

[0070] Each gateway is bound to its party_id identifier; when processing a request from a peer gateway, the receiving gateway can verify the legitimacy of the request through a shared token X-Federation-Token; in deployments with higher security requirements, the source of the request can also be confirmed through a two-way TLS certificate, the gateway_endpoint mapping relationship in the member file, or the payload signature; after the source of the request is confirmed, the receiving party binds the source identifier as source_pid with the inbound topology of this round.

[0071] During the aggregation phase, for a full multi-party view obtained from a peer's `source_pid`, if the participant identifier `pid` of a certain topology block is equal to `source_pid`, then that topology block is considered a topology block directly exported by its owner; if `pid` is not equal to `source_pid`, then that topology block is considered a third-party copy held by the peer. The initiator preferably assigns a higher merging priority to topology blocks directly exported by the owner; specifically, for the same `data_id` and the same `pid`, if the initiator has already obtained a topology block directly exported from the gateway corresponding to `pid`, then subsequent third-party copies from other participants must not overwrite that topology block; if the initiator has not yet obtained a directly exported topology block from the gateway corresponding to `pid`, then a third-party copy can be temporarily used as filler to ensure that existing topology information can still be synchronized when some nodes are unreachable.

[0072] In a preferred embodiment, the participating topology block carries ownership metadata; this ownership metadata includes one or more of owner_pid, owner_revision, and block_hash, and may further include owner_signature; owner_pid represents the authoritative claimant of the topology block; owner_revision represents the updated version of the topology block by the authoritative claimant; block_hash represents the digest of the normalized representation of the topology block; owner_signature represents the signature of owner_pid on owner_pid, data_id, owner_revision, and block_hash; wherein, block_hash is calculated from the normalized representation of the participating topology block; for JSON topology blocks, the normalized representation can use uniform character encoding, fixed key order, and content after removing meaningless whitespace; for YAML topology blocks, it can be first converted into a key-value structure containing only the set of fields allowed to be written before calculating the digest; owner_signature The signature object of `re` includes at least `data_id`, `owner_pid`, `owner_revision`, and `block_hash`. The public key used for verification is obtained from the member file, member certificate, or pre-set trusted public key table. The receiver stores the highest received `owner_revision` and corresponding `block_hash` for each `data_id` and `party_id`. If the version of the inbound copy is lower than the local record, it is rejected. If the versions are the same and the digests are the same, it is considered a duplicate synchronization. If the versions are the same but the digests are different, a conflict is recorded and overwriting is rejected. When merging topology blocks, the receiver verifies whether `owner_pid` is consistent with the topology block's primary key `pid`. If they are inconsistent, the topology block is rejected or the owner's primary key is forcibly filled back to `pid` before writing. If the inbound topology block comes from a third-party copy, it is only allowed to overwrite an old topology block with the same local `pid` if the signature verification is successful and the version is higher than the locally recorded version. If the versions are the same and the digests are the same, it is considered a duplicate synchronization, and no write is performed. If the versions are the same but the digests are different, a conflict is recorded and overwriting is rejected to avoid mutual contamination between copies from different sources.

[0073] For configuration centers that support configuration version numbers or revision numbers, the gateway records the configuration version number when reading the business configuration file and includes this version number in the conditional release when publishing the updated business configuration file. If the configuration version number has changed during release, the gateway rereads the current file content, rewrites the topology blocks that have not yet taken effect, and republishes. For configuration centers that do not support conditional release, the gateway at least uses the content digest to determine whether an actual change has occurred and avoids publishing without changes. This process reduces the risk of lost updates when multiple gateways initiate synchronization simultaneously.

[0074] The security and conflict handling in this embodiment do not change the basic process of aggregation-broadcasting and skipping self-blocks described in Embodiment 2. Its function is to ensure that the rule that each party maintains authority only over its own topology block can be stably implemented in the presence of old copies, third-party copies, and concurrent synchronization. Thus, this invention can not only achieve topology union convergence, but also prevent the peer from using old copies to overwrite the owner's latest topology. Even if the ownership signature verification of the third-party copy passes, the receiving gateway still skips the topology block with the same identifier as the receiving party's own participant during merging, and does not allow the third-party copy to overwrite the receiving party's own topology block.

[0075] Example 5:

[0076] like Figure 6 As shown, this embodiment provides a federated gateway for executing the above-described synchronization method. The federated gateway includes a processor, a memory, a network communication unit, and a configuration center access unit. The memory stores computer program instructions, and when the processor executes these instructions, the federated gateway at least forms a member management module, a configuration center adaptation module, a configuration processing module registry, a full view export module, a topology merging module, a synchronization orchestration module, and a security verification module.

[0077] The member management module is used to maintain the member files of the party, save the participant identifier, participant metadata and gateway access endpoint, and provide the peer participant list to the synchronization orchestration module; the configuration center adaptation module is used to read and publish business configuration files, and read and carry the configuration version number when the configuration center supports version control; the configuration processing module registry is used to manage multiple configuration processing modules according to data_id, and provide the corresponding file extraction interface and writing interface to the full view export module and the topology merging module.

[0078] The full view export module responds to GET / federation / setup / export requests, reads configuration files from the configuration center, calls the extract_all interface of the corresponding configuration processing module, and assembles the full multi-party view. The topology merging module receives the full multi-party view, finds the configuration processing module by data_id, and calls the write_peer interface to perform partial writing after skipping the receiver's own topology block. The synchronization orchestration module responds to POST / federation / sync requests, executes the aggregation phase and broadcast phase in sequence, and also responds to POST / federation / sync / receive requests, receives inbound topology bundles, and calls the topology merging module to complete the merging. The security verification module verifies the shared token, gateway identity, payload signature, or other authentication information, and provides the verification results to the topology merging module.

[0079] The same federated gateway can play different roles in different synchronization scenarios. When it receives a synchronization request triggered by its own operations and maintenance, the gateway acts as the initiator, performing aggregation and broadcasting; when it receives an export request from another gateway, the gateway acts as the exporter, returning its own full multi-party view; when it receives a synchronization receive request from another gateway, the gateway acts as the receiver, performing member metadata updates and topology merging. These three roles can be implemented using the same program, without requiring the deployment of additional centralized rendering nodes.

[0080] This embodiment also provides a federated configuration synchronization system. The system includes N federated gateways and N configuration centers corresponding to each federated gateway, where N is greater than or equal to 2. Each federated gateway establishes control plane communication through the gateway_endpoint in its member file, and each configuration center stores the service configuration files of its respective participant. Any federated gateway can initiate a synchronization operation. After synchronization, provided that the participant identifier is globally unique, the member endpoints are resolvable, and the network between gateways is connected, the participant topology blocks in each participant's configuration center converge to the same topology union. Simultaneously, each participant's own topology block retains authority through its local configuration center, and its local configuration is not overwritten by the peer.

[0081] In a running example, after receiving the synchronization trigger, the gateway G1000 of participant 1000 first pulls the full multi-party views from G2000 and G3000, and merges the topology blocks except for the one with party_id 1000 into C1000. Then, G1000 exports the aggregated full multi-party views from C1000 and pushes them to G2000 and G3000 respectively. During the merging process, G2000 skips the topology block with party_id 2000, and G3000 skips the one with party_id 3000. After synchronization, C1000, C2000, and C3000 all store the same union of the three topology blocks, but their local configurations and their own topology blocks are not overwritten by other participants.

[0082] In the above embodiments, the number, name, and internal fields of the business configuration files are merely examples for illustrative purposes. The essence of this invention lies in: separating the participating party topology blocks that can be synchronized across heterogeneous business configuration files from their local configurations, aggregating and broadcasting them between federated gateways using a transient bundling structure, and consistently skipping the receiving party's own topology blocks during merging; simultaneously, through the local write capability of the configuration processing module, ensuring that comments, key order, and locally sensitive configurations in different format configuration files are not corrupted; this combination enables federated topology synchronization to simultaneously possess owner authority, idempotent convergence, order-preserving write, and format expansion capabilities.

[0083] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for order-preserving idempotent synchronization of federated gateway topology configuration, applied to a federated system with multiple participants, each participant having a participant identifier and deploying a gateway and a configuration center, the configuration center storing business configuration files in at least two formats, the formats including JSON arrays, JSON objects, or YAML files, the business configuration files containing participant topology blocks indexed by participant identifiers and local configurations, characterized in that, The initiating gateway shall perform the following steps: Read the member file to determine the peer gateway; Request a full multi-party view organized by configuration identifier and participant identifier from each peer gateway; The configuration processing module with topology path description information is invoked according to the configuration identifier, and the topology blocks in which the participant identifier is not equal to the local identifier are merged into the local configuration center; Export the merged full multi-party view from the local configuration center, which contains the topology block union of reachable participants in this round, and broadcast it to each peer gateway so that each peer gateway merges according to the same rules, so that the reachable participants in this round form the same topology union view; The topology path description information includes the topology parent path, the participant primary key field, and the prohibited local configuration path. The configuration processing module only extracts, inserts, or replaces topology blocks within the topology parent path. When writing, the participant primary key field is filled back with the identifier of the participant to be written, and the content corresponding to the prohibited local configuration path is not extracted, sent, or overwritten.

2. The order-preserving idempotent synchronization method for federated gateway topology configuration according to claim 1, characterized in that, When reading the member file, the initiating gateway reads the participant identifier, gateway access endpoint, and identity verification materials, and generates a peer gateway list after removing its own participant identifier; the member file is only used to discover peer gateways and the source of verification requests, and is not used to save or write back the participant topology block.

3. The order-preserving idempotent synchronization method for federated gateway topology configuration according to claim 1, characterized in that, The topology path description information includes configuration identifier, file content type, topology parent path, participant primary key field, set of allowed write fields, set of prohibited local configuration paths, insertion order strategy, and rendering strategy; The configuration processing module only recognizes topology blocks indexed by the primary key field of the participating party within the parent path of the topology.

4. The order-preserving idempotent synchronization method for federated gateway topology configuration according to claim 1, characterized in that, When generating a full multi-party view, the peer gateway reads the registered service configuration file and searches for the configuration processing module according to the configuration identifier. If the search is successful, the configuration processing module extracts the participant topology block. If the search fails, the corresponding configuration identifier is skipped, and the extraction result is assembled into a mapping of configuration identifier, participant identifier, and topology block.

5. The order-preserving idempotent synchronization method for federated gateway topology configuration according to claim 1, characterized in that, When merging all multi-party views, the topology blocks to be written are grouped according to the configuration identifier; the current content of the same business configuration file is read only once, and multiple participating party topology blocks are written continuously; after writing, the content summary of the business configuration file is calculated and compared with the content summary of the business configuration file before writing. If the summaries are consistent, it is not published. When the configuration center supports version numbers, it carries the read version for conditional publishing.

6. The order-preserving idempotent synchronization method for federated gateway topology configuration according to claim 1, characterized in that, For JSON array-type files, the configuration processing module searches for elements in the array whose primary key field is equal to the participant identifier to be written. If the element exists, it is replaced in its original position; otherwise, it is inserted according to the insertion order strategy. For JSON object-type files, the module only adds or replaces the child object corresponding to the participant identifier to be written under the parent path of the topology.

7. The order-preserving idempotent synchronization method for federated gateway topology configuration according to claim 1, characterized in that, For YAML files, the configuration processing module reads the file content line by line, locates the topology parent path and the sub-block line interval corresponding to the participant identifier to be written according to the indentation level; if the sub-block line interval exists, it is replaced; if it does not exist, it is inserted in the topology parent block. The line sequence outside the topology parent path remains unchanged line by line, and the relative order of non-target participant topology blocks in the topology parent block remains unchanged.

8. The order-preserving idempotent synchronization method for federated gateway topology configuration according to claim 1, characterized in that, When topology blocks with the same configuration identifier and participant identifier come from multiple sources, the topology block whose source identifier is equal to the participant identifier is preferred as the owner's directly exported block. If no owner's directly exported block is obtained, the third-party copy is used for missing data filling only if the participant identifier of the third-party copy is consistent with the participant identifier, the attribution version number is higher than the local record, the digest calculated based on the third-party copy is consistent with the digest it carries, and the signature verification is successful. The local record includes the highest received attribution version number and the corresponding digest. Replicas with the same version but different digests are rejected from being overwritten.

9. A federated gateway topology configuration for order-preserving idempotent synchronization, characterized in that, It includes a processor, a memory, a network communication unit, and a configuration center access unit. The memory stores computer program instructions. When the processor executes the computer program instructions, it causes the federal gateway to perform the order-preserving idempotent synchronization method for federal gateway topology configuration as described in any one of claims 1 to 8.

10. A sequentially idempotent synchronization system for a federated gateway topology configuration, characterized in that, It includes multiple federated gateways as described in claim 9 and a configuration center corresponding to each federated gateway; each federated gateway is bound to a participant identifier and communicates with other federated gateways through the gateway access endpoint recorded in the member file; Any federated gateway can trigger synchronization as the initiating gateway, so that the topology blocks of the initiating party and the peer participants who successfully returned the full multi-party view and successfully received the broadcast in this round converge into the same topology union, and the local configuration in each configuration center is not overwritten by other federated gateways.

Images