A communication state diagnosis method, a communication method, and related devices

Abstract

Embodiments of the present application relate to a communication state diagnosis method, applied to a cloud management platform, the method comprising: obtaining at least one communication index of a first service node in a plurality of service nodes, the communication index being used to indicate a communication condition between a second service node and the first service node, at least one second service node being a service node associated with the first service node in the plurality of service nodes; determining a number of target service nodes in the at least one second service node based on the at least one communication index, the target service nodes corresponding to the communication index satisfying a first set condition; determining a communication state of the first service node based on the number of target service nodes; and if the first service node is determined to be in a sub-healthy state, instructing a registration center to delete the first service node from a service list. Thus, the service node in the sub-healthy state is isolated in time to prevent the service node in the sub-healthy state from being continuously called.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a method for diagnosing communication status, a communication method, and related equipment. Background Technology

[0002] Microservice architecture is a software architecture that distributes business functions across various service nodes to decouple business implementation. Each service node's microservice runs in its own independent process, and the service nodes can interact with each other through lightweight communication protocols. Because microservices are deployed independently, the failure of one microservice node will not affect the normal operation of other microservice nodes.

[0003] Currently, service nodes send heartbeat packets to the registry center at set intervals. The registry center determines whether a service node is faulty by checking whether it receives a heartbeat packet from the client within the timeout period. If the registry center does not receive a heartbeat packet from the service node within the timeout period, it determines that the service node's communication status is faulty. The registry center then deletes the session of the faulty service node to prevent other service nodes from calling the services of the faulty service node through the registry center.

[0004] However, network sub-health typically doesn't immediately lead to service interruption, but rather manifests as decreased communication performance and prolonged response times. In heartbeat mechanisms, the timeout period is fixed. It's possible that a service node, while not completely faulty, can still send heartbeats within the timeout period, but its actual communication performance has already deteriorated and it can no longer process business requests in a timely manner, causing the registry to believe the service node is still in a normal state. Alternatively, a fault might be determined only if a heartbeat hasn't been received by the timeout period, and the service might still be invoked before the timeout expires. This significantly extends the fault response time, thus impacting the efficiency of processing business requests.

[0005] Therefore, how to monitor the communication status of service nodes more flexibly and respond in a timely manner has become an urgent problem to be solved. Summary of the Invention

[0006] This application provides a communication status diagnosis method, a communication method, and related equipment for diagnosing the communication status of microservice nodes in a microservice architecture, determining whether a service node is in a healthy or sub-healthy state, and thus promptly isolating service nodes in a sub-healthy state to prevent them from being continuously invoked. This improves fault response time and reduces operation and maintenance costs and complexity.

[0007] Firstly, this application provides a method for diagnosing communication status. This method is applied to a cloud management platform, which manages infrastructure including multiple service nodes, each running one or more user-defined services. The method includes:

[0008] At least one communication indicator of a first service node among multiple service nodes is obtained. This at least one communication indicator represents the communication status between at least one second service node and the first service node. The at least one second service node is a service node among the multiple service nodes that is associated with the first service node. Based on the at least one communication indicator, the number of target service nodes among the at least one second service node is determined. The communication indicator between the target service node and the first service node satisfies a first predetermined condition. Here, at least one second service node can also be understood as all service nodes among the multiple service nodes that are communicatively connected to the first service node.

[0009] Then, based on the number of target service nodes, the communication status of the first service node is determined. If the communication status of the first service node is determined to be sub-optimal, a first instruction message is sent to the registry center, which instructs the registry center to remove the first service node from the service list.

[0010] In this application, since a service node can run one or more services, different service nodes can collaborate to run the same service. That is, in the network topology of the infrastructure, the various service nodes are interconnected. Therefore, the cloud management platform obtains communication metrics between a service node (such as a first service node) and other service nodes (such as at least one second service node connected to the first service node). By using an overall communication metric view of the service node cluster, the communication status of the service nodes is determined, thereby improving the flexibility of monitoring the sub-health status of network communication between service nodes. Furthermore, based on the communication status between service nodes, and by determining the number of target service nodes that meet the first set condition for the communication metrics, it is possible to further determine whether the first service node is in a sub-healthy state or other service nodes are malfunctioning, thereby improving the accuracy of monitoring the sub-healthy state of network communication between service nodes.

[0011] In one possible implementation, determining the communication status of the first service node based on the number of target service nodes includes: if the number of target service nodes meets a second preset condition, determining the communication status of the first service node as sub-healthy; or, if the number of target service nodes does not meet the second preset condition, determining the communication status of the first service node as healthy. The second preset condition includes that the ratio of the number of target service nodes to the number of at least one second service node is greater than a health threshold.

[0012] In this implementation, after determining the number of target service nodes whose communication indicators meet the first preset conditions for the first service node and at least one second service node associated with the first service node, the communication status of the first service node can be determined based on the number of target service nodes. When the ratio of the number of target service nodes to the number of at least one second service node is greater than a health threshold, the first service node is determined to be in a sub-healthy state. Further determination can be made as to whether the first service node is in a sub-healthy state or whether other target service nodes have malfunctioned, thereby improving the accuracy of sub-healthy state monitoring of network communication between service nodes.

[0013] In one possible implementation, the communication metric includes a packet loss rate, determined based on the number of packets sent by the first service node to the second service node and the number of packets received by the first service node in response to the second service node. A first predefined condition includes a packet loss rate greater than a first predefined threshold.

[0014] In this implementation, the packet loss rate effectively reflects the communication status between the first and second service nodes. Generally, a higher packet loss rate indicates worse communication. In other words, when the packet loss rate between the second and first service nodes exceeds a first preset threshold, the second service node is considered the target service node.

[0015] In one possible implementation, the communication metric includes network latency, which is determined based on the timestamps of the first service node sending data packets to the second service node and the timestamps of the data packets received by the first service node in response to the second service node. A first predefined condition includes network latency exceeding a second predefined threshold.

[0016] In this implementation, network latency effectively reflects the communication status between the first and second service nodes. Generally, higher network latency indicates poorer communication. In other words, when the network latency between the second and first service nodes exceeds a second preset threshold, the second service node is considered the target service node.

[0017] In one possible implementation, after sending the first instruction information to the registry center, the method further includes: if the communication status of the first service node is determined to be healthy, sending a second instruction information to the registry center, the second instruction information being used to instruct the registry center to add the first service node to the service list.

[0018] In this implementation, after sending the first instruction message to the registry center, the registry center removes the first service node from the service list. However, the communication status of the first service node is not static. When the cloud management platform detects a change in the communication status of the first service node—that is, when the communication status of the first service node is reassessed as healthy—it can send a second instruction message to the registry center to inform it that the communication status of the first service node is healthy, instructing the registry center to add the first service node's information back to the service list. This allows for timely rejoining of the restored service node to the cluster, resuming normal service provision and ensuring the stability of its self-healing capabilities.

[0019] In one possible implementation, after determining that the communication status of the first service node is in a sub-healthy state, sending the first indication information to the registration center further includes: if the ratio of the number of first service nodes deployed in the same availability zone and in a sub-healthy state to the number of all service nodes deployed in the same availability zone is less than a first alarm threshold, then sending the first indication information to the registration center.

[0020] In this implementation, the first service node is one of multiple service nodes. The cloud management platform determines the communication status of each of these service nodes to identify the number of first service nodes in a sub-healthy state. That is, within the network topology of the service node cluster, the fault scope of the first service node in a sub-healthy state can be further determined; for example, the fault scope may be at the availability zone level or lower.

