Flow scheduling method, device and equipment for fused CDN (Content Delivery Network)

Abstract

The embodiment of the invention provides a traffic scheduling method, device and equipment for a fused CDN (Content Delivery Network). The method comprises the following steps: acquiring first bandwidth data of a dynamic service domain in a target area; wherein the dynamic service domain belongs to a first sub-domain name; wherein a mapping relationship exists between the dynamic service domain and the first CDN service node of the 95 charging mode; the target area further comprises at least one second sub-domain name, and the second CDN service node corresponding to the second sub-domain name is charged based on the flow; determining a first weight of the dynamic service domain according to the first bandwidth data and a historical weight of the dynamic service domain; determining second weights of the first sub-domain names and third weights corresponding to the second sub-domain names based on the first weights; and scheduling the access request from the target area based on the first weight, the second weight and the third weight. Accurate configuration of the access request to the CDN service node is realized, and the traffic scheduling efficiency can be improved.

Description

Technical Field

[0001] The embodiments of the present disclosure relate to the field of computer and network communication technology, and in particular, to a traffic scheduling method, device and equipment for converged CDN. Background Art

[0002] Content Delivery Network (CDN) stores and distributes content by deploying server nodes in multiple geographical locations. It allocates content services to the server node that is geographically closest to the user to provide content services, thereby reducing network congestion and improving the response efficiency of user content requests. CDN can be applied to content distribution services of different types of businesses, such as video streaming services, software downloads, e-commerce platforms, web content, and mobile content acceleration.

[0003] Fusion CDN can combine CDN services provided by different CDN providers to optimize performance and reduce costs. Currently, fusion CDN can schedule traffic by combining cost reduction and service performance, but the above scheduling scheme is not accurate to the CDN service edge node, resulting in low accuracy and efficiency of traffic scheduling. Summary of the invention

[0004] The embodiments of the present disclosure provide a traffic scheduling method, apparatus and device for converged CDN to overcome the problem of low accuracy and efficiency of traffic scheduling currently used for converged CDN.

[0005] In a first aspect, an embodiment of the present disclosure provides a traffic scheduling method for a converged CDN, comprising: obtaining first bandwidth data of a dynamic service domain in a target area; wherein the dynamic service domain belongs to a first subdomain name; wherein a mapping relationship exists between the dynamic service domain and a first CDN service node of a 95 billing method; the target area also includes at least one second subdomain name, and the second CDN service node corresponding to the second subdomain name is based on traffic billing; determining a first weight of the dynamic service domain based on the first bandwidth data and a historical weight of the dynamic service domain; determining a second weight of the first subdomain name and a third weight corresponding to each of the second subdomain names based on the first weight; and scheduling access requests from the target area based on the first weight, the second weight, and the third weight.

[0006] In a second aspect, an embodiment of the present disclosure provides a traffic scheduling device for a converged CDN, comprising: an acquisition unit, configured to acquire first bandwidth data of a dynamic service domain within a target area; wherein the dynamic service domain belongs to a first subdomain name; wherein a mapping relationship exists between the dynamic service domain and a first CDN service node of a 95 billing method; the target area also includes at least one second subdomain name, and the second CDN service node corresponding to the second subdomain name is based on traffic billing; a first weight determination unit, configured to determine a first weight of the dynamic service domain based on the first bandwidth data and a historical weight of the dynamic service domain; a second weight determination unit, configured to determine a second weight of the first subdomain name and a third weight corresponding to each second subdomain name based on the first weight; and a scheduling unit, configured to schedule access requests from the target area based on the first weight, the second weight and the third weight.

[0007] In a third aspect, an embodiment of the present disclosure provides an electronic device, including: a processor and a memory;

[0008] The memory stores computer-executable instructions;

[0009] The processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the method described in the first aspect and various possible designs of the first aspect.

[0010] In a fourth aspect, an embodiment of the present disclosure provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer execution instructions. When a processor executes the computer execution instructions, the method described in the first aspect and various possible designs of the first aspect are implemented.

[0011] In a fifth aspect, an embodiment of the present disclosure provides a computer program product, including a computer program, which, when executed by a processor, implements the method described in the first aspect and various possible designs of the first aspect.

[0012] The traffic scheduling method, device and equipment for converged CDN provided in this embodiment, the method obtains the first bandwidth data of the dynamic service domain in the target area; wherein the dynamic service domain belongs to the first subdomain; wherein the dynamic service domain has a mapping relationship with the first CDN service node of the 95 billing method; the target area also includes at least one second subdomain, and the second CDN service node corresponding to the second subdomain is based on traffic billing; according to the first bandwidth data and the historical weight of the dynamic service domain, the first weight of the dynamic service domain is determined; based on the first weight, the second weight of the first subdomain and the third weight corresponding to each second subdomain are determined; based on the first weight, the second weight and the third weight, the access request from the target area is scheduled. In the above process, due to the dynamic service domain corresponding to the first CDN service node participating in the traffic configuration, the cost can be accurately controlled. In addition, under the premise of reducing costs, the accurate configuration of access requests to the CDN service node is realized, which can improve the efficiency of traffic scheduling. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0014] Figure 1 A flow chart of a traffic scheduling method for integrated CDN provided in an embodiment of the present disclosure Figure 1 ;

[0015] Figure 2 A schematic diagram of 95 billing provided in an embodiment of the present disclosure;

[0016] Figure 3 A flow chart of a traffic scheduling method for integrated CDN provided in an embodiment of the present disclosure Figure 2 ;

[0017] Figure 4 It is a flow distribution diagram;

[0018] Figure 5 A schematic diagram of the structure of a traffic scheduling device for integrating CDN provided in an embodiment of the present disclosure;

