Gateway API version distributed management method and device

Abstract

The invention relates to a gateway API version distributed management method and device, and belongs to the technical field of version management, and the method comprises the following steps: a management client submits a vector clock of a new API version and a vector clock of an old API version to a first gateway node; the first gateway node judges whether the version is the latest consensus version of the current new API version, and performs causal updating or concurrent updating according to the judgment result; the first gateway node persists the updated API version and the vector clock to the local; aPI version historical information synchronously stored among the plurality of peer-to-peer gateway nodes enables the plurality of peer-to-peer gateway nodes to have a consistent API version graph; the management client displays concurrent API versions existing in a plurality of peer-to-peer gateway nodes, and an administrator initiates a solution request after analyzing the concurrent API versions; and the gateway node receiving the solution request creates a solution API version, and the solution API version is synchronized to the whole network as a latest consensus version, so that the plurality of peer-to-peer gateway nodes recover a consistent state.

Description

Technical Field

[0001] This invention belongs to the field of gateway API version management technology, and particularly relates to a distributed management method and apparatus for gateway API versions. Background Technology

[0002] In modern microservices and cloud-native architectures, API gateways play a crucial role in traffic governance. Dynamic changes and deployments of their configurations (such as routes and policies) are high-frequency and critical operations. Traditional architectures typically employ a "control plane-data plane" separation model: a centralized control panel manages the configuration and then distributes it to all gateway nodes (data plane).

[0003] This model has inherent flaws: Centralization bottleneck and single point of failure: The availability of the control plane directly determines the availability of the entire gateway system. If the control plane crashes, all gateway nodes will be unable to obtain new configurations, and may even be considered abnormal due to heartbeat interruption.

[0004] Network Dependency and Latency: Configuration changes to gateway nodes are heavily dependent on their network connection to the control plane. In cases of network partitioning or high latency, data plane nodes may fail to obtain the latest configuration in a timely manner, leading to service inconsistencies or delays in changes.

[0005] Concurrent release conflicts: If multiple administrators or automated scripts simultaneously submit configuration changes to the control plane, the control plane typically uses a simple "last-write-win" strategy to resolve conflicts. This discards unnoticed updates and makes it impossible to trace the source of the conflict, making auditing and troubleshooting very difficult.

[0006] While some studies have attempted to achieve complete peering of gateway nodes, the resulting configuration synchronization and conflict resolution present new technical challenges. Simple version numbers (such as monotonically increasing integers) cannot accurately depict the causal history of changes in a distributed environment, making it difficult to detect and resolve concurrent update conflicts. Therefore, there is an urgent need in this field for a version management solution that is applicable to distributed gateway scenarios, can accurately track the causal history of changes, and can reliably handle concurrent conflicts. Summary of the Invention

[0007] In view of the shortcomings of the prior art, the purpose of the invention is to provide a distributed management method and apparatus for gateway API versions, which is applicable to distributed gateway scenarios, can accurately track the cause-and-effect history of changes, and can reliably handle concurrent conflicts in gateway API version management.

[0008] In a first aspect, the present invention proposes a distributed management method for gateway API versions, applied to a system comprising multiple peer gateway nodes and a management client, the method comprising: When the management client receives a request from the administrator to publish a new API version to the first gateway node, the management client submits the new API version and the vector clock of the old API version on which the new API version is based to the first gateway node. When the first gateway node receives the new API version and the vector clock of the old API version on which the new API version is based, it determines whether the vector clock of the old API version is the latest consensus version of the new API version, and performs causal update or concurrent update according to the determination result. The first gateway node persists the updated API version and the corresponding vector clock to its local machine; Multiple peer gateway nodes synchronize their stored API version history information through the Gossip protocol, enabling them to have a complete and consistent API version graph. The management interface of the management client monitors and displays the concurrent API versions of multiple peer gateway nodes. After analyzing the concurrent API versions, the administrator initiates a resolution request based on the concurrent API versions or the content after manual merging. The gateway node that receives the resolution request creates a resolution API version. The resolution API version, as the latest consensus version, is synchronized to the entire network via the Gossip protocol, eventually covering all concurrent API versions and restoring multiple peer gateway nodes to a consistent state.

[0009] Furthermore, in the aforementioned distributed management method for gateway API versions, the method determines whether the vector clock of the old API version is the latest consensus version of the current new API version, and performs causal updates based on the determination result, including: If the determination result is that the vector clock of the old API version is the latest consensus version of the current new API version, then the first gateway node accepts the publication; Generate the vector clock for the current new API configuration version; The process of generating the vector clock for the current new API configuration version includes: the vector clock for the current new API configuration version is based on the vector clock of the old API version, with the counter of the first gateway node incremented by one.

