Service assurance method and system

Abstract

The embodiments of the present specification provide a service guarantee method and system, wherein the service guarantee system comprises: a center server and a scheduling server; the center server is configured to obtain service state data of a target server, perform anomaly analysis on the service state data, generate a service anomaly detection result of the target server, send configuration data for generating a transmission link to the scheduling server through a first data transmission channel, and send the service anomaly detection result to the scheduling server through a second data transmission channel; and the scheduling server is configured to obtain the configuration data from the center server through the first data transmission channel, obtain the service anomaly detection result from the center server through the second data transmission channel, and detect an abnormal link in a candidate transmission link corresponding to to-be-transmitted data according to the configuration data and the service anomaly detection result.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of computer technology, and in particular to service assurance methods and systems. Background Technology

[0002] Cloud services are services that provide computing and storage resources via the internet in an on-demand and easily scalable manner. Currently, to cover a wider range of scenarios and provide better services to as many users as possible, cloud services are typically provided through a combination of central servers and edge servers. Consequently, the network providing cloud services features diverse server software and hardware, complex transmission links, and an unstable service environment.

[0003] However, in practical applications, users require stable services. Therefore, how to provide stable services in unstable environments is a problem that cloud service providers urgently need to solve. Summary of the Invention

[0004] In view of this, embodiments of this specification provide a service assurance system. One or more embodiments of this specification also relate to service assurance methods, service assurance devices, computing devices, computer-readable storage media, and computer programs to address technical deficiencies in the prior art.

[0005] According to a first aspect of the embodiments of this specification, a service assurance system is provided, comprising: a central server and a scheduling server; the central server is configured to acquire service status data of a target server, perform anomaly analysis on the service status data, generate a service anomaly detection result for the target server, send configuration data for generating a transmission link to the scheduling server through a first data transmission channel, and send the service anomaly detection result to the scheduling server through a second data transmission channel; the scheduling server is configured to obtain the configuration data from the central server through the first data transmission channel, obtain the service anomaly detection result from the central server through the second data transmission channel, and detect abnormal links among candidate transmission links corresponding to data to be transmitted based on the configuration data and the service anomaly detection result.

[0006] According to a second aspect of the embodiments of this specification, a service assurance method is provided, comprising: acquiring service status data of a target server; performing anomaly analysis on the service status data of the target server to generate a service anomaly detection result of the target server; sending configuration data for generating a transmission link to a scheduling server through a first data transmission channel; and sending the service anomaly detection result to the scheduling server through a second data transmission channel.

[0007] According to a third aspect of the embodiments of this specification, a service assurance method is provided, comprising: obtaining configuration data for generating transmission links from a central server through a first data transmission channel; obtaining service anomaly detection results of a target server from the central server through a second data transmission channel; and detecting abnormal links among candidate transmission links corresponding to data to be transmitted based on the configuration data and the service anomaly detection results.

[0008] According to a fourth aspect of the embodiments of this specification, a computing device is provided, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, wherein the computer-executable instructions, when executed by the processor, implement the steps of the service assurance method described in any embodiment of this specification.

[0009] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of the service assurance method described in any embodiment of this specification.

[0010] According to a sixth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the service assurance method described in any embodiment of this specification.

[0011] This specification provides a service assurance system in one embodiment. In this system, the central server obtains the service status data of the target server. Therefore, the central server can perceive the service status of the target server and perform anomaly analysis on the service status data of the target server, generating a service anomaly detection result for the target server. The scheduling server obtains the configuration data through a first data transmission channel with the central server and obtains the service anomaly detection result through a second data transmission channel with the central server. Moreover, the amount of service anomaly detection result data that is updated at any time is relatively small. Therefore, the periodic or on-demand update of the configuration data with a large data scale through the first data transmission channel does not affect the timely update of the service anomaly detection result through the second data transmission channel, and they do not interfere with each other. The scheduling server can obtain the service anomaly detection result with extremely short latency. Then, based on the configuration data and the service anomaly detection result, it can promptly detect abnormal links in the candidate transmission links corresponding to the data to be transmitted, so that the data to be transmitted can escape from the abnormal links in a timely manner, further ensuring the stability of the service.

[0012] Another embodiment of this specification provides a service assurance method. Since the method obtains the service status data of the target server, it can perceive the service status of the target server, and then perform anomaly analysis on the service status data of the target server to generate the service anomaly detection result of the target server. The configuration data used to generate the transmission link is sent to the scheduling server through the first data transmission channel, and the service anomaly detection result is sent to the scheduling server through the second data transmission channel. This enables the scheduling server to obtain the service anomaly detection result with extremely short latency, promptly detect abnormal links in the candidate transmission links corresponding to the data to be transmitted, and enable the data to be transmitted to escape from the abnormal links in a timely manner, thus ensuring the stability of the service.

[0013] Another embodiment of this specification provides a service assurance method. This method obtains configuration data for generating transmission links from a central server through a first data transmission channel and obtains service anomaly detection results of the target server from the central server through a second data transmission channel. This allows the method to detect abnormal links among the candidate transmission links corresponding to the data to be transmitted based on the configuration data and the service anomaly detection results, thereby filtering abnormal links and enabling the data to be transmitted to escape from abnormal links in a timely manner, thus ensuring the stability of the service. Attached Figure Description

