Cloud service system, information update method, device, storage medium, and program product

Abstract

Embodiments of the present application provide a cloud service system, an information updating method, equipment, a storage medium and a program product. In the embodiments of the present application, a decentralized global service relationship updating mechanism is provided. On the one hand, the route configuration nodes in each availability zone synchronize the target service relationship that changes between availability zones, realizing the eventual consistency of the global service relationship in different availability zones. On the other hand, the local global service relationship of the route configuration nodes in the availability zone is updated in the case that the route configuration nodes in the availability zone reach a consensus on the target service relationship, realizing the consistency of the global service relationship in the availability zone. The decentralized design provides maximum availability guarantee, does not need to maintain a global route configuration node, and solves the single-point failure problem.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a cloud service system, information update method, device, storage medium and program product. Background Technology

[0002] In the field of cloud computing, the concept of Availability Zones (AZs) has been proposed to improve service reliability and disaster recovery capabilities. An Availability Zone refers to a physical area within the same region where power and network resources are independent. Multiple Availability Zones are deployed within the same region, with service clusters in different Availability Zones and their internal networks interconnected. If one Availability Zone fails, service clusters in other Availability Zones can continue to provide services, thus improving service reliability and disaster recovery capabilities.

[0003] In existing cloud service systems, global routing service nodes maintain global routing tables corresponding to service clusters in multiple availability zones. Global routing service nodes periodically send global routing tables to local routing service nodes in each availability zone. Local routing service nodes provide routing services for service clusters to clients within their respective availability zones.

[0004] The global routing service node is a single point of failure. If the global routing service node fails, the routing service of the entire service system will be affected, causing the service instance to be unable to provide services to the client. Summary of the Invention

[0005] This application provides a cloud service system, information update method, device, storage medium, and program product to achieve decentralization, eliminate the need to maintain global routing configuration nodes, solve single point of failure problems, and ensure the consistency of global service relationships.

[0006] This application provides a cloud service system, including: multiple availability zones; at least one service cluster, multiple routing configuration nodes, and at least one routing service node are deployed in each availability zone; the routing service node has a service relationship with at least some of the service clusters in its own availability zone; the routing service node is used to maintain at least some routing information of the service clusters with which it has a service relationship, and to provide routing services to the outside world based on the routing information; the routing configuration node is used to maintain the global service relationship between the service clusters in the multiple availability zones and the routing service node, and to synchronize with other routing configuration nodes in other availability zones for a target service relationship, wherein the other availability zones are availability zones other than the routing configuration node; and to reach consensus with other routing configuration nodes in the availability zone to which the routing configuration node belongs for a target service relationship, so as to update the global service relationship; wherein the target service relationship is the service relationship that changes within the availability zone where any routing configuration node is located.

[0007] This application also provides an information update method applicable to routing configuration nodes in any availability zone of a cloud service system. The cloud service system includes multiple availability zones, each deploying at least one service cluster, multiple routing configuration nodes, and at least one routing service node. The method includes: maintaining a global service relationship between the service clusters and routing service nodes within the multiple availability zones, wherein at least a portion of the routing information in the service clusters is maintained by routing service nodes that have a service relationship with the service clusters, and this routing information is used by the routing service nodes to provide routing services externally; synchronizing with other routing configuration nodes in other availability zones for a target service relationship, where the target service relationship is a service relationship that has changed within the availability zone where any routing configuration node is located, and the other availability zones are availability zones other than the routing configuration nodes among the multiple availability zones; and reaching a consensus with other routing configuration nodes in the same availability zone for the target service relationship to update the global service relationship maintained by the routing configuration nodes.

[0008] This application also provides an electronic device, including: a memory and a processor; the memory for storing a computer program; and the processor, coupled to the memory, for executing the computer program to implement the steps in the information update method provided in this application.

[0009] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to implement the steps in the information update method provided in this application.

[0010] This application also provides a computer program product, including a computer program / instructions, which, when executed by a processor, cause the processor to implement the steps in the information update method provided in this application.

[0011] In this application embodiment, a decentralized global service relationship update mechanism is provided. On the one hand, the routing configuration nodes in each availability zone synchronize the target service relationship that has changed between availability zones to achieve eventual consistency of the global service relationship in different availability zones. On the other hand, when the routing configuration nodes in the availability zone reach a consensus on the target service relationship, the local global service relationship of the routing configuration nodes in the availability zone is updated to achieve consistency of the global service relationship in the availability zone. The decentralized design provides maximum availability guarantee, eliminates the need to maintain global routing configuration nodes, and solves the single point of failure problem. Attached Figure Description

[0012] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0013] Figure 1a A schematic diagram of the domain name system provided for an exemplary embodiment of this application;

[0014] Figure 1b A schematic diagram of the structure of a cloud service system provided as an exemplary embodiment of this application;

[0015] Figure 2 A schematic diagram of the structure of a cloud service system provided as an exemplary embodiment of this application;

[0016] Figure 3 A schematic diagram of a two-hop addressing mechanism provided for an exemplary embodiment of this application;

[0017] Figure 4 A schematic diagram illustrating a structure for a master node and slave nodes to reach consensus and update global service relationships, provided as an exemplary embodiment of this application;

[0018] Figure 5 A schematic diagram of a structure for updating global service relationships is provided as an exemplary embodiment of this application;

[0019] Figure 6 A flowchart illustrating an information updating method provided for an exemplary embodiment of this application;

[0020] Figure 7 A schematic diagram of the structure of an information updating device provided for an exemplary embodiment of this application;

[0021] Figure 8 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0024] Figure 1a This is a schematic diagram of the Domain Name System (DNS) structure provided for an exemplary embodiment of this application. The DNS is implemented as a tree structure, including root servers, top-level domain name servers, and second-level domain name servers, with the connection relationships as follows: Figure 1a As shown, routing services can be provided through the Domain Name System.

[0025] When a client needs to access a DNS address, it actually relies on a hierarchical caching server system (such as the root server, top-level domain name server, and second-level domain name server mentioned above). The client sends domain name information to the second-level domain name server. If the second-level domain name server does not find the corresponding IP address information for that domain name, it queries the root server. The root server records the access address information for each top-level domain name server and returns the access address information of the top-level domain name server that contains the corresponding IP address information to the client. Based on this access address information, the client accesses the top-level domain name server, obtains the IP address information corresponding to the domain name information, and can then access the server corresponding to that IP address. Although the existence of caching servers at each level can effectively alleviate the single point of failure problem of the root server, ... Figure 1a The provided tree structure is not a decentralized, highly available disaster recovery design and still has a single point of failure problem.

