Service scheduling method

Abstract

The invention discloses a service scheduling method, and belongs to the technical field of Internet, in the method, a service scheduling request of a source device in a CDN is received, the service scheduling request comprises service demand information and data flow direction information of a target service, and the target service is scheduled according to the service demand information. The method comprises the following steps: selecting alternative equipment capable of meeting service requirements from service equipment accessed to an intranet in a CDN, selecting target equipment from the alternative equipment according to data flow direction information, and if the target equipment is selected, sending a first transmission identifier for indicating data transmission through the intranet and equipment information of the target equipment to source equipment. Wherein when the data transmission direction is one-way, the target equipment and the source equipment can transmit data through the intranet in the corresponding one-way data transmission direction, and when the data transmission direction is two-way, the target equipment and the source equipment can transmit data through the intranet in at least one one-way data transmission direction. In this way, as much data as possible can be transmitted through the intranet, and the data transmission performance of the CDN is improved.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a business scheduling method. Background Technology

[0002] Currently, data transmission between service devices in a Content Delivery Network (CDN) typically relies on the external network (or public network). Because the external network is susceptible to network fluctuations, data loss and significant transmission latency are common. Furthermore, the transmission cost over the external network is relatively high. Improving CDN data transmission performance and reducing transmission costs are pressing technical challenges that need to be addressed. Summary of the Invention

[0003] This application provides a service scheduling method to improve the data transmission performance of CDN and reduce transmission costs.

[0004] In a first aspect, embodiments of this application provide a service scheduling method applied in a scheduling center, comprising: The system receives a service scheduling request from a source device. The service scheduling request contains service requirement information and data flow information of the target service. The data flow information is used to indicate the data transmission direction of the target service. The source device is a service device that accesses the intranet in a content delivery network (CDN). Based on the business requirement information, at least one alternative device that can meet the business requirements is selected from the various service devices accessing the intranet in the CDN; Based on the data flow information, a destination device is selected from the at least one candidate device. When the data transmission direction is unidirectional, the destination device and the source device can transmit data through the intranet in the corresponding unidirectional data transmission direction. When the data transmission direction is bidirectional, the destination device and the source device can transmit data through the intranet in at least one unidirectional data transmission direction. If a destination device is selected, a service scheduling result is sent to the source device. The service scheduling result includes a first transmission identifier and device information of the destination device. The first transmission identifier is used to indicate that the source device and the destination device transmit data through the intranet.

[0005] Secondly, embodiments of this application provide a service scheduling method applied to a source device, comprising: Receive a service request, which contains the service requirement information of the target service; When it is determined that the source device cannot meet the service requirements based on the service requirement information, a service scheduling request is sent to the scheduling center. The service scheduling request includes the service requirement information and data flow information. The data flow information is used to indicate the data transmission direction of the target service. Receive the service scheduling result from the scheduling center, wherein the service scheduling result is obtained by the scheduling center according to the service scheduling method in the first aspect; If the service scheduling result includes a first transmission identifier and device information of the destination device, then data is transmitted with the target device through the intranet according to the device information.

[0006] Thirdly, embodiments of this application provide a service scheduling device applied in a scheduling center, comprising: The receiving module is used to receive a service scheduling request from the source device. The service scheduling request contains service requirement information and data flow information of the target service. The data flow information is used to indicate the data transmission direction of the target service. The source device is a service device in the Content Delivery Network (CDN) that accesses the intranet. The first selection module is used to select at least one alternative device that can meet the business requirements from the various service devices accessing the intranet in the CDN, based on the business requirement information. The second selection module is used to select a destination device from the at least one alternative device according to the data flow direction information, wherein when the data transmission direction is unidirectional, the destination device and the source device can transmit data through the intranet in the corresponding unidirectional data transmission direction; when the data transmission direction is bidirectional, the destination device and the source device can transmit data through the intranet in at least one unidirectional data transmission direction. The sending module is configured to send a service scheduling result to the source device if a destination device is selected. The service scheduling result includes a first transmission identifier and device information of the destination device. The first transmission identifier is used to indicate that the source device and the destination device transmit data through the intranet.

[0007] Fourthly, embodiments of this application provide a service scheduling device applied to a source device, comprising: The first receiving module is used to receive a service request, which contains the service requirement information of the target service. The sending module is used to send a service scheduling request to the scheduling center when it is determined that the source device cannot meet the service requirements based on the service requirement information. The service scheduling request includes the service requirement information and data flow direction information, and the data flow direction information is used to indicate the data transmission direction of the target service. The second receiving module is used to receive the service scheduling result of the scheduling center, wherein the service scheduling result is obtained by the scheduling center according to the service scheduling method in the first aspect. The transmission module is used to transmit data with the target device via the intranet according to the device information if the service scheduling result includes a first transmission identifier and device information of the destination device.

[0008] Fifthly, embodiments of this application provide an electronic device, including: at least one processor, and a memory communicatively connected to the at least one processor, wherein: The memory stores a computer program that can be executed by at least one processor, which enables the at least one processor to perform any of the above-described service scheduling methods.

[0009] Sixthly, embodiments of this application provide a storage medium in which, when a computer program in the storage medium is executed by a processor of an electronic device, the electronic device is able to execute any of the above-described service scheduling methods.

[0010] Seventhly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, implements any of the above-described service scheduling methods.

[0011] In this embodiment, a service scheduling request sent by a source device in the CDN is received. The service scheduling request includes service requirement information and data flow direction information of the target service. The data flow direction information is used to indicate the data transmission direction of the target service. First, based on the service requirement information, at least one alternative device that can meet the service requirements is selected from the service devices accessing the intranet in the CDN. Then, based on the data flow direction information, a destination device is selected from these at least one alternative device. If a destination device is selected, a service scheduling result is sent to the source device. The service scheduling result includes a first transmission identifier and device information of the destination device. The first transmission identifier is used to indicate that the source device and the destination device transmit data through the intranet. Wherein, when the data transmission direction is unidirectional, the destination device and the source device can transmit data through the intranet in the corresponding unidirectional data transmission direction. When the data transmission direction is bidirectional, the destination device and the source device can transmit data through the intranet in at least one unidirectional data transmission direction. In other words, when the data transmission direction of the target service is unidirectional, even if the source and destination devices cannot transmit data via the intranet in one unidirectional data transmission direction (e.g., from the source device to the alternative device), it does not affect their ability to transmit data via the intranet in the other unidirectional data transmission direction (i.e., from the alternative device to the source device). Conversely, when the data transmission direction of the target service is bidirectional, it is sufficient for the destination and source devices to transmit data via the intranet in one unidirectional direction; it is not required that both devices transmit data via the intranet in both directions. This allows as much data as possible to be transmitted via the intranet, which is less affected by network fluctuations, less prone to data loss, has lower transmission latency, and higher transmission security, thus improving CDN data transmission performance. Furthermore, the transmission cost of the intranet is also relatively low. Attached Figure Description