[0014] Figure 1a This is a block diagram of a service assurance system provided in one embodiment of this specification;

[0015] Figure 1b This specification provides a schematic diagram of an application scenario for a service assurance system, based on one embodiment.

[0016] Figure 2 This is a flowchart illustrating a service assurance method provided in one embodiment of this specification;

[0017] Figure 3 This is a schematic diagram of the service status detection module layout provided in one embodiment of this specification;

[0018] Figure 4 This is a schematic diagram of the service guarantee device provided in one embodiment of this specification;

[0019] Figure 5 This is a flowchart illustrating a service assurance method provided in another embodiment of this specification;

[0020] Figure 6 This is a schematic diagram of the architecture of a service assurance system provided in one embodiment of this specification;

[0021] Figure 7 This is a schematic diagram of the service guarantee device provided in one embodiment of this specification;

[0022] Figure 8 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0023] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0024] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0025] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0026] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0027] A Content Delivery Network (CDN) is an intelligent network built on top of the existing network infrastructure. Through the load balancing, content distribution, and scheduling functions of a central server, it enables users to obtain the content they need from edge servers deployed in various locations, thereby reducing network congestion and improving access response speed and hit rate.

[0028] A central server is a server located relatively far from users in a content delivery network (CDN), and its capabilities include, but are not limited to, providing resource scheduling. Edge servers are servers located relatively close to users in a CDN. Multiple edge servers can exist within a CDN, providing storage, computing, and networking resources. In a CDN, various user terminals collect massive amounts of data. Smaller, localized data requiring real-time processing is handled locally on edge servers, while complex, large-scale, global tasks are aggregated and analyzed by the central server. The central and edge servers are centrally managed and intelligently scheduled, thereby optimizing the allocation of computing power. Therefore, offloading some critical tasks to the edge of the access network can reduce bandwidth and latency losses caused by network transmission and multi-level forwarding.

[0029] A transmission link is a transmission path formed by the connection between devices in a network. These devices may include physical devices and / or virtual devices.

[0030] A scheduling server is a server that schedules traffic. The scheduling server described in this specification detects abnormal links in the candidate transmission links of traffic, allowing traffic to escape from these abnormal links, thus providing service assurance. For example, in practical applications, the scheduling server can function as a domain name server. After resolving the domain name of a user request, the domain name server obtains candidate transmission links and detects abnormal links among them.

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

[0032] In content delivery networks (CDNs), edge servers are closer to users and have lower network latency, enabling them to cover a wider range of scenarios and provide better services to as many users as possible. Edge servers are distributed across thousands of nodes globally, handling hundreds of terabytes of traffic. These massive edge server clusters operate in complex and diverse server and network environments. Providing stable service in such complex environments requires making quick and correct escape decisions and rapidly mobilizing massive services handling hundreds of terabytes of traffic to escape anomalies—no easy task. Therefore, providing stable service in unstable environments is a critical problem that cloud services urgently need to solve.

[0033] In view of this, a service assurance method is provided in this specification. This specification also relates to service assurance devices, service assurance systems, computing devices, and computer-readable storage media, which are described in detail in the following embodiments.

[0034] See Figure 1a Figure 1 shows a block diagram of a service assurance system provided according to one embodiment of this specification. Figure 1a As shown, the service guarantee system may include: a central server 110 and a scheduling server 120.

[0035] The central server 110 is configured to acquire service status data of the target server, perform anomaly analysis on the service status data, generate service anomaly detection results of the target server, send configuration data for generating transmission links to the scheduling server through the first data transmission channel, and send the service anomaly detection results to the scheduling server through the second data transmission channel.

[0036] The scheduling server 120 is configured to obtain the configuration data from the central server through the first data transmission channel, obtain the service anomaly detection result from the central server through the second data transmission channel, and detect abnormal links in the candidate transmission links corresponding to the data to be transmitted based on the configuration data and the service anomaly detection result.

[0037] In the service assurance system provided in the embodiments of this specification, the scheduling server can be set up at any location in the content delivery network as needed. The scheduling server can be implemented as a server with only service assurance functions, or it can be implemented as a server that also includes other functions; this specification does not impose any limitations on this.

[0038] See Figure 1b , Figure 1b A schematic diagram illustrating an application scenario of a service assurance system according to an embodiment of this specification is shown. Figure 1b As shown, in an application scenario where the scheduling server provides service assurance to the edge server, the scheduling server can, as follows: Figure 1b As shown, the system communicates with both the central server and the edge servers, allowing data to escape from the transmission links of edge servers experiencing anomalies. Accordingly, the target server detected by the service status detection module can refer to the edge server.

[0039] Of course, the scheduling server can also be applied to service assurance scenarios for the central server. Accordingly, the scheduling server can be located in a network close to the central server, allowing data to escape from the transmission link of the central server experiencing anomalies. The target server detected by the service status detection module can refer to any central server.