[0026] Figure 1b This is a schematic diagram of the structure of a cloud service system, such as... Figure 1b As shown, the cloud service system 100 includes multiple availability zones, each with a corresponding local routing configuration node 101. In addition, the cloud service system also includes a global routing configuration node 102. Figure 1b The example uses availability zones Y1, Y2, and Y3, but is not limited to these. Figure 1b The illustration uses three service clusters in each availability zone as an example, but it is not limited to this.

[0027] In this system, the global routing configuration node 102 establishes communication connections with the local routing configuration nodes 101 in each availability zone. The global routing configuration node 102 maintains global routing tables corresponding to multiple availability zones. Based on the communication connections between the global routing configuration node 102 and each local routing configuration node 101, the global routing configuration node 102 periodically sends this global routing table to each local routing configuration node 101, thus ensuring that each local routing configuration node 101 maintains its own global routing table. When a client wants to access a service cluster in a specific availability zone, the client sends a query request to the local routing configuration node 101 in that availability zone. The local routing configuration node 101 then provides routing query services to the client based on its locally maintained global routing table.

[0028] If global routing configuration node 102 fails, local routing configuration node 101 can only provide routing query services based on the locally maintained global routing table. If the global routing table needs updating, local routing configuration node 101 will be unable to obtain the updated information due to the failure of global routing configuration node 102. Therefore, global routing configuration node 102 can be considered a major single point of failure. If global routing configuration node 102 fails, the routing service of the entire service system will be affected, causing the service instance to be unable to provide services to clients.

[0029] This application provides a decentralized cloud service system. Instead of maintaining a global routing configuration node, this system sets up multiple routing configuration nodes in each availability zone. These nodes are responsible for routing synchronization between availability zones and within availability zones, ensuring that each availability zone's routing configuration node maintains a global route and that their final states are consistent. In this configuration, each availability zone's routing configuration node can provide routing query services based on its maintained global route.

[0030] The following is a detailed description of the cloud service system with reference to the accompanying diagram.

[0031] Figure 2 This is a schematic diagram illustrating the structure of a cloud service system provided as an exemplary embodiment of this application. The cloud service system can be various cloud computing-based service systems, such as cloud storage systems, cloud computing systems, cloud network systems, cloud security systems, etc. Figure 2 As shown, the system includes: multiple availability zones, each of which deploys at least one service cluster 201, multiple routing configuration nodes 202, and at least one routing service node. Figure 2 The diagram uses three availability zones, namely availability zone Z1, availability zone Z2 and availability zone Z3, as an example, but it is not limited to this.

[0032] In this embodiment, an availability zone refers to a cluster of data centers established by a cloud computing service provider within a geographical area, each with its own independent power, network, cooling, and other infrastructure. Each availability zone can operate as an independent entity, and even if one availability zone fails (e.g., power outage, network problems, or natural disasters), other availability zones can continue to provide services, thereby ensuring high availability and fault tolerance.

[0033] In this embodiment, service cluster 201 refers to a collection of independent yet collaborative service components, which can provide one or more specific services. A service component refers to the various functional modules or sub-services that constitute the entire service cluster 201. Different types of service components can provide different services, and they communicate and collaborate with each other through network connections. Each service component may have specific functions and responsibilities; for example, the functions of a service component may include, but are not limited to, data read / write, metadata management, replication mechanisms, compression algorithms, and security encryption. Service components can be implemented as virtual machines, containers, functional modules, or interface components, etc.

[0034] For example, a service cluster might be implemented as an object storage service cluster, which includes at least a metadata management component, a data read / write component, and a replication component. The metadata management component is responsible for managing and maintaining the object's metadata, such as object name, size, and type. The data read / write component handles user requests to upload and download objects, ensuring correct data access. The replication component guarantees data security and reliability, preventing data loss through a multi-copy mechanism.

[0035] For example, a service cluster might be implemented as a relational database service, which includes at least a Structured Query Language (SQL) engine component, a backup and recovery component, and a performance monitoring component. The SQL engine component is responsible for executing SQL queries and returning the results. The backup and recovery component is responsible for periodically taking snapshots of the database and quickly restoring it when needed. The performance monitoring component is responsible for monitoring database performance metrics in real time and providing optimization suggestions.

[0036] For example, a service cluster might be implemented as an elastic computing service, which includes at least a virtualization management component, a network isolation component, and an auto-scaling component. The virtualization management component is responsible for creating, configuring, and managing virtualization instances. The network isolation component ensures network security isolation between different tenants, guaranteeing the security of the private network environment. The auto-scaling component automatically adjusts the amount of computing resources based on preset rules or load conditions, supporting dynamic changes in the service.

[0037] In this embodiment, a routing service node is a node that provides routing services to service clusters 201 within its availability zone. A routing service node has a service relationship with at least some service clusters 201 within its availability zone. From the perspective of a service cluster 201, this service relationship exists between the service cluster 201 and one or more routing service nodes within its availability zone. For example, a service cluster can be provided with routing services by 5, 8, or 10 routing service nodes. For ease of distinction and description, the service relationship between a service cluster 201 and one or more routing service nodes within its availability zone is referred to as the service relationship corresponding to service cluster 201.

[0038] For example, the service relationships corresponding to service cluster 201 can be represented as: service cluster A1 <—> routing service node B1, routing service node B2 and routing service node B3; service cluster A2 <—> routing service node B4 and routing service node B5, etc.

[0039] Optionally, the service relationship corresponding to service cluster 201 can be implemented as a correspondence between the identification information of service cluster 201 and the description information of routing service nodes. The description information of the routing service nodes may include, but is not limited to, the identification information and access address information of the routing service nodes. For example, the access address information may include, but is not limited to, Internet Protocol address (IP) information or port number.

[0040] In this embodiment, a routing service node can maintain some or all of the routing information in the service cluster 201 that has a service relationship with it. The routing service node can then provide routing services to external parties based on the routing information it maintains.

[0041] In this embodiment, the routing configuration node 202 is a node used to maintain the service relationships between the service cluster 201 and the routing service nodes. Specifically, the routing configuration node 202 can maintain global service relationships across multiple availability zones. For ease of distinction and description, the service relationships between the service clusters 201 and the routing service nodes in the multiple availability zones included in the cloud service system are referred to as global service relationships. For example, global service relationships include local service relationships maintained by each of the multiple availability zones. The local service relationships of each availability zone are typically the service relationships between the service clusters within the availability zone and the routing service nodes within that availability zone. The local service relationships of each availability zone are maintained through multiple entries; for example, each entry stores the service relationships corresponding to a service cluster.

[0042] In this embodiment, the global service relationships maintained by the routing configuration node 202 may change. For example, a service relationship can be represented as: service cluster identification information <—> (routing service instance identification information - access address information). Based on this, changes in service relationships may include, but are not limited to, the following: adding routing service instances, reducing routing service instances, and changing the access address information of routing service instances.