[0010] Furthermore, in the aforementioned distributed management method for gateway API versions, the method determines whether the current new API version is the latest consensus version based on the vector clock of the old API version, and performs concurrent updates based on the determination result, including: If the determination result is that the vector clock of the old API version is not the latest consensus version of the current new API version, the first gateway node will still accept the publication; Mark the current new API version as a concurrent version; Generate a concurrent version of the vector clock; The process of generating concurrent versions of the vector clock includes: taking the union of the old API version vector clock and all concurrent API version vector clocks known to the first gateway node, and incrementing the counter of the first gateway node by one.

[0011] Furthermore, in the aforementioned distributed management method for gateway API versions, multiple peer gateway nodes periodically synchronize their stored API version history information via the Gossip protocol, ensuring that the multiple peer gateway nodes possess a complete and consistent API version graph, including: After receiving the API version from the first gateway node, the second gateway node merges it with the version stored locally by the first gateway node. If the merge result shows that the local API version is missing, retrieve the complete API version content from the other party's gateway node.

[0012] Furthermore, the aforementioned distributed management method for gateway API versions also includes: After receiving the API version from the first gateway node, the second gateway node compares it with the version stored locally by the first gateway node using vector clock rules. If the comparison result shows that all components of the API version of the first gateway node are less than or equal to the API version of the second gateway node and at least one component is less than, then the API version of the first gateway node is discarded or considered an old version.

[0013] Furthermore, the aforementioned distributed management method for gateway API versions also includes: After receiving the API version from the first gateway node, the second gateway node compares it with the version stored locally by the first gateway node using vector clock rules. If the comparison result shows that the vector clocks of the API versions of the first gateway node and the second gateway node are not comparable, it is identified as a concurrent API version, and both the API versions of the first gateway node and the API versions of the second gateway node are retained.

[0014] Furthermore, in the aforementioned distributed management method for gateway API versions, the vector clock for resolving version issues is the union of the vector clocks of all concurrent API versions, and the counter of the current gateway node is incremented by one.

[0015] A second aspect of the present invention also proposes a distributed management device for gateway API versions, applied to a system comprising: multiple peer gateway nodes and a management client, including: The publishing module is used to manage the client when it receives a request from the administrator to publish a new API version to the first gateway node. The management client submits the new API version and the vector clock of the old API version on which the new API version is based to the first gateway node. Update module: When the first gateway node receives a new API version and the vector clock of the old API version on which the new API version is based, it determines whether the vector clock of the old API version is the latest consensus version of the new API version, and performs causal update or concurrent update according to the determination result. Persistence module: Used by the first gateway node to persist the updated API version and the corresponding vector clock to the local machine; Synchronization module: Used to periodically synchronize the API version history information stored by multiple peer gateway nodes through the Gossip protocol, so that multiple peer gateway nodes have a complete and consistent API version graph. Display module: Used to manage the management interface of the client to monitor and display the concurrent API versions of multiple peer gateway nodes. After the administrator analyzes the concurrent API versions, he / she initiates a resolution request based on the concurrent API versions or the content after manual merging. Recovery module: The gateway node that receives the resolution request creates a resolution API version. The resolution API version, as the latest consensus version, is synchronized to the entire network via the Gossip protocol, eventually covering all concurrent API versions and restoring multiple peer gateway nodes to a consistent state.

[0016] A third aspect of the present invention also provides an electronic device comprising: a processor and a memory; The processor executes a distributed management method for a gateway API version by calling programs or instructions stored in memory, as described above.

[0017] In a fourth aspect, the present invention also provides a computer-readable storage medium that stores a program or instructions that cause a computer to execute a distributed management method for a gateway API version as described in any of the preceding claims.

[0018] The beneficial effects of this invention are as follows: 1) Decentralized publishing mechanism: Allows administrators to publish configurations to any gateway node, and each gateway node can serve as an entry point for configuration publishing, thus abandoning the traditional centralized control plane.

[0019] 2) Vector clock-based version identification: Using vector clocks, a globally unique version number that reflects causal history is generated for each configuration release, providing a theoretical basis for version comparison and conflict detection in a distributed environment.