[0040] To improve the accuracy of service status data detection, the same target server in the system can be detected by multiple service status detection modules, thereby reducing the volatility of service status data detected by a single service status detection module. Since there may be situations where individual service status detection modules experience network anomalies with the target server being detected, but the target server is still providing normal service, to minimize judgment errors caused by problems with the service status detection modules themselves, in one or more embodiments of this specification, multiple service status detection modules are positioned on different transmission links of the target server to detect the same target server. Since there can be multiple target servers, the multiple service status detection modules and multiple target servers can communicate as follows: Figure 3 The diagram shows a many-to-many relationship.

[0041] Taking the application scenario of a scheduling server providing service assurance for edge servers as an example, the stable operation of edge server services relies on a robust global awareness system and rapid escape capabilities. According to the service assurance system provided in the embodiments of this specification, on the one hand, the central server can obtain service status data of the edge servers through service status detection modules set on different transmission links, thereby comprehensively, quickly, and accurately perceiving anomalies at various levels of the network, analyzing and deciding on service anomaly detection results; on the other hand, the scheduling server can obtain configuration data for generating transmission links through a first data transmission channel and service anomaly detection results through a second data transmission channel. The long-term periodic updates of large-scale configuration data do not affect the timely updates of smaller-scale service anomaly detection results, improving the timeliness of anomaly perception. Based on the configuration data and the service anomaly detection results, the scheduling server detects abnormal links in the candidate transmission links corresponding to the data to be transmitted and can quickly execute escape, causing the traffic corresponding to the data to be transmitted to be quickly diverted away from the problematic edge server or area in a short time. The faster the execution, the lower the probability that users perceive the service anomaly, achieving the goal of rapid anomaly escape as unnoticed as possible, making the service more stable.

[0042] The servers described in this specification can include servers that provide various services, such as servers that provide communication services to multiple clients, servers that support backend training of models used on clients, and servers that process data sent by clients. It should be noted that the servers described in this specification can be implemented as a distributed server cluster composed of multiple servers, or as a single server. Servers can also be servers in a distributed system, or servers integrated with blockchain. Servers can also be cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, or intelligent cloud computing servers or intelligent cloud hosts with artificial intelligence technology.

[0043] See Figure 2 , Figure 2 A flowchart of a service assurance method according to an embodiment of this specification is shown. The service assurance method provided in this embodiment can be applied to a central server. The method specifically includes the following steps.

[0044] Step 202: Obtain the service status data of the target server.

[0045] The target server can be any one or more servers in a content delivery network.

[0046] In one or more embodiments of this specification, in order to improve the detection accuracy of service status data, the step of obtaining the service status data of the target server includes:

[0047] The system acquires service status data detected by multiple service status detection modules, which are set up on different transmission links of the target server to detect the same target server.

[0048] The service status detection module is a component used to detect the service status of the target server. The service status detection module can be installed on any number of transmission links of the target server.

[0049] The service status data is data used to indicate the service availability of the target server. The service status data may include Boolean values ​​such as available / unavailable and / or transmission performance metrics. For example, the service status data may include any one or more of the following: transmission performance metrics for data transmitted based on the Internet Control Message Protocol (TCP), transmission performance metrics for data transmitted based on the User Datagram Protocol (UDP), transmission performance metrics for data transmitted based on the Transmission Control Protocol (TCP), transmission performance metrics for data transmitted based on the Hypertext Transfer Protocol (HTTP), and transmission performance metrics for data transmitted based on the Hypertext Transfer Security Protocol (HTTP). More specifically, for example, the service status data may include any one or more performance metrics such as TCP (Transmission Control Protocol) packet loss rate and ICMP (Internet Control Message Protocol) packet loss rate.

[0050] Depending on the specific application scenario, any method can be used to detect performance metrics representing the service availability of the target server. For example, in one or more embodiments of this specification, the detection performed by the service status detection module may include any one or more of the following service status detection categories:

[0051] Service status detection for data transmitted based on the Internet Control Message Protocol;

[0052] Service status detection for data transmitted based on the User Datagram Protocol;

[0053] Service status detection for data transmitted based on the Transmission Control Protocol;

[0054] Service status detection for data transmitted based on the Hypertext Transfer Protocol;

[0055] Service status detection based on data transmitted using the Hypertext Transfer Security Protocol.

[0056] In the above embodiments, service status detection can be performed on transmitted data based on various transmission protocols sent to the target server. Due to the rich variety of detection categories, a comprehensive analysis of the target server's service availability is possible. Therefore, this embodiment enables a more comprehensive, rapid, and accurate perception of anomalies at various layers of the network. Furthermore, detection can be performed at a finer granular level, segmented by network layer. For example, the Internet Control Message Protocol (ICP) has three layers, the User Datagram Protocol (UDP) has four layers, the Transmission Control Protocol (TCP) has four layers, the Hypertext Transfer Protocol (HTTP) has seven layers, and the Hypertext Transfer Security Protocol (HTTP) has seven layers; one or more layers can be detected separately as needed.

[0057] The target server can be any server in the cloud; the specific target server to be detected is set according to the application scenario. Below, we will combine this with... Figure 3 The schematic diagram of the service status detection module shown illustrates an example of how the service status detection module performs service status detection on edge servers.

