Configuration optimization method, system and equipment for multi-cloud DNS (Domain Name Server) service and medium

Abstract

The invention discloses a multi-cloud DNS service configuration optimization method, system and device and a medium, and the method specifically comprises the steps: deploying at least one DNS service node in each cloud service environment to form a DNS service cluster, and carrying out the configuration management of the DNS service cluster through Terraform; according to the geographical position distribution condition of players in the global range, edge computing nodes used for sinking the DNS service are planned and arranged in all the areas; synchronizing a DNS analysis record among the DNS service nodes by adopting a block chain technology, and verifying and confirming the DNS analysis record through a consensus algorithm; and performing fault prediction on each DNS service node and each edge computing node through a deep learning algorithm to obtain a fault prediction result, and dynamically adjusting DNS service parameter configuration according to the fault prediction result. According to the invention, comprehensive optimization and intelligent management of the DNS service are realized, and the reliability, safety and performance of the DNS service are improved.

Description

Technical Field

[0001] The present invention relates to the field of Internet technology, and in particular to a configuration optimization method, system, device and medium for a multi-cloud DNS service. Background Art

[0002] In Internet services, the Domain Name System (DNS), as a distributed database that maps domain names and IP addresses, is one of the core components of the Internet. With the rapid development of cloud computing and edge computing, DNS services are also constantly undergoing technological innovation and optimization to adapt to the growing demand for Internet access. However, the current DNS service configuration and management still face many challenges.

[0003] First, the risk of single point failure is a major problem in current DNS services. Many companies and organizations rely on the DNS service of a single cloud vendor, such as Tencent Cloud's DNSPod. This single dependency means that when the cloud vendor's control plane or service layer fails, the entire DNS service may be interrupted, causing the website or service to be inaccessible. For example, if a regional service of Tencent Cloud DNSPod fails, the game development company will not be able to modify the DNS resolution record through the API interface, which seriously affects the normal operation of the business.

[0004] Secondly, the response speed of DNS service is also an issue that needs to be solved urgently. When the DNS service fails, the existing failover mechanism is often not fast enough, resulting in a decrease in user access speed and affecting user experience. Especially in application scenarios that require low latency, such as games, the response speed of DNS service is crucial.

[0005] Furthermore, the current level of automation of DNS services still needs to be improved. Fault detection and switching mechanisms mostly rely on manual intervention and lack automated fault detection and switching capabilities. This not only increases operation and maintenance costs, but may also lead to untimely fault handling, further affecting business continuity and stability.

[0006] In addition, the introduction of edge computing nodes provides new possibilities for DNS optimization, but existing technical solutions do not fully utilize this advantage. By combining edge computing nodes, DNS services can be decentralized and user access speed can be improved. However, this also brings single point failure risks and data consistency issues. How to ensure data consistency and security in a multi-node environment has become a technical problem that needs to be solved urgently.

[0007] At the same time, with the continuous development of big data and artificial intelligence technology, the application of AI technology in DNS services is becoming more and more extensive. However, the current technical solutions are still insufficient in terms of the accuracy of fault detection and the intelligence level of switching decisions. The lack of an intelligent decision support system makes the optimization and fault handling of DNS services still rely on experience and manual judgment.

[0008] Finally, the current technical solution lacks the ability to predict potential failures. Preventive measures cannot be taken in advance, resulting in passive responses when failures occur. This not only increases the difficulty and cost of troubleshooting, but may also have a serious impact on business continuity and stability. Summary of the invention

[0009] The object of the present invention is to provide a configuration optimization method, system, device and medium for a multi-cloud DNS service, which realizes comprehensive optimization and intelligent management of DNS services, improves the reliability, security and performance of DNS services, and solves at least one of the above-mentioned prior art problems.

[0010] In a first aspect, the present invention provides a configuration optimization method for a multi-cloud DNS service, the method specifically comprising:

[0011] At least one DNS service node is deployed in each cloud service environment to form a DNS service cluster, and the DNS service cluster is configured and managed through Terraform;

[0012] According to the geographical distribution of players around the world, edge computing nodes for sinking DNS services are planned and set up in each region;

[0013] Blockchain technology is used to synchronize DNS resolution records between various DNS service nodes, and the DNS resolution records are verified and confirmed through a consensus algorithm;

[0014] Perform fault prediction on each DNS service node and each edge computing node through a deep learning algorithm to obtain a fault prediction result, and dynamically adjust the DNS service parameter configuration according to the fault prediction result;

[0015] When a fault occurs in the DNS service cluster, the fault type and fault cause are determined based on a preset fault diagnosis model, a self-healing solution is determined according to the fault type and the fault cause, and fault recovery is performed through the self-healing solution.

[0016] In a second aspect, the present invention provides a configuration optimization system for a multi-cloud DNS service, the system specifically comprising:

[0017] A first configuration optimization module is used to deploy at least one DNS service node in each cloud service environment to form a DNS service cluster, and perform configuration management on the DNS service cluster through Terraform;

[0018] The second configuration optimization module plans and sets edge computing nodes for sinking DNS services in various regions according to the geographical distribution of players around the world;

[0019] The third configuration optimization module uses blockchain technology to synchronize DNS resolution records between various DNS service nodes, and verifies and confirms the DNS resolution records through a consensus algorithm;

[0020] The fourth configuration optimization module predicts faults of each DNS service node and each edge computing node through a machine learning algorithm to obtain fault prediction results, and dynamically adjusts the DNS service parameter configuration according to the fault prediction results;

[0021] The fifth configuration optimization module determines the fault type and fault cause based on a preset fault diagnosis model when the DNS service cluster fails, determines a self-healing solution according to the fault type and the fault cause, and performs fault recovery through the self-healing solution.

[0022] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor and a computer program stored in the memory, and when the computer program is executed on the processor, a configuration optimization method for a multi-cloud DNS service as described in any one of the above methods is implemented.

[0023] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the configuration optimization method for a multi-cloud DNS service as described in any one of the above methods is implemented.

[0024] Compared with the prior art, the present invention has at least one of the following technical effects:

[0025] 1. The present invention realizes comprehensive optimization and intelligent management of DNS services, improves the reliability, security and performance of DNS services, enhances the high availability, low latency and self-optimization capabilities of DNS services, and ensures the stability of game services and user experience.

[0026] 2. The present invention deploys multiple DNS service nodes to form a cluster and uses Terraform for configuration management, thereby improving the reliability and scalability of DNS services. At the same time, edge computing nodes are set according to the geographical distribution of global players, which realizes the local resolution of DNS services, reduces latency, and improves user experience.

[0027] 3. The present invention analyzes the player's geographic location data through the K-means clustering algorithm and accurately sets edge computing nodes in the player gathering area, so that the DNS service can respond to player requests more quickly, reduce network delays, and improve service availability.