[0020] 3) Conflict detection and retention mechanism: By comparing vector clocks, conflicts caused by concurrent updates can be accurately identified, and a strategy of "retaining all conflicting versions" is adopted to avoid data loss problems caused by the "last write wins" strategy based on timestamps or single version numbers.

[0021] 4) Eventual consistency synchronization based on Gossip: The asynchronous Gossip protocol is used to synchronize the configuration version history between gateway nodes, ensuring the eventual consistency and high availability of the cluster, and can tolerate network partitions and node failures.

[0022] 5) Explicit Conflict Resolution API: Provides an interface for administrators or automated scripts to view conflicts and submit solutions, delegating complex merging logic to upper layers, with the system only responsible for reliably recording and synchronizing the resolved results. Attached Figure Description

[0023] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. It is obvious that the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings.

[0024] Figure 1 A diagram illustrating a distributed management method for gateway API versions provided in an embodiment of the present invention; Figure 2 A diagram illustrating a method for causal updating provided in an embodiment of the present invention; Figure 3 This is a diagram illustrating a method for performing concurrent updates according to an embodiment of the present invention; Figure 4 The method for synchronizing API version history information provided in this embodiment of the invention Figure 1 ; Figure 5 The method for synchronizing API version history information provided in this embodiment of the invention Figure 2 ; Figure 6 The method for synchronizing API version history information provided in this embodiment of the invention Figure 3 ; Figure 7 A diagram of a distributed management device for a gateway API version provided in an embodiment of the present invention; Figure 8 This is a schematic block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0025] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0026] Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts disclosed in this invention.

[0027] In the description of this invention, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The terms "installed," "connected," and "linked" should be interpreted broadly; for example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of methods and systems consistent with some aspects of the invention as detailed in the appended claims.

[0029] This invention proposes a distributed management method, device, electronic device, and storage medium for gateway API versions, which is applicable to distributed gateway scenarios, can accurately track the causal history of changes, and can reliably handle concurrent conflicts in gateway API version management.

[0030] Before introducing the embodiments of the present invention, the technical terms involved in the present invention will be introduced first.

[0031] API Gateway: A core component in a microservice architecture, serving as the entry point for all external requests and responsible for cross-aspect concerns such as routing, authentication, rate limiting, and version control.

[0032] API Version / Configuration: This refers to the set of policies published to the API Gateway, including routing rules, upstream service addresses, load balancing strategies, and plugin configurations (such as rate limiting and authentication). Each change generates a new version.

[0033] Vector clocks: A data structure and algorithm used in distributed systems for partially ordering events. Each node (here, the gateway node) maintains a vector (a set of counters), where each element corresponds to a node's logical clock. By comparing the vectors, the causal or concurrent relationships between events can be inferred.

[0034] Eventual consistency: A consistency model in distributed systems that guarantees that if no new updates are made to a data item, eventually all requests to access that data will return the last updated value.

[0035] Control plane: The system component responsible for managing and distributing configurations and policies, typically deployed centrally or in a weakly distributed manner.

[0036] Data plane: The system component responsible for actually processing and forwarding user requests; here it refers to a distributed API gateway node cluster.

[0037] Configuration discrepancies / conflicts: In a distributed system, when two or more gateway nodes accept new configuration updates based on different historical versions without being fully synchronized, it leads to an inconsistent understanding of the "currently valid configuration" within the cluster.

[0038] Method Implementation Examples Figure 1 This diagram illustrates a distributed management method for gateway API versions provided in an embodiment of the present invention.

[0039] In a first aspect, this invention proposes a distributed management method for gateway API versions, applied to a system comprising multiple peer-to-peer gateway nodes and a management client, combined with... Figure 1 The method comprises six steps, S1 to S6: S1: When the management client receives a request from the administrator to publish a new API version to the first gateway node, the management client submits the new API version and the vector clock of the old API version on which the new API version is based to the first gateway node.

[0040] Specifically, in this embodiment of the invention, each of the multiple peer gateway nodes has the ability to independently receive API version release requests, store API version history, and synchronize with other nodes. The management client can initiate a configuration release request to any gateway node.

[0041] It should be understood that the first gateway node is any one of multiple peer gateway nodes. For example, in a distributed API gateway cluster containing two nodes: First Gateway Node-A and First Gateway Node-B, when a management client receives a request from an administrator to First Gateway Node-A to publish a new API version C_new, the administrator specifies the vector clock V_old of the old API version upon which the new API version C_new is based. After receiving the publication request, the management client submits the new API version and the vector clock of the old API version upon which the new API version is based to First Gateway Node. The API version is the basic unit of management. A complete API version publication is called a version, which includes routing rules, plugin configurations, etc. Each version has a unique vector clock identifier.

