Cloud service cluster detection method and device, electronic equipment and storage medium

By acquiring and detecting the gateway parameters of the cloud service cluster, identifying the probe and test gateway, and monitoring traffic data in real time, the problem of not being able to detect changes in the gateway status during cloud service changes is solved, thus achieving real-time quality assurance for cloud services.

CN119052134BActive Publication Date: 2025-11-25NETEASE (HANGZHOU) NETWORK CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202410970258.8
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2024-06-14
Filing Date
2024-07-18
Publication Date
2025-11-25
Estimated Expiration
2044-07-18

AI Technical Summary

Technical Problem

In cloud computing, changes in gateway status cannot be effectively detected during cloud service changes, which prevents operations and maintenance personnel from handling anomalies in a timely manner and affects service quality.

Method used

By obtaining the gateway parameters of the cloud service cluster, the probe gateway and test gateway are determined, packets are sent and traffic data is obtained, and the data is visualized and detected in real time to generate gateway detection results to characterize communication anomalies.

Benefits of technology

It enables real-time monitoring of the status of cloud service cluster gateways, allowing for timely detection and handling of communication anomalies, thus ensuring the quality of cloud services.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119052134B_ABST
    Figure CN119052134B_ABST
Patent Text Reader

Abstract

Embodiments of the present application provide a cloud service cluster detection method and device, electronic equipment and storage medium, relating to the technical field of cloud computing, the method comprises: in response to a detection instruction for a cloud service cluster, obtaining the gateway parameters of the cloud service cluster; according to the gateway parameters, determine the detection gateway and the test gateway from the cloud service cluster; through the detection gateway, send a package to the test gateway, and obtain the traffic data between the detection gateway and the test gateway in the process of sending a package, and visually display the traffic data; according to the traffic data, detect the test gateway, generate the gateway detection result for the test gateway, the gateway detection result is used to represent whether the test gateway exists communication exception, so as to continuously detect the cloud service cluster, so as to timely carry out targeted operation and maintenance, ensure the quality of cloud service.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a method for detecting cloud service clusters, a device for detecting cloud service clusters, an electronic device, and a computer-readable storage medium. Background Technology

[0002] In recent years, cloud computing has been a hot research area in the ICT (Information and Communication Technology) field, and the quality control of cloud computing platforms has always been a major concern. Testing cloud networks can effectively identify problems and ensure service quality. However, the impact of changes to cloud services is often not effectively perceived; responses typically rely on user feedback and manpower to roll back versions. Furthermore, the lack of user-level monitoring of network status means that maintenance personnel cannot address anomalies promptly, impacting service quality. Summary of the Invention

[0003] The present invention provides a method, apparatus, electronic device, and computer-readable storage medium for detecting cloud service clusters, in order to solve or partially solve the problem of the inability to effectively detect gateways in clusters involved in cloud computing, especially when changes in cloud services cause changes in gateway status, making it difficult to effectively grasp the network status of the gateway.

[0004] This invention discloses a method for detecting cloud service clusters, including:

[0005] In response to a detection command for a cloud service cluster, the gateway parameters of the cloud service cluster are obtained;

[0006] The probe gateway and test gateway are determined from the cloud service cluster based on the gateway parameters.

[0007] The probe gateway sends packets to the test gateway, acquires traffic data between the probe gateway and the test gateway during the packet sending process, and visualizes the traffic data.

[0008] The test gateway is detected based on the traffic data, and a gateway detection result is generated for the test gateway. The gateway detection result is used to characterize whether there is a communication anomaly in the test gateway.

[0009] This invention also discloses a detection device for a cloud service cluster, comprising:

[0010] The parameter acquisition module is used to acquire the gateway parameters of the cloud service cluster in response to the detection command for the cloud service cluster.

[0011] The gateway selection module is used to determine the probe gateway and the test gateway from the cloud service cluster based on the gateway parameters;

[0012] The traffic acquisition module is used to send packets from the probe gateway to the test gateway, acquire traffic data between the probe gateway and the test gateway during the packet sending process, and visualize the traffic data.

[0013] The detection module is used to detect the test gateway based on the traffic data and generate a gateway detection result for the test gateway. The gateway detection result is used to characterize whether the test gateway has any communication abnormalities.

[0014] This invention also discloses an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0015] The memory is used to store computer programs;

[0016] When the processor executes a program stored in the memory, it implements the method described in the embodiments of the present invention.

[0017] This invention also discloses a computer-readable storage medium storing instructions that, when executed by one or more processors, cause the processors to perform the methods described in this invention.

[0018] The embodiments of the present invention have the following advantages:

[0019] In this embodiment of the invention, in a cloud computing scenario, by inputting a detection command for a cloud service cluster, the detection system can obtain the gateway parameters of the cloud service cluster. Then, based on the gateway parameters, the system determines the probe gateway and test gateway from the cloud service cluster, sends packets from the probe gateway to the test gateway, and acquires the traffic data between the probe gateway and the test gateway during the packet sending process. This traffic data is then visualized. By displaying the traffic data between the probe gateway and the test gateway in real time, operations and maintenance personnel can perceive the status of the corresponding communication links and understand the gateway status. Then, based on the traffic data, the test gateway is detected, generating gateway detection results for the test gateway. These results indicate whether the test gateway has communication anomalies. Thus, during the continuous provision of cloud services to users, corresponding probe gateways and test gateways can be constructed in real time for gateways requiring detection, effectively adapting to different clusters. Simultaneously, by sending packets from the probe gateway to the test gateway and acquiring the traffic data between them, the communication link is continuously and dynamically monitored for cloud service traffic, enabling timely and targeted operations and maintenance to ensure the quality of cloud services. Attached Figure Description

[0020] Figure 1 This is a flowchart of the steps of a cloud service cluster detection method provided in an embodiment of the present invention;

[0021] Figure 2 This is a schematic diagram of a gateway detection scenario provided in an embodiment of the present invention;

[0022] Figure 3 This is a schematic diagram of the network topology provided in an embodiment of the present invention;

[0023] Figure 4 This is a schematic diagram of gateway creation provided in an embodiment of the present invention;

[0024] Figure 5 This is a schematic diagram of the generation process of the detection task provided in the embodiment of the present invention;

[0025] Figure 6 This is a structural block diagram of a cloud service cluster detection device provided in an embodiment of the present invention;