[0043] For example, before the service relationship changes, a service relationship can be represented as: service cluster C1 <—> (routing service node D1 - access address E1), (routing service node D2 - access address E2), and (routing service node D3 - access address E3); after adding a new routing service node D4 with a service relationship to service cluster C1, the service relationship can be represented as: service cluster C1 <—> (routing service node D1 - access address E1), (routing service node D2 - access address E2), (routing service node D3 - access address E3), and (routing service node D4 - access address E4).

[0044] For example, before the service relationship changes, a service relationship can be represented as: service cluster C2 <—> (routing service node F1 - access address G1) and (routing service node F2 - access address G2). After the service relationship changes, it can be represented as: service cluster C2 <—> (routing service node F1 - access address G1) and (routing service node F2 - access address G3).

[0045] In this embodiment, for ease of distinction and description, the service relationship that changes in the global service relationship is referred to as the target service relationship. The target service relationship can be the service relationship that changes within the availability zone where any routing configuration node is located.

[0046] In this embodiment, any routing configuration node can synchronize target service relationships with other routing configuration nodes in other availability zones. For ease of distinction and description, availability zones other than the one to which the routing configuration node belongs are referred to as "other availability zones," and routing configuration nodes in other availability zones are referred to as "other routing configuration nodes." "Synchronization" means that a routing configuration node sends the target service relationship within its own availability zone to other routing configuration nodes in other availability zones, or receives the target service relationship within its own availability zone from other routing configuration nodes. In this way, target service relationships can be synchronized across routing configuration nodes in multiple availability zones.

[0047] In this embodiment, any routing configuration node reaches a consensus with other routing configuration nodes within its availability zone regarding the target service relationship to update the global service relationship. Here, "consensus" refers to the agreement reached among all routing configuration nodes within the availability zone regarding the operation of "updating the target service relationship to the global service relationship." The consensus mechanism ensures that even in situations of network instability, partial node failure, or malicious behavior, normally functioning routing configuration nodes can update the target service relationship to the global service relationship. This is crucial for guaranteeing the consistency, reliability, and high availability of all routing configuration nodes within the availability zone. Once the routing configuration nodes within the availability zone reach a consensus, each routing configuration node updates its local global service relationship according to the target service relationship.

[0048] For example, considering that the service relationships corresponding to a service cluster may change multiple times, in the case of multiple changes, the target service relationships corresponding to service cluster K are represented sequentially as: target service relationship L1, target service relationship L2, and target service relationship L3, according to the order of the changes from earliest to latest. When synchronizing target service relationships, the routing configuration node may receive at least one of target service relationships L1, L2, and L3. Which target service relationship to update to the global service relationship within the availability zone requires consensus between the routing configuration node and other routing configuration nodes within the same availability zone. The consensus-reached target service relationship is then updated to the global service relationship. Generally, consensus can be reached on the most recently changed target service relationship.

[0049] In this embodiment, a decentralized global service relationship update mechanism is provided. On the one hand, the routing configuration nodes in each availability zone synchronize the target service relationship that has changed between availability zones to achieve eventual consistency of the global service relationship in different availability zones, which can meet the disaster recovery requirements of cross-regional scenarios. On the other hand, when the routing configuration nodes in the availability zone reach a consensus on the target service relationship, the local global service relationship of the routing configuration nodes in the availability zone is updated to achieve consistency of the global service relationship in the availability zone. The decentralized design provides maximum availability assurance, eliminates the need to maintain global routing configuration nodes, and solves the single point of failure problem.

[0050] In one optional embodiment, the availability zone includes clients that need to access service components within the service cluster. Optionally, the client can be implemented as a compute node in a cloud service system, the service cluster as a storage cluster, and the service component as a storage component within the storage cluster. The compute node needs to access the storage component within the storage cluster. A storage component is a functional module responsible for persistent storage, retrieval, and management of data, ensuring that data can be securely stored and quickly accessed when needed.

[0051] When a client accesses service components within a service cluster, a two-hop routing mechanism can be used. The routing configuration node acts as the first hop for the client, and the routing service node acts as the second hop. The first and second hops work together to provide routing services for the service components within the service cluster to the client.

[0052] First hop: The client sends the identification information of the target service cluster to the routing configuration node. The routing configuration node queries the target routing service node that has a service relationship with the target service cluster from the global service relationship maintained locally.

[0053] Specifically, a client can send a service request to a routing configuration node in its availability zone. This request includes the identification information of the target service cluster. The identification information may include, but is not limited to, the service cluster name, identifier, cluster version, availability zone identification information, and geographical region identifier. The client can send the service request to any routing configuration node in the availability zone without restriction. For example, the cloud service system also includes load balancing nodes. The client can send a service request to a load balancing node, which can then select a routing configuration node with lower resource utilization based on the resource utilization of each routing configuration node in the availability zone and redirect the service request to that node.

[0054] The process involves a routing configuration node receiving service requests from clients within its own availability zone. Based on the target service cluster's identifier, it queries the local global service relationships for the access address information of target routing service nodes that have a service relationship with the target service cluster. If no access address information for a target routing service node with a service relationship is found, it indicates that the global service relationships maintained by the current routing configuration node do not include the service relationship corresponding to the target service cluster. The node then determines whether the target service cluster belongs to the availability zone to which it belongs. For example, if the target service cluster's identifier includes an availability zone identifier, and this identifier matches the identifier of any availability zone, the target service cluster belongs to any availability zone. If the identifier does not match the identifier of any availability zone, the target service cluster does not belong to any availability zone. If the target service cluster does not belong to any availability zone, the node queries the global service relationships maintained by routing configuration nodes in other availability zones for the access address information of the target routing service nodes. The retrieved access address information of the target routing service nodes is then returned to the client for second-hop routing. If the local query fails to find the access address information of the target routing service node, and the target service cluster does not belong to any availability zone, the system will query the routing configuration nodes in other availability zones. This mechanism ensures that even if some service relationships are missing in the current availability zone, the system can still find the correct service path, thereby enhancing the system's fault tolerance and high availability. Optionally, if the routing configuration node in the client's current availability zone fails, the client can send a service request to the routing configuration nodes in other availability zones, allowing the routing configuration nodes in those other availability zones to query the access address information of the target routing service node. This ensures that even if an availability zone fails or some routing service nodes are unavailable, the system can still find the correct service path, thereby enhancing the system's fault tolerance and high availability.

[0055] Optionally, the access address information of the target routing service node can be queried from the global service relationships maintained by routing configuration nodes in other availability zones. The implementation method for obtaining the access address information of the target routing service node is not limited. An example is provided below.