[0019] Figure 6 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0020] In order to make the purpose, technical solution and advantages of the embodiments of the present disclosure clearer, the technical solution in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present disclosure.

[0021] A converged CDN can include CDN services provided by different CDN providers. Each CDN provider can deploy multiple CDN edge servers in multiple geographic regions. Content providers can cache content (such as video content, application content) to CDN edge servers through the network. When receiving a user's access request for content, the user is dispatched to obtain the content nearby. Different CDN providers have different advantages in different geographic regions. The use of a converged CDN can ensure better coverage and performance in different geographic regions. For example, the use of a converged CDN service can transfer the CDN service provided by other providers when a problem occurs with the CDN service provided by one provider, which can significantly reduce latency and improve reliability and redundancy. By scheduling access requests, the CDN with the best performance in a specific area can be routed to speed up loading time and optimize performance. Traffic distribution can be performed across CDNs of different providers to prevent overload of any single network, especially during network overload during traffic surges.

[0022] CDN services provided by different providers can be charged according to different billing methods, such as 95th percentile billing and flow-based billing. For converged CDN, the CDN allocation and usage ratio provided by different CDN providers deployed in different geographical areas (geographical areas here can be divided according to different granularities, such as country or region) can be determined according to the capacity and cost of different providers.

[0023] At present, traffic (traffic refers to user access requests) is allocated to different CDN services according to the CDN allocation usage ratio of different providers. Traffic allocation is carried out under the allocation rule of reducing the total CDN service cost while ensuring the CDN service performance. In the above traffic allocation, traffic can be allocated to the subdomains corresponding to different providers, but it cannot be accurately allocated to the CDN service nodes. Therefore, it is impossible to achieve accurate traffic scheduling while reducing costs, and the scheduling efficiency is also low.

[0024] refer to Figure 1 , Figure 1 A flow chart of a traffic scheduling method for integrated CDN provided in an embodiment of the present disclosure Figure 1The method of this embodiment can be applied to a scheduling system of a CDN service, and the method includes:

[0025] S101: Obtain first bandwidth data of a dynamic service domain in a target area; wherein the dynamic service domain belongs to a first subdomain; wherein there is a mapping relationship between the dynamic service domain and a first CDN service node of a 95 billing method; the target area also includes at least one second subdomain, and a second CDN service node corresponding to the second subdomain is charged based on traffic.

[0026] The above scheduling service system may include a weight maintenance platform and a scheduling server. The weight maintenance platform may store static weight allocation information corresponding to different subdomains, and obtain bandwidth data sent by different service nodes in multiple areas.

[0027] In order to quickly dispatch the user's access request, in this embodiment, the access request is dispatched according to the source area of ​​the access request. For each geographical area, the CDN service node set in the geographical area provides services for the access request from the geographical area.

[0028] The target area here may be any geographical area among a plurality of geographical areas divided according to a preset division granularity.

[0029] The CDN service in the first CDN service node is provided by the first CDN provider. Here, the first CDN provider charges for the CDN service in accordance with the 95 billing method. A dynamic service domain can be uniquely mapped to a first CDN service node.

[0030] The target area also includes at least one second subdomain other than the first subdomain. The second subdomain here refers to other subdomains other than the first subdomain. As an example, each second subdomain may correspond to a second CDN provider. Each second subdomain may correspond to at least one second CDN service node. The second CDN providers corresponding to different second subdomains may be different. The second CDN provider charges for CDN services according to traffic.

[0031] That is, the CDN services provided by different CDN providers can be divided into two types according to the billing method. One is billing based on traffic, and the other is 95 billing method (also known as 95 percentile billing).

[0032] CDN providers that use traffic-based billing can charge based on the actual amount of data transmitted in the CDN service. The cost incurred is directly related to the actual amount of data required for content distribution.

[0033] The 95th percentile billing method uses the bandwidth usage corresponding to the 95th percentile within the billing period (for example, the period from t0 to t1) as the billing value within the billing period, and uses the product of the billing value, the duration of the billing period (for example, the time interval from t0 to t1) and the unit price as the cost incurred during that period.

[0034] Please refer to Figure 2 , Figure 2 Figure 1 is a schematic diagram of traffic adjustment for different billing methods. Figure 2 As shown in FIG. 1 , for the 95th billing method, the bandwidth usage data corresponding to the 95th percentile is used as the billing value for the entire billing period. The cost generated during the billing period is positively correlated with the area of ​​rectangle 202. In fact, the bandwidth usage during the billing period is as follows: Figure 2 As shown by the middle dotted line 201. The actual bandwidth usage during the off-peak period in the entire billing cycle is shown by the dotted line 201, that is, the bandwidth that has incurred costs during the off-peak period is not used. At the same time, the CDN service that charges by flow is still allocating traffic during the off-peak period and is also incurring costs. In order to reduce the total CDN service cost, it is possible to consider adjusting at least a portion of the traffic allocated to the CDN service using flow charging during the off-peak period to the CDN service using 95 charging. In the CDN service using 95 charging, the traffic distribution in the billing cycle after the traffic adjustment is shown as curve 203.

[0035] In the CDN service of flow billing mode, the flow distribution before flow adjustment is shown as curve 205, and the flow distribution after flow adjustment is shown as curve 204. Through the above adjustment, it can be seen that during the valley period, the flow allocated to the CDN service of flow billing mode decreases, while the flow allocated to the CDN service of 95 billing mode increases. It can be understood that the above adjustment of flow distribution is a dynamic process.

[0036] In order to achieve the above adjustment, the above scheduling server can periodically (for example, every 5 minutes) obtain the first bandwidth data of the dynamic service domain from the dynamic service domain. The duration of the above period can be set according to the specific application scenario, and is limited here. The above first bandwidth data may include the bandwidth usage of the dynamic service domain, the target bandwidth, and the bandwidth of the first CDN service node.