[0028] 4. The present invention uses blockchain technology to ensure the security and consistency of DNS resolution records. Through smart contracts and PoW consensus algorithms, distributed storage and verification of DNS resolution records are realized, which prevents data from being tampered with and improves the security of the system.

[0029] 5. The present invention uses the LSTM model to learn historical operation data and external environment data to build a fault prediction model. The model can predict the potential failures of DNS service nodes and edge computing nodes in advance, providing a basis for dynamically adjusting service parameter configurations, thereby reducing the probability of failures.

[0030] 6. The present invention constructs a fault diagnosis model through correlation analysis algorithm and decision tree model, which can quickly and accurately determine the fault type and fault cause of the DNS service cluster. Based on this information, the self-healing solution is automatically selected from the fault handling strategy knowledge base, which realizes rapid recovery of the fault and reduces downtime.

[0031] 7. The present invention uses a reinforcement learning algorithm to train DNS resolution log data and constructs a model that can automatically optimize the DNS resolution strategy. It can dynamically adjust the resolution strategy parameters according to the resolution request characteristics and system operation indicators to improve the resolution success rate, reduce the response time and optimize resource utilization.

[0032] 8. The present invention collects game operation data and user feedback scores to quantitatively evaluate the importance of each game, and predicts future traffic change trends based on historical traffic data. This information is used to formulate a DNS resolution resource allocation plan for each game, ensuring that important games can obtain sufficient resource support during peak periods, thereby improving the overall performance of the service and user satisfaction. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0034] Figure 1 It is a flowchart of a configuration optimization method for a multi-cloud DNS service provided by an embodiment of the present invention;

[0035] Figure 2 It is a structural diagram of a configuration optimization system for a multi-cloud DNS service provided by an embodiment of the present invention;

[0036] Figure 3 It is a structural schematic diagram of a computer device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0037] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0038] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0039] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0040] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "uponce" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "uponce it is determined" or "in response to determining" or "uponce [described condition or event] is detected" or "in response to detecting [described condition or event]", depending on the context.

[0041] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0042] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0043] In the embodiment of the present application, the execution subject of the process includes a terminal device, which includes but is not limited to: a server, a computer, a smart phone, a tablet computer, and other devices capable of executing the method disclosed in the present application. Figure 1 A flow chart of a configuration optimization method for a multi-cloud DNS service disclosed in an embodiment of the present invention is shown, and the details are as follows:

[0044] S101, deploy at least one DNS service node in each cloud service environment to form a DNS service cluster, and configure and manage the DNS service cluster through Terraform.

[0045] In this embodiment, a suitable cloud service provider (such as AWS, Azure, GCP, etc.) is selected according to business needs, and at least one DNS service node is deployed on each cloud service environment. These nodes can be open source DNS server software (such as BIND, PowerDNS, etc.) or DNS services provided by cloud service providers. Write Terraform configuration files (such as main.tf, variables.tf, outputs.tf, etc.), define the resources and configuration of the DNS service cluster, and specify the cloud service provider's credential information, the specifications and quantity of DNS service nodes, network configuration, etc. in the configuration file. Execute the terraforminit command in the command line to initialize the Terraform project. Execute the terraform plan command to view the operations that Terraform will perform. Execute the terraform apply command to deploy the DNS service cluster. Verify the deployment of the DNS service cluster through Terraform's output and the cloud service provider's management console, and use monitoring tools (such as Prometheus, Grafana, etc.) to monitor the performance and availability of DNS service nodes.

[0046] In this embodiment, by deploying at least one DNS service node on each cloud service environment, a distributed DNS service cluster is formed, which improves the availability and scalability of the DNS service. When a cloud service environment or DNS service node fails, other nodes can take over its work to ensure the continuity of the DNS service. Terraform can dynamically adjust the number and specifications of DNS service nodes according to business needs, avoiding waste and idleness of resources.

[0047] S102, based on the geographical distribution of players around the world, plan and set up edge computing nodes in each region for sinking the DNS service.

[0048] In this embodiment, the geographic location data of global players, including information such as IP addresses, regions, and countries, are collected. Big data analysis technology is used to perform cluster analysis on the geographic location data of players to identify hot spots where players gather. The location and number of edge computing nodes are planned based on the hot spots where players gather. Considering network latency and bandwidth costs, a data center or cloud service provider close to the player gathering area is selected as the deployment location of the edge computing node. Deploy the DNS service on the planned edge computing node to achieve local resolution of the DNS service. Configure the load balancing and failover strategy of the DNS service to ensure the high availability and stability of the DNS service. Use monitoring tools to monitor the performance of edge computing nodes and the response speed of the DNS service in real time. Based on the monitoring data, regularly adjust the configuration of the edge computing nodes and the parameters of the DNS service to optimize performance and improve user experience.

[0049] In this embodiment, by sinking the DNS service to the edge computing node close to the player gathering area, the DNS resolution is processed nearby, the distance and time of data transmission are reduced, and the network delay is reduced. The edge computing node has higher network bandwidth and lower latency, which can better cope with network fluctuations and peak traffic, and improve the connection stability of players in the game.

[0050] In some embodiments, in the above step S102, the edge computing nodes for sinking the DNS service are planned and set in each region according to the geographical distribution of players in the world, specifically including:

[0051] Obtaining geographical location distribution data of players worldwide, clustering the geographical location distribution data of players using a K-means clustering algorithm, and obtaining the distribution of players in each region;

[0052] Determine the player gathering area and non-player gathering area in each area according to the player distribution situation;

[0053] Edge computing nodes are set up in player gathering areas in each region to sink DNS services.

[0054] In this embodiment, the geographical location distribution data of global players is obtained, the player location data is preprocessed, abnormal data and noise data are removed, and the data quality is improved. The K-means clustering algorithm is used to perform cluster analysis on the preprocessed player location data, and the optimal player gathering area division result is obtained by iteratively optimizing the cluster center. According to the player gathering area division result obtained by cluster analysis, the player gathering degree in each area is determined. If the gathering degree exceeds the preset threshold, it is determined as a player gathering area, otherwise it is determined as a non-gathering area. In the area determined as a player gathering area, a network node with low network latency and sufficient bandwidth is selected as an edge computing node for carrying DNS services. The network topology structure and load data of the edge computing node are obtained, and a suitable DNS server is allocated to each edge node through the network topology algorithm and the load balancing algorithm. According to the processing capacity and load of the DNS server, the DNS service allocation of each edge node is dynamically adjusted to achieve balanced sinking of the DNS service at the edge node. The player distribution changes in each area and the service quality of the edge node are continuously monitored. When the player gathering area changes or the service quality of the edge node decreases, the above steps are re-executed to dynamically optimize the DNS service sinking solution.