[0021] In one possible implementation, if the ratio of the number of first service nodes deployed in the same availability zone and in a sub-healthy state to the total number of all service nodes deployed in the same availability zone is greater than a first alarm threshold, an alarm message is output.

[0022] In this implementation, when the fault scope reaches the availability zone level—that is, when the ratio of the number of first service nodes deployed in the same availability zone and in a sub-healthy state to the total number of service nodes deployed in the same availability zone exceeds the first alarm threshold—the fault scope is too large. Considering the overall stability of the cluster, only alarm information is issued, and manual intervention is required.

[0023] Secondly, embodiments of this application provide a communication method applied to service nodes, where the infrastructure includes multiple service nodes. The method includes: a first service node among the multiple service nodes sending a probe request to at least one second service node, wherein the at least one second service node is a service node associated with the first service node among the multiple service nodes. The first service node receives response information sent from the at least one second service node, the response information being determined based on the probe request. Based on the response message, the first service node determines at least one communication indicator, the communication indicator representing the communication status between the at least one second service node and the first service node. The first service node reports the at least one communication indicator to a cloud management platform.

[0024] In this application, multiple service nodes communicate with each other, and communication metrics are used to represent the communication status between at least one second service node and the first service node. That is, the communication metrics between the first service node and the second service node can be determined by probing request and response information.

[0025] Thirdly, embodiments of this application provide a cloud management platform for managing infrastructure, which includes multiple service nodes. The cloud management platform includes:

[0026] The acquisition unit is used to acquire communication information of a first service node among multiple service nodes. The communication information includes at least one communication indicator corresponding to at least one second service node. The communication indicator is used to indicate the communication status between the second service node and the first service node. The at least one second service node is a service node associated with the first service node among multiple service nodes.

[0027] The processing unit is configured to determine the number of target service nodes among at least one second service node based on at least one communication indicator, wherein the communication indicators corresponding to the target service nodes and the first service node satisfy a first set condition.

[0028] The processing unit is also used to determine the communication status of the first service node based on the number of target service nodes;

[0029] The sending unit is configured to send a first instruction message to the registration center when the communication status of the first service node is determined to be in a sub-healthy state. The first instruction message is used to instruct the registration center to delete the first service node from the service list.

[0030] In one possible implementation, the processing unit is further configured to: determine the communication status of the first service node as sub-healthy if the number of target service nodes meets a second preset condition; or, determine the communication status of the first service node as healthy if the number of target service nodes does not meet the second preset condition. The second preset condition includes that the ratio of the number of target service nodes to the number of at least one second service node is greater than a health threshold.

[0031] In one possible implementation, the communication metric includes a packet loss rate, determined based on the number of packets sent by the first service node to the second service node and the number of packets received by the first service node in response to the second service node. A first predefined condition includes a packet loss rate greater than a first predefined threshold.

[0032] In one possible implementation, the communication metric includes network latency, which is determined based on the timestamps of the first service node sending data packets to the second service node and the timestamps of the data packets received by the first service node in response to the second service node. A first predefined condition includes network latency exceeding a second predefined threshold.

[0033] In one possible implementation, the sending unit is further configured to: send a second instruction message to the registration center when the communication status of the first service node is determined to be healthy, the second instruction message being used to instruct the registration center to add the first service node to the service list.

[0034] In one possible implementation, the sending unit is further configured to: send a first indication message to the registration center if the ratio of the number of first service nodes deployed in the same availability zone and in a sub-healthy state to the total number of service nodes deployed in the same availability zone is less than a first alarm threshold.

[0035] In one possible implementation, the sending unit is further configured to: output alarm information if the ratio of the number of first service nodes deployed in the same availability zone and in a sub-healthy state to the total number of all service nodes deployed in the same availability zone is greater than a first alarm threshold.

[0036] Fourthly, embodiments of this application provide a service node, the infrastructure of which includes multiple service nodes, the service nodes including:

[0037] The transceiver unit is used to send a probe request to at least one second service node, wherein the at least one second service node is a service node associated with the service node among a plurality of service nodes;

[0038] The transceiver unit is also used to receive response information sent from at least one second service node, the response information being determined based on the probe request;

[0039] The processing unit is used to determine at least one communication indicator based on the response message, the communication indicator being used to represent the communication status between at least one second service node and the service node;

[0040] The transceiver unit is also used to report at least one communication metric to the cloud management platform.

[0041] Fifthly, this application provides a computing device including a processor and a memory. The processor of the computing device is used to execute instructions stored in the memory, causing the computing device to implement the method shown in the first aspect or any possible implementation of the first aspect.

[0042] Sixthly, this application provides a computing device including a processor and a memory. The processor of the computing device is used to execute instructions stored in the memory, causing the computing device to implement the methods shown in the second aspect above, or any possible implementation of the second aspect.

[0043] In a seventh aspect, this application provides a computing device cluster, including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, such that the computing device cluster implements the method disclosed in any possible implementation of the first or second aspect.

[0044] Eighthly, this application provides a computer program product containing instructions that, when executed on a processor, implement the method shown in the first aspect or any possible implementation of the first aspect; or, when the instructions are run by a cluster of computer devices, cause the cluster of computer devices to implement the method disclosed in any possible implementation of the first or second aspect.

[0045] Ninthly, this application provides a computer-readable storage medium storing computer program instructions that, when executed on a processor, implement the method shown in the first aspect or any possible implementation of the first aspect; or, when executed by a cluster of computer devices, cause the cluster of computer devices to implement the method disclosed in any possible implementation of the first or second aspect.

[0046] The beneficial effects shown in any of the second to ninth aspects are similar to those of the first aspect or any possible implementation of the first aspect, and will not be repeated here. Attached Figure Description

[0047] Figure 1 The system architecture diagram provided for this application;

[0048] Figure 2 Another schematic diagram of the system architecture for the communication status diagnosis method provided in this application;

[0049] Figure 3 A flowchart illustrating a communication status diagnosis method provided in an embodiment of this application;

[0050] Figure 4 A schematic diagram of a communication indicator in the communication status diagnosis method provided in the embodiments of this application;

[0051] Figure 5 Another flowchart illustrating the communication status diagnosis method provided in this application embodiment;

[0052] Figure 6 A schematic diagram of the structure of a cloud management platform provided in an embodiment of this application;

[0053] Figure 7 A schematic diagram of the structure of a service node provided in an embodiment of this application;

[0054] Figure 8 Another schematic diagram of the cloud management platform provided in the embodiments of this application;

[0055] Figure 9 This is a schematic diagram of a computing device cluster provided in an embodiment of this application;

[0056] Figure 10 This is a schematic diagram illustrating the connection method between computing device clusters provided in an embodiment of this application. Detailed Implementation

[0057] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such terms are interchangeable where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0058] It should be understood that, in addition, the character " / " in this document generally indicates that the preceding and following objects are in an "or" relationship. The phrase "at least one of the following" or similar expressions in this document are used to indicate any combination of the listed items; for example, at least one of A, B, and / or C can represent the following six situations: A exists alone, B exists alone, C exists alone, A and B exist simultaneously, B and C exist simultaneously, A and C exist simultaneously, and A, B, and C exist simultaneously, where A, B, and C can be single or multiple. In the embodiments of this application, "instruction" can mean control, that is, one object controls another object to perform an action, and the controlled object must perform the action. Furthermore, "instruction" can also mean notification, that is, one object informs another object to perform an action, and the object informed to perform the action can choose to perform the action or not. In addition, "instruction" can be a direct instruction, such as one object directly issuing the instruction to another object; or it can be an indirect instruction, that is, one object issuing the instruction to another object through one or more intermediate objects. Furthermore, the meaning of "instruction" can also be interpreted based on the meaning expressed in the embodiments of this application, and is not limited here. The term "one or more" in the embodiments of this application can be understood as one or more, and vice versa. "One or more" can also mean "at least one".