[0012] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A schematic diagram of a CDN architecture provided for an embodiment of this application; Figure 2 A schematic diagram illustrating a process for calculating the proportion of requests that any two service devices can process via the intranet in each data transmission direction, as provided in an embodiment of this application; Figure 3 An interactive flowchart of a service scheduling method provided in an embodiment of this application; Figure 4 A flowchart illustrating a method for selecting a destination device capable of transmitting data via an intranet in a data transmission direction from at least one alternative device, as provided in this application embodiment; Figure 5This is a schematic diagram of the structure of a service scheduling device provided in an embodiment of this application; Figure 6 A schematic diagram of the structure of another service scheduling device provided in the embodiments of this application; Figure 7 This is a schematic diagram of the hardware structure of an electronic device for implementing a service scheduling method, provided as an embodiment of this application. Detailed Implementation

[0013] To better illustrate the service scheduling method in this application embodiment, CDN will be introduced first.

[0014] See Figure 1 , Figure 1 This application provides a schematic diagram of a CDN architecture, including data centers A through F. Each data center contains service devices (also called CDN servers) and a core switch. The core switch is connected to the external network (or public network), and the service devices can transmit data with other service devices through the external network. Because the external network is susceptible to network fluctuations, data loss is likely, and transmission latency is relatively high. Furthermore, the transmission cost of the external network is also relatively high.

[0015] To improve CDN data transmission performance and reduce transmission costs, at least some service devices can transmit data with other service devices through the internal network. For this purpose, an internal network backbone can be built, such as... Figure 1 As shown, there are backbone switches A to F on the internal network backbone line. After a data center deploys a back-to-source switch to access the internal network, the service devices in the data center can access the back-to-source switch through the core switch, and then transmit data with other service devices through the internal network.

[0016] Figure 1 In this scenario, the service devices in data centers A through E are connected to both the external network and the internal network, while data center F is connected to the external network but not the internal network. That is, the service devices in data centers A through E can choose to transmit data via either the internal network or the external network, while the service devices in data center F can only transmit data via the external network.

[0017] To better control the data transmission of each service device (i.e., service devices in data centers A through E) simultaneously connected to both the external and internal networks, policy-based routing can be configured on the core switch of each device's own data center. This routing control directs the data sent by the service device to be transmitted via the external network for the portion sent and via the internal network for the portion sent. For example, a service device sets the Diff-Serve Coding Point (DSCP) in a data packet to a specified value, such as 31, and then sends the data packet to its own data center's core switch. When the core switch determines that the DSCP in the data packet is the specified value, it forwards the data packet to the internal network via the origin switch, and then transmits it through the internal network. When it determines that the DSCP in the data packet is the default value, such as 0, or that the data packet does not contain a DSCP field, it forwards the data packet to the external network, and then transmits it through the external network. This not only achieves precise control over data packets but also isolates the data center's internal and external networks, reducing intrusion into the existing network of the data center, simplifying data center construction and subsequent operation and maintenance, and preventing the impact of subsequent data center changes on the internal network.

[0018] Furthermore, when any service device sends a data packet to another service device via the origin switch through the internal network, the origin switch can sense the routing status with the other service device based on the acquired BGP protocol before sending the data packet. If the routing is normal, the data packet can be forwarded to the other service device according to the route. If the routing is abnormal, such as an internal network anomaly causing the route to be unavailable, the DSCP of the data packet can be reset to another value, such as 0, and the data packet can be routed back (i.e., forwarded) to the core switch belonging to the same data center as the service device. The core switch then sends the data packet through the public network. In this way, through the backflow mechanism, data packets transmitted through the internal network can be forwarded to the external network for transmission when there is an internal network anomaly, thereby ensuring the transmission reliability of CDN. Moreover, even if the scheduling center (including one or more servers) still schedules requests to the internal network after detecting an anomaly and delays, the backflow mechanism can also achieve the effect of switching internal network transmission to public network transmission, thereby greatly improving the transmission reliability of CDN.

[0019] In practical applications, CDN can provide a variety of business services. The following are examples of the services provided by CDN.

[0020] I. Storage services.

[0021] Any service device (or source device) in a CDN, such as service device A, can receive storage requests from clients. The storage request contains path information of the data to be stored. If the storage space of service device A is insufficient, the data to be stored can be stored in other service devices (or destination devices).

[0022] In this scenario, service device A can send a storage scheduling request to the scheduling center. This request may include storage requirement information such as storage space size and storage format. The scheduling center can then select a suitable service device for data storage, such as service device B, from other service devices and send service device B's device information to service device A. Afterward, service device A can store at least a portion of the data to be stored in service device B.

[0023] II. Resource Access Services.

[0024] Any service device (or source device) in a CDN, such as service device C, can receive resource access requests from clients. The resource access request contains the resource identifier of the resource to be accessed, such as a Uniform Resource Locator (URL). If service device C does not store the resource to be accessed, it needs to obtain the resource from other service devices (or destination devices).

[0025] In this scenario, service device C can send a resource scheduling request to the scheduling center. This request may include resource requirement information such as a URL. The scheduling center can then select a suitable service device, such as service device D, from other service devices to provide the accessed resource and send the device information of service device D to service device C. Service device C can then obtain the accessed resource from service device D.

[0026] III. Transcoding services.

[0027] Any service device (or source device) in the CDN, such as service device E, can receive transcoding requests from clients. The transcoding request can include the data source information of the data to be transcoded and the transcoding requirements, such as which encoding format to convert to, the resolution after transcoding, etc. If service device E does not have the corresponding transcoding capability, it can send the data to be transcoded to other service devices (or destination devices) for transcoding, and then obtain the transcoded data from other service devices.

[0028] In this scenario, service device E can send a transcoding scheduling request to the dispatch center, which includes transcoding requirement information. The dispatch center can then select a suitable service device, such as service device F, from among other service devices to provide transcoding services, and send the device information of service device F to service device E. Service device E can then send the data to be transcoded to service device F, which will perform the transcoding and then send the transcoded data back to service device E.