[0056] Example X1: When the target service cluster does not belong to any availability zone, the service request is sent to any routing configuration node in the target availability zone to which the target service cluster belongs. This allows the routing configuration node to query its local global service relationship for access address information related to the target routing service node (a node with a service relationship to the target service cluster). The client then receives this access address information and uses it to access the target routing service node. In cases where the service relationship to the target service cluster cannot be found locally, and the target service cluster is not in any availability zone, the necessary routing information can be obtained from other availability zones, making cross-regional service access simple and direct.

[0057] Optionally, the current routing configuration node can also reach a consensus with other routing configuration nodes in its availability zone regarding the service relationship of the target service cluster in order to update the local global service relationship.

[0058] Example X2: Each availability zone in this cloud service system also includes a management node. The management node 204 maintains local service relationships within its availability zone. These local service relationships specifically refer to the service relationships between the service cluster and at least some routing service nodes within the availability zone. When the target availability zone is the same as the routing configuration node's own availability zone, it means the management node maintains the service relationships for the target service cluster, but these relationships are not yet sent to the routing configuration nodes within the availability zone. The current routing configuration node can request the service relationships for the target service cluster from the management node, and the management node returns the service relationships. Upon receiving the service relationships from the management node, the current routing configuration node reaches a consensus with other routing configuration nodes within the availability zone regarding these service relationships to update the local global service relationships. Based on the updated global service relationships, it queries the access address information of the target routing service node and returns it to the client. Alternatively, after receiving the service relationships from the management node, the current routing configuration node can provide the access address information of the target routing service node within these service relationships to the client and reach a consensus with other routing configuration nodes within the availability zone regarding these service relationships to update the local global service relationships.

[0059] If the local query fails to find the access address information of the target routing service node, and the target service cluster belongs to any availability zone, then the management node is requested to configure the service relationship to ensure the fault tolerance and high availability of the service.

[0060] In the second hop, the client sends a routing request to the target routing service node based on its access address information. This request carries the logical address paths of the target service components within the target service cluster. The target routing service node maintains routing information for the target service cluster, specifically the mapping between the logical address paths and actual service addresses of at least some of the service components within the target service cluster.

[0061] The logical address path refers to a logical path used to identify the location of a service component. It typically consists of a series of directories or namespaces. For example, in a cloud storage system, a logical address path could be a file path within a file system. The actual service address refers to the physical location information, specifically pointing to the server or node where the service component is deployed. This usually includes specific information required for network communication, such as IP address or port number.

[0062] The target routing service node can query the actual service address corresponding to the logical address path carried in the routing request from the routing information maintained locally, and return the actual service address to the client. The client can then access the specific service component based on the actual service address.

[0063] like Figure 3 The example shown illustrates the addressing process for the first and second hops, but is not limited thereto.

[0064] In an optional embodiment, where each availability zone includes a management node 204, the management node may also send the local service relationships it maintains to the routing configuration nodes within the availability zone. The implementation method for the management node to send the local service relationships it maintains to the routing configuration nodes within the availability zone is not limited. For example, the management node may send the local service relationships it maintains to the routing configuration nodes within the availability zone at set intervals. These set intervals may include, but are not limited to, 1 minute, 10 minutes, 1 day, 1 month, or 6 months.

[0065] Furthermore, any routing configuration node in an availability zone can send local service relationships to other routing configuration nodes in other availability zones. Specifically, any routing configuration node can proactively send local service relationships to other routing configuration nodes, or, in response to a request from another routing configuration node, send the local service relationships to that other routing configuration node. Of course, other routing configuration nodes can also send other local service relationships they maintain to any routing configuration node. For example, other routing configuration nodes can proactively send other local service relationships to any routing configuration node, or, in response to a request from any routing configuration node, send other local service relationships to that routing configuration node.

[0066] Based on this, before any routing configuration node maintains the global service relationship, it can also: receive local service relationships sent by the management node within its own availability zone, and receive other local service relationships sent by the master nodes in other availability zones; and reach consensus with other routing configuration nodes within its own availability zone regarding the local and other local service relationships to obtain the global service relationship between the service clusters and routing service nodes in multiple availability zones. Synchronizing the local service relationships ensures the availability, persistence, and consistency of the global service relationship among all routing configuration nodes.

[0067] Optionally, when a new route configuration node is added to an availability zone, the new node can request a snapshot of the global service relationships from other route configuration nodes within the availability zone. These other nodes can then generate a snapshot of the current global service relationships, including all global service relationships, and provide this snapshot to the newly added node. The new node loads this snapshot to save the global service relationships locally, enabling it to provide services based on these relationships. Similarly, this snapshot can be applied in the event of a route configuration node restart. After restarting, the node obtains the snapshot and loads it locally, allowing it to provide services based on these global service relationships. By synchronizing global service relationships through snapshots, the availability, persistence, and consistency of the global service relationships across all route configuration nodes can be guaranteed.

[0068] In one optional embodiment, service relationships within an availability zone may be updated. In response to a service relationship change event, the management node can generate service relationship update information based on the changed target service relationship. This update information describes the changed target service relationship within the availability zone. The management node can send the service relationship update information to routing configuration nodes within the availability zone, allowing these nodes to update their local global service relationships. This updating of global service relationships by the routing configuration nodes primarily involves synchronizing with other routing configuration nodes in other availability zones regarding the target service relationship, and reaching consensus with other routing configuration nodes within their own availability zone regarding the target service relationship, thereby updating the global service relationships.

[0069] Optionally, the implementation method for the management node to generate service relationship update information based on the changed target service relationship in response to a service relationship change event is not limited. For example, the service relationship change event can be implemented as a service relationship change operation. The management node can provide a human-computer interaction page for management personnel, who can submit the changed target service relationship on this page to generate a service relationship change operation. Alternatively, management personnel can send the target service relationship to the management node via a terminal device to generate a service relationship change operation. In either case, the management node can respond to the service relationship change operation, obtain the changed target service relationship, and generate service relationship update information based on that target service relationship. As another example, the service relationship update event can be implemented as a system event or application event. For instance, if a routing service instance corresponding to a service cluster fails, the system will reallocate a new routing service instance to the service cluster, thereby generating a service relationship change event. In this case, the management node can respond to the service relationship change event and generate service relationship update information based on the changed target service relationship.

[0070] The implementation method for generating service relationship update information based on the changed target service relationship is not limited. For example, the service relationship update information includes at least the target service relationship. Furthermore, the service relationship update information also includes the identification information, timestamp, initiator, status information, legality verification information, and log information of the control node.