[0026] Figure 7 This is a block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0027] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0028] As an example, for cloud networks, the testing solutions in related technologies provide quality assurance for various characteristics of the cloud network, including functional testing, automated regression testing, performance testing, inspection testing, and chaos testing. Functional testing verifies the normal operation of cloud network functions; chaos testing simulates cloud network faults; and performance testing performs cloud network load testing—these identify problems before software release. Inspection testing simulates user operations on online services to verify their normal operation; and automated regression testing performs acceptance testing of key functions after cloud network changes are completed. Based on these tests, cloud network problems can be effectively identified, ensuring quality.

[0029] However, while the above testing methods provide quality assurance before and after service changes, they cannot guarantee the normal operation of the service during the change process or after deployment. For cloud services, the impact of changes is often imperceptible, typically only addressed through user feedback and requiring manpower to roll back the version. Furthermore, current operations and testing systems cannot monitor network conditions at the user level, such as network jitter or packet loss, hindering timely service maintenance.

[0030] In this invention, within a cloud computing scenario, by inputting a detection command for the cloud service cluster, the detection system can obtain the gateway parameters of the cloud service cluster. Then, based on the gateway parameters, the system determines the probe gateway and test gateway from the cloud service cluster. Packets are sent from the probe gateway to the test gateway, and traffic data between the probe gateway and the test gateway is acquired during the packet transmission process. This traffic data is then visualized. By displaying the real-time traffic data between the probe gateway and the test gateway, maintenance personnel can perceive the status of the corresponding communication links in real time, understand the gateway status, and then detect the test gateway based on the traffic data, generating gateway detection results for the test gateway. These results indicate whether the test gateway has communication anomalies. Thus, during the continuous provision of cloud services to users, corresponding probe gateways and test gateways can be constructed in real time for gateways requiring detection, effectively adapting to different clusters. Simultaneously, by sending packets from the probe gateway to the test gateway to obtain traffic data between them, and then detecting the communication link based on the traffic data, continuous dynamic detection of cloud service traffic is performed to enable timely and targeted maintenance operations, ensuring the quality of cloud services.

[0031] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, some technical features involved in the embodiments of the present invention are explained and described below:

[0032] A data center zone is a physical or logical partition within a data center that contains IT infrastructure such as servers, network equipment, and storage devices. Data center zones are typically designed with redundancy, security, and energy efficiency in mind to ensure stable data center operation and data security. Data center zones can be divided based on geographical location, functional requirements, or security levels.

[0033] A cluster is a group of interconnected computers (nodes) that work together to provide greater computing power, storage capacity, or network services. Clusters can be categorized into compute clusters, storage clusters, database clusters, etc., and they use cluster management software to coordinate resource and task allocation among the nodes. The purpose of clustering is to improve system reliability, availability, and scalability.

[0034] A gateway is a device that connects two or more networks, enabling data transfer from one network to another. Gateways can perform various functions, such as protocol conversion, packet forwarding, and security checks. In a data center environment, a gateway might refer to a border router connecting internal and external networks, or a switch connecting different network zones (such as VLANs).

[0035] For data center zones, clusters, and gateways, a data center zone is the physical or logical environment that hosts the cluster. Servers and network devices within the cluster are typically deployed within the data center zone, relying on the data center's infrastructure for power, cooling, and physical security. A cluster can be a component within a data center zone or span multiple data center zones to form a distributed cluster, improving system disaster recovery and scalability. Simultaneously, the cluster communicates with external networks or other clusters through gateways. Gateways are responsible for handling traffic entering and leaving the cluster, ensuring data security and correct routing. In microservice architectures, inter-service communication within a cluster may also be managed through gateways (such as API gateways) to implement functions such as traffic control and security policy enforcement. Accordingly, gateways are typically deployed at the boundary of data center zones, acting as a bridge between the internal and external networks. Gateways can be physical devices or virtual devices, playing a crucial role in the security and network policies of the data center zone. Gateways may also be deployed between different network partitions within a data center zone (such as zones with different security levels) to achieve network isolation and traffic control.

[0036] In summary, the data center provides the physical environment for clusters and gateways to operate. A cluster is a logical collection of computing and storage services within the data center, while a gateway is a key device connecting the cluster to the outside world or other clusters. These three components are interdependent and together constitute the infrastructure architecture of a data center.

[0037] In one example, a gateway can include an external network gateway and an internal network gateway. The external network gateway is responsible for data interaction between the cluster and the public network, while the internal network gateway is responsible for data interaction within the cluster. Furthermore, based on traffic carrying capacity, gateways can be categorized as supporting access from within the cluster to outside the cluster, supporting access from outside the cluster to within the cluster, supporting traffic distribution from within the cluster to outside the cluster, supporting traffic distribution from outside the cluster to outside the cluster, supporting access within the cluster, and supporting traffic distribution within the cluster. In the corresponding implementation, the network topology can be configured based on the gateway type and traffic carrying capacity to configure the cluster's network topology according to actual needs, thereby meeting different cloud computing scenarios and providing corresponding cloud services to different users.

[0038] Reference Figure 1 The diagram illustrates a flowchart of a cloud service cluster detection method provided in an embodiment of the present invention, which may specifically include the following steps:

[0039] Step 101: In response to the detection command for the cloud service cluster, obtain the gateway parameters of the cloud service cluster;

[0040] In this embodiment of the invention, an automatic detection program can be constructed for cloud service clusters (hereinafter referred to as clusters). This automatic detection program works in conjunction with corresponding cloud network components within the cluster to effectively detect gateways and other components within the cluster. For example, after the automatic detection program is deployed in the cluster, it selects the corresponding gateway from the cluster requiring gateway detection based on actual needs. Then, it collects traffic data involved in the data interaction process between the gateway and transmits the collected traffic data to the management scheduler for visualization. Simultaneously, it detects anomalies in the traffic data, thereby continuously detecting the gateway.

[0041] The management scheduler can be used to control the detection tasks of traffic monitoring, as well as the selection of detection gateways and test gateways. It can also be used to store detailed information of gateways in the cloud cluster and provide corresponding interfaces for automatic detection programs to call in order to collect information corresponding to the detection tasks.

[0042] It's important to note that the automated detection program can be a script developed by developers to automatically detect gateways. Specifically, developers can create an executable image of the automated detection program, write cronJobyaml, with each YAWL corresponding to a specific gateway type. Then, the YAWL files can be packaged into a Helm package and deployed on selected clusters, achieving one-click deployment of multiple YAWLs. The YAWL file can be a configuration file for traffic detection, enabling automated gateway detection to ensure the quality of cloud services.