[0029] Generally, there are two directions for data transmission between any two service devices. Taking service device A and service device B as an example, the data transmission directions between service device A and service device B can include: service device A transmitting data to service device B, and service device B transmitting data to service device A. In practical applications, there may be situations where the amount of data that service device A and service device B can transmit through the intranet differs depending on the data transmission direction. For example, service device A may still be able to transmit data to service device B through the intranet, but service device B may no longer be able to transmit data to service device A through the intranet.

[0030] In practical applications, the management platform can maintain the IP addresses and port numbers of the switches at both ends of any transmission line in the intranet. The management platform may include one or more servers, and it can be set up independently of the CDN or integrated into the CDN.

[0031] by Figure 1 For example, the following is some information about the lines in the intranet maintained by the management platform: Line 1: Source switch A - Backbone switch A; Starting address is the IP address of source switch A, and port numbers are ports 1 and 2 of source switch A; Ending address is the IP address of backbone switch A, and port numbers are ports 1 and 2 of backbone switch A; Line capacity is 200G. Line 2: Source switch B - Backbone switch A; starting address is the IP address of source switch B, port number is port 1 of source switch B; ending address is the IP address of backbone switch A, port number is port 3 of backbone switch A; line capacity is 100G. Line 3: Backbone Switch A - Backbone Switch B; Starting address is the IP address of Backbone Switch A, and port numbers are ports 4, 5, and 6 of Backbone Switch A; Ending address is the IP address of Backbone Switch B, and port numbers are ports 1, 2, and 3 of Backbone Switch B; Line capacity is 300G.

[0032] To more accurately control the data transmission of service devices in the CDN via the internal network, the management platform can periodically calculate the proportion of requests that any two service devices can process via the internal network in each unidirectional data transmission direction. Taking service device A and service device B as an example, the two unidirectional data transmission directions between service device A and service device B are: service device A to service device B, and service device B to service device A.

[0033] The following describes how the management platform calculates the proportion of requests that any two service devices can process via the intranet in each unidirectional data transmission direction.

[0034] Generally, the functions of a management platform may include data acquisition and data analysis capabilities; assuming each function constitutes a layer. See also Figure 2 , Figure 2 This is a schematic diagram illustrating a process for calculating the proportion of requests that any two service devices can process via the intranet in each data transmission direction, as provided in an embodiment of this application.

[0035] The data acquisition layer may include a BGP routing acquisition system, a network health detection system, a line information acquisition system, and a switch traffic monitoring system.

[0036] The BGP route acquisition system is used to collect BGP route information of the internal network, such as network layer reachability information and Autonomous System (AS)-path (PATH).

[0037] A network health detection system is used to collect health characteristic data of the internal network. For example, it instructs two service devices to initiate HTTP probe requests to each other, thereby obtaining HTTP probe data such as response status codes / response times volatility and median in each data transmission direction between the two service devices. Volatility is calculated using the interquartile range (IQR), which is a statistical indicator for measuring the degree of dispersion of data.

[0038] The line information acquisition system is used to collect line information such as the line bandwidth capacity between adjacent switches, switch addresses, switch port numbers, and line status. Adjacent switches can be source switches and backbone switches, or backbone switches and backbone switches. Generally, adjacent switches have the same bandwidth capacity in different transmission directions. Line status includes planned status, activated status, deactivated status, and retired status.

[0039] A switch traffic monitoring system is used to collect switch traffic information. Generally, it collects traffic outflow information from each core switch, each source switch, and each backbone switch on each enabled port. The traffic outflow information for each switch on a single port, such as the size of the forwarded data packets and which switch each packet is destined for, indicates how much bandwidth has been used on the corresponding transmission line.

[0040] Taking backbone switch A as an example, traffic outflow information on ports 1, 2, 3, 4, 5, and 6 of backbone switch A can be collected. Specifically, the traffic outflow information on ports 1 and 2 indicates the bandwidth used by line 1 in the unidirectional data transmission direction from backbone switch A to source switch A. The traffic outflow information on port 3 indicates the bandwidth used by line 2 in the unidirectional data transmission direction from backbone switch A to source switch B. The traffic outflow information on ports 4, 5, and 6 indicates the bandwidth used by line 3 in the unidirectional data transmission direction from backbone switch A to backbone switch B.

[0041] Similarly, traffic outflow information on ports 1 and 2 of source switch A, traffic outflow information on port 1 of source switch B, and traffic outflow information on ports 1, 2, and 3 of backbone switch B can be collected. The traffic outflow information on ports 1 and 2 of source switch A indicates the bandwidth used for line 1 in the unidirectional data transmission direction from source switch A to backbone switch A. The traffic outflow information on port 1 of source switch B indicates the bandwidth used for line 2 in the unidirectional data transmission direction from source switch B to backbone switch A. The traffic outflow information on ports 1, 2, and 3 of backbone switch B indicates the bandwidth used for line 3 in the unidirectional data transmission direction from backbone switch B to backbone switch A.

[0042] The data analysis layer may include a path resolution module, a network health value analysis module, a line bandwidth usage ratio analysis module, a return flow ratio analysis module, a request ratio calculation module for the internal network, and a result aggregation module.

[0043] The path resolution module is used to calculate whether a route between any two service devices is reachable based on network layer reachability information. If the route is not reachable, it is assumed that the two service devices cannot transmit data through the internal network; if the route is reachable, it is assumed that the two service devices can transmit data through the internal network. If any two service devices can transmit data through the internal network, the internal network transmission path between the two service devices can be calculated based on the AS-PATH. The internal network transmission path provides the hop count (i.e., which switches are traversed) and path length between the two service devices.

[0044] The network health value analysis module is used to calculate the network health value of the network transmission path between two service devices in the corresponding data transmission direction based on the HTTP probe data of any two service devices in each data transmission direction.

[0045] Taking HTTP probe data from two service devices in each data transmission direction, including response status codes, response time volatility, and median, as an example. Generally, response status codes can be used to indicate whether the internal network transmission path is normal. When the response status code indicates that the internal network transmission path is abnormal, the network health value of the network transmission path in the corresponding data transmission direction can be determined to be 0. When the response status code indicates that the internal network transmission path is normal, the network health value of the network transmission path in the corresponding data transmission direction can be calculated based on the response time volatility and median. For example, the response time volatility and median can be weighted and summed, and the weighted sum can be determined as the network health value of the network transmission path in the corresponding data transmission direction.

[0046] The line bandwidth utilization ratio analysis module is used to calculate the bandwidth utilization ratio of adjacent switches in each transmission direction based on the bandwidth capacity between any two adjacent switches and the traffic information of the adjacent switches.