[0055] Exemplarily, the geographical location distribution data of players can be obtained from game server logs, client SDK reports, third-party data platforms and other channels. For example, a game company can collect the IP addresses of players when they log in, and convert them into longitude and latitude coordinates through the IP geolocation library, so as to obtain the geographical location distribution data of players worldwide. It should be noted that due to issues such as data privacy and security, the collected data needs to be desensitized, such as removing information that can directly identify personal identity. The K-means clustering algorithm is a commonly used unsupervised learning algorithm that can divide data points into different clusters. In the game scene, the K-means algorithm can be used to cluster the geographical location data of players to identify areas where players are more concentrated. The specific operation method is to first regard the longitude and latitude coordinates of the players as two-dimensional data points, then set a cluster number K (for example, K = 10, indicating that global players are divided into 10 regions), and finally run the K-means algorithm. The algorithm will divide the data points with close distances into the same cluster, thereby forming K player clustering areas. It should be noted that the selection of the K value needs to be adjusted according to the actual situation. Too large or too small a K value may lead to poor clustering effect. The appropriate K value can be selected by methods such as the elbow rule. According to the clustering results of the K-means algorithm, the global map can be divided into several regions, each of which contains one or more player gathering areas and some non-player gathering areas where players are sparsely distributed. For example, in North America, players may be mainly concentrated in large cities such as Los Angeles, New York, and Chicago, while the number of players in other regions is relatively small. Setting up edge computing nodes in player gathering areas can effectively reduce network latency and improve players' gaming experience. For example, assuming that there are a large number of players in the Los Angeles area, you can consider deploying edge computing nodes in this area and sinking the DNS service of this area to the edge nodes. When players in Los Angeles access the game server, their DNS requests will be resolved to the nearest edge node, thereby reducing the distance of data transmission and reducing network latency. For non-player gathering areas, due to the small number of players, the cost-effectiveness of deploying edge nodes may be low, and centralized DNS services can continue to be used. Suppose a game has three major player gathering areas in the world: the East Coast of North America, Western Europe, and Southeast Asia. By analyzing the geographic location data of players, we can find that players on the east coast of North America are mainly concentrated in cities such as New York and Boston, players in Western Europe are mainly concentrated in cities such as London and Paris, and players in Southeast Asia are mainly concentrated in cities such as Singapore and Jakarta. Therefore, edge computing nodes can be deployed in New York, London, and Singapore respectively, and the DNS services of the corresponding regions can be sunk to these nodes. In this way, when players in these areas access the game server, their DNS requests will be resolved to the nearest edge node, thereby obtaining lower network latency and a better gaming experience.For example, a player in New York will have his game request directed to the edge node in New York instead of the game server in California, which greatly reduces latency. This approach is particularly effective in areas with a large number of players and relatively concentrated geographical locations. For areas where players are more dispersed, such as South America or Africa, since the cost of deploying edge nodes is high and the benefits are limited, you can continue to use centralized DNS services or adopt other optimization solutions.

[0056] S103, using blockchain technology to synchronize DNS resolution records between various DNS service nodes, and verifying and confirming the DNS resolution records through a consensus algorithm.

[0057] In this embodiment, first, a blockchain network needs to be built, which consists of multiple DNS service nodes, each of which has the function of a blockchain client. The nodes are connected through a point-to-point (P2P) communication protocol to ensure that data can be transmitted efficiently and securely. When the DNS service node receives a domain name resolution request, it formats the resolution result (including domain name, IP address, resolution time and other information) and prepares to put it on the chain. The node packages the resolution record into a blockchain transaction and broadcasts it to the entire blockchain network. After receiving the transaction, other nodes in the network will use a preset consensus algorithm (such as proof of work PoW, proof of equity PoS, etc.) to verify the transaction. The verification process includes checking the legitimacy, integrity and signature validity of the transaction. If the transaction passes the verification, the node will add it to its own copy of the blockchain. As new transactions are continuously generated and verified, each node in the blockchain network will continuously update its own copy of the blockchain to ensure the consistency and latestness of the data. Through the tamper-proof nature of the blockchain, once a resolution record is written to the blockchain, it cannot be modified or deleted, thereby ensuring the authenticity and integrity of the data. After the blockchain network is running stably, the DNS resolution service can be further optimized. For example, the smart contract function of the blockchain can be used to realize automated domain name registration and management, or the distributed characteristics of the blockchain can be used to improve the scalability and fault tolerance of the system.

[0058] In this embodiment, the decentralized and tamper-proof characteristics of blockchain technology effectively prevent security threats such as DNS hijacking and DNS spoofing, and protect user privacy and data security. The distributed ledger characteristics of blockchain enable the DNS system to resist the risk of single point failure. Even if a node fails or is attacked, other nodes can still continue to provide services, ensuring the stability and availability of the system.

[0059] In some embodiments, in the above step S103, the use of blockchain technology to synchronize DNS resolution records between various DNS service nodes and verifying and confirming the DNS resolution records through a consensus algorithm specifically includes:

[0060] When the DNS resolution record of any DNS service node changes, the changed DNS resolution record is packaged into a block through the smart contract and broadcast to other DNS service nodes;

[0061] After each DNS service node receives the block, the digital signature and timestamp of the block are verified through the PoW consensus algorithm. If the verification passes, the respective DNS resolution records are updated according to the block.

[0062] In this embodiment, the change of the resolution record of the DNS service node is monitored. When a change is detected, the smart contract is triggered to package the changed DNS resolution record. The changed DNS resolution record, the node digital signature, the current timestamp and other information are packaged and generated into a block through the smart contract. The packaged block is broadcast to other DNS service nodes through the P2P network. After receiving the broadcasted block, other DNS service nodes first extract the node digital signature and timestamp information in the block. The extracted node digital signature is verified using the preset PoW consensus algorithm to determine whether the digital signature is legal and valid. At the same time, it is determined whether the block is the latest generated block based on the timestamp. If the digital signature verification passes and the timestamp is valid, the DNS resolution data of the node itself is updated according to the DNS resolution record in the block. After each node completes the update of the resolution record, it synchronizes and verifies its own DNS resolution data again to ensure that the DNS resolution records of each node are consistent and the synchronization of records of the entire DNS service network is guaranteed.

[0063] For example, the change information of the DNS service node is broadcast and updated through smart contracts, which enhances the reliability and security of the DNS service. The decentralized nature of smart contracts can avoid single point failures and prevent malicious tampering of DNS records. The introduction of the PoW consensus algorithm further improves the security of the system. Suppose a game company deploys multiple DNS service nodes around the world, located in North America, Europe and Asia, to meet the access needs of players in different regions. To simplify the description, assume that there is only one DNS service node in each region. When the DNS resolution record of the North American node changes, such as when the IP address of the game server is updated, this change information will be packaged into a block. This block contains the changed DNS resolution record, timestamp and digital signature. The digital signature is generated using the private key of the North American node to verify the source and integrity of the information. The smart contract will broadcast this block to other DNS service nodes, that is, the nodes in Europe and Asia. After receiving the block, these nodes will use the PoW consensus algorithm for verification. The verification process of the PoW consensus algorithm includes verifying the digital signature and timestamp. The node will use the public key of the North American node to verify the digital signature to ensure that the information in the block is indeed from the North American node and has not been tampered with. At the same time, the node verifies the timestamp to ensure that the information in the block is new, not outdated. If the verification is successful, the nodes in Europe and Asia will update their respective DNS resolution records based on the information in the block. In this way, players in all regions of the world can access the new game server.