[0059] First, please refer to Figure 1 , Figure 1 This is a schematic diagram of the system architecture provided for an embodiment of this application.

[0060] like Figure 1 As shown, the tenant logs into the cloud management platform 30 via the Internet 20 through client 10 running on a terminal device. The cloud management platform can also be called a cloud platform, cloud service platform, etc. Furthermore, client 10 logs into the cloud management platform 30 using an account and password registered with that account, and uses the cloud services associated with that account. The cloud platform 30 is used to manage infrastructure, which includes multiple data centers located in different communication regions, such as... Figure 1 Region 1, as shown, includes Cloud Data Center 1 and Cloud Data Center 2, while Region 2 includes Cloud Data Center 3 and Cloud Data Center 4. Each cloud data center has multiple servers, each running service instances (including at least one of virtual machines, containers, or dedicated hosts). Each server can also be understood as a service node.

[0061] In some optional implementations, the infrastructure managed by the cloud management platform 30 also includes edge infrastructure, which includes edge computing nodes, edge devices, etc. Edge infrastructure provides edge computing technology, offering edge intelligent services at the network edge close to the source of objects or data, utilizing a platform integrating network, computing, storage, and application capabilities. Edge infrastructure can also be understood as an extension of the cloud platform at the edge.

[0062] In this embodiment, multiple service nodes are deployed in the infrastructure to provide one or more services. For the cloud data center infrastructure, tenants purchase cloud services through client 10 on cloud management platform 30. Cloud management platform 30 determines the health status of service nodes by obtaining at least one communication indicator of each service node, so as to provide tenants with a better user experience when using cloud services and ensure high availability of services.

[0063] This application provides a communication status diagnosis method applied to a cloud management platform. It diagnoses the communication status of microservice nodes in a microservice architecture, determining whether a service node is in a healthy or sub-healthy state. This allows for timely isolation of sub-healthy service nodes to prevent them from being continuously invoked. This application also provides corresponding computing device clusters, computer-readable storage media, etc. To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0064] First, we will explain some concepts involved in the communication status diagnosis method, communication method, and related equipment provided in the embodiments of this application.

[0065] 1. Service Node

[0066] In this embodiment, the service node can be a computing device running a certain service. The computing device can be a server, computer, etc. A service node can be understood as a physical machine (e.g., a physical server) or virtual machine running a service instance. That is, each computing device can also include one or more service nodes, on which a certain service can run.

[0067] Optionally, the service process can be deployed on a physical machine, virtual machine, or container, and each service process has a unique process ID. In practical applications, a service node can be dynamically selected from multiple service nodes through load balancing as the node for running the service. Each service node has a unique node IP address. Multiple service nodes can belong to the same cluster or different clusters, and each cluster has a unique cluster ID. Typically, one service node corresponds to one service, or one cluster corresponds to one service.

[0068] In this embodiment, the cloud management platform can deploy service monitoring processes on each service node to monitor the communication metrics of each service node. The service nodes can communicate with each other using lightweight communication protocols, such as Hypertext Transfer Protocol (HTTP).

[0069] Optionally, the service nodes in the embodiments of this application can also be microservice nodes. A microservice is a small service composed of a single application, with independent processes and lightweight processing mechanisms. Microservices can be designed according to business functions; that is, a microservice is a single, small service with business functions. Microservices can be deployed on one or more servers.

[0070] Understandably, in a microservice architecture, a microservice architecture can include service publishers, service callers, and a service registry. Among multiple service nodes, the service node that calls the service can be called a service caller, and the service node that provides the service can be called a service publisher. A service node may act as a service caller for one service or as a service publisher for another. Both the service caller and the service publisher are connected to the registry.

[0071] 2. Registration Center

[0072] In a microservices architecture, service nodes are typically service providers (i.e., service publishers) or consumers (i.e., service consumers). When a service running on a service node starts, the service node registers its information (e.g., service name, IP address, port, etc.) with a registry. The registry stores this information and allows other service nodes to discover the services they need by querying the registry.

[0073] When the status of a service node changes (such as the addition of a new service node or a service node failure), the registry center updates the service list promptly to ensure that service callers can obtain the latest service information. Service callers can use load balancing algorithms to select one service node from multiple service nodes for invocation, improving service availability and response speed.

[0074] Service registries can be deployed in a cluster, with multiple registries spread across different servers. These registries communicate and collaborate over a network to provide services such as registration, discovery, and health checks. Each registry maintains complete service registration information and uses a distributed consistency protocol to ensure data consistency. This ensures that data consistency and integrity are maintained even in the event of network partitions or failures among multiple registries.

[0075] Understandably, the registry center can also select a suitable service publisher for load balancing based on the load of the service publisher and the routing of service call requests. This helps avoid overloading a single service instance and improves the overall performance and stability of the system.

[0076] 3. Microservice architecture

[0077] refer to Figure 2 , Figure 2 Another schematic diagram of the system architecture for the communication status diagnosis method provided in this application.

[0078] A microservice architecture includes multiple service nodes that can communicate and connect with a registry center. Service nodes can invoke services from other service nodes through the registry center. Understandably, a production-ready microservice architecture can also include other service governance and monitoring / maintenance components. For example, the data messaging center provided in this embodiment can be used to acquire and store communication metrics of each service node for subscription by the cloud management platform.

[0079] A communication region is the logical boundary for communication between service nodes in a microservice architecture. For example, Figure 1 Region 1 and Region 2 are defined. In a microservice architecture, communication between service nodes is typically based on lightweight communication protocols. Communication domains define the rules and boundaries for communication between service nodes, ensuring that communication is secure, reliable, and efficient.