[0058] In the cloud where edge servers reside, virtual servers are typically used as local load balancers, and a group of real servers, known as RSs (Real Servers), are mounted behind the virtual servers to provide services. User requests use the virtual server's VIP (Virtual IP) as the target IP (Internet Protocol) address to access the service. The virtual server forwards these requests to the RSs mounted behind it for processing, and the RSs then respond to the user. However, uncontrollable public networks, imperfect operational configurations, and unpredictable emergencies significantly threaten the availability of the virtual server's VIP. Therefore, in one or more embodiments of this specification, as... Figure 3 As shown, the virtual server is used as an edge server to be monitored, and the system checks whether the virtual server's VIP can provide normal service. Specifically, the service status detection module simulates user access to the VIP to obtain service status data, thus achieving service availability awareness of cloud services. Figure 3 As shown in one or more embodiments of this specification, cloud service availability awareness consists of two parts: a service status detection module and a decision module located on a central server. The service status detection module is responsible for detecting and notifying the detected service status data to the decision module, which then performs anomaly analysis on the service status data to determine the availability of the corresponding VIP. The service status detection module and the decision module are deployed separately in a many-to-one relationship. The service status detection module is deployed in different locations throughout the network, forming various detection sources. For example, the service status detection module can be deployed on L1 nodes (primary nodes), L2 nodes (secondary nodes), and / or clients of the content delivery network.

[0059] In the system provided in the embodiments of this specification, the same target server is probed by multiple service status detection modules. This is to reduce the volatility of the service status detection results detected by a single service status detection module and its impact on the evaluation of service anomaly detection results of the target server. Since there may be situations where individual service status detection modules experience network anomalies with the probed target server, but the probed target server can still provide normal service, in order to minimize judgment errors caused by problems with the service status detection modules themselves, one or more embodiments of this specification may allocate a suitable set of service status detection modules to the target server according to a certain strategy. Specifically, for example, a suitable set of service status detection modules may be selected and set for the target server based on factors such as the geographical location of the service status detection modules, the supported detection categories, and the needs of the service area and service content corresponding to the target server.

[0060] Step 204: Perform anomaly analysis on the service status data of the target server to generate service anomaly detection results for the target server.

[0061] The anomaly analysis can be conducted in any manner depending on the specific application scenario. It is essential to fully consider the diverse nature of the factors causing the target server to malfunction and to classify them in detail.

[0062] The service anomaly detection result is information used to describe whether the target server is experiencing service anomalies or the degree of anomaly.

[0063] For example, in application scenarios where the target server to be detected is a virtual edge server, for any virtual server, the number of unavailable real servers obtained from recent rounds of detection can be combined, and the result can be divided by the total number of real servers connected to it. This value can be used as the error rate to reflect the degree of unavailability. As another example, for any virtual server, the sum of error rates over a preset historical period can be calculated. Based on preset anomaly judgment rules, transmission performance indicators such as TCP packet loss rate and ICMP packet loss rate can be judged to obtain a transmission performance anomaly judgment result. When the sum of the transmission performance anomaly judgment result and / or error rate of any virtual server meets the preset service anomaly judgment condition, the transmission link where that virtual server is located is determined to be an abnormal link, and the transmission link is marked, thus obtaining the service anomaly detection result.

[0064] To more accurately analyze service anomaly detection results, in one or more embodiments of this specification, the step of performing anomaly analysis on the service status data of the target server and generating service anomaly detection results for the target server includes:

[0065] By utilizing the service status data detected multiple times by the multiple service status detection modules, the distribution data of the service status detection modules that failed detection, the failure categories corresponding to the failures, and the transmission logs of the transmission links in the network, anomaly analysis is performed to generate the service anomaly detection results for the target server.

[0066] The distribution data of the service status detection modules that failed to access the target server, as simulated by a user, refers to the geographical distribution and / or temporal distribution data of these service status detection modules. Based on this distribution data, it is possible to pinpoint the region where the target server experiencing service anomalies is located and the time period during which the anomalies occurred, thereby helping to generate more accurate service anomaly detection results.

[0067] The failure categories corresponding to the detection failures can be categorized according to the actual application scenario. For example, the failure categories can correspond to the aforementioned service status detection categories, with different service status detection categories corresponding to different failure categories. For instance, if the access packet loss rate exceeds a preset packet loss rate threshold, the failure category can be packet loss. As another example, if the access feedback delay exceeds a preset delay threshold, the failure category can be timeout.

[0068] The transmission logs of the transmission links in the network can be obtained from the log database, and the log information recorded therein can be analyzed.

[0069] In addition, depending on the actual application scenario, it can also obtain abnormal information detected by other network anomaly monitoring components in the network and combine this network anomaly information for analysis.

[0070] According to the above embodiments, based on the service status data obtained from multiple detections, the distribution data corresponding to the detection failures, the failure categories and transmission logs, the diversity of factors that cause the target server to be unable to provide normal service is fully considered, and detailed analysis is carried out from various angles, so as to analyze more accurate service anomaly detection results.

[0071] Step 206: Send the configuration data used to generate the transmission link to the scheduling server through the first data transmission channel.