[0042] S2: When the first gateway node receives the new API version and the vector clock of the old API version on which the new API version is based, it determines whether the vector clock of the old API version is the latest consensus version of the new API version, and performs causal update or concurrent update according to the determination result.

[0043] Specifically, in this embodiment of the invention, the latest consensus version of the current new API version is the latest causal version known to most nodes in the cluster. If it is not the latest consensus version of the current new API version, it is because other releases based on updated versions have been accepted by other nodes. The methods for performing causal updates or concurrent updates are described in detail below.

[0044] S3: The first gateway node persists the updated API version and the corresponding vector clock to its local machine.

[0045] Specifically, in this embodiment of the invention, the first gateway node Node-A persists the new API version C_new and the new API version vector clock V_new to its local machine and immediately applies the new configuration.

[0046] S4: Multiple peer gateway nodes synchronize their stored API version history information through the Gossip protocol, so that multiple peer gateway nodes have a complete and consistent API version graph.

[0047] Specifically, in this embodiment of the invention, all versions of an API version history form a directed acyclic graph, with edges representing causal relationships between versions. The version history provides administrators with a clear view of change tracing, greatly facilitating troubleshooting and auditing. The method of synchronizing the API version history stored by multiple peer gateway nodes through the Gossip protocol, so that multiple peer gateway nodes have a complete and consistent API version graph, is described in detail below.

[0048] S5: The management interface of the management client monitors and displays the concurrent API versions of multiple peer gateway nodes. After analyzing the concurrent API versions, the administrator initiates a resolution request based on the concurrent API versions or the content after manual merging.

[0049] Specifically, in this embodiment of the invention, the management interface of the management client monitors and displays the concurrent API versions existing on multiple peer gateway nodes, i.e., the conflicting API versions. After analyzing the conflicting API versions, the administrator initiates a resolution request based on the conflicting API versions or the manually merged content. The resolution request includes the set of conflicting versions to be resolved. [V_conflict1, V_conflict2, ...].

[0050] S6: The gateway node that receives the resolution request creates a resolution API version. The resolution API version, as the latest consensus version, is synchronized to the entire network via the Gossip protocol, eventually covering all concurrent API versions, so that multiple peer gateway nodes can be restored to a consistent state.

[0051] Specifically, in this embodiment of the invention, the gateway node receiving this request will create a resolved API version V_resolved. The vector clock of the resolved API version is the union of the vector clocks of all conflicting versions. The node will then increment its counter. The resolved API version will become the successor of all conflicting versions in the historical graph. The resolved API version, as the new consensus version, will be synchronized to the entire network via the Gossip protocol, ultimately covering all conflicting API versions and restoring multiple peer gateway nodes in the cluster to a consistent state.

[0052] Figure 2 This diagram illustrates a method for causal updates provided in an embodiment of the present invention.

[0053] Furthermore, in the aforementioned distributed management method for gateway API versions, the method determines whether the vector clock of the old API version is the latest consensus version of the new API version, performs causal updates based on the determination result, and combines... Figure 2 It includes two steps, S21 and S22: S21: If the determination result is that the vector clock of the old API version is the latest consensus version of the current new API version, then the first gateway node accepts the publication; S22: Generate the vector clock for the current new API version; The process of generating the vector clock for the current new API version includes: the vector clock for the current new API configuration version is based on the vector clock of the old API version, with the counter of the first gateway node incremented by one.

[0054] Specifically, in this embodiment of the invention, if the vector clock V_old of the old API version is exactly the latest consensus version of the current new API version, where the latest consensus version is the latest causal version known to most nodes in the cluster, then the release is accepted. The vector clock V_new of the new API version is based on the vector clock V_old of the old API version, and the counter of the first gateway node Node-A is incremented by one: V_new = V_old.inc("Gateway-A").

[0055] Figure 3 This diagram illustrates a method for performing concurrent updates according to an embodiment of the present invention.