[0080] An availability zone is a group of isolated physical areas into which a cloud data center is divided (e.g., Figure 2 The availability zones (Availability Zone 1 and Availability Zone 2) are also known as fault isolation zones (AZs). Each zone has its own independent power supply, network, and cooling system. In a microservices architecture, deploying microservices in different availability zones can improve system availability and fault tolerance. Even if the cloud data center in one availability zone fails, microservices in other availability zones can still continue to provide services, ensuring system stability and reliability.

[0081] A Pod is the smallest unit of deployment, a group of tightly coupled containers (such as Docker containers) containing the environment to run one or more containers. In a microservice architecture, each microservice can be deployed as one or more Pods. Multiple Pods can communicate with each other, enabling dynamic discovery and load balancing between microservices. Furthermore, Pods provide resource isolation and limiting capabilities, ensuring that each microservice has sufficient resources to run without interfering with each other.

[0082] A host is a physical server or virtual machine that provides the computing and storage resources required to run a Pod. In a microservices architecture, hosts are typically organized into clusters or cloud environments to support the elastic scaling and high availability of Pods. Multiple hosts can be managed and scheduled through cluster management features to ensure that Pods can run at the appropriate time and place. A host can include one or more service nodes.

[0083] For example, such as Figure 2 As shown, the communication domain includes Availability Zone 1 and Availability Zone 2. Availability Zone 1 deploys POD1 running on host 1, which includes service node 1 and service node 2. Availability Zone 2 deploys POD2 running on hosts 2 and 3, where host 2 includes service node 3 and service node 4, and host 3 includes service node 5. Service node 1, service node 2, service node 3, service node 4, and service node 5 can communicate via a communication protocol.

[0084] In addition, a registry center can be deployed within the communication domain. The registry center can communicate with multiple service nodes within the communication domain to manage service calls between service nodes. The cloud management platform provided in this application embodiment can communicate with both the registry center and each service node to perform fault diagnosis on each service node and instruct the registry center to perform corresponding service deletion or restoration operations.

[0085] Understandably, the registry center can be deployed within the internal communication domain of the service node, or it can be deployed as a separate service. A separately deployed registry center can be deployed on its own dedicated server, or it can run as a containerized service on a cloud platform; the specifics are not limited here.

[0086] The microservice architecture provided in this application has been described above. Next, based on this microservice architecture, the communication status diagnosis method provided in the embodiments of this application will be further explained as follows:

[0087] In a microservice architecture, multiple service nodes can be deployed across multiple hosts in a cluster to implement business functions. This avoids single points of failure; if one service node fails, the others can still continue to provide services, thus ensuring the stable operation of the system. Here, the first service node can be understood as any one of the multiple service nodes.

[0088] The network topology of the communication links between service node clusters determines how the service nodes in the cluster connect and communicate. For example, in a mesh topology, each service node in the cluster can connect to all other service nodes via communication links. Therefore, the second service node associated with the first service node can be understood as all service nodes in the cluster that are connected to the first service node via communication links.

[0089] refer to Figure 3 , Figure 3 This is a flowchart illustrating a communication status diagnosis method provided in an embodiment of this application.

[0090] Optionally, Figure 3 The alarm platform, central control module, and data message center can be three independent cloud management platforms, or they can be combined into a single cloud management platform. For example, the cloud management platform can provide integration or support for the data message center to meet users' needs for processing data messages in the cloud environment. The specific configuration depends on actual needs, and this application's embodiments do not impose limitations.

[0091] Step 301: The first service node sends a probe request to at least one second service node.

[0092] For example, a first service node sends a probe request to at least one second service node, the probe request being used to obtain response information returned by the second service node. The probe request includes the identifier of at least one second service node. At least one second service node can be understood as all service nodes in the computing device cluster that are communicatively connected to the first service node.

[0093] Optionally, the first service node can send a probe request to at least one second service node at set intervals. The set intervals can be customized, such as 10ms, 50ms, 1s, 5s, etc. This ensures that the response messages returned by the second service node are timely.

[0094] Optionally, a probe request can be one or more data packets or a message. For example, a data packet might be a Transmission Control Protocol (TCP) segment, a User Datagram Protocol (UDP) datagram, or an application layer message.

[0095] For example, in the TCP / IP protocol stack, the probe request sent by the first service node could be a TCP packet encapsulated with a request message, used to request the second service node to reply with an acknowledgment packet after receiving the packet sent by the first service node. Alternatively, the request message could be used to request the second service node to reply with its corresponding communication metrics. These metrics could be determined based on the packets received from the first service node, and they represent the communication status between the first and second service nodes.

[0096] Understandably, the probe request may also include information such as the address of the first service node, the address of the second service node, or the timestamp of sending the probe request, etc., which are not limited here.

[0097] Step 302: The second service node sends a response message to the first service node.

[0098] For example, after receiving a probe request from the first service node, the second service node processes the probe request and sends a response message to the first service node based on the probe request. Optionally, the response message may include an acknowledgment data packet sent back to the first service node based on the probe request. For instance, after receiving the probe request, the second service node processes the probe request and sends a corresponding number of data packets to the first service node based on the number of data packets that need to be replied to, as indicated in the probe request. This allows the first service node to determine communication metrics based on the probe request and the response.

[0099] Optionally, the first service node may send a probe request to at least one second service node at set intervals, and the second service node shall send a response message to the first service node each time it receives a probe request from the first service node.

[0100] Understandably, the response message may also include information such as the address of the first service node, the address of the second service node, and the timestamp of receiving the probe request, but the specifics are not limited here.

[0101] Step 303: The first service node determines at least one communication indicator based on the response message sent by the second service node.

[0102] For example, when a second service node returns a response message to a first service node based on a probe request, the first service node can determine at least one communication indicator corresponding to at least one second service node based on the response message. The communication indicator is used to indicate the communication status between the second service node and the first service node.

[0103] Because network communication between the first and second service nodes may experience failures or instability, data packet loss or errors may occur during the transmission of probe requests and response messages. Therefore, the first service node can determine the corresponding communication metrics based on the response messages sent by the second service node and the probe requests sent by the first service node to the second service node.

[0104] Alternatively, communication metrics may include one or more of the following parameters: packet error rate, packet loss rate, or network latency.

[0105] The packet error rate can be understood as the proportion of erroneous data packets received by the second service node after the first service node sends data packets to the second service node, out of the total number of data packets sent. The packet loss rate can be understood as the proportion of data packets received by the second service node out of the total number of data packets sent by the first service node to the second service node.

[0106] Network latency can be understood as the time it takes for a data packet to travel from a first service node to a second service node. Network latency can include node processing latency, queuing latency, transmission latency, and propagation latency. For example, a first service node can send a timestamped data packet to a receiver and request an acknowledgment packet with a received timestamp after receiving the packet. Upon receiving the acknowledgment packet, the sender can approximate the network latency by calculating the difference between the transmission timestamp and the received timestamp in the acknowledgment packet, and then subtracting the data packet processing time at the receiver (if known).

[0107] Understandably, communication metrics may also include packet loss rate, packet loss rate, packet error rate, or packet error rate, etc., but specific details are not limited here.

[0108] Step 304: The first service node reports at least one communication indicator of the first service node to the data message center.

[0109] Optionally, the first service node may report to the data message center after determining at least one communication indicator each time. The data message center can store at least one communication indicator received from the first service node at multiple times.

[0110] Since the first service node can send a probe request to at least one second service node at set intervals, and the second service node sends a response message to the first service node each time it receives a probe request, the first service node can determine at least one communication indicator at different times based on the probe requests sent at different times and the corresponding response messages received. After determining at least one communication indicator at different times, the first service node can report it to the data message center. Therefore, the communication indicators stored in the data message center are time-sensitive and can be subscribed to by the central control module at any time.

[0111] Alternatively, in a microservice architecture, a data messaging center can be used to decouple service call relationships between multiple service nodes. By allowing services to exchange data and information asynchronously, the scalability and fault tolerance of the system are improved. A data messaging center can be implemented through message queues, topic subscriptions, and other methods.

[0112] For example, the data message center can persistently store at least one communication metric of the first service node through a message queue until it is retrieved and processed (e.g., the central control module subscribes to and executes steps 305 and 306). This approach effectively mitigates the risk of data loss, especially in cases where data processing may fail. The message queue's "insert-retrieve-delete" paradigm also ensures data integrity and security; a message is only deleted from the queue after it has been processed.

[0113] Step 305: The central control module sends a communication indicator subscription message to the data message center.

[0114] For example, the central control module can send communication indicator subscription messages to the data message center. These messages are used to obtain at least one communication indicator from the first service node. For instance, the data message center can maintain a subscriber list, recording the communication indicator subscription messages sent by the central control module. When a new message (i.e., at least one communication indicator reported by the first service node) arrives at the data message center, the center can iterate through this list and send the new message to the subscriber (i.e., the central control module).

[0115] Optionally, the communication metric subscription message may include the identifier of the first service node. There may be multiple first service nodes, and when there are multiple first service nodes, the communication metric subscription message may include the identifiers of multiple first service nodes. For example, the communication metric subscription message may include a list of identifiers containing the identifiers of multiple first service nodes.

[0116] Optionally, the communication metric subscription message may also include timestamp information for sending the communication metric subscription message.

[0117] Step 306: The data message center sends at least one communication indicator of the first service node to the central control module based on the communication indicator subscription message.

[0118] For example, after receiving a communication indicator subscription message from the central control module, the data message center can send at least one communication indicator of the first service node to the central control module based on the communication indicator subscription message. Based on step 204, after the first service node determines at least one communication indicator, it will report the communication indicator to the data message center. The data message center stores at least one communication indicator reported by the first service node each time for subscription. Then, when the data message center receives the communication indicator subscription message, it can send the stored communication indicator to the central control module.

[0119] Optionally, at least one communication indicator can be carried in the message, which may also include timestamp information of the at least one communication indicator. The timestamp information of the at least one communication indicator indicates the timestamp at which the data message center received the at least one communication indicator. This allows the central control module to determine the timeliness based on the timestamp information of the at least one communication indicator after the data message center sends it to the central control module.

[0120] For example, the data message center subscribes to messages based on communication indicators and sends at least one communication indicator of the first service node to the central control module. This at least one communication indicator is determined at time t1. The central control module determines whether the time difference between time t1 and the current time meets the timeliness requirement, for example, whether the time difference is less than a time threshold. If it does, that is, the time difference is less than the time threshold, then the at least one communication indicator at time t1 is used to further determine the communication status of the first service node. If it does not, that is, the time difference is greater than the time threshold, then the notification indicator at time t1 is considered not to meet the timeliness requirement, and using the communication indicator determined at time t1 may cause a large error. In this case, the central control module can continue to wait for a new communication indicator sent by the data message center, for example, a communication indicator determined at time t2, where time t1 occurred before time t2. For communication indicators, the communication indicator determined at time t2 is more timely than the communication indicator determined at time t1, and the time difference between time t2 and the current time is less than the time difference between time t1 and the current time.

[0121] Step 307: The central control module determines the number of target service nodes based on at least one communication indicator.

[0122] For example, after obtaining at least one communication indicator of the first service node, it is further determined whether each communication indicator meets a first preset condition. In other words, it is determined whether the communication indicators between the first service node and the second service node are healthy. The target service node is the second service node whose corresponding communication indicator meets the first preset condition among at least one second service node.

[0123] Optionally, after receiving at least one communication indicator, the central control module needs to first determine its timeliness to avoid factors such as message backlog affecting the real-time monitoring of the service node's communication status. In other words, if the timeliness condition is not met, the central control module can wait for the data message center to send a new communication indicator.

[0124] Optionally, there can be zero or one or more target service nodes. The number of target service nodes that meet the first set condition is determined by judging whether the communication indicators corresponding to each of the at least one second service node meet the first set condition.

[0125] Optionally, the communication metrics may include one or more of the following parameters: packet error rate, packet loss rate, or network latency. The first condition is that any parameter in the communication metrics is less than its corresponding set threshold. That is, if every parameter in the communication metrics is less than its corresponding set threshold, the communication metric is considered healthy. If any parameter in the communication metrics is greater than its corresponding set threshold, the communication metric is considered unhealthy, and the second service node corresponding to that communication metric is designated as the target service node.

[0126] For example, communication metrics include packet loss rate. A first predefined condition is that the packet loss rate during communication between the first and second service nodes exceeds a first predefined threshold. In other words, a higher packet loss rate indicates poorer communication between the first and second service nodes, potentially indicating a faulty or sub-optimal state.

[0127] For example, communication metrics include network latency. A first predefined condition is that the network latency between the first and second service nodes exceeds a second predefined threshold. In other words, higher network latency indicates poorer communication between the first and second service nodes, potentially indicating a faulty or suboptimal state.

[0128] For example, communication metrics include packet error rate. A first predefined condition is that the packet error rate during communication between the first and second service nodes exceeds a third predefined threshold. In other words, a higher packet error rate indicates more unstable communication between the first and second service nodes, potentially suggesting a faulty or sub-optimal state.

[0129] Understandably, communication metrics may also include packet error rate, packet error rate, packet loss rate, or packet loss rate, but no specific limit is set here.

[0130] like Figure 4 As shown, Figure 4 This is a schematic diagram of communication indicators in the communication status diagnosis method provided in this application embodiment. A first service node maintains a queue of communication indicators. For example, if the first service node is service node 1, and service nodes 2, 3, 4, and 5 are all associated with service node 1, then there are multiple second service nodes, namely service node 2, service node 3, service node 4, and service node 5. Service node 1 can determine communication indicators a, b, c, and d corresponding to service nodes 2, 3, 4, and 5, respectively.

[0131] After receiving at least one communication indicator from the first service node, the central control module further determines the health status of each communication indicator. For example, communication indicator a is healthy, communication indicator b is healthy, communication indicator c is unhealthy, and communication indicator d is healthy. The target service node is the service node whose communication indicators are determined to be unhealthy (i.e., meeting the first set condition), namely service node 4 corresponding to communication indicator c. Therefore, for the first service node (i.e., service node 1), there are 4 second service nodes, and 1 of these 4 second service nodes is identified as the target service node. Then, step 308 is executed.

[0132] Step 308: The central control module determines whether the communication status of the first service node is healthy based on the number of target service nodes.

[0133] For example, since the communication index reflects the communication status between the first service node and the second service node, when the ratio of the number of target service nodes to the number of all second service nodes is greater than the health threshold, it means that when the first service node communicates with at least one second service node, it cannot communicate normally with the target service node. In this case, the communication status of the first service node is considered to be sub-healthy or faulty.

[0134] In other words, when the first service node communicates with at least one second service node, the more target service nodes whose communication indicators meet the first set conditions, the greater the possibility that the first service node is in a faulty or sub-healthy state.

[0135] For example, when the ratio of the number of target service nodes to the number of second service nodes is less than a health threshold, meaning that when the first service node communicates with at least one second service node, only a few target service nodes are unable to communicate normally with the first service node, then the communication status of the target service nodes communicating with the first service node is considered to be sub-healthy or faulty. Further investigation is needed to determine if at least one target service node is faulty.

[0136] Understandably, when the number of target service nodes is 0, that is, when all communication indicators of the first service node are healthy, the communication status of the first service node is determined to be healthy.

[0137] Step 309: When the communication status of the first service node is determined to be in a sub-healthy state, the central control module sends the first instruction information to the registration center.

[0138] For example, the first instruction information is used to instruct the registry center to remove the first service node from the service list.

[0139] In a microservice architecture, when a service instance running on a service node starts, the service node registers its information with a registry center. The registry center stores this information and allows other service nodes to discover the services they need by querying the registry center. Therefore, the service list in the registry center can be understood as the collection of information about all service nodes stored and managed by the registry center.

[0140] Optionally, the service list in the registry may include the service name, IP address, and port of the service node. The service name is used to identify and differentiate different microservices. The IP address and port provide the network address of the service node so that other service nodes can access it. Understandably, the service list may also include other information, such as service metadata, status, and version, which helps service consumers select and use services more accurately. Specific details are not limited here.

[0141] Optionally, before sending the first instruction information to the registration center, it is necessary to determine the oscillation cycle to reduce jitter.

[0142] It should be noted that after sending the first instruction information to the registration center, the data message center may still receive at least one new communication indicator reported by the first service node, meaning steps 301 to 304 will be executed. For example, after maintenance personnel repair the first service node, normal communication is restored. Then, the central control module determines the communication status of the first service node again based on at least one new communication indicator reported after the first service node restores normal communication. If the communication status of the first service node is determined to be healthy, a second instruction information can be sent to the registration center. The second instruction information is used to instruct the registration center to add the information of the first service node to the service list for other service nodes to call.

[0143] Step 310: When the communication status of the first service node is determined to be either sub-healthy or healthy, the central control module sends status information to the alarm platform.

[0144] For example, the status information includes the communication status of the first service node (including sub-healthy or healthy status), so that the alarm platform can issue alarm information based on the status information.

[0145] Understandably, the alarm platform can further determine the fault level of multiple service nodes in the computing device cluster based on the communication status of one or more first service nodes determined by the central control module, in order to determine the fault range of service nodes in a sub-healthy state in the microservice architecture. For detailed explanations, please refer to steps 501 to 507.

[0146] It should be noted that in any of the above steps, "first service node," "second service node," and "target service node" do not specifically refer to any one service node. The first service node can be any one of multiple service nodes, and the second service node can be any one of multiple service nodes associated with the first service node. For example, if the multiple service nodes include interconnected service node 1, service node 2, and service node 3, then when service node 1 acts as the first service node in implementing steps 301 to 310, service node 2 and service node 3 act as two second service nodes of service node 1. Similarly, service node 2 can also act as the first service node in implementing steps 301 to 310, in which case service node 1 and service node 3 act as two second service nodes of service node 1. In other words, in a microservice architecture, when there are n service nodes, it is ultimately possible to determine whether the communication status of the n service nodes is healthy, where n is a natural number.

[0147] Steps 301 to 310 above describe the diagnostic process for the communication status of service nodes in a microservice architecture. The first service node can be any one of multiple service nodes; that is, for each of the multiple service nodes, steps 301 to 310 can be executed to determine whether the communication status of each service node is healthy. Based on this, by aggregating the communication status of each service node, the fault level of multiple service nodes in the computing device cluster can be further determined to identify the fault range of service nodes in a sub-healthy state within the microservice architecture, as detailed below:

[0148] A single service node can be understood as a virtual machine (VM). If a single service node detects network health issues, it might be due to a network interface card (NIC) failure. When a VM experiences a network failure, it could be due to a problem with the network of the host machine it's deployed on. When the host network is compromised, it could be due to a network failure in the Point of Development (POD) zone where the host resides. When the POD zone experiences a network failure, it could be due to damage to the Availability Zone (AZ) network. The alarm platform determines the failure rate at different storage unit levels based on the storage units of the first service node whose communication status is unhealthy, thereby progressively defining the scope of the failure.

[0149] refer to Figure 5 , Figure 5 Another flowchart illustrating the communication status diagnosis method provided in this application embodiment.

[0150] Step 501: The alarm platform determines the host-level failure ratio based on the number of first service nodes whose communication status is sub-healthy.

[0151] For example, refer to Figure 2 The diagram illustrates the deployment of service nodes in a microservice architecture. Based on the network topology of the communication links between service nodes in the service node cluster, each service node can have different levels of storage units. Different levels of storage units allow for the determination of different fault levels. This effectively addresses network interface card (NIC) level, host level, POD level, and Availability Zone (AZ) faults in cloud service scenarios, accurately identifies network partitions caused by various scenarios, reduces false positives, and allows for different actions based on different fault levels.

[0152] The host-level failure ratio can be understood as the ratio of the number of the first service node deployed on the same host and in a sub-healthy state to the total number of all service nodes deployed on that host.

[0153] Since one or more service nodes can be deployed on the same host, if the communication status of multiple service nodes on the same host is determined to be suboptimal, then the host may have experienced a host-level failure. For example, when a server experiences a host-level failure, all services on that server may be affected, including network services (such as network communication, data transmission, and network connectivity).

[0154] Optionally, the storage unit of the first service node can be understood as the address of the host to which the first service node belongs, or the storage unit of the first service node can be understood as the address of the availability zone to which the first service node belongs, or the storage unit of the first service node can be understood as the address of the POD to which the first service node belongs. Therefore, the fault level can include host-level fault, POD-level fault, or availability zone fault.

[0155] Step 502: If the proportion of host-level failures is less than the second alarm threshold, then the service node cluster is determined to be at the network card level failure level, and the first indication information is output.

[0156] For example, the first instruction information is used to instruct the registry center to remove the first service node in a sub-healthy state from the service list. If the host-level failure rate is less than the second alarm threshold, that is, if only a few first service nodes deployed on the same host are in a sub-healthy state, then it can be considered that the first service node in the sub-healthy state itself has failed. A network interface card (NIC) level failure can be understood as a hardware or software problem with the network interface card of the first service node in a sub-healthy state. This type of failure may prevent the service node from communicating normally with other service nodes.

[0157] Step 503: If the fault ratio at the host level is greater than the second alarm threshold, output the first indication information and continue to execute step 504.

[0158] For example, the first indication information is used to instruct the registry center to remove the first service node in a sub-healthy state from the service list. If the host-level failure rate is greater than the second alarm threshold, that is, if there are a large number of first service nodes deployed on the same host in a sub-healthy state, then the host can be considered to be in a faulty state, which causes multiple first service nodes deployed on the host to be unable to communicate or to have degraded communication performance.

[0159] When a host-level failure occurs, it can be further determined whether there is a higher level of failure, such as a POD-level failure or an availability zone failure.

[0160] Step 504: The alarm platform determines the POD-level failure ratio based on the number of first service nodes whose communication status is sub-healthy.

[0161] For example, refer to Figure 2 The diagram illustrates the deployment of service nodes in a microservice architecture. One or more hosts can be deployed within the same POD. When a host-level failure occurs, it can be further determined whether a POD-level failure has occurred, thus defining the scope of the failure. For example, if a POD's network configuration has a problem, that POD may be unable to communicate normally with other PODs or external networks.

[0162] The failure rate at the POD level can be understood as the ratio of the number of hosts deployed in the same POD that are classified as faulty to the total number of hosts deployed in that POD. Alternatively, it can be understood as the ratio of the number of the first service node deployed in the same POD that is in a sub-optimal state to the total number of service nodes deployed in that POD.

[0163] Step 505: If the proportion of POD-level faults is greater than the third alarm threshold, output the first indication information and continue to execute step 506.

[0164] For example, the first indication information is used to instruct the registry center to remove the first service node in a sub-healthy state from the service list. If the failure rate at the POD level is greater than the third alarm threshold, that is, on the basis of host-level failure, there are a large number of hosts deployed in the same POD and in a failure state, then the POD can be considered to be in a failure state, which causes multiple first service nodes deployed in the POD to be unable to communicate or to have degraded communication performance.

[0165] When a POD-level failure occurs, it can be further determined whether there is a higher level of failure, such as an availability zone failure.

[0166] Step 506: The alarm platform determines the failure ratio at the availability zone level based on the number of first service nodes whose communication status is sub-healthy.

[0167] For example, refer to Figure 2 The diagram illustrates the deployment of service nodes in a microservice architecture. One or more PODs can be deployed within the same Availability Zone (AZ). When a POD-level failure occurs, it can be further determined whether an Availability Zone-level failure has occurred, thus defining the scope of the failure. For example, if a network or infrastructure failure occurs in an Availability Zone (AZ), all servers and PODs within that AZ may be affected.

[0168] The failure ratio at the AZ level can be understood as the ratio of the number of PODs (Points of Demand) deployed in the same AZ and deemed to be in a failed state to the total number of PODs deployed in that AZ. Alternatively, the failure ratio at the AZ level can be understood as the ratio of the number of the first service node deployed in the same AZ and in a sub-optimal state to the total number of service nodes deployed in that AZ.

[0169] Step 507: If the failure rate at the AZ level is greater than the first alarm threshold, then output alarm information.

[0170] For example, alarm messages are used to alert users or maintenance personnel to AZ-level failures. Since an AZ deploys one or more PODs, and a POD deploys one or more hosts, and each host can deploy one or more service nodes, when an AZ-level failure is determined, the operational scope of the service nodes is too large. Considering the overall stability of the service node cluster, only alarm messages are issued, and manual intervention is required to handle the failure.

[0171] The following describes the relevant equipment provided in the embodiments of this application.

[0172] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a cloud management platform provided in an embodiment of this application. Figure 6 As shown, the cloud management platform 600 includes an acquisition unit 601, a processing unit 602, and a sending unit 603. The cloud management platform 600 is used to manage infrastructure, which includes multiple service nodes, on which one or more user services run.

[0173] The acquisition unit 601 is used to acquire communication information of a first service node among multiple service nodes. The communication information includes at least one communication indicator corresponding to at least one second service node. The communication indicator is used to indicate the communication status between the second service node and the first service node. The at least one second service node is a service node associated with the first service node among multiple service nodes.

[0174] Processing unit 602 is configured to determine the number of target service nodes among at least one second service node based on at least one communication indicator, wherein the communication indicators corresponding to the target service nodes and the first service nodes satisfy a first set condition.

[0175] The processing unit 602 is also used to determine the communication status of the first service node based on the number of target service nodes;

[0176] The sending unit 603 is used to send a first instruction message to the registration center when the communication status of the first service node is determined to be in a sub-healthy state. The first instruction message is used to instruct the registration center to delete the first service node from the service list.

[0177] The processing unit 602 is further configured to: determine the communication status of the first service node as sub-healthy when the number of target service nodes meets a second preset condition; or, determine the communication status of the first service node as healthy when the number of target service nodes does not meet the second preset condition. The second preset condition includes that the ratio of the number of target service nodes to the number of at least one second service node is greater than a health threshold.

[0178] The sending unit 603 is further configured to: send a second instruction message to the registration center when the communication status of the first service node is determined to be healthy, the second instruction message being used to instruct the registration center to add the first service node to the service list.

[0179] The sending unit 603 is further configured to: send a first indication message to the registration center if the ratio of the number of first service nodes deployed in the same availability zone and in a sub-healthy state to the total number of service nodes deployed in the same availability zone is less than a first alarm threshold.

[0180] The sending unit 603 is further configured to: output alarm information if the ratio of the number of first service nodes deployed in the same availability zone and in a sub-healthy state to the total number of service nodes deployed in the same availability zone is greater than the first alarm threshold.

[0181] The acquisition unit 601, processing unit 602, and sending unit 603 can all be implemented in software or in hardware. For example, the implementation of processing unit 602 will be described below. Similarly, the implementation of acquisition unit 601 and sending unit 603 can refer to the implementation of processing unit 602.

[0182] As an example of a software functional unit, processing unit 602 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the aforementioned computing instance may be one or more. For example, processing unit 602 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0183] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0184] As an example of a hardware functional unit, processing unit 602 may include at least one computing device, such as a server. Alternatively, processing unit 602 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0185] The processing unit 602 includes multiple computing devices that can be distributed in the same region or in different regions. Similarly, the processing unit 602 can be distributed within the same Availability Zone (AZ) or in different AZs. Likewise, the processing unit 602 can be distributed within the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0186] It should be noted that the cloud management platform 600 achieves all its functions by implementing different steps in the communication status diagnosis method through the acquisition unit 601, processing unit 602, and sending unit 603. The cloud management platform 600 is used to implement the communication status diagnosis method provided in the embodiments of this application, and will not be described further here.