[0047] The backhaul ratio analysis module calculates the backhaul ratio for service devices in each computer room based on traffic information from the core switch and the origin switch. For example, the backhaul ratio is calculated as: Backhaul ratio = (Amount of data returned from the origin switch to the core switch) / (Amount of data forwarded from the core switch to the origin switch). Here, the amount of data forwarded from the core switch to the origin switch is the total amount of data the service device is configured for internal network transmission, and the amount of data returned from the origin switch to the core switch is the amount of data the service device is transmitting from the internal network to the external network.

[0048] The intranet request ratio calculation module is used to determine the proportion of requests processed by any two service devices through the intranet in each unidirectional data transmission direction.

[0049] Generally, for any two service devices, if the return flow ratio of the data center where either service device is located exceeds a preset value such as 90%, it means that this service device is not suitable for transmitting data through the intranet. Therefore, the proportion of requests processed by the two service devices through the intranet in each unidirectional data transmission direction can be set to a lower limit such as 0%.

[0050] Furthermore, if the line status between any adjacent switches on the intranet transmission path between the two service devices is not open, it indicates that the intranet transmission path between the two service devices is not connected. Therefore, the proportion of requests processed by the two service devices through the intranet in each unidirectional data transmission direction can be set to the lower limit, such as 0%. When the line status between any adjacent switches on the intranet transmission path between the two service devices is open, the proportion of requests processed by the two service devices through the intranet in each unidirectional data transmission direction can be set to the upper limit, such as 100%.

[0051] Subsequently, for each unidirectional data transmission direction between the two service devices, if the bandwidth usage ratio of any adjacent switch on the intranet transmission path between the two service devices exceeds a first upper limit threshold in this unidirectional transmission direction, the proportion of requests that the two service devices can process through the intranet in this unidirectional data transmission direction can be reduced by a first increment. Conversely, if the bandwidth usage ratio of any adjacent switch on the intranet transmission path between the two service devices exceeds a first lower limit threshold in this unidirectional transmission direction, the proportion of requests that the two service devices can process through the intranet in this unidirectional data transmission direction can be increased by a first increment. The first increment could be, for example, 5%, 3%, etc.

[0052] Furthermore, for each unidirectional data transmission direction between two service devices, if the network health value of the intranet transmission path between the two service devices exceeds the second upper threshold in this unidirectional data transmission direction, the proportion of requests that the two service devices can process through the intranet in this unidirectional data transmission direction can be increased by a second increment. Conversely, if the network health value of the intranet transmission path between the two service devices is lower than the second lower threshold in this unidirectional data transmission direction, the proportion of requests that the two service devices can process through the intranet in this unidirectional data transmission direction can be decreased by a second increment. The second increment could be, for example, 5%, 3%, etc.

[0053] In practical applications, bandwidth usage ratio and network health value can be considered separately or together. When considered together, simply increase or decrease the request ratio according to the respective rules for bandwidth usage ratio and network health value.

[0054] In either case, the percentage of requests that the two service devices can process via the intranet in each data transmission direction can be reduced to a minimum of 0% and increased to a maximum of 100%.

[0055] The result aggregation module is used to correlate the proportion of requests that any two service devices can process through the intranet in each unidirectional data transmission direction with the path length of the intranet, to obtain the intranet transmission information of any two service devices in this unidirectional data transmission direction (including the proportion of requests that can be processed through the intranet and the path length of the intranet).

[0056] In this way, based on the acquired BGP routing information, network health information (i.e., HTTP probe data), switch traffic information, and line information, it is possible to analyze the proportion of requests that any two service devices can process through the internal network in this unidirectional data transmission direction from multiple dimensions, including BGP routing, transmission path, switch usage, network health values, and return rate. This can greatly improve the accuracy of subsequent service scheduling and achieve better scheduling results. Moreover, by specifically determining the request ratio based on the bandwidth usage of adjacent switches in each unidirectional data transmission direction, the bandwidth capacity of the internal network can be utilized more effectively, avoiding resource waste. In addition, by collecting traffic information from the underlying switches, the transmission path and transmission status can be detected in a timely manner. When line interruptions cause changes in the internal network transmission path, timely responses can be made to reduce the impact of line interruptions on services.

[0057] Next, the service scheduling method in the embodiments of this application will be introduced.

[0058] See Figure 3 , Figure 3 The interactive flowchart of a service scheduling method provided in this application embodiment includes the following steps.

[0059] In step 301, the source device receives a service request, which contains the service requirement information of the target service.

[0060] The source device is a service device in the CDN that accesses the internal network. Furthermore, when the target service is a storage service, the service request is a storage request, and the service requirement information is storage requirement information; when the target service is a resource access service, the service request is a resource access request, and the service requirement information is resource requirement information; when the target service is a transcoding service, the service scheduling request is a transcoding request, and the service requirement information is transcoding requirement information.

[0061] In step 302, when the source device determines that it cannot meet the service requirements based on the service requirement information, it sends a service scheduling request to the scheduling center. The service scheduling request contains the service requirement information and data flow information of the target service. The data flow information is used to indicate the data transmission direction of the target service.

[0062] It should be noted that after determining that it cannot meet the business requirements based on the business demand information, the source device will generally first communicate with other service devices in the same data center through the data center intranet to determine whether the other service devices in the same data center can meet the business requirements. After determining that the other service devices in the same data center also cannot meet the business requirements, it will then send a business scheduling request to the scheduling center.

[0063] Specifically, when the target service is a storage service, the service scheduling request is a storage scheduling request, and the data transmission direction is from the source device to the destination device. When the target service is a resource access service, the service scheduling request is a resource scheduling request, and the data transmission direction is from the destination device to the source device. When the target service is a transcoding service, the service scheduling request is a transcoding scheduling request, and the data transmission direction is first from the source device to the destination device, and then from the destination device back to the source device.

[0064] In step 303, the dispatch center selects at least one alternative device that can meet the business requirements from the various service devices connected to the internal network in the CDN, based on the business requirement information.

[0065] In practical applications, only some service devices in a CDN may be connected to the intranet, and there may be multiple service devices that can meet business needs. Selecting at least one alternative device that can meet business needs from the service devices in the CDN that are connected to the intranet means selecting an alternative device that can meet business needs and has intranet transmission conditions with the source device.

[0066] It should be noted that the dispatch center selects alternative devices from service equipment in different computer rooms than the source device. Therefore, each alternative device is located in a different computer room than the source device.

[0067] In step 304, the dispatch center selects the destination device from at least one alternative device based on the data flow information.