[0064] This DNS update mechanism based on smart contracts and PoW consensus algorithm brings multiple benefits. First, the decentralized architecture improves the availability of DNS services. Even if the North American node fails, other nodes can still work normally and players can still access the game server. Secondly, the combination of smart contracts and PoW consensus algorithm enhances the security of the system and prevents DNS records from being maliciously tampered with. Finally, this mechanism improves the efficiency of DNS updates. The traditional DNS update mechanism requires synchronization step by step, which is inefficient. The mechanism based on smart contracts can quickly broadcast change information to all nodes for fast updates. This mechanism is especially suitable for delay-sensitive application scenarios such as games. By sinking the DNS service to the edge computing node and adopting an efficient update mechanism, the delay in players accessing the game can be effectively reduced, and the player's gaming experience can be improved.

[0065] S104, performing fault prediction on each DNS service node and each edge computing node through a deep learning algorithm to obtain a fault prediction result, and dynamically adjusting the DNS service parameter configuration according to the fault prediction result.

[0066] In this embodiment, operation data is collected from DNS service nodes and edge computing nodes, including key performance indicators such as CPU usage, memory usage, disk I / O, and network bandwidth. The collected data is cleaned and preprocessed to remove outliers and noise to ensure the accuracy and consistency of the data. The preprocessed data is trained using deep learning models such as recurrent neural networks (RNN), long short-term memory networks (LSTM), or gated recurrent units (GRU). Fault labels such as node crashes and service interruptions are set to divide the training data into two categories: faults and normal. The fault prediction accuracy of the model is improved by adjusting model parameters and optimizing algorithms. The trained deep learning model is deployed to the monitoring system to predict real-time operation data. When a DNS service node or edge computing node is predicted to have a risk of failure, an alarm mechanism is triggered to notify the manager to intervene. According to the fault prediction results, the manager can dynamically adjust the parameter configuration of the DNS service, such as load balancing strategy, cache settings, routing selection, etc. For example, when it is predicted that a certain edge computing node is about to fail, it can be removed from the load balancing pool to avoid affecting the overall service quality.

[0067] In this embodiment, by analyzing and learning a large amount of historical data through deep learning algorithms, the failure risk of DNS service nodes and edge computing nodes can be accurately predicted, and the false positive and false negative rates can be reduced. Dynamically adjusting the parameter configuration of the DNS service according to the fault prediction results can optimize load balancing, improve cache hit rate, reduce network latency, etc., thereby improving the overall performance of the DNS service.

[0068] In some embodiments, in the above step S104, the fault prediction of each DNS service node and each edge computing node is performed by a deep learning algorithm to obtain a fault prediction result, which specifically includes:

[0069] Acquire historical operation data of the DNS service, and obtain a first key feature subset by performing feature extraction on the historical operation data;

[0070] Acquire external environment data, and obtain a second key feature subset by performing feature extraction on the external environment data;

[0071] Inputting the first key feature subset and the second key feature subset into the LSTM model for training to obtain a fault prediction model for determining the probability of a fault occurring, wherein the fault prediction model is used to predict a fault for any DNS service node and any edge computing node and output a fault occurrence probability;

[0072] The fault prediction result is determined by comparing the fault occurrence probability output by the fault prediction model with a preset fault probability threshold.

[0073] In this embodiment, historical operation data of the DNS service is obtained, including performance indicator data such as CPU utilization, memory occupancy, network traffic, and historical fault record data of the DNS service node. External environment data is obtained, including network topology data, network equipment status data, network security event data, etc., which reflect the status of the network environment in which the DNS service is located. Feature engineering is performed on the historical operation data, and key features with a high correlation with DNS service failures are extracted through methods such as correlation analysis and principal component analysis to form a first key feature subset. Feature engineering is performed on the external environment data, and key features that can reflect the network environment status are extracted through methods such as feature selection and feature dimension reduction to form a second key feature subset. The first key feature subset and the second key feature subset are used as input, and the LSTM neural network model is used for training. By setting appropriate network structure parameters, loss function and optimization algorithm, the model can better fit the historical fault data, thereby obtaining a fault prediction model for predicting the probability of failure of DNS service nodes and edge computing nodes. In actual applications, the trained fault prediction model is used to obtain the performance indicator data of the DNS service node and the edge computing node in real time, as well as the status data of the network environment in which they are located, and input them into the model for prediction to obtain the probability value of each node failing. A fault probability threshold is set, and the fault probability value output by the fault prediction model is compared with the threshold. If it is higher than the threshold, it is predicted that the node may fail, and if it is lower than the threshold, it is predicted that the node is working normally. According to the prediction results, the nodes that may fail are repaired or switched in advance, thereby improving the reliability and stability of the DNS service.

[0074] For example, the DNS service is the infrastructure of the Internet, and its stability is crucial. In order to predict the failure of the DNS service, a fault prediction method based on the LSTM model can be used. The core idea of ​​this method is to predict the probability of failure of the DNS service node and the edge computing node by analyzing the operation data and external environment data of the DNS service. First, obtain the historical operation data of the DNS service, which may include the number of DNS queries, response time, error rate, etc. For example, the number of DNS queries per hour in the past year can be collected. By extracting features from these data, a first key feature subset can be obtained. For example, the average number of queries per day, the peak number of queries, the rate of change of the number of queries, etc. can be extracted. The purpose of extracting these features is to capture the changing trend of the operation status of the DNS service. Secondly, obtain external environment data, which may include network traffic, server load, weather conditions, etc. For example, network traffic data per hour in the same period can be collected, and by extracting features from these data, a second key feature subset can be obtained, such as extracting the peak value, average value, rate of change, etc. of the network traffic. These external environmental factors may have an impact on the operation status of the DNS service. Next, the first key feature subset and the second key feature subset are input into the LSTM model for training. LSTM (Long Short-Term Memory Network) is a special type of recurrent neural network that is good at processing time series data. Through training, a fault prediction model can be obtained to determine the probability of failure. This model can predict the probability of a DNS service node or edge computing node failing in the future based on the input features. For example, suppose a fault prediction model has been trained. Now we want to predict the probability of a North American DNS service node failing in the next 24 hours. Extract features from the operating data (such as the number of queries, response time, etc.) and external environment data (such as network traffic, server load, etc.) of the North American DNS service node in the past 24 hours and input them into the model. The model will output a probability value, such as 0.05, which means that the probability of a North American DNS service node failing in the next 24 hours is 5%. Similarly, the failure probability of an edge computing node can also be predicted. For example, suppose an edge computing node located in New York is responsible for processing DNS query requests from some game players. Data such as the CPU usage, memory usage, and network connection status of the node can be collected and features extracted. By inputting these features into the fault prediction model, the probability of the node failing in the future can be obtained. Finally, the fault prediction result is determined by comparing the fault probability output by the fault prediction model with the preset fault probability threshold. The preset fault probability threshold is a value set according to the actual situation (for example, set to 0.1). If the predicted fault probability is greater than or equal to the threshold, it is considered that the node has a fault risk and corresponding measures need to be taken, such as increasing server resources, switching to a backup node, etc.Doing so can effectively prevent failures and improve the availability and stability of DNS services. For example, in the previous example, the failure probability of the North American DNS node is 0.05, which is less than the preset threshold of 0.1. It is considered that the node is currently operating normally and no additional measures are required. If the failure probability of the New York edge computing node is 0.2, which is higher than the preset threshold of 0.1, it is considered that the node is at risk of failure and needs to be handled in a timely manner, such as increasing the computing resources of the node or switching the traffic to other edge nodes, so as to avoid potential failures and ensure the smoothness of players' access to the game.