[0072] The configuration data refers to the scheduling-related data provided by the central server to the scheduling server to ensure that traffic reaches the target edge server on demand. For example, in an application scenario where a VIP accepts user access, the configuration data includes at least the domain name and the VIP. Depending on the actual application scenario, it may also include node information, scheduling policies, and / or IP database information. The domain name is a string of names separated by dots, representing the name of a computer or group of computers on the Internet, used as a location identifier (sometimes also referring to geographical location) for data transmission. The node information refers to the information of the server cluster; one node corresponds to one server cluster. A content delivery network can include multiple nodes, i.e., multiple server clusters. For example, scheduling servers, represented by DNS (Domain Name System), HTTPDNS (a system based on Hypertext Transfer Protocol and domain name resolution), and 302 servers, need to migrate user traffic to different edge servers according to the scheduling policies given by the central server. Therefore, in a large-scale edge server cluster, the scheduling server needs to read massive amounts of configuration data, including domain names, node information, VIPs, scheduling policies, IP databases, and other types of configuration data.

[0073] Step 208: Send the service anomaly detection result to the scheduling server through the second data transmission channel.

[0074] The data transmission channel refers to the data transmission channel built to transmit data from the central server to the scheduling server. For example, the central server can build a transmission channel based on existing data transmission services, distributing data stored centrally to edge servers through the transmission channel. It is understood that the first data transmission channel and the second data transmission channel are two independent data transmission channels. The first data transmission channel is used to transmit the central server's configuration data to the scheduling server; the second data transmission channel is used to transmit the central server's service anomaly detection results to the scheduling server. Because two independent data transmission channels are used to transmit the two types of data, they do not interfere with each other, improving transmission efficiency.

[0075] Because this method obtains the service status data of the target server, it can perceive the service status of the target server, and then perform anomaly analysis on the service status data. It can generate the service anomaly detection result of the target server, send the configuration data for generating the transmission link to the scheduling server through the first data transmission channel, and send the service anomaly detection result to the scheduling server through the second data transmission channel. This allows the scheduling server to obtain the service anomaly detection result with extremely short latency, promptly detect abnormal links in the candidate transmission links corresponding to the data to be transmitted, and ensure that the data to be transmitted escapes from the abnormal links in a timely manner, thus guaranteeing the stability of the service.

[0076] Corresponding to the above method embodiments, this specification also provides a service assurance device embodiment, which can be configured on a central server. Figure 4 A schematic diagram of a service assurance device according to one embodiment of this specification is shown. Figure 4 As shown, the device includes:

[0077] The status data acquisition module 402 can be configured to acquire service status data of the target server.

[0078] The anomaly analysis module 404 can be configured to perform anomaly analysis on the service status data of the target server and generate service anomaly detection results for the target server.

[0079] The first sending module 406 can be configured to send configuration data for generating the transmission link to the scheduling server through the first data transmission channel.

[0080] The second sending module 408 can be configured to send the service anomaly detection result to the scheduling server through the second data transmission channel.

[0081] In one or more embodiments of this specification, the status data acquisition module can be configured to acquire service status data detected by multiple service status detection modules, wherein the multiple service status detection modules are set on different transmission links of the target server and perform detection on the same target server.

[0082] In one or more embodiments of this specification, the anomaly analysis module can be configured to perform anomaly analysis using service status data detected multiple times by the plurality of service status detection modules, distribution data of service status detection modules that failed detection, failure categories corresponding to detection failures, and transmission logs of transmission links in the network, and generate service anomaly detection results for the target server.

[0083] The above is an illustrative scheme of a service assurance device according to this embodiment. It should be noted that the technical solution of this service assurance device and the technical solution of the above-described service assurance method belong to the same concept. For details not described in detail in the technical solution of the service assurance device, please refer to the description of the technical solution of the above-described service assurance method.

[0084] See Figure 5 , Figure 5 A flowchart of a service assurance method according to another embodiment of this specification is shown. The service assurance method provided in this embodiment can be applied to a scheduling server. The method specifically includes the following steps.

[0085] Step 502: Obtain configuration data for generating the transmission link from the central server through the first data transmission channel.

[0086] The configuration data can refer to the overall configuration data of the content delivery network, or it can refer to a part of the content delivery network, such as the configuration data of the cloud where the central server is located or the cloud where the edge server is located.

[0087] For example, in the application scenario of central service assurance, the method provided in this embodiment can be applied to the scheduling server of the cloud where the central server is located.

[0088] For example, in the application scenario of edge service assurance, the method provided in this embodiment can be applied to the scheduling server of the cloud where the edge server is located. The scheduling server can obtain configuration data for generating transmission links from the central server.

[0089] For details regarding the specific content of the configuration data, please refer to the above description of the service assurance method applied to the central server; further details will not be provided here.

[0090] Step 504: Obtain the service anomaly detection result of the target server from the central server through the second data transmission channel.

[0091] For example, in the application scenario of central service assurance, the method provided in this embodiment can be applied to the scheduling server of the cloud where the central server is located.

[0092] For example, in the application scenario of edge service assurance, the method provided in this embodiment can be applied to the scheduling server of the cloud where the edge server is located. The scheduling server can obtain service anomaly detection results from the central server.