[0068] When the data transmission direction of the target service is unidirectional, the destination device and the source device can transmit data through the intranet in the corresponding unidirectional data transmission direction. When the data transmission direction of the target service is bidirectional (including two unidirectional data transmission directions in opposite directions), the destination device and the source device can transmit data through the intranet in at least one unidirectional data transmission direction.

[0069] In practice, the dispatch center can, according to Figure 4 The illustrated process involves selecting a destination device from at least one alternative device that can transmit data via the intranet in the corresponding data transmission direction. This process includes the following steps.

[0070] In step 3041, based on the data flow information, the proportion of requests that each candidate device and the source device can process through the intranet is obtained.

[0071] In practical applications, the management platform can periodically determine the proportion of requests that can be processed via the intranet between any two service devices. Here, the latest determined proportion of requests that each candidate device and the source device can process via the intranet can be obtained from the management platform.

[0072] Furthermore, when the data transmission direction is unidirectional, the proportion of requests that each candidate device and the source device can process through the intranet in the corresponding unidirectional data transmission direction can be obtained; when the data transmission direction is bidirectional, the proportion of requests that each candidate device and the source device can process through the intranet in both unidirectional data transmission directions can be obtained.

[0073] For example, if the unidirectional data transmission direction is from the source device to the destination device, then the proportion of requests that can be processed through the intranet from the source device to each alternative device can be obtained; if the unidirectional data transmission direction is from the destination device to the source device, then the proportion of requests that can be processed through the intranet from each alternative device to the source device can be obtained.

[0074] For example, if the bidirectional data transmission direction is from the source device to the destination device and from the destination device to the source device, then the proportion of requests that can be processed through the intranet from the source device to each alternative device, and the proportion of requests that can be processed through the intranet from each alternative device to the source device, can be obtained.

[0075] In step 3042, a random ratio is generated based on the business requirement information, wherein the random ratio is used to characterize the probability of processing business scheduling requests through the intranet.

[0076] In practice, the business requirement information can be hashed to obtain a hash value, which is then mapped to a random ratio. For example, the remainder of the hash value modulo the target value can be multiplied by the upper limit of the ratio to obtain the random ratio. The target value is determined based on the upper limit of the ratio; for example, if the upper limit is 100%, the target value could be 100. That is, random ratio = hash(business requirement information) modulo 100 × 100%.

[0077] In step 3043, the destination device is selected based on the random ratio and the ratio of requests that each candidate device and the source device can process through the intranet.

[0078] The first step is to select the target device from the alternative devices.

[0079] In the first scenario, the data transmission direction of the target service is unidirectional.

[0080] In this scenario, a candidate device can be selected as the target device if the proportion of requests that can be processed via the internal network in the unidirectional data transmission direction required by the target service is not less than a random proportion. This eliminates the need to consider the proportion of requests that the source device can process via the internal network in the unidirectional data transmission direction not required by the target service.

[0081] The following example illustrates the process of selecting a target device.

[0082] Taking storage as an example, the data transmission direction is unidirectional, from the source device to the destination device. Assume that 80% of requests from the source device to a candidate device can be processed via the intranet. Then, if the randomness ratio is 70%, this candidate device can be used as the target device; however, if the randomness ratio is 90%, this candidate device cannot be used as the target device.

[0083] Taking resource access as an example, the data transmission direction is unidirectional, from the destination device to the source device. Assume that a candidate device can handle 90% of requests through the intranet to the source device. Then, if the random percentage is 80%, this candidate device can be used as the target device; however, if the random percentage is 95%, this candidate device cannot be used as the target device.

[0084] In the second scenario, the data transmission direction of the target service is bidirectional.

[0085] In this scenario, the target device can be selected first if the proportion of requests processed by the source device via the intranet in both bidirectional data transmission directions is no less than a random proportion. If no target device can be selected, then another candidate device can be selected if the proportion of requests processed by the source device via the intranet in any unidirectional data transmission direction is no less than a random proportion. In other words, priority is given to selecting a target device capable of transmitting data via the intranet in both bidirectional data transmission directions; if none is found, then a target device capable of transmitting data via the intranet in a single unidirectional data transmission direction is selected.

[0086] The following example illustrates the process of selecting a target device.

[0087] Taking transcoding as an example, the data transmission direction is first from the source device to the destination device, and then from the destination device back to the source device. The data transmission direction is bidirectional: from the source device to the destination device and from the destination device to the source device.

[0088] Suppose that 90% of requests from an alternative device to the source device can be processed through the internal network, while 80% of requests from the source device to this alternative device can be processed through the internal network.

[0089] Therefore, when the randomness ratio is 75%, since both 90% and 80% are greater than 75%, it indicates that the source device and the backup device can transmit data bidirectionally via the intranet, and the backup device can be used as the target device. When the randomness ratio is 85%, since 90% is greater than 85% and 80% is not greater than 85%, it indicates that the source device and the backup device can transmit data unidirectionally via the intranet (from the backup device to the source device), and the backup device can still be used as the target device. However, when the randomness ratio is 95%, since both 90% and 80% are less than 95%, it indicates that the source device and the backup device cannot transmit data at all via the intranet, and the backup device cannot be used as the target device.

[0090] In other words, for a target service involving unidirectional data transmission, the determination is whether the source device and the alternative device meet the requested ratio in the unidirectional transmission direction required by the target service. Even if the source device and the alternative device cannot transmit data via the intranet in a unidirectional transmission direction not required by the target service, it does not affect the alternative device's status as the destination device. For a target service involving bidirectional data transmission, the alternative device that can transmit data bidirectionally with the source device via the intranet is preferentially selected as the destination device. If no alternative device can be selected, then the alternative device that can transmit data unidirectionally with the source device via the intranet is selected as the destination device. Even if the source device and the alternative device cannot transmit data via the intranet in one unidirectional data transmission direction, this also does not affect the alternative device's status as the destination device.

[0091] In this way, regardless of whether the data transmission direction of the target service is unidirectional or bidirectional, as much data as possible can be transmitted through the intranet. The intranet is less affected by network fluctuations, less prone to data loss, has low transmission latency, and relatively high transmission security, thus improving the data transmission performance of CDN. In addition, the transmission cost of the intranet is also relatively low.

[0092] The second step is to select the target device from the target devices that has the shortest intranet transmission path with the source device as the destination device.

[0093] This can improve the intranet transmission speed between the source device and the target device, thereby improving the intranet transmission performance between the source device and the target device.

[0094] In addition, before selecting the target device, alternative devices that are abnormal (faulty or alarm, etc.) can be eliminated from at least one alternative device to improve the effectiveness of the alternative devices.