[0075] S105, when the DNS service cluster fails, the fault type and fault cause are determined based on a preset fault diagnosis model, a self-healing solution is determined according to the fault type and the fault cause, and the fault is recovered through the self-healing solution.

[0076] In this embodiment, first, a preset fault diagnosis model needs to be built. The model can be trained by machine learning algorithms (such as decision trees, random forests, support vector machines, etc.) or deep learning algorithms (such as convolutional neural networks CNN, recurrent neural networks RNN, etc.). The training data should contain historical DNS service cluster fault records, fault types, fault causes, and corresponding solutions. During the training process, the model will learn how to extract key features from fault phenomena and determine the fault type and cause. Once the model training is completed, it can be used to diagnose DNS service cluster faults in real time.

[0077] When a DNS service cluster fails, the monitoring system will immediately detect the anomaly and trigger the fault diagnosis process. At this time, the preset fault diagnosis model will receive fault data from the monitoring system, including fault symptoms, performance indicators, etc. The model will process and analyze this data to determine the type and cause of the fault. For example, the fault may be caused by hardware failure, software vulnerability, network problem or configuration error.

[0078] Once the fault type and cause are determined, the system will select the appropriate self-healing solution based on the preset self-healing strategy library. The self-healing strategy library contains solutions for different fault types and causes, such as restarting services, restoring configurations, switching backups, etc. For example, if the fault is caused by a hardware failure in a DNS service node, the self-healing solution may be to remove the node from the cluster and start a backup node to take over its work. If the fault is caused by a software vulnerability, the self-healing solution may be to update the software version or apply a patch. Finally, the system will execute the selected self-healing solution to recover the DNS service cluster. During the execution process, the system will continuously monitor the status of the cluster to ensure the effectiveness of the self-healing solution. If the self-healing solution fails or fails to completely solve the problem, the system will trigger an alarm mechanism to notify the administrator to intervene manually.

[0079] In this embodiment, through the preset fault diagnosis model and self-healing solution, the system can automatically determine the fault type and cause in a short time and execute the corresponding self-healing solution, thereby greatly shortening the fault recovery time. The automated fault recovery process reduces the frequency and cost of manual intervention and reduces the complexity of operation and maintenance.

[0080] In some embodiments, in the above step S105, when the DNS service cluster fails, determining the fault type and fault cause based on a preset fault diagnosis model, and determining a self-healing solution according to the fault type and the fault cause specifically includes:

[0081] Obtaining fault monitoring indicator data of the DNS service cluster in real time;

[0082] Acquire historical fault type data, and perform correlation analysis on the historical fault type data and the fault monitoring indicator data through a correlation analysis algorithm to obtain a fault classification data set, wherein the fault classification data set includes each fault type and several fault monitoring indicators whose correlation exceeds a correlation threshold;

[0083] Inputting the fault classification data set into a decision tree model for training to obtain a fault diagnosis model;

[0084] When the DNS service cluster fails, the fault type and cause are determined according to the fault diagnosis model;

[0085] Based on the fault type and the fault cause, a corresponding self-healing solution is determined from a preset fault handling strategy knowledge base.

[0086] In this embodiment, real-time fault monitoring index data of the DNS service cluster is obtained and stored in a fault monitoring database. Historical fault type data is obtained from the historical fault database, and the historical fault type data and the real-time fault monitoring index data are correlated and analyzed according to a preset correlation analysis algorithm. If the correlation exceeds a preset threshold, the fault monitoring index is associated with the corresponding fault type to obtain a fault classification data set. According to the fault classification data set, the key fault monitoring index of each fault type is determined, and a fault feature vector is constructed. The fault feature vector is input into a decision tree model, and a fault diagnosis model is obtained through training. By monitoring the key performance indicators of the DNS service cluster, it is determined whether the cluster has a fault. If a fault occurs, the fault diagnosis process is triggered. According to the pre-established fault diagnosis model, a machine learning algorithm such as a decision tree, a support vector machine or a neural network is used to analyze the fault phenomenon and determine the specific fault type and fault cause. For the diagnosed fault type and cause, a match is retrieved from a preset fault handling strategy knowledge base to obtain a recommended fault self-healing solution. The self-healing solution includes targeted fault handling steps, such as restarting the service, switching the service node, adjusting the configuration parameters, rolling back the version, etc., and these processing steps are executed by an automated operation and maintenance tool. In the process of executing the fault self-healing solution, the operating status of the DNS service cluster is continuously monitored, key performance indicator data is obtained, and it is determined whether the fault has been eliminated. If the fault is still not eliminated, the relevant information is fed back to the fault diagnosis model, and the diagnosis model is optimized through machine learning algorithms to improve the accuracy of fault diagnosis, and the fault handling strategy in the knowledge base is updated accordingly. When it is confirmed that the DNS service cluster has fully recovered to normal, a summary report of this fault handling is generated, recording the fault phenomenon, diagnosis results, processing steps and effects, etc., as a basis for optimizing the fault diagnosis model and improving the knowledge base, so as to continuously improve the fault self-healing capability of the DNS service cluster.