[0043] In some feasible implementations, the detection command can be a command generated when a state change is detected in the cloud service cluster. Specifically, a detection command for the cloud service cluster can be generated in response to the detection of a state change. Detecting a state change in the cloud service cluster includes at least: detecting the addition of a new gateway to the cloud service cluster, or detecting a change in the state of a gateway; wherein the gateway state change includes at least one of the following: a change in connection state, a change in running state, a change in performance state, a change in security state, a change in configuration state, and a change in version state.

[0044] In addition, it can also be detection instructions generated periodically by the automatic detection program. Periodic detection instructions can be instructions to detect relevant gateways according to a preset detection cycle or at regular intervals, or to randomly select gateways for detection. For newly added gateways in the cluster, since there are no corresponding detection records before, when a new gateway is added, it can be detected so that operation and maintenance personnel can effectively grasp the status of each gateway. Correspondingly, when the status of a gateway changes, in order to ensure the stability of the gateway, the gateway can be detected, etc., so that when the gateways in the cluster undergo corresponding changes, the gateways can be detected in a timely manner to ensure the stability of the gateways.

[0045] It should be noted that, for periodic detection commands, since the stability detection system has a corresponding automatic detection program deployed, based on the characteristics of the automatic detection program, it can be executed periodically in the cluster to trigger detection commands for the cloud service cluster, etc., and this invention does not limit this.

[0046] Step 102: Determine the probe gateway and test gateway from the cloud service cluster based on the gateway parameters;

[0047] After obtaining the gateway parameters corresponding to each gateway in the cloud service cluster, the probe gateway and test gateway can be determined from the gateways based on the gateway parameters. The probe gateway can act as a data sender relative to the test gateway, while the test gateway can act as a data receiver relative to the probe gateway. That is, probe data packets sent between the probe gateway and the test gateway can be transmitted from the probe gateway to the test gateway, but the test gateway does not send data packets to the probe gateway.

[0048] The gateway parameters can include at least the gateway type and traffic capacity. The automatic detection program can use the gateway type and traffic capacity to determine the probe gateway and test gateway from the gateways, so as to build a communication link between the probe gateway and the test gateway, and then carry out data transmission based on the communication link.

[0049] In some feasible implementations, if the gateway type is an external network gateway in the cluster, and the traffic carrying capacity is sufficient for the gateway to support access from within the cluster to outside the cluster, then any gateway in any cluster in the first data center area is selected as the probe gateway, and any gateway in any cluster in the second data center area is selected as the first test gateway; or, a URL with an IP address located in the first geographical region is selected as the second test gateway, and a URL with an IP address located in the second geographical region is selected as the third test gateway. If the gateway type is an external network gateway in the cluster, and the traffic carrying capacity is sufficient for the gateway to support access from outside the cluster to within the cluster, then any gateway in any cluster in the first data center area is selected as the probe gateway, and... In the second data center area, select any gateway from any cluster as the first test gateway. If the gateway type is an external network gateway in the cluster, and the traffic carrying capacity is such that the gateway supports traffic distribution from within the cluster to outside the cluster, then select any gateway from any cluster in the first data center area as the probe gateway, and select any gateway from any cluster in the second data center area as the first test gateway. If the gateway type is an external network gateway in the cluster, and the traffic carrying capacity is such that the gateway supports traffic distribution from outside the cluster to outside the cluster, then select any gateway from any cluster that supports the Istio function as the probe gateway, and select any gateway from any cluster in a different data center area than the probe gateway as the test gateway.

[0050] In other feasible implementations, if the gateway type is an intranet gateway in the cluster and the traffic carrying capacity is such that the gateway supports access within the cluster, then any gateway in each cluster in each first data center area is selected as the probe gateway, and any gateway in each cluster in each second data center area is selected as the test gateway; if the gateway type is an intranet gateway in the cluster and the traffic carrying capacity is such that the gateway supports traffic distribution within the cluster, then any gateway in any cluster in the first data center area is selected as the probe gateway, and any gateway in any cluster in the second data center area is selected as the first test gateway.

[0051] In specific implementations, the external network gateway can be SNAT GW, DNAT GW, NAT64 GW, L4ELB, and ISTIO GATEWAY, etc. SNAT GW (Source Network Address Translation Gateway): The SNAT gateway is mainly used to translate the private IP addresses of the internal network into the public IP addresses of the external network, thereby enabling internal hosts to access the external network (i.e., access from within the cluster to outside the cluster), while hiding the internal network structure and increasing security.

[0052] DNAT GW (Destination Network Address Translation Gateway) is used to map public IP addresses and ports of an external network to private IP addresses and ports of an internal network, so that external users can access services provided by internal servers (i.e., access from outside the cluster to inside the cluster).

[0053] A NAT64 gateway (Network Address Translation 64 Gateway) is a special network address translation device used to translate addresses between IPv6 and IPv4 networks. It allows IPv6 hosts to communicate with IPv4 servers and is typically used in conjunction with DNS64 to achieve seamless dual-stack communication. Optionally, a NAT64 gateway can also enable external access to the cluster from within the cluster.

[0054] L4 ELB (Layer 4 Elastic Load Balancer) is a load balancer that operates at OSI Layer 4 (Transport Layer). It can distribute traffic based on IP address and port number, supporting both TCP and UDP protocols. L4 ELB is typically used to provide basic traffic distribution and failover functionality. Optionally, L4 ELB can be used to distribute traffic within and outside the cluster.

[0055] Istio Gateway, a component within the Istio service mesh, defines the traffic rules for traffic entering and leaving the mesh. It can be configured as an L4-L7 load balancer, supporting HTTP / HTTPS, TCP, and UDP traffic. Administrators can control traffic entering and leaving the mesh, including TLS termination, traffic routing, and security policy enforcement. Optionally, Istio Gateway can be used to distribute traffic from outside the cluster to within the cluster.

[0056] For intranet gateways, they may include support for intra-cluster access and L4 ELB, etc. The corresponding descriptions can be found in the aforementioned process and will not be repeated here.

[0057] It should be noted that traffic carrying capacity refers to the ability to support traffic for different objects, including internal network containers, internal networks, external networks, and external network containers. Internal network containers can be virtual machines deployed within the cluster's internal network, while external network containers can be virtual machines deployed outside the cluster's network. External networks can be categorized as domestic or overseas networks. Based on traffic carrying capacity, an external network gateway can support internal network containers accessing external networks (domestic and overseas networks), external networks accessing external network containers, and external networks accessing internal network containers. Similarly, an internal network gateway can support internal network containers accessing internal networks or other internal network containers. This invention does not impose any limitations on these aspects.