[0095] In step 305, the dispatch center determines whether the destination device has been selected. If yes, proceed to step 306; otherwise, proceed to step 308.

[0096] In step 306, the dispatch center sends the service scheduling result to the source device. The service scheduling result includes the first transmission identifier and the device information of the destination device. The first transmission identifier is used to indicate that the source device and the destination device transmit data through the intranet.

[0097] In practical applications, if the destination device is selected, it means that the intranet between the source device and the destination device is working, that is, the two can transmit data through the intranet, and then the first transmission identifier and the device information of the destination device, such as the device address, can be sent to the source device.

[0098] In step 307, the source device transmits data with the destination device via the intranet based on the device information.

[0099] The service scheduling result received by the source device contains a first transmission identifier and the device address of the destination device. Since the first transmission identifier indicates that the source device transmits data through the intranet, when sending a data packet, the source device can set the DSCP in the data packet to a specified value and carry the device address of the destination device in the data packet. Then, the source device sends the data packet to the core switch in the same data room. After the core switch determines that the DSCP in the data packet is the specified value, it can send the data packet to the return-source switch in the same data room. The return-source switch then sends the data packet to the destination device through the intranet according to the device address in the data packet.

[0100] If the target device needs to send data packets to the source device, it can set the DSCP in the data packet to a specified value and include the source device's address in the data packet. Then, the data packet is sent to the core switch in the same data center. After confirming that the DSCP is the specified value, the core switch can send the data packet to the return-to-source switch in the same data center. The return-to-source switch then forwards the data packet to the source device through the internal network based on the device address.

[0101] In step 308, the dispatch center selects the destination device that can meet the business requirements from the various service devices in the CDN that are connected to the external network.

[0102] In practical applications, if a destination device is not selected, it indicates that the intranet between the source and destination devices is not working, meaning data transmission between them cannot occur via the intranet. In this case, a destination device that meets the business requirements can be selected from the various service devices in the CDN that access the external network.

[0103] In step 309, the dispatch center sends the service scheduling result to the source device. The service scheduling result includes the second transmission identifier and the device information of the destination device. The second transmission identifier is used to indicate that the source device and the destination device transmit data through the external network.

[0104] In step 310, the source device transmits data with the destination device via the external network based on the device information.

[0105] The service scheduling result received by the source device includes a second transmission identifier and the device address of the destination device. Because the second transmission identifier indicates that the source device is transmitting data via the external network, the source device can carry the device address of the destination device in the data packet when sending the data packet without needing to set the DSCP. Then, the data packet is sent to the core switch in the same data center. After the core switch determines that the DSCP in the data packet is the default value, it can send the data packet to the destination device via the external network.

[0106] If the target device needs to send data packets to the source device, it can include the source device's address in the data packet without configuring DSCP. Then, it sends the data packet to the core switch in the same data center. After confirming that DSCP is set to the default value, the core switch can forward the data packet to the source device via the external network based on the device address.

[0107] In this embodiment, for each service scheduling request from the source device to the target service, based on the proportion of requests that can be processed via the intranet in the data transmission direction corresponding to the target service between the source device and the candidate devices, the destination device with the shortest transmission path that can be transmitted via the intranet to the source device is selected. This enables request-level service decision-making and data transmission control, ensuring that data that may be transmitted via the intranet is transmitted via the intranet with the shortest transmission distance. This reduces transmission latency, reduces the consumption of backbone switches, increases the data transmission volume on the intranet, and also improves the intranet transmission speed between the source and target devices, thereby enhancing intranet transmission performance.

[0108] Based on the same technical concept, this application also provides two service scheduling devices. The principle of the service scheduling device in solving the problem is similar to that of the above-mentioned service scheduling method. Therefore, the implementation of the service scheduling device can refer to the implementation of the service scheduling method, and the repeated parts will not be described again.

[0109] Figure 5 A schematic diagram of a service scheduling device provided in this application embodiment, applied in a scheduling center, includes: The receiving module 501 is used to receive a service scheduling request from the source device. The service scheduling request includes service requirement information and data flow information of the target service. The data flow information is used to indicate the data transmission direction of the target service. The source device is a service device in the content delivery network CDN that accesses the intranet. The first selection module 502 is used to select at least one alternative device that can meet the business requirements from the various service devices accessing the intranet in the CDN, based on the business requirement information. The second selection module 503 is used to select a destination device from the at least one alternative device according to the data flow direction information, wherein when the data transmission direction is unidirectional, the destination device and the source device can transmit data through the intranet in the corresponding unidirectional data transmission direction, and when the data transmission direction is bidirectional, the destination device and the source device can transmit data through the intranet in at least one unidirectional data transmission direction. The sending module 504 is used to send a service scheduling result to the source device if a destination device is selected. The service scheduling result includes a first transmission identifier and device information of the destination device. The first transmission identifier is used to indicate that the source device and the destination device transmit data through the intranet.

[0110] In some embodiments, the second selection module 503 is specifically used for: Based on the data flow information, the request ratio that each candidate device and the source device can process through the intranet is obtained. When the data transmission direction is unidirectional, the request ratio is the request ratio in the corresponding unidirectional data transmission direction. When the data transmission direction is bidirectional, the request ratio is the request ratio in the two unidirectional data transmission directions with opposite transmission directions. Based on the business requirement information, a random ratio is generated, which is used to characterize the probability of processing the business scheduling request through the intranet; The destination device is selected based on the random ratio and the ratio of requests that each candidate device and the source device can process through the intranet.

[0111] In some embodiments, a determining module 505 is further included, configured to determine the ratio of requests that each candidate device and the source device can process via the intranet according to the following steps: Based on the obtained intranet routing information, determine the intranet transmission path between the candidate device and the source device; Based on the transmission performance information of the intranet transmission path in each unidirectional data transmission direction, determine the ratio of requests that the candidate device and the source device can process through the intranet in the unidirectional data transmission direction.

[0112] In some embodiments, the transmission performance information includes the bandwidth usage ratio of any two adjacent switches on the intranet transmission path in the unidirectional data transmission direction. The determining module 505 is specifically used for: If the bandwidth usage ratio of any two adjacent switches in the unidirectional data transmission direction exceeds the first upper limit threshold, the request ratio that the alternative device and the source device can process through the intranet in the unidirectional data transmission direction will be reduced by the first amount. Initially, the request ratio is the upper limit of the ratio. If the bandwidth utilization ratio of any two adjacent switches in the unidirectional data transmission direction is lower than the first lower limit threshold, then the proportion of requests that the candidate device and the source device can process through the intranet in the unidirectional data transmission direction is increased by the first magnitude.