[0093] The method for generating the service anomaly detection results can be found in the description of the service assurance method applied to the central server described above, and will not be elaborated further here. For example, the service anomaly detection results can be used to indicate which target servers are abnormal and unavailable. This means that after obtaining the service anomaly detection results, the domain name server's scheduling server can promptly modify the resolution results of data to be transmitted that was originally scheduled to these target servers, ensuring that subsequent requests are kept away from these abnormal target servers.

[0094] Step 506: Based on the configuration data and the service anomaly detection results, detect abnormal links in the candidate transmission links corresponding to the data to be transmitted.

[0095] The abnormal link refers to the transmission link where the target server is located and cannot provide services to users normally.

[0096] The data to be transmitted can be user service-related data. For example, the data to be transmitted can be user request data that needs to be processed by an edge server, or data that needs to be distributed to users by a central server, and so on.

[0097] The candidate transmission links are generated based on the configuration data and the destination corresponding to the data to be transmitted. Each transmission link contains server information, and the service anomaly detection result indicates which target servers are abnormal or the degree of abnormality. Therefore, based on the service anomaly detection result, abnormal links can be identified from the candidate transmission links. Since multiple virtual servers typically provide the same service in a content delivery network, there are multiple candidate destinations for the data to be transmitted. With multiple virtual servers available to provide the service, there are correspondingly multiple candidate transmission links for the data to be transmitted. Abnormal links may exist among these multiple candidate transmission links; therefore, the scheduling server needs to detect these abnormal links in order to escape from them.

[0098] For example, in one or more embodiments of this specification, detecting abnormal links in the candidate transmission links corresponding to the data to be transmitted based on the configuration data and the service anomaly detection result includes:

[0099] Based on the service anomaly detection results and the configuration data, an abnormal link is generated;

[0100] The abnormal link is compared with the candidate transmission link corresponding to the data to be transmitted to determine the abnormal link among the candidate transmission links corresponding to the data to be transmitted.

[0101] In this embodiment, instead of changing the existing candidate transmission link generation method to avoid generating abnormal links, abnormal links are removed from the candidate transmission links based on the existing method. This is equivalent to achieving escape from abnormal links through filtering, which reduces the difficulty of system modification and facilitates implementation.

[0102] Furthermore, after detecting abnormal links from the candidate transmission links for the data to be transmitted, the system can further trigger the replacement of the candidate transmission links in a timely manner based on feedback. Specifically, after detecting abnormal links in the candidate transmission links corresponding to the data to be transmitted, the system further includes:

[0103] The abnormal link is removed from the candidate transmission link corresponding to the data to be transmitted, and an updated candidate transmission link is obtained.

[0104] Determine whether the updated candidate transmission link meets the transmission requirements corresponding to the data to be transmitted;

[0105] If the conditions are not met, the candidate transmission link for the user request will be replaced.

[0106] The above embodiment is equivalent to inserting an anomaly detection process after the candidate transmission link parsing process. After obtaining the candidate transmission links for the data to be transmitted, it is compared with the abnormal links. If a match is found, the parsing is considered to have triggered an escape rule, and the abnormal link is removed. Then, it is determined whether the candidate transmission links after removing the abnormal links can meet the user request. If not, feedback is given to the parsing process to change the parsing result. Through this embodiment, the parsing process can be triggered in a timely manner to change the candidate transmission links, thereby improving data transmission efficiency.

[0107] In addition, after triggering the replacement of the candidate transmission link for the user request, the method may further include: detecting abnormal links in the replaced candidate transmission links based on the configuration data and the service anomaly detection results, so as to further ensure the stability of the service.

[0108] Since this method obtains the configuration data used to generate transmission links in the network and obtains the network service anomaly detection results, it can detect abnormal links in the candidate transmission links corresponding to the data to be transmitted based on the configuration data and the service anomaly detection results, thereby filtering abnormal links and enabling the data to be transmitted to escape from abnormal links in a timely manner, ensuring the stability of the service.

[0109] Below, in conjunction with, for example Figure 6 The schematic diagram of the service assurance system shown illustrates an exemplary implementation of how the scheduling server obtains configuration data and service anomaly detection results from the central server.

[0110] like Figure 6The service assurance system shown may include: a central server, a database, and a scheduling server.

[0111] The central server may include a decision-making module, a flow control module, and a central data storage module. It should be noted that the central server can be implemented as a single server or as a server cluster with multiple servers cooperating with each other; this embodiment does not impose any limitations on this. For example, the decision-making module and the flow control module can be respectively located in different servers within the central server cluster, implementing them as a decision-making server and a flow control server, etc.

[0112] The database can be constructed using various database technologies, such as SQL databases, and this specification does not impose any restrictions on it.

[0113] The scheduling server may include: an update module, a request receiver, a request parser, an anomaly detector, a request responder, an anomaly pool, and a data updater. The update module may include a data loading submodule and memory.