[0187] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a service node provided in an embodiment of this application. Figure 7 As shown, service node 700 (e.g., the first service node) includes:

[0188] The transceiver unit 701 is used to send a probe request to at least one second service node, wherein the at least one second service node is a service node associated with the first service node among a plurality of service nodes.

[0189] The transceiver unit 701 is also used to receive response information sent from at least one second service node, the response information being determined based on the probe request.

[0190] The processing unit 702 is configured to determine at least one communication indicator based on the response message, the communication indicator being used to represent the communication status between at least one second service node and the first service node.

[0191] The transceiver unit 701 is also used to report at least one communication indicator to the cloud management platform.

[0192] Please see Figure 8 , Figure 8 This is a schematic diagram of a computing device provided in an embodiment of this application. The computing device 800 includes a processor 801, a communication interface 802, a bus 803, and a memory 804. The processor 801, the communication interface 802, and the memory 804 communicate with each other via the bus 803. In practical applications, communication can also be achieved through other means such as wireless transmission; the specific method is not limited here.

[0193] The computing device 800 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memory in the computing device 800.

[0194] Processor 801 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0195] The communication interface 802 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 800 and other devices or communication networks.

[0196] The 803 bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 8The bus 803 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 803 may include a path for transmitting information between various components of the computing device 800 (e.g., memory 804, processor 801, communication interface 802).