[0113] In some embodiments, the transmission performance information further includes the network health value of the intranet transmission path in the unidirectional data transmission direction. The determining module 505 is specifically used for: If the network health value exceeds the second upper limit threshold, the proportion of requests that the alternative device and the source device can process through the intranet in the unidirectional data transmission direction will be increased by the second amount. Initially, the request proportion is the upper limit of the proportion. If the network health value is lower than the second lower limit threshold, the proportion of requests that the alternative device and the source device can process through the intranet in the unidirectional data transmission direction is reduced by the second amount.

[0114] In some embodiments, the determining module 505 is further configured to: If any of the following conditions are met, the ratio of requests that the candidate device and the source device can process through the intranet in the unidirectional data transmission direction is determined to be the lower limit of the ratio; The intranet transmission path is not in operation; The return ratio of the alternative device or the source device exceeds a preset value. The return ratio of any service device among the alternative device and the source device refers to the proportion of the amount of data that the service device changes from intranet transmission to extranet transmission in the total amount of data that the service device is set to intranet transmission.

[0115] In some embodiments, the second selection module 503 is specifically used for: Perform a hash operation on the aforementioned business requirement information to obtain a hash value; The hash value is mapped to a random ratio.

[0116] In some embodiments, the second selection module 503 is specifically used for: When the data transmission direction is unidirectional, a candidate device whose proportion of requests that can be processed through the intranet in the corresponding unidirectional data transmission direction is not less than the random proportion is selected as the target device. When the data transmission direction is bidirectional, a candidate device with a request ratio that can be processed through the intranet in the bidirectional data transmission direction with the source device and is not less than the random ratio is selected as the target device. If no target device is selected, a candidate device with a request ratio that can be processed through the intranet in any unidirectional data transmission direction with the source device and is not less than the random ratio is selected as the target device. Select the target device that has the shortest intranet transmission path with the source device from the target devices as the destination device.

[0117] In some embodiments, the data transmission direction is any of the following: Data is transmitted from the destination device to the source device; Data is transmitted from the source device to the destination device; Data is first transmitted from the source device to the destination device, and then data is transmitted from the destination device to the source device.

[0118] In some embodiments, a third selection module 506 is further included, which is used to select a destination device that can meet the business requirements from among the service devices accessing the external network in the CDN if no destination device is selected. The sending module 504 is further configured to send a service scheduling result to the source device. The service scheduling result includes a second transmission identifier and device information of the destination device. The second transmission identifier is used to indicate that the source device and the destination device transmit data through the external network.

[0119] Figure 6 A schematic diagram of another service scheduling device provided in this application embodiment, applied to a source device, includes: The first receiving module 601 is used to receive a service request, wherein the service request contains service requirement information of the target service; The sending module 602 is used to send a service scheduling request to the scheduling center when it is determined that the source device cannot meet the service requirements based on the service requirement information. The service scheduling request includes the service requirement information and data flow direction information, and the data flow direction information is used to indicate the data transmission direction of the target service. The second receiving module 603 is used to receive the service scheduling result of the scheduling center, wherein the service scheduling result is obtained by the scheduling center according to the above-mentioned relevant service scheduling method. The transmission module 604 is used to transmit data with the target device through the intranet according to the device information if the service scheduling result includes a first transmission identifier and device information of the destination device.

[0120] In some embodiments, the transmission module 604 is further configured to: If the service scheduling result includes a second transmission identifier and device information of the destination device, then data is transmitted to the target device via the external network according to the device information. The second transmission identifier is used to indicate that the source device and the destination device transmit data via the external network.

[0121] In some embodiments, the data transmission direction is any of the following: Data is transmitted from the destination device to the source device; Data is transmitted from the source device to the destination device; Data is first transmitted from the source device to the destination device, and then data is transmitted from the destination device to the source device.

[0122] The module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, other division methods are possible. Furthermore, the functional modules in each embodiment of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. Coupling between modules can be achieved through interfaces, typically electrical communication interfaces, but mechanical interfaces or other types of interfaces are also possible. Therefore, modules described as separate components may or may not be physically separate; they can be located in one place or distributed across different locations on the same or different devices. The integrated modules described above can be implemented in hardware or as software functional modules.

[0123] Having introduced the service scheduling method and apparatus according to exemplary embodiments of this application, we will now introduce an electronic device according to another exemplary embodiment of this application.

[0124] The following reference Figure 7 To describe an electronic device 130 implemented according to this embodiment of the present application. Figure 7 The electronic device 130 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0125] like Figure 7 As shown, the electronic device 130 is presented in the form of a general electronic device. The components of the electronic device 130 may include, but are not limited to: at least one processor 131, at least one memory 132, and a bus 133 connecting different system components (including memory 132 and processor 131).

[0126] Bus 133 represents one or more of several bus structures, including a memory bus or memory controller, peripheral bus, processor, or local bus using any of the various bus structures.

[0127] The memory 132 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 1321 and / or cache memory 1322, and may further include read-only memory (ROM) 1323.

[0128] The memory 132 may also include a program / utility 1325 having a set (at least one) of program modules 1324, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0129] Electronic device 130 can also communicate with one or more external devices 134 (e.g., keyboard, pointing device, etc.), and with one or more devices that enable a user to interact with electronic device 130, and / or with any device that enables electronic device 130 to communicate with one or more other electronic devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 135. Furthermore, electronic device 130 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 136. As shown, network adapter 136 communicates with other modules used in electronic device 130 via bus 133. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 130, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0130] In an exemplary embodiment, the electronic device of this application may include at least one processor and a memory communicatively connected to the at least one processor, wherein the memory stores a computer program that can be executed by the at least one processor, and when the computer program is executed by the at least one processor, it can cause the at least one processor to perform the steps of any service scheduling method provided in the embodiments of this application.

[0131] In an exemplary embodiment, a storage medium is also provided, which enables the electronic device to execute any of the above-described service scheduling methods when a computer program in the storage medium is executed by a processor of the electronic device. Optionally, the storage medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0132] In an exemplary embodiment, a computer program product is also provided, which, when executed by an electronic device, enables the electronic device to implement any of the exemplary methods provided in this application.

[0133] It should be noted that although several modules or sub-modules of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more modules described above can be embodied in one module. Conversely, the features and functions of one module described above can be further divided and embodied by multiple modules.

[0134] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0135] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0136] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0137] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, then this application also includes such modifications and variations.