[0056] Furthermore, in the aforementioned distributed management method for gateway API versions, the method determines whether the current API version is the latest consensus version based on the vector clock of the old API version, and performs concurrent updates based on the determination result, combined with... Figure 3 It includes three steps, S31 to S33: S31: If the determination result is that the vector clock of the old API version is not the latest consensus version of the current new API version, the first gateway node will still accept the publication; S32: Mark the current new API version as a concurrent version; S33: Generate a concurrent version of the vector clock; The process of generating concurrent versions of the vector clock includes: taking the union of the old API version vector clock and all concurrent API version vector clocks known to the first gateway node, and incrementing the counter of the first gateway node by one.

[0057] Specifically, in this embodiment of the invention, if the vector clock V_old of the old API version is not the latest consensus version, that is, other nodes have already accepted other releases based on the updated version, a conflict occurs. In this case, the first gateway node Node-A will still accept this release, mark the current new API version as a concurrent version, that is, a conflicting version, take the union of the vector clock V_old of the old API version and the vector clocks of all concurrent versions known to the current Node-A, here taking the maximum value for each component, and then increment the counter of the first gateway node Node-A by one.

[0058] Figure 4 The method for synchronizing API version history information provided in this embodiment of the invention Figure 1 .

[0059] Furthermore, in the aforementioned distributed management method for gateway API versions, multiple peer gateway nodes periodically synchronize their stored API version history information via the Gossip protocol, ensuring that the multiple peer gateway nodes possess a complete and consistent API version graph. Figure 4 It includes two steps, S41 and S42: S41: After receiving the API version from the first gateway node, the second gateway node merges it with the version stored locally by the first gateway node; S42: If the merge result is that the local API version is missing, pull the complete API version content from the other party's gateway node.

[0060] Specifically, in this embodiment of the invention, the first gateway node and the second gateway node are any two gateway nodes with an adjacent relationship among a plurality of gateway nodes. After receiving the version information of the neighboring gateway node, the gateway node will merge it with the version stored locally. If the result of the merger is that the local API version is missing, the gateway node will pull the complete API version content from the other gateway node.

[0061] It should be understood that adding a new gateway node only requires joining the Gossip cluster to automatically synchronize the entire configuration history, making it easy to scale horizontally and distribute the pressure of publishing requests across all gateway nodes.

[0062] Figure 5 The method for synchronizing API version history information provided in this embodiment of the invention Figure 2 .

[0063] Furthermore, the aforementioned distributed management method for gateway API versions, combined with Figure 5 It also includes two steps, S51 and S52: S51: After receiving the API version from the first gateway node, the gateway node compares it with the version stored locally by the first gateway node using the vector clock rule; S52: If the comparison result is that all components of the API version of the first gateway node are less than or equal to the API version of the second gateway node and at least one component is less than, then the API version of the first gateway node is discarded or regarded as an old version.

[0064] Specifically, in this embodiment of the invention, the first gateway node and the second gateway node are any two gateway nodes with an adjacent relationship among a plurality of gateway nodes. After receiving the version information of the neighboring gateway node, the gateway node will compare it with the version stored locally. If all components of the API version V1 of the first gateway node are <= V2 and at least one component is <, then the API version V1 of the first gateway node can be discarded or regarded as an old version.

[0065] Exemplary: V1: {A: 1, B: 1}, V2: {A: 2, B: 2}, comparison: A: 1 < A: 2, B: 1 < B: 2, then the API version V1 of the first gateway node can be discarded or regarded as an old version.

[0066] Figure 6 The method for synchronizing API version historical information provided by the embodiments of the present invention Figure 3 .

[0067] Further, in the above method for distributed management of gateway API versions, combined with Figure 6 , it further includes two steps S61 to S62: S61: After the second gateway node receives the API version of the first gateway node, it uses the vector clock rule to compare it with the version stored locally by the first gateway node; S62: If the comparison result is that the vector clocks of the API versions of the first gateway node and the second gateway node cannot be compared, it is identified as a concurrent API version, and both the API version of the first gateway node and the API version of the second gateway node are retained.

[0068] Specifically, in the embodiments of the present invention, the first gateway node and the second gateway node are any two adjacent gateway nodes among multiple gateway nodes. After a gateway node receives the version information of a neighbor gateway node, it will compare it with the version stored locally. If the comparison result is that the vector clocks of the API versions of the first gateway node and the second gateway node cannot be compared, that is, some components are large and some components are small, then both the API version of the first gateway node and the API version of the second gateway node are identified as concurrent API versions, and both the API version of the first gateway node and the API version of the second gateway node are retained.

[0069] Further, in the above method for distributed management of gateway API versions, the solution version vector clock is the union of the vector clocks of all concurrent API versions, and the counter of the current gateway node is incremented by one.