[0114] Specifically, the decision module acquires service status data detected by the service status detection module and analyzes the data to generate service anomaly detection results. The decision module sends these results to the flow control module. The flow control module generates a global scheduling policy based on bandwidth, CPU (Central Processing Unit), memory, and resource information. After obtaining the service anomaly detection results, the flow control module marks the target servers corresponding to these results, ensuring that the generated scheduling policy does not include policies that route traffic to these abnormal target servers. At this point, the scheduling policy incorporates information from the service anomaly detection results. A scheduling policy can be understood as a rule for matching user domain name requests with service resources. The domain name, node information, VIP, and scheduling policy stored in the central data storage module are transmitted to the database for storage via the first data transmission channel. The data loading submodule in the scheduling server's update module loads this configuration data from the database to generate candidate transmission links for the data to be transmitted. After loading the configuration data, it can be processed as needed. For example, it can filter abnormal dirty data, adjust the organizational data structure as needed, and so on. The data loading submodule updates the processed configuration data into memory, enabling the request parser to retrieve the latest configuration data from memory to parse user requests and generate valid candidate transmission links. Updating the configuration data into memory can be achieved using an AB pointer swapping method. Specifically, when using old memory block data, a new memory block is opened to load the new configuration data. After loading is complete, the storage pointer is set to point to the new memory, and then the old memory is destroyed.

[0115] Understandably, in a content delivery network (CDN), the configuration data issued by the central server is quite large. This is because, with the development of services, network changes, and service diversification, there is a high frequency and large volume of incremental configuration data updates. Therefore, on the one hand, the transmission, loading, and updating of configuration data, the generation of candidate transmission links based on information such as domain names, node information, and scheduling policies, and finally the data taking effect on the scheduling server, involve multiple processing steps and a large data volume, resulting in a long loading time for the complete configuration data. On the other hand, the integration of service anomaly detection results into the global policy through the flow control module also takes time. Therefore, the central server's configuration data can be periodically sent to the scheduling server, enabling the scheduling server to respond to requests and generate candidate transmission links based on the latest configuration data.

[0116] To enable the scheduling server to obtain timely and updated service anomaly detection results and improve processing efficiency, such as Figure 6 As shown, the decision module of the central server sends the service anomaly detection results to the data updater of the scheduling server separately through a second data transmission channel. That is, the service anomaly detection results are transmitted to the scheduling server in an incremental update manner. Because the data volume of the service anomaly detection results is relatively small and incremental transmission is used, it can be transmitted to the scheduling server with very short latency. Compared with the first data transmission channel, the second data transmission channel enables the scheduling server to obtain the service anomaly detection results faster, with a smaller data volume and higher timeliness; it can be understood as a fast transmission channel. The data updater generates anomaly links based on the service anomaly detection results and the configuration data, and puts the generated anomaly links into an anomaly pool. The request receiver receives user requests and sends them to the request parser. The request parser parses the user requests and obtains candidate transmission links for the user requests. The anomaly detector compares the anomaly links in the anomaly pool with the candidate transmission links corresponding to the user requests, determines the anomaly links among the candidate transmission links corresponding to the user requests, and removes the anomaly links from the candidate transmission links corresponding to the user requests, obtaining updated candidate transmission links. If the updated candidate transmission links meet the transmission requirements, the request responder returns the corresponding response message to the user. If the updated candidate transmission link does not meet the transmission requirements, feedback is sent to the request parser to trigger the request parser to re-parse the user request in order to replace the candidate transmission link.

[0117] It can be seen that, according to Figure 6The system architecture shown implements a service assurance scheme that achieves service anomaly detection results through bypass updates, rapid filtering of abnormal links, and timely feedback to trigger replacement of candidate transmission links. On the one hand, it enables the scheduling server to perform long-term data updates on configuration data; on the other hand, it enables the scheduling server to quickly obtain service anomaly detection results, thereby making rapid anomaly escape decisions and achieving high-efficiency anomaly escape in edge scenarios.

[0118] Corresponding to the above method embodiments, this specification also provides embodiments of a service assurance device configured on a scheduling server. Figure 7 A schematic diagram of a service assurance device according to one embodiment of this specification is shown. Figure 7 As shown, the device includes:

[0119] The first receiving module 702 is configured to obtain configuration data for generating the transmission link from the central server through the first data transmission channel.

[0120] The second receiving module 704 is configured to obtain the service anomaly detection result of the target server from the central server through the second data transmission channel.

[0121] The anomaly decision module 706 is configured to detect anomaly links in the candidate transmission links corresponding to the data to be transmitted based on the configuration data and the service anomaly detection results.

[0122] In one or more embodiments of this specification, the anomaly decision-making module may include:

[0123] The abnormal link generation submodule is configured to generate abnormal links based on the service anomaly detection results and the configuration data;

[0124] The link comparison submodule is configured to compare the abnormal link with the candidate transmission link corresponding to the data to be transmitted, and determine the abnormal link among the candidate transmission links corresponding to the data to be transmitted.

[0125] In one or more embodiments of this specification, the apparatus further includes:

[0126] The abnormal link elimination module is configured to remove the abnormal link from the candidate transmission link corresponding to the data to be transmitted, and obtain an updated candidate transmission link.

[0127] The demand judgment module is configured to determine whether the updated candidate transmission link meets the transmission requirements corresponding to the data to be transmitted;

[0128] The link replacement triggering module is configured to trigger the replacement of the candidate transmission link for the user request if the requirement judgment module determines that the requirement is not met.

[0129] The above is an illustrative scheme of a service assurance device according to this embodiment. It should be noted that the technical solution of this service assurance device and the technical solution of the above-described service assurance method belong to the same concept. For details not described in detail in the technical solution of the service assurance device, please refer to the description of the technical solution of the above-described service assurance method.