[0037] S102: Determine a first weight of the dynamic service domain according to the first bandwidth data and a historical weight of the dynamic service domain.

[0038] The historical weight of the dynamic service domain may be the weight corresponding to the last traffic distribution adjustment.

[0039] As an implementation method, the historical weight of the dynamic service domain can be used as the first weight of the current period. For example, when the absolute value of the difference between the bandwidth usage and the target bandwidth in the first bandwidth data is less than a preset threshold, the historical weight can be used as the first weight of the current period. The above target bandwidth can be a bandwidth pre-configured for the dynamic service domain. Under the above target bandwidth usage, the dynamic service domain can provide better CDN services.

[0040] In some implementations, the above step S102 includes:

[0041] According to the bandwidth usage and the target bandwidth, the historical weight is increased or decreased to obtain a first weight; wherein the first bandwidth data includes the bandwidth usage and the target bandwidth.

[0042] For example, if the bandwidth usage in the first bandwidth data is less than the target bandwidth, the size of the historical weight may be increased to obtain the first weight.

[0043] For another example, if the bandwidth usage is greater than the target bandwidth, the historical weight may be reduced to obtain a first weight.

[0044] In these implementations, the historical weight is increased or decreased according to the bandwidth usage and the target bandwidth, so that when traffic is allocated to the dynamic service domain according to the obtained first weight, the bandwidth usage of the traffic allocated to the dynamic service domain can be close to the target bandwidth.

[0045] In the above process, the weight of the dynamic service domain can be periodically increased or decreased, so that the access requests allocated to the dynamic service domain can be dynamically adjusted according to the bandwidth usage of the dynamic service domain, so as to allocate as many access requests as possible to the dynamic service domain without affecting performance.

[0046] S103: Based on the first weight, determine the second weight of the first subdomain and the third weight corresponding to each second subdomain.

[0047] The first subdomain may have multiple node domain names, and the multiple node domain names may include the domain name of the dynamic service domain and the secondary logical domain name of the first subdomain.

[0048] As an implementation method, the static weights corresponding to each subdomain may be preset. For example, if the second subdomain includes the second subdomains A1 and A2, and the first subdomain includes the first subdomain A3, the static weights of the second subdomains A1, A2 and the first subdomain A3 may be preset. For example, the static weights of the second subdomains A1, A2 and the first subdomain A3 are 30%, 30% and 40% respectively. The static weights may be set according to specific application scenarios, and are not limited here.

[0049] The first subdomain name may correspond to at least one dynamic service domain. Each dynamic service domain may have its own domain name.

[0050] The second weight of the first subdomain name may be determined according to the respective first weights of at least one dynamic service domain corresponding to the first subdomain name, and the third weights corresponding to the respective second subdomain names may be determined.

[0051] For example, the increase in the first weight corresponding to the dynamic service domain relative to the historical weight is added to the historical weight of the first subdomain according to a preset ratio to obtain the second weight of the first subdomain. Then, the third weight of each second subdomain is determined based on the second weight of the first subdomain.

[0052] In an illustrative manner, the difference may be obtained by subtracting the second weight from the sum of all preset weights, and then the third weight corresponding to each second subdomain name is determined according to the proportional relationship between the weights of each second subdomain name.

[0053] S104: Scheduling access requests from the target area based on the first weight, the second weight, and the third weight.

[0054] In one example, the first weight, the second weight, and the third weight can be sent to the scheduler, and the scheduler determines the first part of the user access requests from the total user access requests received in the current cycle according to the first weight of the dynamic service domain, and sets the service IP address of the first CDN service node for the first part of the user access requests. Feedback information carrying the service IP address of the first CDN service node is sent to the terminal device that sent the first part of the user access request, so that the terminal device accesses the first CDN service node according to the service IP address. This achieves accurate allocation of user access requests to the first CDN service node according to the first weight, thereby improving the efficiency of traffic scheduling.

[0055] In one example, the scheduling server may determine the second part of user access requests to the second subdomain according to the third weight. For each second subdomain, the scheduling server may configure an access request to at least one second CDN service node corresponding to the second subdomain according to load balancing.

[0056] The target weights corresponding to other CDN service nodes other than the first CDN service node under the first subdomain may be determined according to the first weight and the second weight, and access requests may be allocated to these other CDN service nodes according to the target weight.

[0057] In this embodiment, by obtaining the first bandwidth data of the dynamic service domain in the target area; wherein the dynamic service domain belongs to the first subdomain; wherein there is a mapping relationship between the dynamic service domain and the first CDN service node of the 95 billing method; the target area also includes at least one second subdomain, and the second CDN service node corresponding to the second subdomain is based on traffic billing; according to the first bandwidth data and the historical weight of the dynamic service domain, the first weight of the dynamic service domain is determined; based on the first weight, the second weight corresponding to the first subdomain and the third weight corresponding to each second subdomain are determined; based on the first weight, the second weight and the third weight, the access request from the target area is scheduled. In the above scheduling process, due to the dynamic service domain corresponding to the first CDN service node participating in the traffic configuration, accurate cost control can be achieved. In addition, under the premise of reducing costs, accurate configuration of access requests to CDN service nodes is achieved, which can improve the efficiency of traffic scheduling.

[0058] Please refer to Figure 3 , Figure 3 Schematic diagram of the flow of the traffic scheduling method for integrated CDN provided in the present disclosure Figure 2 .like Figure 3 As shown, the method comprises the following steps:

[0059] S301: Obtain first bandwidth data of a dynamic service domain in a target area; wherein the dynamic service domain belongs to a first subdomain; wherein there is a mapping relationship between the dynamic service domain and a first CDN service node of a 95 billing method; the target area also includes at least one second subdomain, and a second CDN service node corresponding to the second subdomain is charged based on traffic.

[0060] The specific implementation of the above step S301 can refer to Figure 1 The description of step S101 is omitted here.

[0061] The first subdomain name may include multiple node domain names. The multiple node domain names may include a domain name of a dynamic service domain and a secondary logical domain name of the first subdomain name.

[0062] S302: According to the bandwidth usage and the target bandwidth, increase or decrease the historical weight to obtain a first weight; wherein the first bandwidth data includes the bandwidth usage and the target bandwidth.

[0063] As an implementation method, the above step S302 includes the following steps:

[0064] First, the update ratio is determined according to the target bandwidth, bandwidth usage, and the maximum bandwidth of the dynamic service domain.

[0065] Secondly, the historical weight is increased or decreased based on the update ratio to obtain the first weight.

[0066] For the dynamic service domain D1, the update ratio of the dynamic service domain D1 in the current period can be determined according to the first bandwidth data obtained in the current period. The above update ratio is used to update the first weight of the previous period.

[0067] Schematically, it is assumed that the target bandwidth of the dynamic service domain (that is, the first CDN service node corresponding to the dynamic service domain) is B t , bandwidth usage is B c , the maximum bandwidth of the dynamic service domain is B d , the above update ratio p can be calculated based on the following formula (1):

[0068]

[0069] The above target bandwidth B t Can be smaller than the maximum bandwidth B of the dynamic service domain d For example, the target bandwidth of the dynamic service domain can be set to the maximum B d 80% etc.

[0070] The historical weight of the dynamic service domain D1 may be increased or decreased according to the above update ratio.

[0071] In some application scenarios, if the bandwidth usage is less than the target bandwidth, the historical weight is increased according to the update ratio to obtain the first weight.

[0072] If the bandwidth usage in the first bandwidth data obtained in the current period of the dynamic service domain D1 is less than the target bandwidth, for example, if the historical weight is w h , the first weight w1 can be determined according to the following formula (2):

[0073] w 1＝ w h ×(1+p) (2).

[0074] This application scenario can be a traffic scheduling scenario corresponding to a low traffic period. In this application scenario, since the total number of access requests during this period is small, access requests can be added to the dynamic service domain to utilize the paid but unused "free" bandwidth. Since access requests are added to the dynamic service domain, access requests on the CDN service node in the traffic billing method can be reduced, thereby saving the fees generated on the CDN service node in the traffic billing method.

[0075] In some application scenarios, if the bandwidth usage is less than the target bandwidth, the historical weight is reduced according to the update ratio to obtain a candidate first weight; the first weight is determined according to the size of the candidate first weight and the preset first weight threshold. The preset first weight threshold here is pre-determined for the dynamic service domain.

[0076] If the bandwidth usage in the first bandwidth data obtained in the current period of the dynamic service domain D1 is greater than the target bandwidth, for example, if the historical weight is w h , the candidate first weight w2 can be determined according to the following formula (3):

[0077] w 2＝ w h ×(1-p) (3).

[0078] The candidate first weight w2 and the preset first weight threshold (w min ) is used as the larger one of the first weight of the dynamic service domain.

[0079] S303: Determine the secondary weight of the first subdomain name according to the first weight of the dynamic service domain.

[0080] The weight corresponding to the secondary logical domain name of the first subdomain name may be determined according to the first weight of the dynamic service domain, and the weight may be used as the secondary weight of the first subdomain name.

[0081] Here you can set the secondary weights corresponding to each node domain name under the first subdomain. Assume that the weight of the secondary logical domain name of the first subdomain is a, and the secondary weights corresponding to the domain names v1 and v2 of the dynamic service domain are b and c respectively. You can set the final weight of the secondary logical domain name assigned to the first subdomain to be equal to the static weight.

[0082]

[0083] The above x can be the static weight of the secondary logical domain name of the first subdomain; w 1-v1 It can be the first weight of the domain name v1 of the dynamic service domain calculated by formula (2) or (3), w 1-v2 It can be the first weight of the domain name v2 of the dynamic service domain calculated by formula (2) or (3). a, b and c can be calculated by the above formulas (4) to (6).

[0084] S304: Determine the second weight based on a preset constraint relationship between the secondary weight of the first subdomain name and the second weight.

[0085] The preset constraint relationship may be, for example, that the product of the secondary weight of the first subdomain and the second weight is equal to the static weight assigned to the secondary logical domain of the first subdomain to determine the second weight of the first subdomain.

[0086] The above constraint relationship can be expressed as:

[0087] m×a=x (7);

[0088] The above m is the second weight of the first subdomain, a is the secondary weight of the first subdomain, and x is the static weight of the secondary logical domain corresponding to the first subdomain.

[0089] The second weight of the first subdomain name may be calculated using the above constraint relationship.

[0090] S305: Determine third weights corresponding to the second subdomains based on the second weights and the preset ratios corresponding to the second subdomains.

[0091] After the second weight of the first subdomain is obtained, the weights of the multiple second subdomains may be determined.

[0092] For example, if the second weight of the first subdomain is m, then the weights of the multiple second subdomains are 1-m.

[0093] If the second subdomain includes D4 and D5, and the preset ratio of the weights of D4 and D5 is, for example, 2:1, then the third weight of the second subdomain D4 is determined to be equal to And the third weight of the second subdomain D5 is equal to

[0094] S306: Scheduling access requests from the target area based on the first weight, the second weight, and the third weight.

[0095] The specific implementation of step S306 can refer to Figure 1 The relevant description of step S301 is not repeated here.