[0070] Specifically, in the embodiments of the present invention, the solution API version vector clock is the union of the vector clocks of all conflicting versions, and then the counter of this node is incremented by one. The solution API version will become the successor of all conflicting versions in the history graph. The solution API version is synchronized to the entire network through the Gossip protocol as a new consensus version, finally covering all API conflicting versions, and enabling multiple peer gateway nodes in the cluster to restore a consistent state.

[0071] Device embodiments Figure 7 A diagram of a device for distributed management of gateway API versions provided by the embodiments of the present invention.

[0072] A second aspect of the invention also proposes a distributed management device for gateway API versions, applied to a system comprising multiple peer gateway nodes and a management client, in conjunction with... Figure 7 ,include: Module 71: When the management client receives a request from the administrator to publish a new API version to the first gateway node, the management client submits the new API version and the vector clock of the old API version on which the new API version is based to the first gateway node.

[0073] Specifically, in this embodiment of the invention, each of the multiple peer gateway nodes has the ability to independently receive API version release requests, store API version history, and synchronize with other nodes. The management client can initiate a configuration release request to any gateway node.

[0074] It should be understood that the first gateway node is any one of multiple peer gateway nodes. For example, in a distributed API gateway cluster containing two nodes: First Gateway Node-A and First Gateway Node-B, when the management client's publishing module 71 receives a request from the administrator to publish a new API version C_new to First Gateway Node-A, the administrator specifies the vector clock V_old of the old API version upon which the new API version C_new is based. After receiving the publishing request, the management client submits the new API version and the vector clock of the old API version upon which the new API version is based to the first gateway node. The API version is the basic unit of management. A complete API version publication is called a version, which includes routing rules, plugin configurations, etc. Each version has a unique vector clock identifier.

[0075] Update module 72: When the first gateway node receives a new API version and the vector clock of the old API version on which the new API version is based, it determines whether the vector clock of the old API version is the latest consensus version of the current new API version, and performs causal update or concurrent update according to the determination result.

[0076] Specifically, in this embodiment of the invention, the latest consensus version of the current new API version is the latest causal version known to most nodes in the cluster. If it is not the latest consensus version of the current new API version, it is because other releases based on updated versions have been accepted by other nodes. The method of the update module 72 to perform causal updates or concurrent updates has been described in detail in the method class embodiments.

[0077] Persistence module 73: Used by the first gateway node to persist the updated API version and the corresponding vector clock to the local machine.

[0078] Specifically, in this embodiment of the invention, the persistence module 73 of the first gateway node Node-A persists the new API version C_new and the new API version vector clock V_new to the local machine and immediately applies the new configuration.

[0079] Synchronization Module 74: Used for multiple peer gateway nodes to periodically synchronize their stored API version history information via the Gossip protocol, so that multiple peer gateway nodes have a complete and consistent API version graph.

[0080] Specifically, in this embodiment of the invention, all versions of an API version history form a directed acyclic graph, with edges representing causal relationships between versions. The version history provides administrators with a clear view of change tracing, greatly facilitating troubleshooting and auditing. Multiple peer gateway nodes synchronize their stored API version history information through the synchronization module 74 of the Gossip protocol, enabling multiple peer gateway nodes to have a complete and consistent API version graph.

[0081] Display module 75: Used to manage the client's management interface to monitor and display the concurrent API versions of multiple peer gateway nodes. After analyzing the concurrent API versions, the administrator initiates a resolution request based on the concurrent API versions or the manually merged content.

[0082] Specifically, in this embodiment of the invention, the display module 75 of the management client monitors and displays the concurrent API versions existing in multiple peer gateway nodes, i.e., those conflicting API versions. After analyzing the conflicting API versions, the administrator initiates a resolution request based on the conflicting API versions or the content after manual merging. The resolution request includes the set of conflicting versions to be resolved. [V_conflict1, V_conflict2, ...].

[0083] Recovery Module 76: Used to create a resolution API version for gateway nodes that receive resolution requests. The resolution API version is synchronized to the entire network as the latest consensus version via the Gossip protocol, eventually covering all concurrent API versions and restoring multiple peer gateway nodes to a consistent state.

[0084] Specifically, in this embodiment of the invention, the gateway node receiving this request will create a resolved API version V_resolved. The vector clock of the resolved API version is the union of the vector clocks of all conflicting versions. The node counter will then be incremented by one. The resolved API version will become the successor of all conflicting versions in the historical graph. The resolved API version, as the new consensus version, will be synchronized to the entire network via the Gossip protocol, ultimately covering all API conflicting versions. The recovery module 76 will restore multiple peer gateway nodes in the cluster to a consistent state.