[0087] For example, in order to improve the availability of DNS services and reduce the impact of failures, a DNS fault self-healing system based on a decision tree model can be constructed. The system can diagnose the type and cause of failures in real time and automatically execute the corresponding repair plan. First, the system needs to obtain the fault monitoring indicator data of the DNS service cluster in real time. These data can be collected through various monitoring tools. For example, the CPU usage, memory usage, network traffic, DNS query success rate, response time and other indicators of all DNS servers can be collected every minute. Suppose at a certain moment, the monitoring system collects that the CPU usage of server A suddenly soars to 95%, the DNS query success rate drops to 80%, and the response time rises to 500 milliseconds. These abnormal indicator data indicate that server A may have a failure. At the same time, the system also needs to obtain historical fault type data. These data can be obtained from the fault record library, which records various DNS fault types that have occurred in the past, such as network connection interruption, server hardware failure, configuration error, attack, etc. Each historical fault record contains the time when the fault occurred, the affected server, the fault type, the cause of the fault and the corresponding treatment measures. For example, at xx:00 on x / x / 2024, the network connection of server B was interrupted, resulting in the failure of DNS query. The fault was finally resolved by restarting the network service. Next, the system needs to perform correlation analysis on the historical fault type data and fault monitoring indicator data to construct a fault classification data set. For example, through the correlation analysis algorithm, it can be found that CPU usage, memory usage, and DNS query success rate are highly correlated with the server hardware fault type. Set the correlation threshold to 8, and filter out fault monitoring indicators with correlations exceeding the threshold, such as CPU usage, memory usage, etc. The final fault classification data set contains each fault type and several highly correlated fault monitoring indicators. For example, the indicators corresponding to the "server hardware fault" type may include CPU usage, memory usage, disk IO, etc. The indicators corresponding to the "network connection interruption" type may include network traffic, packet loss rate, etc. Then, the fault classification data set is input into the decision tree model for training to obtain a fault diagnosis model. The decision tree model builds a decision tree by learning historical fault data, which is used to determine the fault type and cause based on real-time monitoring indicator data. For example, if the CPU usage is high and the memory usage is also high, the decision tree model may classify the fault as a server hardware failure. When a DNS service cluster fails, such as server A experiencing abnormal conditions such as a surge in CPU usage, a drop in query success rate, and an increase in response time, the system will input these real-time monitoring indicator data into the fault diagnosis model. Assume that the diagnosis model determines that the fault type is "server hardware failure" and the cause of the fault may be "CPU overload." Finally, based on the diagnosed fault type and cause, the system will select a suitable self-healing solution from the pre-set fault handling strategy knowledge base.The knowledge base stores predefined processing strategies for various types of faults. For example, for "server hardware failure" - "CPU overload", the preset processing strategy may be "restart the server" or "migrate the service to the backup server". The system will automatically execute the selected self-healing solution, such as restarting server A, or migrating the DNS service on server A to the backup server C, so as to quickly restore the DNS service and reduce the impact of the failure. This can improve the availability and stability of the DNS service, avoid manual intervention, speed up fault recovery, and improve operation and maintenance efficiency.

[0088] In some embodiments, the method further comprises:

[0089] Obtaining DNS resolution log data, taking the DNS resolution log data as input, and training using a reinforcement learning algorithm to obtain a reinforcement learning model;

[0090] The state space of the reinforcement learning model includes parsing request features and system operation indicators, the action space of the reinforcement learning model includes various parsing strategy parameters, and the reward function of the reinforcement learning model comprehensively considers the parsing success rate, response time and resource utilization;

[0091] The user's DNS resolution request is received in real time, and the optimal DNS resolution strategy corresponding to the DNS resolution request is determined according to the reinforcement learning model.

[0092] In this embodiment, DNS resolution log data is obtained, the log data is preprocessed, and relevant information such as resolution request features and system operation indicators are extracted. The state space of the reinforcement learning model is constructed based on the extracted information, including resolution request features and system operation indicators, and the action space, i.e., various optional DNS resolution strategy parameters, is determined. The reward function is designed, and factors such as DNS resolution success rate, response time, and resource utilization are comprehensively considered to give corresponding reward values ​​to different resolution strategies. Reinforcement learning algorithms such as Q-learning are used to train the model using the constructed state space, action space, and reward function, and the resolution strategy is optimized through continuous trial and error and learning. After the optimal reinforcement learning model is trained, it is deployed to the DNS resolution system. When the user's DNS resolution request is received in real time, the feature information of the request is extracted. The extracted request features are input into the reinforcement learning model, and the model quickly selects the optimal DNS resolution strategy parameters based on the current state and reward function. The selected optimal resolution strategy is applied to perform DNS resolution on the user request, and the resolution results are recorded for subsequent model updates and optimizations, continuously improving the performance and user experience of the DNS system.

[0093] For example, DNS resolution log data contains rich user behavior information and system performance indicators, and is a valuable resource for optimizing DNS resolution strategies. Reinforcement learning is a goal-oriented machine learning method that allows the DNS resolution system to continuously learn through interaction with the environment and ultimately find the optimal resolution strategy. The core components of the reinforcement learning model include state space, action space, and reward function. The state space describes the current state of the DNS resolution system. It can include resolution request features, such as request domain name, request type, client IP address, etc., as well as system operation indicators, such as server load, cache hit rate, network delay, etc. For example, a state can be represented as: domain name www.Example.com, request type A, client IP address 19161, server load 80%, cache hit rate 60%, network delay 50ms. The action space defines the various actions that the DNS resolution system can take. It can include various resolution strategy parameters, such as cache timeout, DNS server selection strategy, load balancing algorithm, etc. For example, an action can be: set the cache timeout of www.example.com to 300 seconds, and select the DNS server closest to the client for resolution. The reward function is used to evaluate the quality of the actions taken by the DNS resolution system. It needs to comprehensively consider the resolution success rate, response time and resource utilization. For example, a reward function can be defined as: resolution success rate × 5 + (1-response time / maximum response time) × 3 + (1-resource utilization / maximum resource utilization) × 2. If a resolution is successful, the response time is 100ms (maximum response time is 1000ms), and the resource utilization is 50% (maximum resource utilization is 100%), then the reward value is 5 + (1-1 / 10) × 3 + (1-1 / 2) × 2 = 5 + 2.7 + 1 = 8.7. The reinforcement learning algorithm continuously tries different actions and adjusts the strategy according to the feedback of the reward function, and finally learns an optimal resolution strategy. For example, if an action leads to an increase in the resolution success rate, a decrease in response time, and a decrease in resource utilization, then the probability of this action will increase; conversely, if an action leads to a resolution failure or performance degradation, then the probability of this action will decrease. In actual applications, the system will receive users' DNS resolution requests in real time, and input the resolution request characteristics and system operation indicators into the reinforcement learning model as input. The reinforcement learning model will select an optimal DNS resolution strategy based on the current state, such as selecting the best cache timeout, DNS server, and load balancing algorithm. In this way, the DNS resolution system can dynamically adjust the resolution strategy according to the real-time situation, thereby improving resolution efficiency and user experience.For example, for domain names with high access frequency, a longer cache timeout can be set to reduce the load on the DNS server; for domain names with low access frequency, a shorter cache timeout can be set to ensure the accuracy of the resolution results. Through reinforcement learning, the DNS resolution system can be more intelligent and adaptive, thus better meeting the needs of users.

[0094] In some embodiments, the method further comprises:

[0095] Collecting game operation data and user feedback scores, and performing quantitative evaluation on the importance of each game based on the game operation data and the user feedback scores to obtain quantitative evaluation results;