[0058] In some examples, assuming the gateway is an SNAT GW that allows internal containers to access the external network, any gateway in any cluster in each first data center region (such as Shanghai, Guangzhou, Beijing, etc.) can be selected as the probe gateway. Accordingly, a website with an IP address located in China can be used as the test gateway, and / or a website with an IP address located abroad can be used as the test gateway, etc.

[0059] Assuming the gateway is a DNAT GW or a NAT64 GW, which supports external network access to external containers, then any gateway can be selected as the probe gateway in any cluster in each first data center region (such as Shanghai, Guangzhou, Beijing, etc.), and any gateway can be selected as the test gateway in any cluster in each second data center region (Shanghai, Guangzhou, Beijing, etc.) (these gateways are all bound to the external SNAT GW).

[0060] Assuming the gateway is L4ELB, which supports internal network containers to access the external network, then any gateway can be selected as the probe gateway in any cluster in each first data center region (such as Shanghai, Guangzhou, Beijing, etc.), and any gateway can be selected as the test gateway in any cluster in each second data center region (Shanghai, Guangzhou, Beijing, etc.) (these gateways are all bound to the external SNAT GW).

[0061] Assuming the gateway is ISTIO GATEWAY, which supports access from the external network to external containers, any gateway can be selected from each cluster that supports ISTIO functionality as the probe gateway, and any gateway can be selected from any cluster in each data center region (Shanghai, Guangzhou, Beijing, etc.) as the test gateway (these gateways are all bound to the external SNAT GW).

[0062] Accordingly, if the gateway is an internal network gateway that supports internal network containers to access the internal network and / or internal network containers, then any gateway can be selected as a probe gateway in each cluster of each first data center region (such as Shanghai, Guangzhou, Beijing, etc.), and any gateway can be selected as a test gateway in any cluster of each second data center region (such as Shanghai, Guangzhou, Beijing, etc.) (these gateways are all bound to the external SNAT GW); if the gateway is an internal network L4ELB that supports internal network containers to access the internal network, then any gateway can be selected as a probe gateway in any cluster of each first data center region (such as Shanghai, Guangzhou, Beijing, etc.), and any gateway can be selected as a test gateway in any cluster of each second data center region (Shanghai, Guangzhou, Beijing, etc.).

[0063] Through the above process, the probe gateway and test gateway can be determined based on the gateway parameters, effectively adapting to different clusters and meeting the needs of gateway detection for different clusters.

[0064] In some feasible implementations, after determining the probe gateway and the test gateway, the system can obtain the first gateway information of the probe gateway and the second gateway information of the test gateway, and construct tasks based on the first gateway information and the second gateway information to obtain probe tasks for the probe gateway and the test gateway. The gateway information can include at least IP type, probe method, network type, and transmission protocol. The IP type can include IPv4 and IPv6, etc.; the probe method can include fullmesh and one-way probing, etc. Fullmesh is a probe method where each node tests other nodes, while one-way probing is a one-way latency probe method from one point to another; the network type can include external network and internal network; the transmission protocol can include ICMP-ping, ICMP-mtr, TCP, UDP, HTTP(s), and messiah, etc., and this invention does not limit these.

[0065] In a specific implementation, the automatic detection program can send a probe request to the management scheduler. The probe request can include gateway information corresponding to the probe gateway and the test gateway, respectively. Then, the management scheduler can extract at least one of the following from the first gateway information and the second gateway information: IP type, probe method, network type, and transmission protocol between the probe gateway and the test gateway. Then, it uses at least one of the IP type, probe method, network type, and transmission protocol to construct a probe task for the probe gateway and the test gateway, and then sends the probe task to the automatic detection program so that the automatic detection program can execute the corresponding probe task.

[0066] Step 103: Send packets from the probe gateway to the test gateway, and obtain traffic data between the probe gateway and the test gateway during the packet sending process, and visualize the traffic data;

[0067] For probe gateways and test gateways, the automated detection program can send probe tasks to the probe gateway. Upon receiving the probe task, the probe gateway can initiate a probe of the test target. Specifically, the probe gateway can send corresponding test data packets to the test gateway, and simultaneously acquire traffic data between the probe gateway and the test gateway during packet transmission. This allows for detection of the test gateway based on the traffic data. Furthermore, the collected traffic data can be visualized, enabling operations and maintenance personnel to monitor the status of the corresponding communication links in real time and understand the gateway's status.

[0068] In practical implementation, the probe gateway and the test gateway can first establish a communication link based on IP type and network type, and then control the probe gateway to send packets to the test gateway according to the probe method and transmission protocol. Optionally, assuming the probe gateway is located outside the cluster and the test gateway is located inside the cluster, a gateway communication link between the internal and external networks can be established based on IP type and network type, and then the corresponding test data packets can be sent to the test gateway according to the probe method and transmission protocol. In one example, assuming the IP type is IPv4, the probe method is one-way dial-up, the network type is external network, and the transmission protocol is ICMP-ping, a communication link can be established between the probe gateway and the test gateway from the cluster's external network to the internal network, and the probe gateway can be controlled to send corresponding test data packets to the test gateway according to one-way dial-up and ICMP-ping methods to achieve the detection of the test cloud service cluster.

[0069] Step 104: Detect the test gateway based on the traffic data and generate a gateway detection result for the test gateway. The gateway detection result is used to characterize whether the test gateway has any communication anomalies.

[0070] Once the traffic data corresponding to the packet transmission process between the probe gateway and the test gateway is obtained, the communication link between the probe gateway and the test gateway can be detected based on this traffic data. Gateway detection results for the test gateway can be generated. Thus, in the process of cloud computing continuously providing cloud services to users, corresponding probe gateways and test gateways can be built in real time for the gateways that need to be detected. The probe gateway sends packets to the test gateway to obtain the traffic data between the two. Then, the communication link is detected based on the traffic data, and the traffic of cloud services is continuously and dynamically detected so as to perform targeted operation and maintenance operations in a timely manner and ensure the quality of cloud services.

[0071] In some feasible implementations, the traffic data includes at least one of the following: packet loss rate, link availability, average latency of request response time, statistical percentile of request response time, and standard deviation of request response time. The automatic inspection program can then detect the communication link between the probe gateway and the test gateway based on at least one of the following: packet loss rate, link availability, average latency of request response time, statistical percentile of request response time, and standard deviation of request response time, and generate gateway detection results for the test gateway.

[0072] For example, regarding packet loss rate, if a certain percentage of data packets sent by the probe gateway are lost or dropped during transmission within a certain period, the automatic detection program can assess the stability of the link by calculating the packet loss rate. For instance, if the packet loss rate exceeds a certain threshold (such as 1%), it may indicate network congestion or link failure, and an abnormal gateway result can be generated for the test gateway; conversely, if the packet loss rate is less than or equal to the corresponding threshold, a normal gateway result can be generated for the test gateway.