[0085] A third aspect of the present invention also provides an electronic device comprising: a processor and a memory; The processor executes a distributed management method for a gateway API version by calling programs or instructions stored in memory, as described above.

[0086] In a fourth aspect, the present invention also provides a computer-readable storage medium that stores a program or instructions that cause a computer to execute a distributed management method for a gateway API version as described in any of the preceding claims.

[0087] Figure 8 This is a schematic block diagram of an electronic device provided in an embodiment of the present invention.

[0088] like Figure 8 As shown, the electronic device includes at least one processor 801, at least one memory 802, and at least one communication interface 803. The various components in the electronic device are coupled together via a bus system 804. The communication interface 803 is used for information transmission with external devices. It is understood that the bus system 804 is used to implement communication between these components. In addition to a data bus, the bus system 804 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 8 The general labeled all buses as Bus System 804.

[0089] It is understood that the memory 802 in this embodiment may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.

[0090] In some implementations, memory 802 stores elements such as executable units or data structures, or subsets thereof, or extended sets thereof: operating systems and applications.

[0091] The operating system includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application programs include various applications, such as media players and browsers, used to implement various application functions. Programs implementing any method in the distributed management method for a gateway API version provided in this embodiment of the invention can be included in the application programs.

[0092] In this embodiment of the invention, the processor 801 executes the steps of various embodiments of the gateway API version distributed management method provided in this embodiment of the invention by calling the program or instructions stored in the memory 802, specifically, the program or instructions stored in the application.

[0093] When the management client receives a request from the administrator to publish a new API version to the first gateway node, the management client submits the new API version and the vector clock of the old API version on which the new API version is based to the first gateway node. When the first gateway node receives the new API version and the vector clock of the old API version on which the new API version is based, it determines whether the vector clock of the old API version is the latest consensus version of the new API version, and performs causal update or concurrent update according to the determination result. The first gateway node persists the updated API version and the corresponding vector clock to its local machine; Multiple peer gateway nodes synchronize their stored API version history information through the Gossip protocol, enabling them to have a complete and consistent API version graph. The management interface of the management client monitors and displays the concurrent API versions of multiple peer gateway nodes. After analyzing the concurrent API versions, the administrator initiates a resolution request based on the concurrent API versions or the content after manual merging. The gateway node that receives the resolution request creates a resolution API version. The resolution API version, as the latest consensus version, is synchronized to the entire network via the Gossip protocol, eventually covering all concurrent API versions and restoring multiple peer gateway nodes to a consistent state.

[0094] Any method in the distributed management method for a gateway API version provided in this embodiment of the invention can be applied to, or implemented by, the processor 801. The processor 801 can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by the integrated logic circuits in the hardware of the processor 801 or by instructions in software form. The processor 801 can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0095] The steps of any method in the distributed management method for gateway API versions provided in this embodiment of the invention can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software units in the decoding processor. The software units can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 802, and processor 801 reads the information in memory 802 and combines it with its hardware to complete the steps of the method.

[0096] Those skilled in the art will understand that although some embodiments described herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of the invention and form different embodiments.

[0097] Those skilled in the art will understand that the descriptions of the various embodiments have different focuses, and for parts not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0098] Although embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention. All such modifications and variations fall within the scope defined by the appended claims. The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0099] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A distributed management method for gateway API versions, characterized in that, The application is applied to a system comprising a plurality of peer gateway nodes and a management client, and the method comprises: When the management client receives a request from an administrator to publish a new API version to a first gateway node, the management client submits a new API version and a vector clock of an old API version on which the new API version is based to the first gateway node; When the first gateway node receives the new API version and the vector clock of the old API version on which the new API version is based, the first gateway node determines whether the old API version is the latest consensus version of the current new API version according to the vector clock of the old API version, and performs causal update or concurrent update according to the determination result; The first gateway node persists the updated API version and the corresponding vector clock locally; The plurality of peer gateway nodes synchronize the API version history information stored by each of the plurality of peer gateway nodes through a Gossip protocol, so that the plurality of peer gateway nodes have complete and consistent API version graphs; A management interface of the management client monitors and displays concurrent API versions existing in the plurality of peer gateway nodes, and an administrator analyzes the concurrent API versions, and initiates a resolution request based on the concurrent API versions or manually merged contents; A gateway node receiving the resolution request creates a resolution API version, and the resolution API version is synchronized to the entire network as the latest consensus version through the Gossip protocol, and finally covers all concurrent API versions, so that the plurality of peer gateway nodes restore a consistent state.