[0197] Memory 804 may include volatile memory, such as random access memory (RAM). Memory 804 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0198] The memory 804 stores executable program code, and the processor 801 executes the executable program code to implement the functions of the aforementioned acquisition unit 601, processing unit 602, and sending unit 603, thereby realizing the data encoding method provided in this application embodiment. That is, the memory 804 stores instructions for executing the data encoding method.

[0199] Understandably, Figure 8 The computing device 800 shown can perform, for example Figure 6 The functions of the cloud management platform, or, as... Figure 8 The computing device shown can also perform tasks such as Figure 7 The function of the service node is that when the computing device performs, such as Figure 7 The functions of the service nodes and the description of the computing devices can be found in the foregoing description. Figure 8 The specific details will not be elaborated here.

[0200] This application also provides a computing device cluster, which includes at least one computing device. For example, the computing device cluster may include devices deployed such as... Figure 3 The alarm platform, central control module, and data message center are three independent cloud management platforms with multiple computing devices, or the computing device cluster may include multiple computing devices deployed as such. Figure 3 The system integrates the alarm platform, central control platform, and data message center into a single cloud management platform. This computing device can be a server, such as a central server, edge server, or a local server in a local data center. In some alternative implementations, the computing device can also be a desktop computer, laptop computer, or smartphone.