[0073] Regarding link availability, the automatic detection program can calculate the link availability by recording the link's online time and total time. That is, the proportion of a link that is available within a certain period of time. If the link availability is lower than a certain threshold (such as 95%), it may indicate that there are many faults or instabilities in the link, and an abnormal gateway result can be generated for the test gateway. Conversely, if the link availability is greater than or equal to the corresponding threshold, it indicates that there are no faults or instabilities in the link, and a normal gateway result can be generated for the test gateway.

[0074] The average latency of the request-response time can be statistically analyzed to show the average latency of the probe gateway sending a request to the test gateway and receiving a response. This reflects the latency of the communication link. A higher average latency may affect the real-time performance and response speed of the service. If the average latency is greater than or equal to the corresponding time threshold, an abnormal gateway result can be generated for the test gateway; conversely, if the average latency is less than the time threshold, a normal gateway result can be generated for the test gateway.

[0075] In addition to the average latency, statistical quantiles of request response times can also be calculated for request response times (such as the median, 75th percentile, 95th percentile, etc.) to help understand the stability and reliability of the communication link. A higher statistical quantile may indicate that there are a certain number of requests with large delays. Therefore, when the statistical quantile reaches the corresponding threshold, an abnormal gateway result can be generated for the test gateway; conversely, a normal gateway result can be generated for the test gateway.

[0076] The standard deviation of request response time reflects the data distribution of request response time. A larger standard deviation may indicate poor stability of the communication link and large fluctuations. Therefore, when the standard deviation is greater than or equal to the preset threshold, an abnormal gateway result can be generated for the test gateway; otherwise, a normal gateway result can be generated for the test gateway.

[0077] It should be noted that in the above process, the communication link of the test gateway is detected in a single dimension. It is understood that the communication link of the test gateway can also be detected in a comprehensive manner in multiple dimensions, such as based on packet loss rate, average latency and standard deviation, or based on average latency, statistical quantile and standard deviation, etc. This invention does not limit this.

[0078] During the above process, if the gateway detection result indicates that there is an anomaly in the communication link, an alarm message is output for the test gateway so that the relevant operation and maintenance personnel can make timely adjustments to the abnormal gateway, link, etc., to ensure the quality of cloud services.

[0079] Furthermore, when a corresponding gateway is deleted, the associated resources and probing tasks can be deleted simultaneously. Specifically, in response to a deletion command for a probe gateway and / or a test gateway, the system can delete the test tasks corresponding to the probe gateway and / or the test gateway. By continuously monitoring the gateways in the cluster, the system can effectively detect the stability of the gateways after changes, thus ensuring the quality of cloud services.

[0080] It should be noted that the embodiments of the present invention include, but are not limited to, the examples described above. It is understood that those skilled in the art can make further settings according to actual needs under the guidance of the ideas in the embodiments of the present invention, and the present invention does not limit such settings.

[0081] In this embodiment of the invention, in a cloud computing scenario, by inputting a detection command for a cloud service cluster, the detection system can obtain the gateway parameters of the cloud service cluster. Then, based on the gateway parameters, the system determines the probe gateway and test gateway from the cloud service cluster, sends packets from the probe gateway to the test gateway, and acquires the traffic data between the probe gateway and the test gateway during the packet sending process. This traffic data is then visualized. By displaying the traffic data between the probe gateway and the test gateway in real time, operations and maintenance personnel can perceive the status of the corresponding communication links and understand the gateway status. Then, based on the traffic data, the test gateway is detected, generating gateway detection results for the test gateway. These results indicate whether the test gateway has communication anomalies. Thus, during the continuous provision of cloud services to users, corresponding probe gateways and test gateways can be constructed in real time for gateways requiring detection, effectively adapting to different clusters. Simultaneously, by sending packets from the probe gateway to the test gateway and acquiring the traffic data between them, the communication link is continuously and dynamically monitored for cloud service traffic, enabling timely and targeted operations and maintenance to ensure the quality of cloud services.

[0082] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the following examples are provided for illustrative purposes:

[0083] Reference Figure 2 This diagram illustrates a gateway detection scenario provided in this embodiment of the invention. CrobJob can be an automatic detection program, Client can be a probe gateway, Server can be a test gateway, interface can be the interface of the management scheduler (Operation Control Center), and WaterflowCenter can be a traffic dashboard. During Server detection, CrobJob can periodically or automatically trigger Server detection under certain conditions. Specifically, it can first initiate a probe request to the management scheduler through the interface and obtain the probe task issued by the management scheduler. Then, based on the probe task, it controls the Client to send data packets to the Server and collects the traffic data involved in the packet sending process. The traffic data is then transmitted to the management scheduler, which visualizes the traffic data through the traffic dashboard. Simultaneously, the traffic dashboard can detect the Server based on the traffic data, and trigger corresponding alarms if an anomaly is detected.

[0084] Reference Figure 3This diagram illustrates the network topology provided in this embodiment of the invention. Specifically, all cloud network component types in the cluster and the required network resources can be listed first. For external gateways, a subnet needs to be applied for as the client, and a fullmesh traffic probing tool image needs to be used as the container image. For internal gateways, an Nginx image needs to be used as the container image as the server. Next, based on the data center region where the gateway is located, the corresponding computing cluster is selected to create containers and network resources. When sending packets, the gateway will forward them to the corresponding backend container using the shortest path strategy, thereby achieving stable resource coverage of the gateway. For example, a Kubernetes cluster can consist of a gateway area and a computing area. Corresponding gateway areas and computing clusters can be deployed in the same data center, and data communication can be established between different data centers. Figure 3 A gateway located in data center A can select computing clusters located in data centers B, C, and D as containers and network resources; a gateway located in data center B can select computing clusters located in data centers B, C, and D as containers and network resources, etc., and this invention does not impose any restrictions on this.

[0085] Reference Figure 4 This diagram illustrates the gateway creation process provided in an embodiment of the present invention. The specific process may include:

[0086] S401. Technicians first create an executable image of the program, then write crobJob YAML files, with each YAML file corresponding to a different gateway type. Next, the YAML files are packaged into a Helm package, and the Helm package is deployed on the selected cluster, enabling one-click deployment of multiple YAML files.

[0087] S402. Due to the characteristics of crobJob, it can be executed on the cluster at regular intervals every day to check the number of gateways and add or delete resources.

[0088] S403. The program is executable code implemented based on the network topology diagram. When the program runs, it first calls the management scheduler interface to obtain the current list of probe sources, which will be used to configure ACL network resources in the next step.