[0071] Optionally, the implementation method for synchronizing the target service relationship between the routing configuration node and other routing configuration nodes in other availability zones is not limited. For example, when the management node sends service relationship update information, the routing configuration node can receive the service relationship update information sent by the management node and broadcast the service relationship update information to the routing configuration nodes in other availability zones; as another example, when the routing configuration nodes in other availability zones broadcast service relationship update information externally, the routing configuration node can receive the service relationship update information broadcast by the master nodes in other availability zones to synchronize the target service relationship. Yet another example, when the management node sends service relationship update information and the routing configuration nodes in other availability zones broadcast service relationship update information externally, the routing configuration node can receive the service relationship update information sent by the management node and the service relationship update information broadcast by the master nodes in other availability zones.

[0072] Broadcasting offers advantages such as simplicity, scalability, high fault tolerance, and decentralization, accelerating the propagation of service relationship updates throughout the cloud service system. This allows service relationship updates to quickly reach all routing configuration nodes within the cloud service system. Broadcasting is a decentralized, highly available method, eliminating single points of failure. If the routing configuration nodes of each availability zone are organized into a directed connected graph, then for any two availability zones, as long as a connecting path exists between them (communication between the routing configuration nodes in the two availability zones), the connectivity between the two availability zones will not be affected, thus avoiding the single point of failure problem of global routing configuration nodes. For example, during the broadcasting of service relationship updates, broadcast protocols can be used to encapsulate the service relationship update information. Broadcast protocols can include, but are not limited to, gossip protocols, eventual consistency gossip protocols, or flooding protocols. The Gossip protocol features decentralization, eventual consistency, and distributed fault tolerance. When using Gossip, routing configuration nodes within each availability zone are peers, requiring no central node. Each routing configuration node communicates randomly with other routing configuration nodes. After a series of seemingly chaotic communications, the states of all routing configuration nodes eventually reach a global consistency in service relationships. Alternatively, target service relationships can also be synchronized between availability zones via point-to-point data protocols; this is not a limitation.

[0073] In one optional embodiment, the multiple routing configuration nodes in an availability zone include a master node and at least one slave node. The master node is the routing configuration node responsible for initiating consensus on the target service relationship within the availability zone, and the slave node is the routing configuration node that responds to the consensus. It should be noted that, in synchronizing the target service relationship, the master and slave nodes in any availability zone, as well as the master and slave nodes in other availability zones, can synchronize the target service relationship with each other. When the management node sends a partial service relationship, it can send the partial service relationship to the master node or to a slave node within the availability zone, and the slave node forwards the partial service relationship to the master node. Furthermore, when the management node sends service relationship update information, it can send the service relationship update information to the master node or to a slave node, and the slave node forwards the service relationship update information to the master node.

[0074] The implementation method for selecting a master node from multiple routing configuration nodes is not limited. For example, a routing configuration node can be randomly designated as the master node. Another example is selecting the routing configuration node with the most resources from among the multiple routing configuration nodes. Yet another example is selecting the routing configuration node with the smallest sum of distances to the other routing configuration nodes from among the multiple routing configuration nodes based on their geographical locations.

[0075] Optionally, the service relationship update information also includes: target version information of the target service relationship, which includes the identifier information of the target service cluster and the access address information of the target routing service instance. This version information can reflect the order of service relationship updates. Correspondingly, the global service relationship includes the service relationships corresponding to each service cluster, and each service cluster's service relationship has corresponding local version information. It is not that a global version information is maintained for the global service relationship, but rather that version information is configured for each service cluster's corresponding service relationship, managed and updated separately, providing a foundation for subsequent updates. When the routing configuration node is selected as the master node, based on the identifier information of the target service cluster in the target service relationship, the local service relationship to which the target service cluster belongs is obtained from the global service relationship, and the local version information is parsed from the local service relationship; if the target version information is greater than the local version information, consensus is reached with at least one slave node within the same availability zone regarding the target service relationship to update the global service relationship.

[0076] It should be noted that when the routing configuration node is implemented as a slave node, the slave node can provide the target service relationship to the master node, and the master node and at least one slave node can reach a consensus on the target service relationship.

[0077] Before reaching consensus with at least one subordinate node within the same availability zone on the target service relationship to update the global service relationship, a conditional update (Compare-And-Set, CAS) operation is used to determine whether the target service relationship meets the update conditions. For example, the CAS operation can be implemented by checking if the target version information is greater than the local version information. If the target version information is greater than the local version information, the target service relationship is considered to meet the update conditions. For changed target service relationships, updates are managed one by one based on the CAS operation, providing an overall guarantee of eventual consistency across all availability zone routing configuration nodes.

[0078] like Figure 5 As shown in the diagram, taking the global service relationship as an example, which includes three service relationships, the three service relationships are represented as follows: service cluster identification information P1 - routing service node access address information Q1 - version information R1; service cluster identification information P2 - routing service node access address information Q2 - version information S1; service cluster identification information P3 - routing service node access address information Q3 - version information T1; the service relationship update information includes: service cluster identification information P2 - routing service node access address information Q2 - version information S2; where version information S2 is greater than version information S1, then the service relationship corresponding to service cluster identification information P2 in the global service relationship is updated to: service cluster identification information P2 - routing service node access address information Q2 - version information S2.

[0079] Alternatively, if the target version information is less than the local version information, in cases where version rollback or reverting of global service relationships is required, the old version of the service relationship can be updated locally to achieve version rollback or reverting. If the target version information is equal to the local version information, it means that the service relationship already exists in the local service relationships and no update is needed.

[0080] In one optional embodiment, the implementation method of reaching consensus with at least one subordinate node within the availability zone regarding the target service relationship to update the global service relationship is not limited. A specific example is provided below: the target service relationship is sent to at least one subordinate node within the availability zone, which then returns consensus confirmation information; the received consensus confirmation information from subordinate nodes is counted, and if the number of consensus confirmation information exceeds a set threshold, it is determined that the master node and the at least one subordinate node have reached a consensus; based on the target service relationship, the local global service relationship is updated, and the at least one subordinate node is notified to update its local global service relationship according to the target service relationship. The set threshold is not limited. For example, the threshold could be 50%, 80%, or 95% of the total number of subordinate nodes. This consensus mechanism ensures the consistency, availability, and persistence of the global service relationship maintained by each routing configuration node within the availability zone.

[0081] The implementation method for sending the target service relationship to at least one slave node within the availability zone is not limited. An example is provided below, where at least one slave node can receive the target service relationship and verify the legitimacy of the master node. For instance, when a routing configuration node sends the target service relationship to at least one slave node within the availability zone, it specifically performs the following steps: packages the target service relationship and the master node's identification information into a target data packet, and sends the target data packet to at least one slave node within the availability zone. The implementation method for at least one slave node to return consensus confirmation information is not limited. An example is provided below, for instance, determining whether the identification information in the target data packet matches the identification information of the current master node; if they match, consensus confirmation information is returned to the master node. If the identification information in the target data packet does not match the identification information of the current master node, consensus confirmation information is not returned. Alternatively, consensus confirmation information cannot be returned if the slave node does not receive the target data packet, or if the slave node fails.