[0096] In some implementations, the above steps S301 to S305 may be performed by a weight maintenance platform. After the above weight maintenance platform determines the above first weight and the third weight, it may update the weight list.

[0097] The weight list may include static weight configuration items and dynamic weight configuration items. The static weight configuration items may include static weights of multiple service nodes corresponding to the first subdomain name and static weights corresponding to each second subdomain name.

[0098] The above step S306 includes:

[0099] First, the pre-created weight list is updated using the first weight and the third weight; the weight list includes static weights and dynamic weight configuration items corresponding to each service node corresponding to the first subdomain and the second subdomain. Second, the updated weight list is sent to the scheduler, and the scheduler schedules the access request according to the updated weight list.

[0100] In these embodiments, the weight maintenance platform can update the dynamic weight configuration items of the weight list. Then send the updated weight list to the scheduling server. The dynamic weight configuration items of the updated weight list include the first weight of the dynamic service domain corresponding to the first subdomain and the third weight corresponding to the second subdomain. The scheduling server can allocate access requests to each CDN service node under the first subdomain according to the dynamic weight in the weight list, and allocate access requests to the CDN service nodes under the second subdomain.

[0101] In these implementations, the weights are determined and the weight list is updated through the weight maintenance platform, and the scheduler allocates access requests according to the updated weight list, thereby further improving the efficiency of traffic scheduling.

[0102] Please refer to Figure 4 , Figure 4 This is a flow distribution diagram. Figure 4 As shown, the weight maintenance platform can determine the first weight y of the dynamic service domain D1 and the first weight z of the dynamic service domain D2 according to the first bandwidth data of the dynamic service domain D1 and the dynamic service domain D2 corresponding to the first subdomain in the target area 1 obtained, and according to the above formulas (1) to (3). And according to the first weight y of the dynamic service domain D1, the first weight z of the dynamic service domain D2 and the static weight x finally allocated to the first subdomain, determine the secondary weight a of the secondary logical domain name of the first subdomain, the secondary weight b of the dynamic service domain D1 and the secondary weight c of the dynamic service domain D2. According to the preset constraint relationship between the secondary weight and the second weight of the first subdomain, determine the second weight (ordinary weight) m of the first subdomain. For example, the above constraint relationship can be that the product of the second weight m of the first subdomain and the secondary weight a of the first subdomain is equal to the static weight x of the secondary logical domain name of the first subdomain. Among them, the sum of the static weight x of the secondary logical domain name of the first subdomain, the first weight of the dynamic service domain D1 and the first weight of the dynamic service domain D2 is equal to the second weight m of the first subdomain.

[0103] In some examples, the second weight m of the first subdomain may be, for example, 20%. The remaining 80% weight is then distributed to the second subdomain 1 and the second subdomain 2. For example, the third weight w of the second subdomain 1 21 The third weight of the second subdomain 2 is 50%. 22 is 30%.

[0104] The dynamic weight configuration items in the weight list can be updated according to the third weight of the second subdomain name 1, 50%, the third weight of the second subdomain name 2, 30%, the second weight of the first subdomain name, the first weight y of the dynamic service domain D1, and the first weight z of the dynamic service domain D2. The weight maintenance platform can send the updated weight list to the scheduler, and the scheduler allocates access requests to the second subdomain name 1 and the second subdomain name 2 according to the third weight of the second subdomain name 1, 50%, and the third weight of the second subdomain name 2, 30% in the above dynamic weight configuration items; the access request allocated to the dynamic service domain D1 is determined by the first weight y of the dynamic service domain D1; the access request allocated to the dynamic service domain D2 is determined by the first weight z of the dynamic service domain D2. Since the dynamic service domain D1 can be mapped to the first CDN service node 1, the access request can be allocated to the first CDN service node 1 according to the first weight y. Since the dynamic service domain D2 can be mapped to the first CDN service node 2, the access request can be allocated to the first CDN service node 2 according to the first weight z. The above method accurately controls the traffic accessing the corresponding node by dynamically adjusting the weight ratio of the node domain name.

[0105] In this embodiment, it is described that according to the first weight of the dynamic service domain, the secondary weight of the first subdomain is determined, and according to the first weight and the secondary weight, the second weight of the first subdomain and the third weight of each second subdomain are determined, so that the weight of each node can be accurately determined, thereby further improving the accuracy and efficiency of traffic scheduling.

[0106] exist Figure 1 and Figure 3 In some implementations of the traffic scheduling method for converged CDN shown, the dynamic service domain in the method is obtained based on the following steps:

[0107] First, obtain the CDN service type and CDN service IP address registered at the edge node in the target area. The edge node is the edge node corresponding to the 95 billing CDN service provider.

[0108] Secondly, a domain name of a dynamic service domain is generated according to the edge node name, CDN service type and CDN service IP address; the domain name of the dynamic service domain and the CDN service IP address are registered to the associated node.

[0109] Specifically, there is a service discovery system at each edge node. When the CDN service is deployed at the edge node, the CDN service type and the corresponding service IP address will be registered in the service discovery system. For example, the short video service uses the vxx keyword as the service type.

[0110] A microservice is provided in the scheduling center for cost scheduling. This microservice will capture the node name, CDN service type, CDN service IP address from each node, and form a dynamic service domain name through the basic service zone. For example, the node name is bkk1, the CDN service type is vxx, and the basic service domain is ABCcdn.com. <service-type>-dyanmic-<node name>. <zone>Then the final domain name is: vxx-dynamic-bkk1.ABCcdn.com. This combination can have many forms as long as it is globally unique.

[0111] After obtaining the domain name of the dynamic service domain, the domain name and the corresponding service IP address are registered to the associated nodes, such as the DNS node and the fusion CDN center node, so that the associated nodes can detect the domain name of the dynamic service domain.