2. The gateway API version distributed management method of claim 1, wherein, Determining whether the old API version is the latest consensus version of the current new API version according to the vector clock of the old API version, and performing causal update according to the determination result, comprises: If the determination result is that the vector clock of the old API version is the latest consensus version of the current new API version, the first gateway node accepts the publishing; Generating a vector clock of the current new API version; Wherein, generating the vector clock of the current new API version comprises: adding one to the counter of the first gateway node on the basis of the vector clock of the old API version.

3. The gateway API version distributed management method of claim 1, wherein, Determining whether the current new API version is the latest consensus version according to the vector clock of the old API version, and performing concurrent update according to the determination result, comprises: If the determination result is that the vector clock of the old API version is not the latest consensus version of the current new API version, the first gateway node still accepts the publishing; Marking the current new API version as a concurrent version; Generating a vector clock of the concurrent version; Wherein, generating the vector clock of the concurrent version comprises: taking the union of the vector clock of the old API version and the vector clocks of all concurrent API versions known by the first gateway node, and adding one to the counter of the first gateway node.

4. The gateway API version distributed management method of claim 1, wherein, The plurality of peer gateway nodes periodically synchronize the API version history information stored by each of the plurality of peer gateway nodes through the Gossip protocol, so that the plurality of peer gateway nodes have complete and consistent API version graphs, comprising: After the second gateway node receives the API version of the first gateway node, the second gateway node merges the API version with the version stored locally by the first gateway node; If the merged result is a local missing API version, the complete API version content is pulled from the opposite gateway node.

5. The gateway API version distributed management method of claim 4, wherein, The method further comprises: After receiving the API version of the first gateway node, the second gateway node compares the API version with the version stored locally in the first gateway node using vector clock rules; If the comparison result is that all components of the API version of the first gateway node are less than or equal to the API version of the second gateway node and at least one component is less than, the API version of the first gateway node is discarded or regarded as an old version.

6. The gateway API version distributed management method of claim 4, wherein, The method further comprises: After receiving the API version of the first gateway node, the second gateway node compares the API version with the version stored locally in the first gateway node using vector clock rules; If the comparison result is that the vector clocks of the API version of the first gateway node and the API version of the second gateway node are not comparable, it is identified as a concurrent API version, and the API version of the first gateway node and the API version of the second gateway node are both retained.

7. The gateway API version distributed management method of claim 1, wherein, The vector clock of the solution version is the union of all concurrent API version vector clocks, and the current gateway node counter is incremented by one. 8.A gateway API version distributed management apparatus characterized by comprising: The device is applied to a system comprising a plurality of peer gateway nodes and a management client, and comprises: A publishing module configured to, when the management client receives a request of an administrator to publish a new API version to a first gateway node, submit, by the management client, the new API version and a vector clock of an old API version on which the new API version is based to the first gateway node; An updating module configured to, when the first gateway node receives the new API version and the vector clock of the old API version on which the new API version is based, determine whether the old API version is the latest consensus version of the current new API version according to the vector clock of the old API version, and perform causal updating or concurrent updating according to a determination result; A persisting module configured to persist, by the first gateway node, the updated API version and the corresponding vector clock locally; A synchronizing module configured to periodically synchronize API version history information stored by each of the plurality of peer gateway nodes through a Gossip protocol, so that the plurality of peer gateway nodes have complete and consistent API version graphs; A display module configured to monitor and display concurrent API versions existing in the plurality of peer gateway nodes on a management interface of the management client, and initiate a resolution request based on the concurrent API versions or manually merged content after an administrator analyzes the concurrent API versions; A restoring module configured to create a resolution API version by a gateway node receiving the resolution request, synchronize the resolution API version as the latest consensus version to the entire network through the Gossip protocol, and finally cover all concurrent API versions, so as to restore the plurality of peer gateway nodes to a consistent state.

9. An electronic device, comprising: comprise: a processor and a memory; the processor is configured to execute a gateway API version distributed management method according to any one of claims 1 to 7 by calling programs or instructions stored in the memory.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores programs or instructions, which cause the computer to execute a gateway API version distributed management method according to any one of claims 1 to 7.

Images