[0089] S404. When the program is running, it will obtain a list of gateways and filter gateways of a specified type or region.

[0090] S405. When the program runs, it will create Kubernetes resources such as Pods, Services, and DNATEips based on the obtained list of gateways. Among them, Eips and Services will be associated with the specified gateways.

[0091] S406. After the resource is created, the program collects information such as EIP ID, gateway ID, cluster ID, and region returned by the interface and sends it to the management scheduler. This information is used to store the probed source / probe source information and to generate probe tasks.

[0092] S407, the management scheduler will collect the detector / source information and, based on cluster / region / gateway information, form detection tasks of different dimensions, and send them to the monitoring center to generate a monitoring dashboard.

[0093] Reference Figure 5 The diagram illustrates the generation process of a detection task provided in an embodiment of the present invention. The specific process may include:

[0094] S501. Technicians inject the detection source, detection target, and necessary tag information into the database via API (Application Programming Interface) on the control device.

[0095] S502: The scheduler collects information from different dimensions such as cluster, region, and gateway type according to the pre-arranged scenario rules (management tasks, etc.), dynamically classifies the detection sources and targets, and outputs them to different detection scenario directories. Then, it generates configurations and sends them to the detection agents.

[0096] After receiving the task, the S503 Agent periodically initiates probes on the target and establishes a communication connection with the target. The target may include API server, internal / external network container, overseas network, gateway, node (pod), etc. The transmission protocol of the communication connection includes HTTP, TCP, ping, etc.

[0097] S504 and Agent report the detection results to the Monitor monitoring center, including indicators such as latency and packet loss.

[0098] S505: Technicians can set alarm configurations such as thresholds and templates for different scenarios in the monitoring center, so that the monitoring center can detect the corresponding data indicators based on the set alarm configurations.

[0099] S506 The monitoring center can send the detection results to the equipment where the technicians are located. There is a receiving device to display the detection results, so that the technicians can view the corresponding detection results in real time.

[0100] Through the above process, in the process of cloud computing continuously providing cloud services to users, corresponding probe gateways and test gateways can be built in real time for the gateways that need to be detected. This can effectively adapt to different clusters. At the same time, packets are sent from the probe gateway to the test gateway to obtain traffic data between the two. Then, based on the traffic data, the communication link is detected, and the traffic of cloud services is continuously and dynamically detected so as to carry out targeted operation and maintenance operations in a timely manner and ensure the quality of cloud services.

[0101] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0102] Reference Figure 6 The diagram illustrates a structural block diagram of a cloud service cluster detection device provided in an embodiment of the present invention, which may specifically include the following modules:

[0103] The parameter acquisition module 601 is used to acquire the gateway parameters of the cloud service cluster in response to a detection command for the cloud service cluster.

[0104] Gateway selection module 602 is used to determine the probe gateway and the test gateway from the cloud service cluster according to the gateway parameters;

[0105] The traffic acquisition module 603 is used to send packets from the probe gateway to the test gateway and acquire traffic data between the probe gateway and the test gateway during the packet sending process.

[0106] The detection module 604 is used to detect the test gateway based on the traffic data and generate a gateway detection result for the test gateway. The gateway detection result is used to characterize whether the test gateway has any communication abnormalities.

[0107] In some feasible implementations, the gateway parameters include at least the gateway type and traffic carrying capacity, and the gateway selection module 602 is specifically used for:

[0108] The probe gateway and test gateway are determined from the cloud service cluster using the gateway type and the traffic carrying capacity, where the traffic carrying capacity is the gateway's ability to access different networks or distribute traffic between different networks.

[0109] In some feasible implementations, the gateway selection module 602 is specifically used for:

[0110] If the gateway type is an external network gateway in the cluster, and the traffic carrying capacity is such that the gateway supports access from within the cluster to outside the cluster, then any gateway in any cluster in the first data center area is selected as the probe gateway, and any gateway in any cluster in the second data center area is selected as the first test gateway, or, the URL with the IP address located in the first geographical area is selected as the second test gateway, and the URL with the IP address located in the second geographical area is selected as the third test gateway.

[0111] If the gateway type is an external network gateway in the cluster, and the traffic carrying capacity is such that the gateway supports access from outside the cluster to inside the cluster, then any gateway in any cluster in the first data center area is selected as the probe gateway, and any gateway in any cluster in the second data center area is selected as the first test gateway.

[0112] If the gateway type is an external network gateway in the cluster, and the traffic carrying capacity is that the gateway supports the distribution of traffic from inside the cluster to outside the cluster, then any gateway in any cluster in the first data center area is selected as the probe gateway, and any gateway in any cluster in the second data center area is selected as the first test gateway.

[0113] If the gateway type is an external network gateway in the cluster, and the traffic carrying capacity is that the gateway supports the distribution of traffic from outside the cluster to outside the cluster, then any gateway in any cluster that supports the Istio function is selected as the probe gateway, and any gateway in any cluster in a different data center area than the probe gateway is selected as the test gateway.

[0114] In some feasible implementations, the gateway selection module 602 is specifically used for:

[0115] If the gateway type is an intranet gateway in the cluster, and the traffic carrying capacity is that the gateway supports access within the cluster, then any gateway in each cluster in each first data center area is selected as the probe gateway, and any gateway in each cluster in each second data center area is selected as the test gateway.

[0116] If the gateway type is an intranet gateway in the cluster, and the traffic carrying capacity is that the gateway supports the distribution of traffic within the cluster, then any gateway in any cluster in the first data center area is selected as the probe gateway, and any gateway in any cluster in the second data center area is selected as the first test gateway.

[0117] In some feasible implementations, the apparatus further includes:

[0118] The information acquisition module is used to acquire the first gateway information of the probe gateway and the second gateway information of the test gateway;

[0119] The task generation module is used to construct tasks based on the first gateway information and the second gateway information to obtain detection tasks for the detection gateway and the test gateway.

[0120] In some feasible implementations, the task generation module is specifically used for:

[0121] From the first gateway information and the second gateway information, at least one of the following is extracted: IP type, detection method, network type, and transmission protocol between the detection gateway and the test gateway;

[0122] A detection task is constructed for the detection gateway and the test gateway by using at least one of the IP type, the detection method, the network type, and the transmission protocol.

[0123] In some feasible implementations, the traffic acquisition module 603 is specifically used for:

[0124] A communication link is established between the probe gateway and the test gateway based on the IP type and the network type, and the probe gateway is controlled to send packets to the test gateway according to the probe method and the transmission protocol.