[0082] This can be achieved by combining a consensus protocol with a replicated state machine (RSM) to ensure state consistency among routing configuration nodes within the availability zone. In this embodiment, the state machine can be implemented as a global service relationship. The principle of the replicated state machine is that each slave node within the availability zone executes the same instructions as the master node, maintaining consistency with the global service relationship maintained by the master node. In this way, even if one or more routing configuration nodes fail, other nodes within the availability zone can continue to operate.

[0083] Consensus protocols address the issue of reaching agreement among routing configuration nodes within an availability zone. Especially in environments prone to failures (such as node downtime), consensus protocols ensure the consistency of global service relationships maintained by all non-failure nodes. For replicated state machines, consensus protocols determine the instructions applied to the state machine. Consensus protocols can include, but are not limited to, Paxos and Raft. Paxos is a classic consensus algorithm used in cloud service systems to solve consistency problems, ensuring that multiple routing configuration nodes can reach consensus on changed target service relationships even in the event of network partitions or node failures. Raft is a relatively easier-to-understand and implement consensus algorithm designed to simplify the complexity of Paxos, ensuring consistency and fault tolerance in cloud service systems through explicit master nodes, log replication, and security.

[0084] For example, when the master node reaches consensus on a target service relationship, it generates a log entry for that target service relationship using a consensus protocol and adds it to its local log sequence. This log entry includes a log index number, the master node's term number, and the target service relationship. The master node then sends this log entry to the slave nodes in the availability zone. The slave nodes verify the received log entry, for example, by checking if the term number is up-to-date. If the term number is up-to-date, it indicates that the node sending the log entry is the master node, so the master node adds the log entry to its local log sequence and returns consensus confirmation information to the master node. If the term number is not up-to-date, it assumes that the node sending the log entry is not the master node and discards the log entry. The master node counts the consensus confirmation information returned by the slave nodes. If the number of consensus confirmation messages exceeds a set threshold (e.g., half the total number of slave nodes), it determines that the master node and at least one slave node have reached a consensus and marks the log entry as consensus-reached. When a log entry is marked as having reached consensus, the master and slave nodes in the availability zone execute the log entries in the log sequence, that is, update the local global service relationship according to the target service relationship, and return a notification message of successful update to the master node if the update is successful.

[0085] like Figure 4 As shown in the diagram, taking an implementation of at least one slave node as three slave nodes as an example, the steps are as follows: (1) The master node sends the target service relationship to the consensus module in the slave node; (2) The consensus module returns consensus confirmation information to the master node; (3) The consensus module adds the target service relationship to the log queue, for example, the target service relationship is implemented as service relationship M3; (4) The master node sends a confirmation to the consensus module that consensus has been reached on service relationship M3; (5) The service relationship M3 is updated in the global service relationship. The global service relationship includes service relationship M1 and service relationship M2.

[0086] In addition to providing cloud service system embodiments, this application also provides an information update method. The process of the information update method provided in this application embodiment will be described below.

[0087] Figure 6 A flowchart illustrating an exemplary embodiment of this application provides an information update method applicable to routing configuration nodes in any availability zone of a cloud service system. The cloud service system includes multiple availability zones, each deploying at least one service cluster, multiple routing configuration nodes, and at least one routing service node. The method includes:

[0088] 601. Maintain the global service relationship between service clusters and routing service nodes in multiple availability zones. At least some routing information in the service cluster is maintained by the routing service nodes that have a service relationship with the service cluster. The routing information is used by the routing service nodes to provide routing services to the outside world.

[0089] 602. Synchronize with other routing configuration nodes in other availability zones for the target service relationship, where the target service relationship is the service relationship that changes within the availability zone where any routing configuration node is located, and other availability zones are the availability zones other than the routing configuration nodes among the plurality of availability zones;

[0090] 603. Reach consensus with other routing configuration nodes within any availability zone regarding the target service relationship to update the global service relationship maintained by the routing configuration nodes.

[0091] In an optional embodiment, the method provided in this application further includes: receiving a service request sent by a client within its availability zone, the service request including the identification information of a target service cluster; based on the identification information of the target service cluster, querying the access address information of a target routing service node that has a service relationship with the target service cluster in the local global service relationship; if the access address information of the target routing service node is not found, and the target service cluster does not belong to any availability zone, then querying the access address information of the target routing service node from the global service relationship maintained by the routing configuration nodes in other availability zones; and returning the queried access address information of the target routing service node to the client, so that the client can access the target routing service node and access the service components in the target service cluster based on the routing information in the target service cluster maintained by the target routing service node.

[0092] Optionally, querying the access address information of the target routing service node from the global service relationships maintained by routing configuration nodes in other availability zones includes: sending the service request to any routing configuration node in the target availability zone to which the target service cluster belongs, so that any routing configuration node can query the access address information of the target routing service node in its local global service relationships and return it, wherein the target routing service node is a routing service node that has a service relationship with the target service cluster; receiving the access address information and providing it to the client.

[0093] Optionally, the method further includes: if the target service cluster belongs to any availability zone, requesting the service relationship of the target service cluster from the management node in any availability zone, so that the management node can return the service relationship; receiving the service relationship returned by the management node, reaching a consensus with other routing configuration nodes in its availability zone on the service relationship, so as to update the global service relationship; and querying the access address information of the target routing service nodes that have a service relationship with the target service cluster in the updated global service relationship based on the identification information of the target service cluster.

[0094] In an optional embodiment, the method further includes: receiving local service relationships sent by a management node in any availability zone, and receiving other local service relationships sent by master nodes in other availability zones; reaching consensus with other routing configuration nodes in the availability zone regarding the local service relationships and other local service relationships, so as to obtain the global service relationships between service clusters and routing service nodes in multiple availability zones.

[0095] In one optional embodiment, synchronizing with other routing configuration nodes in other availability zones for the target service relationship includes: receiving service relationship update information sent by a management node in any availability zone, broadcasting service relationship update information to other availability zones for synchronization of the target service relationship; the service relationship update information describes the changed target service relationship; and / or receiving service relationship update information broadcast by other routing configuration nodes in other availability zones for synchronization of the target service relationship.