[0096] Determining a game priority level for each game based on the quantitative evaluation results;

[0097] Obtain historical traffic data, input the historical traffic data into a time series prediction algorithm for training and prediction, and obtain traffic change trends within a future preset time period;

[0098] A DNS resolution resource allocation scheme for each game is determined according to the game priority level and the traffic change trend.

[0099] In this embodiment, game operation data, including in-game player behavior data, payment data, etc., are obtained to construct a game operation data feature vector; user feedback rating data is obtained, sentiment analysis is performed on the feedback content, keywords are extracted, and a user feedback rating feature vector is constructed; the game operation data feature vector and the user feedback rating feature vector are input into a pre-trained deep neural network model, and a quantitative evaluation score of each game is obtained through model reasoning; based on the quantitative evaluation scores, the games are clustered using a clustering algorithm, and games with similar scores are divided into the same cluster; for the games in each cluster, their priority levels are determined based on their quantitative evaluation scores, and the higher the score, the higher the priority level; the priority level information of each game is updated to the game operation management system, and the operation personnel can formulate operation strategies and resource allocation plans based on the priority level information; the changes in game operation data and user feedback rating data are continuously tracked, and quantitative evaluations and priority levels are re-determined regularly to dynamically adjust the operation strategy and improve the game operation effect.

[0100] Obtain the historical traffic data of the game, pre-process the traffic data, remove outliers and noise data, and obtain the cleaned traffic data. Based on the cleaned historical traffic data, use time series prediction algorithms such as ARIMA and LSTM to establish a traffic prediction model through training to predict the traffic change trend of each game in the future. Obtain the priority data of each game. The priority can be obtained by comprehensive evaluation based on factors such as the importance and profitability of the game. Fusion the game priority data and the predicted traffic change trend data, and calculate the comprehensive weight score of each game by setting the priority weight and traffic weight. Based on the comprehensive weight score of each game, use resource allocation algorithms such as greedy algorithm and dynamic programming to determine the optimal allocation plan of DNS resolution resources among different games. If the actual traffic of a game exceeds the predicted value and lasts for a period of time, dynamically adjust the DNS resolution resource allocation of the game to ensure the smooth operation of the game. Continuously monitor the actual traffic data of each game, compare the actual traffic with the predicted traffic, continuously optimize the traffic prediction model and resource allocation plan, and improve the work efficiency of the overall system.

[0101] Exemplarily, collecting game operation data and user feedback scores is to understand the importance of each game to the company's business. Game operation data may include the number of active users, payment rate, average online time, etc. of the game. User feedback scores can be obtained through questionnaires, app store ratings, etc. For example, the number of daily active users of game A is 100,000, the payment rate is 5%, the average online time is 1 hour, and the user feedback score is 5 points (out of 5 points). The number of daily active users of game B is 50,000, the payment rate is 10%, the average online time is 2 hours, and the user feedback score is 4 points. Through these data, the importance of game A and game B can be quantitatively evaluated. The quantitative evaluation results can be weighted averaged. For example, the weight of the number of daily active users can be set to 4, the weight of the payment rate can be set to 3, the weight of the average online time can be set to 2, and the weight of the user feedback score can be set to 1. Based on the quantitative evaluation results, the game priority level of each game can be determined. This is done to prioritize the experience of important game users when resources are limited.

[0102] The purpose of obtaining historical traffic data is to predict future traffic trends. Historical traffic data can include information such as the number of DNS resolution requests and request time for each game. For example, in the past week, the average number of DNS resolution requests for Game A was 1 million per day, and the average number of DNS resolution requests for Game B was 500,000 per day. By inputting these historical traffic data into a time series prediction algorithm, such as an ARIMA model, the traffic trend for the next week can be predicted. Assume that the prediction results show that the number of DNS resolution requests for Game A will increase by 10% in the next week, and the number of DNS resolution requests for Game B will increase by 20%. Based on the game priority and traffic trend, the DNS resolution resource allocation plan for each game can be determined. For example, Game A has a higher game priority than Game B, and the number of DNS resolution requests for Game A will increase by 10% in the next week, so more DNS resolution resources should be allocated to Game A. Specifically, the number of DNS resolution servers for Game A can be increased proportionally according to the predicted traffic growth ratio, or the DNS resolution cache hit rate for Game A can be increased. This ensures that the DNS resolution requests of important game users can be responded to in a timely manner during traffic peaks, thereby improving user experience. The allocation scheme can be adjusted according to actual conditions, for example, resource allocation can be dynamically adjusted according to the real-time traffic of the game. This can make more efficient use of resources and ensure the user experience of all games.

[0103] Reference Figure 2 An embodiment of the present invention provides a configuration optimization system 2 for a multi-cloud DNS service, and the system 2 specifically includes:

[0104] The first configuration optimization module 201 is used to deploy at least one DNS service node in each cloud service environment to form a DNS service cluster, and perform configuration management on the DNS service cluster through Terraform;

[0105] The second configuration optimization module 202 plans and sets edge computing nodes for sinking DNS services in each region according to the geographical distribution of players around the world;

[0106] The third configuration optimization module 203 uses blockchain technology to synchronize DNS resolution records between various DNS service nodes, and verifies and confirms the DNS resolution records through a consensus algorithm;

[0107] The fourth configuration optimization module 204 performs fault prediction on each DNS service node and each edge computing node through a machine learning algorithm to obtain a fault prediction result, and dynamically adjusts the DNS service parameter configuration according to the fault prediction result;

[0108] The fifth configuration optimization module 205 determines the fault type and fault cause based on a preset fault diagnosis model when the DNS service cluster fails, determines a self-healing solution according to the fault type and the fault cause, and performs fault recovery through the self-healing solution.

[0109] It is understandable that if Figure 1 The contents of the configuration optimization method embodiment of the multi-cloud DNS service shown in the figure are all applicable to the configuration optimization system embodiment of the multi-cloud DNS service. The functions specifically implemented by the configuration optimization system embodiment of the multi-cloud DNS service are similar to those in the embodiment of the multi-cloud DNS service configuration optimization method shown in the figure. Figure 1 The configuration optimization method embodiment of the multi-cloud DNS service shown in FIG. 1 is the same as that of FIG. 1 , and the beneficial effects achieved are the same as those of FIG. Figure 1 The beneficial effects achieved by the configuration optimization method embodiment of the multi-cloud DNS service shown are also the same.

[0110] It should be noted that the information interaction, execution process and other contents between the above-mentioned systems are based on the same concept as the embodiment of the method of the present invention. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0111] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0112] Reference Figure 3 The embodiment of the present invention further provides a computer device 3, comprising: a memory 302 and a processor 301 and a computer program 303 stored on the memory 302. When the computer program 303 is executed on the processor 301, a configuration optimization method for a multi-cloud DNS service as described in any one of the above methods is implemented.