[0112] The above implementation method can create corresponding dynamic service domains for multiple 95 billing service nodes to facilitate traffic scheduling.

[0113] Corresponding to the traffic scheduling method for integrated CDN in the above embodiment, Figure 5 This is a structural block diagram of a traffic scheduling device for a converged CDN provided in an embodiment of the present disclosure. For ease of explanation, only the parts related to the embodiment of the present disclosure are shown. Figure 5 The device includes: an acquisition unit 501, a first weight determination unit 502, a first weight determination unit 503 and a scheduling unit 504.

[0114] The acquisition unit 501 is used to acquire first bandwidth data of a dynamic service domain in a target area; wherein the dynamic service domain belongs to a first subdomain; wherein a mapping relationship exists between the dynamic service domain and a first CDN service node of a 95 billing method; the target area also includes at least one second subdomain, and a second CDN service node corresponding to the second subdomain is charged based on traffic;

[0115] A first weight determination unit 502, configured to determine a first weight of the dynamic service domain according to the first bandwidth data and a historical weight of the dynamic service domain;

[0116] A second weight determination unit 503, configured to determine a second weight of the first subdomain and a third weight corresponding to each second subdomain based on the first weight;

[0117] The scheduling unit 504 is configured to schedule the access request from the target area based on the first weight, the second weight, and the third weight.

[0118] In one embodiment of the present disclosure, the first weight determination unit 502 is further configured to:

[0119] According to the bandwidth usage and the target bandwidth, the historical weight is increased or decreased, and the first weight is determined according to the result of the increase or decrease; wherein the first bandwidth data includes the bandwidth usage and the target bandwidth.

[0120] In one embodiment of the present disclosure, the first weight determination unit 502 is further configured to:

[0121] Determine the update ratio according to the target bandwidth, bandwidth usage and bandwidth of the dynamic service domain;

[0122] The history weight is increased or decreased based on the update ratio.

[0123] In one embodiment of the present disclosure, the first weight determination unit 502 is further configured to:

[0124] If the bandwidth usage is less than the target bandwidth, the historical weight is increased according to the update ratio, and the result of the increase is used as the first weight;

[0125] If the bandwidth usage is less than the target bandwidth, the historical weight is reduced according to the update ratio to obtain a candidate first weight; the first weight is determined according to the size of the candidate first weight and the preset first weight threshold.

[0126] In one embodiment of the present disclosure, the second weight determination unit 503 is further configured to:

[0127] Determining a secondary weight of the first subdomain name according to the first weight of the dynamic service domain;

[0128] The second weight is determined based on a preset constraint relationship between the secondary weight of the first subdomain name and the second weight.

[0129] In one embodiment of the present disclosure, the second weight determination unit 503 is further configured to:

[0130] Based on the second weight and the preset ratio relationship corresponding to each second subdomain name, a third weight corresponding to each second subdomain name is determined.

[0131] In one embodiment of the present disclosure, the scheduling unit 504 is further configured to:

[0132] The pre-created weight list is updated using the first weight and the third weight; the weight list includes static weights corresponding to each service node corresponding to the first subdomain and the second subdomain;

[0133] The updated weight list is sent to the scheduler, and the scheduler schedules the access request according to the updated weight list.

[0134] In one embodiment of the present disclosure, the apparatus 50 further includes a dynamic service domain creation unit (not shown in the figure), and the dynamic service domain creation unit is used to:

[0135] Obtain the CDN service type and CDN service IP address registered at the edge node in the target area. The edge node is the edge node corresponding to the CDN service provider of the 95 billing method.

[0136] Generate a domain name of a dynamic service domain according to the edge node name, CDN service type and CDN service IP address; register the domain name of the dynamic service domain and the CDN service IP address to the associated node.

[0137] The device provided in this embodiment can be used to execute the technical solution of the above method embodiment. Its implementation principle and technical effect are similar, and this embodiment will not be repeated here.

[0138] In order to implement the above embodiment, the embodiment of the present disclosure also provides an electronic device.

[0139] refer to Figure 6 , which shows a schematic diagram of the structure of an electronic device 600 suitable for implementing the embodiment of the present disclosure, and the electronic device 600 may be a terminal device or a server. The terminal device may include but is not limited to mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, personal digital assistants (PDAs), tablet computers, portable multimedia players (PMPs), vehicle terminals (such as vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0140] like Figure 6 As shown, the electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 to a random access memory (RAM) 603. Various programs and data required for the operation of the electronic device 600 are also stored in the RAM 603. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0141] Typically, the following devices may be connected to the I / O interface 605: input devices 606 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; output devices 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 608 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 609. The communication device 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 6 The electronic device 600 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0142] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, the above-mentioned functions defined in the method of the embodiment of the present disclosure are executed.

[0143] It should be noted that the computer-readable medium disclosed above may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in combination with an instruction execution system, device or device. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0144] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device.

[0145] The computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device executes the method shown in the above embodiment.

[0146] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0147] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0148] The units involved in the embodiments described in the present disclosure may be implemented by software or hardware. The name of a unit does not limit the unit itself in some cases. For example, the first acquisition unit may also be described as a "unit for acquiring at least two Internet Protocol addresses".

[0149] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0150] In a first aspect, according to one or more embodiments of the present disclosure, a traffic scheduling method for a converged CDN is provided, including:

[0151] Obtaining first bandwidth data of a dynamic service domain in a target area; wherein the dynamic service domain belongs to a first subdomain; wherein a mapping relationship exists between the dynamic service domain and a first CDN service node of a 95 billing method; the target area also includes at least one second subdomain, and a second CDN service node corresponding to the second subdomain is charged based on traffic;