[0130] Figure 8 A structural block diagram of a computing device 800 according to one embodiment of this specification is shown. The components of the computing device 800 include, but are not limited to, a memory 810 and a processor 820. The processor 820 is connected to the memory 810 via a bus 830, and a database 850 is used to store data.

[0131] The computing device 800 also includes an access device 840, which enables the computing device 800 to communicate via one or more networks 860. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 840 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0132] In one embodiment of this specification, the above-described components of the computing device 800 and Figure 8 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 8 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0133] The computing device 800 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 800 can also be a mobile or stationary server.

[0134] The processor 820 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described service assurance method.

[0135] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the service assurance method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the service assurance method described above.

[0136] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described service assurance method.

[0137] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the service assurance method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the service assurance method described above.

[0138] An embodiment of this specification also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described service guarantee method.

[0139] The above is an illustrative example of a computer program according to this embodiment. It should be noted that the technical solution of this computer program and the technical solution of the aforementioned service assurance method belong to the same concept. Details not described in detail in the technical solution of the computer program can be found in the description of the technical solution of the aforementioned service assurance method.

[0140] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0141] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

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

[0143] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0144] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A service assurance system, comprising: Central server and scheduling server; The central server is configured to acquire service status data of the target server detected by multiple service status detection modules, perform anomaly analysis on the service status data based on the service status data obtained from multiple detections, the distribution data corresponding to the detection failures, the failure categories and transmission logs, generate the service anomaly detection result of the target server, send the configuration data for generating the transmission link to the scheduling server through the first data transmission channel, and send the service anomaly detection result to the scheduling server through the second data transmission channel. The service status data includes available Boolean values ​​and / or transmission performance indicators, or unavailable Boolean values ​​and / or transmission performance indicators; the multiple service status detection modules are set up on different transmission links of the target server to detect the same target server; The scheduling server is configured to obtain the configuration data from the central server through the first data transmission channel, obtain the service anomaly detection result from the central server through the second data transmission channel, generate anomaly links based on the configuration data and the service anomaly detection result, compare the anomaly links with the candidate transmission links corresponding to the data to be transmitted, detect the anomaly links in the candidate transmission links corresponding to the data to be transmitted, remove the anomaly links from the candidate transmission links corresponding to the data to be transmitted, and obtain updated candidate transmission links.

2. A service assurance method, comprising: Obtain service status data of the target server detected by multiple service status detection modules; Based on the service status data obtained from multiple detections, the distribution data corresponding to the detection failures, the failure categories, and the transmission logs, anomaly analysis is performed on the service status data of the target server to generate the service anomaly detection results of the target server. The configuration data used to generate the transmission link is sent to the scheduling server through the first data transmission channel; The service status data includes available Boolean values ​​and / or transmission performance indicators, or unavailable Boolean values ​​and / or transmission performance indicators; the multiple service status detection modules are set up on different transmission links of the target server to detect the same target server; The service anomaly detection result is sent to the scheduling server through the second data transmission channel.

3. The method according to claim 2, wherein obtaining the service status data of the target server includes: The system acquires service status data detected by multiple service status detection modules, which are set on different transmission links of the target server to detect the same target server.

4. The method according to claim 3, wherein the detection performed by the service status detection module includes any one or more of the following service status detection categories: Service status detection for data transmitted based on the Internet Control Message Protocol; Service status detection for data transmitted based on the User Datagram Protocol; Service status detection for data transmitted based on the Transmission Control Protocol; Service status detection for data transmitted based on the Hypertext Transfer Protocol; Service status detection based on data transmitted using the Hypertext Transfer Security Protocol.

5. The method according to claim 3, wherein performing anomaly analysis on the service status data of the target server to generate a service anomaly detection result for the target server includes: By utilizing the service status data detected multiple times by the multiple service status detection modules, the distribution data of the service status detection modules that failed detection, the failure categories corresponding to the failures, and the transmission logs of the transmission links in the network, anomaly analysis is performed to generate the service anomaly detection results for the target server.

6. A service assurance method, comprising: The configuration data for generating the transmission link is obtained from the central server through the first data transmission channel; The service anomaly detection results of the target server are obtained from the central server through the second data transmission channel; Based on the configuration data and the service anomaly detection results, an abnormal link is generated. The abnormal link is compared with the candidate transmission link corresponding to the data to be transmitted. An abnormal link is detected in the candidate transmission link corresponding to the data to be transmitted. The abnormal link is removed from the candidate transmission link corresponding to the data to be transmitted to obtain an updated candidate transmission link.

7. The method according to claim 6, further comprising, after detecting the abnormal link in the candidate transmission link corresponding to the data to be transmitted: Determine whether the updated candidate transmission link meets the transmission requirements corresponding to the data to be transmitted; If the conditions are not met, the candidate transport link for the user's request will be replaced.

8. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the service assurance method according to any one of claims 2 to 7.

9. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the service assurance method according to any one of claims 2 to 7.

10. A computer program, wherein, When the computer program is executed in the computer, it causes the computer to perform the steps of the service assurance method according to any one of claims 2 to 7.

Images