[0113] The computer device 3 may be a computing device such as a desktop computer, a notebook, a PDA, or a cloud server. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will appreciate that Figure 3 It is only an example of computer device 3 and does not constitute a limitation on computer device 3. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components, for example, it may also include input and output devices, network access devices, etc.

[0114] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0115] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as a hard disk or memory of the computer device 3. In other embodiments, the memory 302 may also be an external storage device of the computer device 3, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the computer device 3. Further, the memory 302 may also include both an internal storage unit of the computer device 3 and an external storage device. The memory 302 is used to store an operating system, an application program, a boot loader (Boot Loader), data, and other programs, such as the program code of the computer program, etc. The memory 302 may also be used to temporarily store data that has been output or is to be output.

[0116] An embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the configuration optimization method for a multi-cloud DNS service as described in any one of the above methods is implemented.

[0117] In this embodiment, if the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium. When the computer program is executed by the processor, the steps of the above-mentioned various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium can at least include: any entity or device that can carry the computer program code to the camera / terminal device, recording medium, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium. For example, a USB flash drive, a mobile hard disk, a disk or an optical disk. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electric carrier signals and telecommunication signals.

[0118] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0119] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0120] In the embodiments disclosed in the present application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

Claims

1. A configuration optimization method for a multi-cloud DNS service, characterized in that: The method specifically comprises: At least one DNS service node is deployed in each cloud service environment to form a DNS service cluster, and the DNS service cluster is configured and managed through Terraform; According to the geographical distribution of players around the world, edge computing nodes for sinking DNS services are planned and set up in each region; Blockchain technology is used to synchronize DNS resolution records between various DNS service nodes, and the DNS resolution records are verified and confirmed through a consensus algorithm; Perform fault prediction on each DNS service node and each edge computing node through a deep learning algorithm to obtain a fault prediction result, and dynamically adjust the DNS service parameter configuration according to the fault prediction result; When a fault occurs in the DNS service cluster, the fault type and fault cause are determined based on a preset fault diagnosis model, a self-healing solution is determined according to the fault type and the fault cause, and fault recovery is performed through the self-healing solution.

2. The method according to claim 1, characterized in that According to the geographical distribution of players around the world, edge computing nodes for sinking DNS services are planned and set up in each region, specifically including: Obtaining geographical location distribution data of players worldwide, clustering the geographical location distribution data of players using a K-means clustering algorithm, and obtaining the distribution of players in each region; Determine the player gathering area and non-player gathering area in each area according to the player distribution situation; Edge computing nodes are set up in player gathering areas in each region to sink DNS services.

3. The method according to claim 1, characterized in that The use of blockchain technology to synchronize DNS resolution records between various DNS service nodes and verifying and confirming the DNS resolution records through a consensus algorithm specifically includes: When the DNS resolution record of any DNS service node changes, the changed DNS resolution record is packaged into a block through the smart contract and broadcast to other DNS service nodes; After each DNS service node receives the block, the digital signature and timestamp of the block are verified through the PoW consensus algorithm. If the verification passes, the respective DNS resolution records are updated according to the block.

4. The method according to claim 1, characterized in that: The fault prediction of each DNS service node and each edge computing node is performed by a deep learning algorithm to obtain a fault prediction result, which specifically includes: Acquire historical operation data of the DNS service, and obtain a first key feature subset by performing feature extraction on the historical operation data; Acquire external environment data, and obtain a second key feature subset by performing feature extraction on the external environment data; Inputting the first key feature subset and the second key feature subset into the LSTM model for training to obtain a fault prediction model for determining the probability of a fault occurring, wherein the fault prediction model is used to predict a fault for any DNS service node and any edge computing node and output a fault occurrence probability; The fault prediction result is determined by comparing the fault occurrence probability output by the fault prediction model with a preset fault probability threshold.

5. The method according to claim 1, characterized in that When the DNS service cluster fails, the fault type and fault cause are determined based on a preset fault diagnosis model, and a self-healing solution is determined according to the fault type and the fault cause, specifically including: Obtaining fault monitoring indicator data of the DNS service cluster in real time; Acquire historical fault type data, and perform correlation analysis on the historical fault type data and the fault monitoring indicator data through a correlation analysis algorithm to obtain a fault classification data set, wherein the fault classification data set includes each fault type and several fault monitoring indicators whose correlation exceeds a correlation threshold; Inputting the fault classification data set into a decision tree model for training to obtain a fault diagnosis model; When the DNS service cluster fails, the fault type and cause are determined according to the fault diagnosis model; Based on the fault type and the fault cause, a corresponding self-healing solution is determined from a preset fault handling strategy knowledge base.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: Obtaining DNS resolution log data, taking the DNS resolution log data as input, and training using a reinforcement learning algorithm to obtain a reinforcement learning model; The state space of the reinforcement learning model includes parsing request features and system operation indicators, the action space of the reinforcement learning model includes various parsing strategy parameters, and the reward function of the reinforcement learning model comprehensively considers the parsing success rate, response time and resource utilization; The user's DNS resolution request is received in real time, and the optimal DNS resolution strategy corresponding to the DNS resolution request is determined according to the reinforcement learning model.

7. The method according to any one of claims 1 to 5, characterized in that The method further comprises: Collecting game operation data and user feedback scores, and performing quantitative evaluation on the importance of each game based on the game operation data and the user feedback scores to obtain quantitative evaluation results; Determining a game priority level for each game based on the quantitative evaluation results; Obtain historical traffic data, input the historical traffic data into a time series prediction algorithm for training and prediction, and obtain traffic change trends within a future preset time period; A DNS resolution resource allocation scheme for each game is determined according to the game priority level and the traffic change trend.

8. A configuration optimization system for multi-cloud DNS services, characterized in that: The system specifically comprises: A first configuration optimization module is used to deploy at least one DNS service node in each cloud service environment to form a DNS service cluster, and perform configuration management on the DNS service cluster through Terraform; The second configuration optimization module plans and sets edge computing nodes for sinking DNS services in various regions according to the geographical distribution of players around the world; The third configuration optimization module uses blockchain technology to synchronize DNS resolution records between various DNS service nodes, and verifies and confirms the DNS resolution records through a consensus algorithm; The fourth configuration optimization module predicts faults of each DNS service node and each edge computing node through a machine learning algorithm to obtain fault prediction results, and dynamically adjusts the DNS service parameter configuration according to the fault prediction results; The fifth configuration optimization module determines the fault type and fault cause based on a preset fault diagnosis model when the DNS service cluster fails, determines a self-healing solution according to the fault type and the fault cause, and performs fault recovery through the self-healing solution.

9. A computer device, characterized in that: include: A memory, a processor, and a computer program stored in the memory. When the computer program is executed on the processor, the configuration optimization method for the multi-cloud DNS service according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor, the configuration optimization method of the multi-cloud DNS service as described in any one of claims 1 to 7 is implemented.

Images