[0096] Optionally, the multiple routing configuration nodes include a master node and at least one slave node; the service relationship update information includes: the target service relationship and its target version information; consensus is reached with other routing configuration nodes in the same availability zone regarding the target service relationship to update the global service relationship, including: when selected as the master node, obtaining the local service relationship to which the target service cluster belongs from the global service relationship based on the identifier information of the target service cluster in the target service relationship, and parsing the local version information from the local service relationship; if the target version information is greater than the local version information, consensus is reached with at least one slave node in the same availability zone regarding the target service relationship to update the global service relationship.

[0097] Optionally, consensus is reached with at least one slave node within the availability zone regarding the target service relationship to update the global service relationship. This includes: sending the target service relationship to at least one slave node within the availability zone, so that at least one slave node can return consensus confirmation information; counting the consensus confirmation information returned by the slave nodes, and if the number of consensus confirmation information exceeds a set threshold, then it is determined that the master node and at least one slave node have reached a consensus; updating the local global service relationship according to the target service relationship, and notifying at least one slave node to update its local global service relationship according to the target service relationship.

[0098] Regarding the embodiments provided in this application Figure 6 The detailed implementation methods and beneficial effects of each step in the method shown have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0099] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 601 to 603 can be device A; or the execution subject of steps 601 and 602 can be device A, and the execution subject of step 603 can be device B; and so on.

[0100] Furthermore, in some of the processes described in the above embodiments and accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 601, 602, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0101] Figure 7 A schematic diagram of an information update device provided as an exemplary embodiment of this application is applicable to a routing configuration node in any availability zone of a cloud service system. The cloud service system includes multiple availability zones, and at least one service cluster, multiple routing configuration nodes, and at least one routing service node are deployed in each availability zone. Figure 7 As shown, the device includes: a maintenance module 71, a synchronization module 72, and a consensus module 73.

[0102] The maintenance module 71 is used to maintain the global service relationship between service clusters and routing service nodes in multiple availability zones. The routing service node maintains at least some routing information of the service clusters with which it has a service relationship and provides routing services to the outside world based on the routing information.

[0103] Synchronization module 72 is used to synchronize with other routing configuration nodes in other availability zones for a target service relationship, where the target service relationship is the service relationship that has changed within the availability zone of any routing configuration node; and

[0104] Consensus module 73 is used to reach a consensus with other routing configuration nodes in the same availability zone on the target service relationship, so as to update the global service relationship maintained by the routing configuration nodes.

[0105] In an optional embodiment, the apparatus further includes a receiving module, a querying module, and a returning module. The receiving module receives service requests sent by clients within its own availability zone, the service requests including the identification information of the target service cluster. The querying module queries the access address information of target routing service nodes that have a service relationship with the target service cluster in the local global service relationship based on the identification information of the target service cluster. If the querying module does not find the access address information of the target routing service node and the target service cluster does not belong to any availability zone, it queries the access address information of the target routing service node from the global service relationship maintained by routing configuration nodes in other availability zones. The returning module returns the queried access address information of the target routing service node to the client, so that the client can access the target routing service node and, based on the routing information in the target service cluster maintained by the target routing service node, access the service components in the target service cluster.

[0106] Optionally, the query module is specifically used to: send the service request to any routing configuration node in the target availability zone to which the target service cluster belongs, so that any routing configuration node can query the access address information of the target routing service node that has a service relationship with the target service cluster in its local global service relationship, and return it; receive the access address information and provide it to the client.

[0107] Optionally, the device further includes an application module. The application module is used to apply for a service relationship of the target service cluster from a management node in any availability zone if the target service cluster belongs to any availability zone, so that the management node can return the service relationship; a receiving module is used to receive the service relationship returned by the management node, and to reach a consensus with other routing configuration nodes in its own availability zone regarding the service relationship, so as to update the global service relationship; a query module is used to query the access address information of the target routing service nodes that have a service relationship with the target service cluster in the updated global service relationship based on the identification information of the target service cluster.

[0108] In an optional embodiment, the receiving module is configured to receive local service relationships sent by the management node in any availability zone, and to receive other local service relationships sent by the master node in other availability zones; the consensus module is further configured to: reach consensus with other routing configuration nodes in the availability zone regarding the local service relationships and other local service relationships, so as to obtain the global service relationships between the service clusters and routing service nodes in multiple availability zones.

[0109] In an optional embodiment, the synchronization module is specifically configured to: receive service relationship update information sent by the management node in any availability zone, broadcast service relationship update information to other availability zones, and synchronize the target service relationship; the service relationship update information describes the changed target service relationship; and / or receive service relationship update information broadcast by other routing configuration nodes in other availability zones, and synchronize the target service relationship.

[0110] Optionally, the multiple routing configuration nodes include a master node and at least one slave node; the service relationship update information includes: the target service relationship and its target version information; the consensus module is specifically used to: when selected as the master node, obtain the local service relationship to which the target service cluster belongs from the global service relationship based on the identification information of the target service cluster in the target service relationship, and parse the local version information from the local service relationship; if the target version information is greater than the local version information, then reach a consensus with at least one slave node in the availability zone to update the global service relationship.

[0111] Optionally, the consensus module is specifically used to: send the target service relationship to at least one slave node in the availability zone, so that at least one slave node can return consensus confirmation information; count the consensus confirmation information returned by the slave nodes, and if the number of consensus confirmation information exceeds a set threshold, determine that the master node and at least one slave node have reached a consensus; update the local global service relationship according to the target service relationship, and notify at least one slave node to update its local global service relationship according to the target service relationship.

[0112] Regarding the embodiments provided in this application Figure 7 The detailed implementation methods and beneficial effects of each step in the apparatus shown have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0113] Figure 8 A schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application corresponds to a routing configuration node in any availability zone of a cloud service system. The cloud service system includes multiple availability zones, and each availability zone deploys at least one service cluster, multiple routing configuration nodes, and at least one routing service node. Figure 8As shown, the device includes a memory 84 and a processor 85.

[0114] Memory 84 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device.

[0115] The processor 85, coupled to the memory 84, is used to execute the computer program in the memory 84 for: executing the information update method described in the foregoing embodiments, for details of which will not be repeated here.

[0116] Regarding the embodiments provided in this application Figure 8 The detailed implementation methods and beneficial effects of each step in the device shown have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0117] Furthermore, such as Figure 8 As shown, the electronic device also includes other components such as a communication component 86, a display 87, a power supply component 88, and an audio component 89. Figure 8 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 8 The components shown. Additionally... Figure 8 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the product form of the electronic device. The electronic device in this embodiment can be a desktop computer, laptop computer, smartphone, IoT (Internet of Things) device, or smart wearable device (such as a smartwatch or smart bracelet), or a server-side device such as a conventional server, cloud server, or server array. If the electronic device in this embodiment is a desktop computer, laptop computer, smartphone, or other terminal device, it may include... Figure 8 The components within the dashed box; if the electronic device in this embodiment is implemented as a conventional server, cloud server, or server array, etc., it may be omitted. Figure 8 The component within the dashed box.