[0125] Among some feasible implementation methods are:

[0126] The data deletion module is used to delete the test task corresponding to the probe gateway and / or the test gateway in response to a deletion command for the probe gateway and / or the test gateway.

[0127] In some feasible implementations, the traffic data includes at least one of the following: packet loss rate, link availability, average latency of request response time, statistical quantile of request response time, and standard deviation of request response time. The detection module 604 is specifically used for:

[0128] Based on at least one of the packet loss rate, the link availability rate, the average latency of the request response time, the statistical quantile of the request response time, and the standard deviation of the request response time, the communication link between the probe gateway and the test gateway is detected, and a gateway detection result for the test gateway is generated.

[0129] Among some feasible implementation methods are:

[0130] The prompting module is used to output an alarm prompt message for the test gateway if the gateway detection result indicates that there is an abnormality in the communication link.

[0131] In some feasible implementations, the parameter acquisition module 601 is specifically used for:

[0132] In response to the detection of a change in the state of the cloud service cluster, a detection command is generated for the cloud service cluster;

[0133] The detection of changes in the cloud service cluster status includes at least the following:

[0134] The addition of a new gateway to the cloud service cluster or a change in the status of a gateway is detected.

[0135] The state changes of the gateway include at least one of the following: changes in connection state, changes in running state, changes in performance state, changes in security state, changes in configuration state, and changes in version state.

[0136] In some feasible implementations, the parameter acquisition module 601 is specifically used for:

[0137] Periodically generate detection commands for the cloud service cluster.

[0138] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0139] In addition, this invention also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the above-described cloud service cluster detection method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0140] This invention also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the above-described cloud service cluster detection method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0141] Figure 7 A schematic diagram of the hardware structure of an electronic device for implementing various embodiments of the present invention.

[0142] The electronic device 700 includes, but is not limited to, components such as: a radio frequency unit 701, a network module 702, an audio output unit 703, an input unit 704, a sensor 705, a display unit 706, a user input unit 707, an interface unit 708, a memory 709, a processor 710, and a power supply 711. Those skilled in the art will understand that the electronic device structure involved in the embodiments of the present invention does not constitute a limitation on the electronic device. An electronic device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of the present invention, the electronic device includes, but is not limited to, mobile phones, tablet computers, laptop computers, PDAs, in-vehicle terminals, wearable devices, and pedometers.

[0143] It should be understood that, in this embodiment of the invention, the radio frequency unit 701 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink data from the base station and processes it with the processor 710; additionally, it transmits uplink data to the base station. Typically, the radio frequency unit 701 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier, a duplexer, etc. Furthermore, the radio frequency unit 701 can also communicate with networks and other devices through a wireless communication system.

[0144] Electronic devices provide users with wireless broadband internet access through network module 702, such as helping users send and receive emails, browse web pages, and access streaming media.

[0145] The audio output unit 703 can convert audio data received by the radio frequency unit 701 or the network module 702 or stored in the memory 709 into audio signals and output them as sound. Furthermore, the audio output unit 703 can also provide audio output related to specific functions performed by the electronic device 700 (e.g., call signal reception sound, message reception sound, etc.). The audio output unit 703 includes a speaker, a buzzer, and a receiver, etc.

[0146] Input unit 704 is used to receive audio or video signals. Input unit 704 may include a graphics processing unit (GPU) 7041 and a microphone 7042. The GPU 7041 processes image data of still images or videos acquired by an image capture device (such as a camera) in video capture mode or image capture mode. The processed image frames can be displayed on display unit 706. The image frames processed by GPU 7041 can be stored in memory 709 (or other storage medium) or transmitted via radio frequency unit 701 or network module 702. Microphone 7042 can receive sound and process such sound into audio data. The processed audio data can be converted into a format that can be transmitted to a mobile communication base station via radio frequency unit 701 in telephone call mode.

[0147] The electronic device 700 also includes at least one sensor 705, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 7061 according to the ambient light level, and the proximity sensor can turn off the display panel 7061 and / or backlight when the electronic device 700 is moved to the ear. As a type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity and can be used to identify the posture of the electronic device (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc. The sensor 705 may also include a fingerprint sensor, pressure sensor, iris sensor, molecular sensor, gyroscope, barometer, hygrometer, thermometer, infrared sensor, etc., which will not be described in detail here.

[0148] The display unit 706 is used to display information input by the user or information provided to the user. The display unit 706 may include a display panel 7061, which may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like.

[0149] User input unit 707 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of electronic devices. Specifically, user input unit 707 includes a touch panel 7071 and other input devices 7072. Touch panel 7071, also known as a touch screen, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near touch panel 7071). Touch panel 7071 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 710, which receives and executes commands from the processor 710. In addition, touch panel 7071 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. Besides touch panel 7071, user input unit 707 may also include other input devices 7072. Specifically, other input devices 7072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, joysticks, etc., which will not be described in detail here.

[0150] Furthermore, the touch panel 7071 can cover the display panel 7061. When the touch panel 7071 detects a touch operation on or near it, it transmits the information to the processor 710 to determine the type of touch event. Subsequently, the processor 710 provides corresponding visual output on the display panel 7061 according to the type of touch event. It is understood that in one embodiment, the touch panel 7071 and the display panel 7061 are implemented as two independent components to realize the input and output functions of the electronic device. However, in some embodiments, the touch panel 7071 and the display panel 7061 can be integrated to realize the input and output functions of the electronic device. The specific implementation is not limited here.

[0151] Interface unit 708 serves as an interface for connecting external devices to electronic device 700. For example, external devices may include a wired or wireless headphone port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device with an identification module, an audio input / output (I / O) port, a video I / O port, a headphone port, and so on. Interface unit 708 can be used to receive input from external devices (e.g., data, power, etc.) and transmit the received input to one or more components within electronic device 700, or it can be used to transmit data between electronic device 700 and external devices.

[0152] The memory 709 can be used to store software programs and various data. The memory 709 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback, image playback, etc.), etc.; the data storage area may store data created based on the use of the mobile phone (such as audio data, phonebook, etc.). Furthermore, the memory 709 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0153] The processor 710 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 709, and by calling data stored in the memory 709, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. The processor 710 may include one or more processing units; preferably, the processor 710 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 710.

[0154] The electronic device 700 may also include a power supply 711 (such as a battery) for supplying power to various components. Preferably, the power supply 711 is logically connected to the processor 710 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system.

[0155] In addition, the electronic device 700 includes some functional modules not shown, which will not be described in detail here.

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

[0157] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0158] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

[0159] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0160] Those skilled in the art will 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.