[0152] Determining a first weight of the dynamic service domain according to the first bandwidth data and a historical weight of the dynamic service domain;

[0153] Based on the first weight, determine a second weight of the first subdomain and a third weight corresponding to each second subdomain;

[0154] The access request from the target area is scheduled based on the first weight, the second weight, and the third weight.

[0155] According to one or more embodiments of the present disclosure, determining a first weight of a dynamic service domain according to first bandwidth data and a historical weight includes:

[0156] According to the bandwidth usage and the target bandwidth, the historical weight is increased or decreased, and the first weight is determined according to the result of the increase or decrease; wherein the first bandwidth data includes the bandwidth usage and the target bandwidth.

[0157] According to one or more embodiments of the present disclosure, the historical weight is increased or decreased according to the bandwidth usage and the target bandwidth, including:

[0158] Determine the update ratio according to the target bandwidth, bandwidth usage and bandwidth of the dynamic service domain;

[0159] The history weight is increased or decreased based on the update ratio.

[0160] According to one or more embodiments of the present disclosure, the historical weight is increased or decreased based on the update ratio, and the first weight is determined according to the result of the increase or decrease, including:

[0161] If the bandwidth usage is less than the target bandwidth, the historical weight is increased according to the update ratio, and the result of the increase is used as the first weight;

[0162] If the bandwidth usage is less than the target bandwidth, the historical weight is reduced according to the update ratio to obtain a candidate first weight; the first weight is determined according to the size of the candidate first weight and the preset first weight threshold.

[0163] According to one or more embodiments of the present disclosure, determining the second weight of the first subdomain and the third weight corresponding to each second subdomain based on the first weight includes:

[0164] Determining a secondary weight of the first subdomain name according to the first weight of the dynamic service domain;

[0165] The second weight is determined based on a preset constraint relationship between the secondary weight of the first subdomain name and the second weight.

[0166] According to one or more embodiments of the present disclosure, determining the second weight of the first subdomain and the third weight corresponding to each second subdomain based on the first weight includes:

[0167] Based on the second weight and the preset ratio relationship corresponding to each second subdomain name, a third weight corresponding to each second subdomain name is determined.

[0168] According to one or more embodiments of the present disclosure, scheduling an access request from a target area based on a second weight and a third weight includes:

[0169] The pre-created weight list is updated using the first weight and the third weight; the weight list includes static weights corresponding to each service node corresponding to the first subdomain and the second subdomain;

[0170] The updated weight list is sent to the scheduler, and the scheduler schedules the access request according to the updated weight list.

[0171] According to one or more embodiments of the present disclosure, the dynamic service domain is obtained based on the following steps:

[0172] Obtain the CDN service type and CDN service IP address registered at the edge node in the target area. The edge node is the edge node corresponding to the CDN service provider of the 95 billing method.

[0173] Generate a domain name of a dynamic service domain according to the edge node name, CDN service type and CDN service IP address; register the domain name of the dynamic service domain and the CDN service IP address to the associated node.

[0174] In a second aspect, according to one or more embodiments of the present disclosure, a traffic scheduling device for a converged CDN is provided, including:

[0175] An acquisition unit is used to acquire first bandwidth data of a dynamic service domain in a target area; wherein the dynamic service domain belongs to a first subdomain; wherein there is a mapping relationship between the dynamic service domain and a first CDN service node of a 95 billing method; the target area also includes at least one second subdomain, and a second CDN service node corresponding to the second subdomain is charged based on traffic;

[0176] A first weight determination unit, configured to determine a first weight of the dynamic service domain according to the first bandwidth data and a historical weight of the dynamic service domain;

[0177] A second weight determination unit, configured to determine a second weight of the first subdomain and a third weight corresponding to each second subdomain based on the first weight;

[0178] The scheduling unit is used to schedule the access request from the target area based on the first weight, the second weight and the third weight.

[0179] According to one or more embodiments of the present disclosure, the first weight determination unit is further configured to:

[0180] According to the bandwidth usage and the target bandwidth, the historical weight is increased or decreased, and the first weight is determined according to the result of the increase or decrease; wherein the first bandwidth data includes the bandwidth usage and the target bandwidth.

[0181] According to one or more embodiments of the present disclosure, the first weight determination unit is further configured to:

[0182] Determine the update ratio according to the target bandwidth, bandwidth usage and bandwidth of the dynamic service domain;

[0183] The history weight is increased or decreased based on the update ratio.

[0184] According to one or more embodiments of the present disclosure, the first weight determination unit is further configured to:

[0185] If the bandwidth usage is less than the target bandwidth, the historical weight is increased according to the update ratio, and the result of the increase is used as the first weight;

[0186] If the bandwidth usage is less than the target bandwidth, the historical weight is reduced according to the update ratio to obtain a candidate first weight; the first weight is determined according to the size of the candidate first weight and the preset first weight threshold.

[0187] According to one or more embodiments of the present disclosure, the second weight determination unit is further configured to:

[0188] Determining a secondary weight of the first subdomain name according to the first weight of the dynamic service domain;

[0189] The second weight is determined based on a preset constraint relationship between the secondary weight of the first subdomain name and the second weight.

[0190] According to one or more embodiments of the present disclosure, the second weight determination unit is further configured to:

[0191] Based on the second weight and the preset ratio relationship corresponding to each second subdomain name, a third weight corresponding to each second subdomain name is determined.

[0192] According to one or more embodiments of the present disclosure, the scheduling unit is further configured to:

[0193] The pre-created weight list is updated using the first weight and the third weight; the weight list includes static weights corresponding to each service node corresponding to the first subdomain and the second subdomain;