Claims

1. A traffic scheduling method, characterized by, The application is applied to a dispatch center, comprising: receiving a service scheduling request of a source device, the service scheduling request containing service demand information and data flow direction information of a target service, the data flow direction information being used to indicate a data transmission direction of the target service, the source device being a service device accessing an intranet in a content distribution network (CDN); selecting at least one candidate device satisfying the service demand from each service device accessing the intranet in the CDN according to the service demand information; selecting a destination device from the at least one candidate device according to the data flow direction information, wherein when the data transmission direction is one-way, the destination device and the source device can transmit data through the intranet in a corresponding one-way data transmission direction, and when the data transmission direction is two-way, the destination device and the source device can transmit data through the intranet in at least one one-way data transmission direction; if the destination device is selected, sending a service scheduling result to the source device, the service scheduling result containing a first transmission identifier and device information of the destination device, the first transmission identifier being used to indicate that the source device and the destination device transmit data through the intranet.

2. The method of claim 1, wherein, selecting a destination device from the at least one candidate device according to the data flow direction information, comprising: obtaining a request proportion that each candidate device and the source device can handle through the intranet according to the data flow direction information, wherein when the data transmission direction is one-way, the request proportion is a request proportion in a corresponding one-way data transmission direction, and when the data transmission direction is two-way, the request proportion is a request proportion in two one-way data transmission directions with opposite transmission directions; generating a random proportion according to the service demand information, the random proportion being used to represent a probability of handling the service scheduling request through the intranet; selecting the destination device according to the random proportion and the request proportion that each candidate device and the source device can handle through the intranet.

3. The method of claim 2, wherein, determining the request proportion that each candidate device and the source device can handle through the intranet according to the following steps: determining an intranet transmission path between the candidate device and the source device according to obtained intranet routing information; determining a request proportion that the candidate device and the source device can handle in each one-way data transmission direction through the intranet according to transmission performance information of the intranet transmission path in the one-way data transmission direction.

4. The method of claim 3, wherein, the transmission performance information includes a bandwidth usage proportion of any two adjacent switches on the intranet transmission path in the one-way data transmission direction, and the request proportion that the candidate device and the source device can handle in the one-way data transmission direction through the intranet is determined according to the transmission performance information of the intranet transmission path in the one-way data transmission direction, comprising: if the bandwidth usage proportion of any two adjacent switches in the one-way data transmission direction exceeds a first upper limit threshold, the request proportion that the candidate device and the source device can handle in the one-way data transmission direction through the intranet is reduced by a first amplitude, and the initial request proportion is a proportion upper limit; If the bandwidth usage ratio of any two adjacent switches in the unidirectional data transmission direction is less than a first lower threshold, the request ratio of the candidate device and the source device that can be processed by the intranet in the unidirectional data transmission direction is increased by a first amplitude.

5. The method of claim 3 or 4, wherein, The transmission performance information further includes a network health value of the intranet transmission path in the unidirectional data transmission direction. According to the transmission performance information of the intranet transmission path in each unidirectional data transmission direction, the request ratio of the candidate device and the source device that can be processed by the intranet in the unidirectional data transmission direction is determined, including: If the network health value exceeds a second upper threshold, the request ratio of the candidate device and the source device that can be processed by the intranet in the unidirectional data transmission direction is increased by a second amplitude. Initially, the request ratio is the upper limit of the ratio; If the network health value is less than a second lower threshold, the request ratio of the candidate device and the source device that can be processed by the intranet in the unidirectional data transmission direction is decreased by a second amplitude.

6. The method of claim 3, wherein, If any of the following conditions is met, the request ratio of the candidate device and the source device that can be processed by the intranet in the unidirectional data transmission direction is determined to be the lower limit of the ratio; The intranet transmission path is in an unopened state; The backflow ratio corresponding to the candidate device or the source device exceeds a preset value, wherein the backflow ratio corresponding to any service device of the candidate device and the source device refers to the proportion of the data amount transmitted by the intranet to the total data amount set by the intranet transmission of the service device.

7. The method of claim 2, wherein, According to the business demand information, a random ratio is generated, including: Hashing the business demand information to obtain a hash value; Map the hash value to a random ratio.

8. The method of claim 2, wherein, According to the random ratio and the request ratio of each candidate device and the source device that can be processed by the intranet, the destination device is selected, including: When the data transmission direction is unidirectional, the candidate device whose request ratio that can be processed by the intranet in the corresponding unidirectional data transmission direction with the source device is not less than the random ratio is selected as the target device; When the data transmission direction is bidirectional, the candidate device whose request ratio that can be processed by the intranet in the bidirectional data transmission direction with the source device is not less than the random ratio is selected as the target device. If no target device is selected, the candidate device whose request ratio that can be processed by the intranet in any unidirectional data transmission direction with the source device is not less than the random ratio is selected as the target device; The intranet transmission path between the source device and the target device is the shortest.

9. The method of claim 1, wherein, The data transmission direction is any of the following: Transmit data from the destination device to the source device; Transmit data from the source device to the destination device; First transmit data from the source device to the destination device, and then transmit data from the destination device to the source device.

10. The method of claim 1, wherein, Further comprising: If no destination device is selected, select a destination device that can meet the business demand from each service device in the CDN that accesses the extranet; The source device sends a service scheduling result to the target device, the service scheduling result comprising a second transmission identifier and device information of the target device, the second transmission identifier being used to indicate that the source device and the target device transmit data through an external network.

11. A service scheduling method characterized by comprising: The source device comprises: receiving a service request, the service request comprising service requirement information of a target service; when it is determined that the source device cannot meet the service requirement according to the service requirement information, sending a service scheduling request to a scheduling center, the service scheduling request comprising the service requirement information and data flow direction information, the data flow direction information being used to indicate a data transmission direction of the target service; receiving a service scheduling result from the scheduling center, the service scheduling result being obtained by the scheduling center according to the service scheduling method of any one of claims 1 to 10; if the service scheduling result comprises a first transmission identifier and device information of a target device, transmitting data to the target device through an internal network according to the device information.

12. The method of claim 11, wherein, Further comprising: if the service scheduling result comprises a second transmission identifier and device information of a target device, transmitting data to the target device through an external network according to the device information, the second transmission identifier being used to indicate that the source device and the target device transmit data through an external network.

13. The method of claim 11, wherein, The data transmission direction is any one of: transmitting data from the target device to the source device; transmitting data from the source device to the target device; transmitting data from the source device to the target device first and then transmitting data from the target device to the source device.

Images