[0161] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0162] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0163] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0164] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

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

Claims

1. A method for detecting cloud service clusters, characterized in that, include: In response to a detection command for a cloud service cluster, the gateway parameters of the cloud service cluster are obtained, wherein the detection command includes a command generated when a state change of the cloud service cluster is detected; The probe gateway and test gateway are determined from the cloud service cluster based on the gateway parameters. The probe gateway sends packets to the test gateway, acquires traffic data between the probe gateway and the test gateway during the packet sending process, and visualizes the traffic data. The test gateway is detected based on the traffic data, and a gateway detection result is generated for the test gateway. The gateway detection result is used to characterize whether there is a communication anomaly in the test gateway.

2. The method according to claim 1, characterized in that, The gateway parameters include at least the gateway type and traffic carrying capacity. The step of determining the probe gateway and test gateway from the cloud service cluster based on the gateway parameters includes: Based on the gateway type and the traffic carrying capacity, a probe gateway and a test gateway are determined from the cloud service cluster. The traffic carrying capacity is the gateway's ability to access different networks or distribute traffic between different networks.

3. The method according to claim 2, characterized in that, The step of determining the probe gateway and test gateway from the cloud service cluster based on the gateway type and the traffic carrying capacity includes: If the gateway type is an external network gateway in the cluster, and the traffic carrying capacity is such that the gateway supports access from within the cluster to outside the cluster, then any gateway in any cluster in the first data center area is selected as the probe gateway, and any gateway in any cluster in the second data center area is selected as the first test gateway, or, the URL with the IP address located in the first geographical area is selected as the second test gateway, and the URL with the IP address located in the second geographical area is selected as the third test gateway. If the gateway type is an external network gateway in the cluster, and the traffic carrying capacity is such that the gateway supports access from outside the cluster to inside the cluster, then any gateway in any cluster in the first data center area is selected as the probe gateway, and any gateway in any cluster in the second data center area is selected as the first test gateway. If the gateway type is an external network gateway in the cluster, and the traffic carrying capacity is that the gateway supports the distribution of traffic from inside the cluster to outside the cluster, then any gateway in any cluster in the first data center area is selected as the probe gateway, and any gateway in any cluster in the second data center area is selected as the first test gateway. If the gateway type is an external network gateway in the cluster, and the traffic carrying capacity is that the gateway supports the distribution of traffic from outside the cluster to outside the cluster, then any gateway in any cluster that supports the Istio function is selected as the probe gateway, and any gateway in any cluster in a different data center area than the probe gateway is selected as the test gateway.

4. The method according to claim 2, characterized in that, The step of determining the probe gateway and test gateway from the cloud service cluster based on the gateway type and the traffic carrying capacity includes: If the gateway type is an intranet gateway in the cluster, and the traffic carrying capacity is that the gateway supports access within the cluster, then any gateway in each cluster in each first data center area is selected as the probe gateway, and any gateway in each cluster in each second data center area is selected as the test gateway. If the gateway type is an intranet gateway in the cluster, and the traffic carrying capacity is that the gateway supports the distribution of traffic within the cluster, then any gateway in any cluster in the first data center area is selected as the probe gateway, and any gateway in any cluster in the second data center area is selected as the first test gateway.

5. The method according to claim 1, characterized in that, After determining the probe gateway and test gateway from the cloud service cluster based on the gateway parameters, the method further includes: Obtain the first gateway information of the probe gateway and the second gateway information of the test gateway; Based on the first gateway information and the second gateway information, a task is constructed to obtain a detection task for the detection gateway and the test gateway.

6. The method according to claim 5, characterized in that, The step of constructing a task based on the first gateway information and the second gateway information to obtain a probe task for the probe gateway and the test gateway includes: From the first gateway information and the second gateway information, at least one of the following is extracted: IP type, detection method, network type, and transmission protocol between the detection gateway and the test gateway; A detection task is constructed for the detection gateway and the test gateway by using at least one of the IP type, the detection method, the network type, and the transmission protocol.

7. The method according to claim 6, characterized in that, The step of sending packets from the probe gateway to the test gateway includes: A communication link is established between the probe gateway and the test gateway based on the IP type and the network type, and the probe gateway is controlled to send packets to the test gateway according to the probe method and the transmission protocol.

8. The method according to any one of claims 1 to 7, characterized in that, Also includes: In response to a deletion command for the probe gateway and / or the test gateway, the test task corresponding to the probe gateway and / or the test gateway is deleted.

9. The method according to claim 1, characterized in that, The traffic data includes at least one of the following: packet loss rate, link availability, average latency of request response time, statistical quantile of request response time, and standard deviation of request response time. The step of detecting the test gateway based on the traffic data and generating gateway detection results for the test gateway includes: Based on at least one of the packet loss rate, the link availability rate, the average latency of the request response time, the statistical quantile of the request response time, and the standard deviation of the request response time, the communication link between the probe gateway and the test gateway is detected, and a gateway detection result for the test gateway is generated.

10. The method according to claim 9, characterized in that, Also includes: If the gateway detection result indicates that there is an anomaly in the communication link, an alarm message will be output for the test gateway.

11. The method according to claim 1, characterized in that, in, The detected changes in the cloud service cluster status include at least the following: The addition of a new gateway to the cloud service cluster or a change in the status of a gateway is detected. The state changes of the gateway include at least one of the following: changes in connection state, changes in running state, changes in performance state, changes in security state, changes in configuration state, and changes in version state.

12. The method according to claim 1, characterized in that, Also includes: Periodically generate detection commands for the cloud service cluster.

13. A detection device for a cloud service cluster, characterized in that, include: The parameter acquisition module is used to acquire the gateway parameters of the cloud service cluster in response to a detection command for the cloud service cluster. The detection command includes a command generated when a state change of the cloud service cluster is detected. The gateway selection module is used to determine the probe gateway and the test gateway from the cloud service cluster based on the gateway parameters; The traffic acquisition module is used to send packets from the probe gateway to the test gateway, acquire traffic data between the probe gateway and the test gateway during the packet sending process, and visualize the traffic data. The detection module is used to detect the test gateway based on the traffic data and generate a gateway detection result for the test gateway. The gateway detection result is used to characterize whether the test gateway has any communication abnormalities.

14. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method as described in any one of claims 1-12.

15. A computer-readable storage medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the method as described in any one of claims 1-12.

Citation Information

Patent Citations

  • Gateway equipment testing method and device, electronic equipment and storage medium

    CN115996182A

  • Traffic scheduling method and device for cloud gateway, computer equipment and medium

    CN116155816A