[0201] Please see Figure 9 and Figure 10 , Figure 9 and Figure 10 These are all schematic diagrams of the computing device clusters provided in the embodiments of this application.

[0202] like Figure 9 As shown, the computing device cluster includes at least one computing device 800. The memory 804 of one or more computing devices 800 in the computing device cluster may store the same instructions for executing the data encoding method provided in the embodiments of this application.

[0203] In some possible implementations, the memory 804 of one or more computing devices 800 in the computing device cluster may also store partial instructions for executing the data encoding method. In other words, a combination of one or more computing devices 804 can jointly execute the instructions for executing the data encoding method.

[0204] It should be noted that the memory 804 in different computing devices 800 within the computing device cluster can store different instructions, each used to execute a portion of the functions of the data encoding device. That is, the instructions stored in the memory 804 of different computing devices 800 can implement the functions of one or more of the acquisition unit 601, processing unit 602, and sending unit 603.

[0205] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 10 One possible implementation is shown. For example... Figure 10 As shown, the two computing devices 800A and 800B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this possible implementation, the memory 804 in computing device 800A stores instructions for executing the functions of processing unit 602 and acquisition unit 601. Meanwhile, the memory 804 in computing device 800B stores instructions for executing the functions of transmission unit 603.

[0206] Figure 10 The connection method between the computing device clusters shown can be based on the data encoding method provided in this application, which separates the processing operation from the operation outside the processing operation. That is, it is considered that the function of the acquisition unit 601 is executed by the computing device 800A, and the function of the processing unit 602 is executed by the computing device 800B.