[0194] The updated weight list is sent to the scheduler, and the scheduler schedules the access request according to the updated weight list.

[0195] According to one or more embodiments of the present disclosure, the device further includes a dynamic service domain creation unit, and the dynamic service domain creation unit is used to:

[0196] Obtain the CDN service type and CDN service IP address registered at the edge node in the target area. The edge node is the edge node corresponding to the CDN service provider of the 95 billing method.

[0197] Generate a domain name of a dynamic service domain according to the edge node name, CDN service type and CDN service IP address; register the domain name of the dynamic service domain and the CDN service IP address to the associated node.

[0198] In a third aspect, according to one or more embodiments of the present disclosure, there is provided an electronic device, comprising: at least one processor and a memory;

[0199] Memory stores computer-executable instructions;

[0200] At least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the method of the first aspect and various possible designs of the first aspect as described above.

[0201] In a fourth aspect, according to one or more embodiments of the present disclosure, a computer-readable storage medium is provided, in which computer execution instructions are stored. When a processor executes the computer execution instructions, the method of the first aspect and various possible designs of the first aspect are implemented.

[0202] In a fifth aspect, according to one or more embodiments of the present disclosure, a computer program product is provided, including a computer program, which, when executed by a processor, implements the method of the first aspect and various possible designs of the first aspect.

[0203] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present disclosure (but not limited to) by each other to form a technical solution.

[0204] In addition, although each operation is described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.

[0205] Although the subject matter has been described in language specific to structural features and / or methodological logical actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims.< / zone>

Claims

1. A traffic scheduling method for integrated CDN, characterized in that: include: Acquire first bandwidth data of a dynamic service domain in a target area; wherein the dynamic service domain belongs to a first subdomain; wherein there is a mapping relationship between the dynamic service domain and a first CDN service node of a 95 billing method; the target area also includes at least one second subdomain, and a second CDN service node corresponding to the second subdomain is charged based on traffic; Determine a first weight of the dynamic service domain according to the first bandwidth data and a historical weight of the dynamic service domain; determine a second weight of the first subdomain name and a third weight corresponding to each of the second subdomain names based on the first weight; Based on the first weight, the second weight, and the third weight, access requests from the target area are scheduled.

2. The method according to claim 1, characterized in that The determining, according to the first bandwidth data and the historical weight, a first weight of the dynamic service domain includes: The historical weight is increased or decreased according to the bandwidth usage and the target bandwidth, and the first weight is determined according to the result of the increase or decrease; wherein the first bandwidth data includes the bandwidth usage and the target bandwidth.

3. The method according to claim 2, characterized in that The increasing or decreasing the historical weight according to the bandwidth usage and the target bandwidth includes: Determining an update ratio according to the target bandwidth, the bandwidth usage, and the bandwidth of the dynamic service domain; The historical weight is increased or decreased based on the update ratio.

4. The method according to claim 3, characterized in that The increasing or decreasing the historical weight based on the update ratio, and determining the first weight according to the result of the increase or decrease comprises: If the bandwidth usage is less than the target bandwidth, the historical weight is increased according to the update ratio, and the result of the increase is used as the first weight; If the bandwidth usage is less than the target bandwidth, the historical weight is reduced according to the update ratio to obtain a candidate first weight; and the first weight is determined according to the size of the candidate first weight and a preset first weight threshold.

5. The method according to any one of claims 1 to 4, characterized in that: Determining, based on the first weight, a second weight of the first subdomain and a third weight corresponding to each of the second subdomains, includes: Determining a secondary weight of the first subdomain name according to the first weight of the dynamic service domain; The second weight is determined based on a preset constraint relationship between the secondary weight of the first subdomain name and the second weight.

6. The method according to any one of claims 1 to 4, characterized in that: The determining, based on the first weight, the second weight of the first subdomain and the third weight corresponding to each of the second subdomains includes: Based on the second weight and the preset ratio relationship corresponding to each of the second subdomain names, a third weight corresponding to each of the second subdomain names is determined.

7. The method according to any one of claims 1 to 4, characterized in that: The scheduling of the access request from the target area based on the second weight and the third weight includes: Using the first weight and the third weight, a pre-created weight list is updated; the weight list includes static weights corresponding to each service node corresponding to the first subdomain and the second subdomain; The updated weight list is sent to a scheduler, and the scheduler schedules the access request according to the updated weight list.

8. The method according to claim 1, characterized in that The dynamic service domain is obtained based on the following steps: Obtaining the CDN service type and CDN service IP address registered at the edge node in the target area, where the edge node is the edge node corresponding to the CDN service provider of the 95 billing method; Generate a domain name of a dynamic service domain according to the edge node name, the CDN service type and the CDN service IP address; The domain name of the dynamic service domain and the CDN service IP address are registered to an associated node.

9. A traffic scheduling device for integrated CDN, comprising: An acquisition unit is used to acquire first bandwidth data of a dynamic service domain in a target area; wherein the dynamic service domain belongs to a first subdomain; wherein there is a mapping relationship between the dynamic service domain and a first CDN service node of a 95 billing method; the target area also includes at least one second subdomain, and a second CDN service node corresponding to the second subdomain is based on traffic billing; A first weight determining unit, configured to determine a first weight of the dynamic service domain according to the first bandwidth data and a historical weight of the dynamic service domain; a second weight determining unit, configured to determine, based on the first weight, a second weight of the first subdomain and a third weight corresponding to each of the second subdomains; A scheduling unit is used to schedule the access request from the target area based on the first weight, the second weight and the third weight.

10. An electronic device, characterized in that: include: Processor and memory; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when a processor executes the computer-executable instructions, the method according to any one of claims 1 to 8 is implemented.

12. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images