[0118] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, can implement the steps that can be performed by an electronic device in the above-described information update method embodiments.

[0119] Accordingly, this application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, causes the processor to perform the steps that can be executed by an electronic device in the above-described information update method embodiments.

[0120] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0121] The aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices. The device containing the communication components can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.

[0122] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0123] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0124] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0125] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0126] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0127] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0128] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0129] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

[0130] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0131] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0132] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0133] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A cloud service system, characterized in that, include: Multiple availability zones; The availability zone is equipped with at least one service cluster, multiple routing configuration nodes, and at least one routing service node. The routing service node has a service relationship with at least some of the service clusters within its availability zone; The routing service node is used to maintain at least a portion of the routing information in the service cluster with which it has the service relationship, and to provide routing services to the outside world based on the routing information; The routing configuration node is used to maintain the global service relationship between the service clusters and routing service nodes in the multiple availability zones, and to synchronize with other routing configuration nodes in other availability zones for the target service relationship. The other availability zones are the availability zones other than the routing configuration node among the multiple availability zones. as well as The routing configuration node reaches a consensus with other routing configuration nodes in the availability zone to update the global service relationship; wherein, the target service relationship is a service relationship that has changed within the availability zone of any routing configuration node.

2. The system according to claim 1, characterized in that, The availability zone also includes: a management node, used to maintain the local service relationship between the service cluster and the routing service node within its availability zone; and to send the local service relationship to the routing configuration node within the availability zone; The routing configuration node is also used to: receive local service relationships sent by the management node in its own availability zone, and receive other local service relationships sent by other routing configuration nodes in other availability zones; and reach consensus with other routing configuration nodes in its own availability zone on the local service relationships and the other local service relationships to obtain the global service relationships between the service clusters and the routing service nodes in the multiple availability zones.

3. An information updating method, characterized in that, The method is applicable to routing configuration nodes in any availability zone of a cloud service system, wherein the cloud service system includes multiple availability zones, and each availability zone deploys at least one service cluster, multiple routing configuration nodes, and at least one routing service node; the method includes: Maintain the global service relationship between the service clusters and routing service nodes of the multiple availability zones, wherein at least some routing information in the service cluster is maintained by the routing service nodes that have a service relationship with the service cluster, and the routing information is used for the routing service nodes to provide routing services to the outside world; Synchronize with other routing configuration nodes in other availability zones for a target service relationship, where the target service relationship is a service relationship that changes within the availability zone where any routing configuration node is located, and the other availability zones are availability zones other than the routing configuration node among the plurality of availability zones; and Consensus is reached with other routing configuration nodes within any of the availability zones regarding the target service relationship, in order to update the global service relationship maintained by the routing configuration nodes.

4. The method according to claim 3, characterized in that, Also includes: Receive service requests sent by clients within any of the availability zones, the service requests including the identification information of the target service cluster; Based on the identification information of the target service cluster, query the access address information of the target routing service node that has a service relationship with the target service cluster in the local global service relationship; If the access address information of the target routing service node is not found, and the target service cluster does not belong to any of the availability zones, then the access address information of the target routing service node is queried from the global service relationship maintained by the routing configuration nodes in other availability zones. The access address information of the target routing service node obtained from the query is returned to the client so that the client can access the target routing service node and access the service components in the target service cluster based on the routing information in the target service cluster maintained by the target routing service node.

5. The method according to claim 4, characterized in that, The access address information of the target routing service node is queried from the global service relationships maintained by the routing configuration nodes in other availability zones, including: The service request is sent to any routing configuration node in the target availability zone to which the target service cluster belongs, so that the routing configuration node can query the access address information of the target routing service node in its local global service relationship and return it. The target routing service node is a routing service node that has a service relationship with the target service cluster. The access address information is received and provided to the client.

6. The method according to claim 4, characterized in that, Also includes: If the target service cluster belongs to any of the availability zones, then request the service relationship of the target service cluster from the management node in any of the availability zones, so that the management node can return the service relationship; The system receives the service relationship returned by the management node and reaches a consensus with other routing configuration nodes in its availability zone regarding the service relationship in order to update the global service relationship. Based on the identification information of the target service cluster, query the access address information of the target routing service node that has a service relationship with the target service cluster in the updated global service relationship.

7. The method according to claim 3, characterized in that, Also includes: Receive local service relationships sent by the control node in any of the availability zones, and receive other local service relationships sent by the master nodes in other availability zones; The system reaches a consensus with other routing configuration nodes within the same availability zone regarding the local service relationship and the other local service relationship, in order to obtain the global service relationship between the service clusters and routing service nodes within the multiple availability zones.

8. The method according to claim 3, characterized in that, Synchronize with other routing configuration nodes in other availability zones for the target service relationship, including: The system receives service relationship update information sent by the management node in any of the availability zones and broadcasts the service relationship update information to the other availability zones to synchronize the target service relationship; the service relationship update information is used to describe the changed target service relationship. And / or, Receive service relationship update information broadcast by other routing configuration nodes in other availability zones to synchronize the target service relationship.

9. The method according to claim 8, characterized in that, The plurality of routing configuration nodes includes a master node and at least one slave node; The service relationship update information includes: the target service relationship and its target version information; and reaching consensus with other routing configuration nodes within the same availability zone regarding the target service relationship to update the global service relationship, including: When selected as the master node, the local service relationship to which the target service cluster belongs is obtained from the global service relationship based on the identifier information of the target service cluster in the target service relationship, and the local version information is parsed from the local service relationship. If the target version information is greater than the local version information, consensus is reached with at least one slave node in the availability zone regarding the target service relationship in order to update the global service relationship.

10. The method according to claim 9, characterized in that, Reaching consensus with at least one slave node within the same availability zone regarding the target service relationship to update the global service relationship includes: The target service relationship is sent to at least one slave node within the availability zone, so that the at least one slave node can return consensus confirmation information; The consensus confirmation information returned by the subordinate nodes is counted. If the number of consensus confirmation information exceeds a set threshold, it is determined that the master node and the at least one subordinate node have reached a consensus. Based on the target service relationship, update the local global service relationship and notify the at least one subordinate node to update its local global service relationship based on the target service relationship.

11. An electronic device, characterized in that, include: Memory and processor; The memory is used to store a computer program; the processor, coupled to the memory, is used to execute the computer program to implement the steps of the method according to any one of claims 3-10.

12. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of the method according to any one of claims 3-10.

13. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, the processor is caused to perform the steps of the method according to any one of claims 3-10.

Images