[0207] It should be understood that Figure 10 The functions of the computing device 800A shown can also be performed by multiple computing devices 800. Similarly, the functions of the computing device 800B can also be performed by multiple computing devices 800.

[0208] This application also provides another computing device cluster. The connection relationships between the computing devices in this computing device cluster can be similarly referred to... Figure 9 and Figure 10 The connection method of the computing device cluster will not be described in detail here.

[0209] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computer device, it causes the at least one computer device to perform the data encoding method described above.

[0210] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform the aforementioned data encoding method.

[0211] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0212] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

Claims

1. A method for diagnosing communication status, characterized in that, Applied to a cloud management platform for managing infrastructure, the infrastructure including multiple service nodes, the method includes: Obtain at least one communication indicator of the first service node among the plurality of service nodes, wherein the at least one communication indicator is used to represent the communication status between at least one second service node and the first service node, and the at least one second service node is a service node among the plurality of service nodes that is associated with the first service node; Based on the at least one communication indicator, the number of target service nodes among the at least one second service node is determined, and the communication indicator corresponding to the target service node and the first node satisfies a first set condition; Based on the number of target service nodes, determine the communication status of the first service node; If the communication status of the first service node is determined to be in a sub-healthy state, a first instruction message is sent to the registration center, which is used to instruct the registration center to delete the first service node from the service list.

2. The method according to claim 1, characterized in that, Determining the communication status of the first service node based on the number of target service nodes includes: If the number of target service nodes meets the second set condition, the communication status of the first service node is determined to be in a sub-healthy state. Alternatively, if the number of target service nodes does not meet the second set condition, the communication status of the first service node is determined to be healthy. The second setting condition includes a ratio of the number of target service nodes to the number of at least one second service node that is greater than a health threshold.

3. The method according to claim 1 or 2, characterized in that, The communication metrics include the packet loss rate, which is determined based on the number of data packets sent by the first service node to the second service node and the number of data packets received by the first service node in response to the second service node. The first set condition includes the packet loss rate being greater than a first set threshold.

4. The method according to any one of claims 1 to 3, characterized in that, The communication metrics include network latency, which is determined based on the timestamp of the first service node sending data packets to the second service node and the timestamp of the first service node receiving the data packets responded by the second service node. The first setting condition includes the network latency being greater than the second setting threshold.

5. The method according to claims 2 to 4, characterized in that, After sending the first instruction information to the registration center, the method further includes: If the communication status of the first service node is determined to be healthy, a second instruction message is sent to the registration center, which instructs the registration center to add the first service node to the service list.

6. The method according to any one of claims 1 to 5, characterized in that, After determining that the communication status of the first service node is in a sub-healthy state, sending the first indication information to the registration center further includes: If the ratio of the number of the first service nodes deployed in the same availability zone and in the sub-healthy state to the total number of all service nodes deployed in the same availability zone is less than the first alarm threshold, the first indication information is sent to the registry center.

7. The method according to claim 6, characterized in that, The method further includes: If the ratio of the number of the first service nodes deployed in the same availability zone and in the sub-healthy state to the total number of all service nodes deployed in the same availability zone is greater than the first alarm threshold, an alarm message is output.

8. A communication method, characterized in that, The method is applied to service nodes, where the infrastructure communicates with a cloud management platform, and the infrastructure includes multiple service nodes; the method includes: The first service node among the plurality of service nodes sends a probe request to at least one second service node, wherein the at least one second service node is a service node associated with the service node among the plurality of service nodes; The first service node receives response information sent from the at least one second service node, the response information being determined based on the probe request; Based on the response information, the first service node determines at least one communication indicator, which is used to represent the communication status between at least one second service node and the first service node; The first service node reports at least one communication metric to the cloud management platform.

9. A cloud management platform, characterized in that, The cloud management platform is used to manage infrastructure, which includes multiple service nodes and a registry center. The cloud management platform includes: The acquisition unit is used to acquire communication information of a first service node among a plurality of service nodes. The communication information includes at least one communication indicator corresponding to at least one second service node. The communication indicator is used to indicate the communication status between the second service node and the first service node. The at least one second service node is a service node associated with the first service node among the plurality of service nodes. A processing unit is configured to determine the number of target service nodes among the at least one second service node based on the at least one communication indicator, wherein the communication indicator between the target service node and the first service node satisfies a first preset condition. The processing unit is further configured to determine the communication status of the first service node based on the number of the target service nodes; The sending unit is configured to send a first indication message to the registration center when the communication status of the first service node is determined to be in a sub-healthy state. The first indication message is used to instruct the registration center to delete the first service node from the service list.

10. The cloud management platform according to claim 9, characterized in that, The processing unit is further specifically used for: If the number of target service nodes meets the second preset condition, the communication status of the first service node is determined to be in a sub-healthy state; or, if the number of target service nodes does not meet the second preset condition, the communication status of the first service node is determined to be in a healthy state. The second setting condition includes a ratio of the number of target service nodes to the number of at least one second service node that is greater than a health threshold.

11. The cloud management platform according to claim 9 or 10, characterized in that, The communication metrics include the packet loss rate, which is determined based on the number of data packets sent by the first service node to the second service node and the number of data packets received by the first service node in response to the second service node. The first set condition includes the packet loss rate being greater than a first set threshold.

12. The cloud management platform according to any one of claims 9 to 11, characterized in that, The communication metrics include network latency, which is determined based on the timestamp of the first service node sending data packets to the second service node and the timestamp of the first service node receiving the data packets responded by the second service node. The first setting condition includes the network latency being greater than the second setting threshold.

13. The cloud management platform according to any one of claims 10 to 12, characterized in that, The transmitting unit is further specifically used for: If the communication status of the first service node is determined to be healthy, a second instruction message is sent to the registration center, which instructs the registration center to add the first service node to the service list.

14. The cloud management platform according to any one of claims 10 to 13, characterized in that, The transmitting unit is further specifically used for: If the ratio of the number of the first service nodes deployed in the same availability zone and in the sub-healthy state to the total number of all service nodes deployed in the same availability zone is less than the first alarm threshold, the first indication information is sent to the registry center.

15. The cloud management platform according to claim 14, characterized in that, The transmitting unit is further specifically used for: If the ratio of the number of the first service nodes deployed in the same availability zone and in the sub-healthy state to the total number of all service nodes deployed in the same availability zone is greater than the first alarm threshold, an alarm message is output.

16. A service node, characterized in that, The infrastructure communicates with the cloud management platform, and the infrastructure includes multiple service nodes, the service nodes including: A transceiver unit is configured to send a probe request to at least one second service node, wherein the at least one second service node is a service node associated with the service node among a plurality of service nodes; The transceiver unit is also configured to receive response information sent from the at least one second service node, the response information being determined based on the probe request; The processing unit is configured to determine at least one communication indicator based on the response message, the communication indicator being used to represent the communication status between at least one second service node and the service node; The transceiver unit is also used to report the at least one communication indicator to the cloud management platform.

17. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1 to 7 or the method as described in claim 8.

18. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster causes the computing device cluster to perform the method as described in any one of claims 1 to 7 or the method as described in claim 8.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer program instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method as claimed in any one of claims 1 to 7 or the method as claimed in claim 8.

Images