A data back source system, method, network node and storage medium

Abstract

The embodiment of the application provides a data back source system, method, network node and storage medium, and relates to the technical field of Internet, and the system comprises: an upstream service node, a center node and a downstream content distribution network (CDN) node; the upstream service node is used for sending a registration request to the center node in response to a starting operation; and the IP address is reported to the center node when the IP address is changed; the center node is used for storing the correspondence between the identification and the IP address of the upstream service node in response to the registration request; and the IP address reported by the upstream service node is updated to the stored correspondence; the downstream CDN node is used for acquiring the correspondence from the center node; determining the target node identification of the target service according to the service request of the user for the target service; determining the target IP address corresponding to the target node identification based on the acquired correspondence; and performing data back source based on the target IP address. The technical scheme provided by the embodiment of the application can improve the back source processing efficiency.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a data back-to-source system, method, network node, and storage medium. Background Technology

[0002] With the popularization of cloud computing and microservice architecture, more and more services are migrating to cloud-native architecture. In other words, cloud-native architecture can deploy upstream service nodes that can provide various services.

[0003] A CDN (Content Delivery Network) is an important network content service system that provides users with efficient content distribution services. In a CDN, when a user requests access to content provided by a service, downstream CDN nodes receive the user's request and check if they have cached the requested content. If the downstream CDN node does not have the requested content cached, it needs to perform origin server processing, requesting the requested content from the upstream service node.

[0004] When a CDN's transport network adopts a cloud-native architecture, the IP addresses of various network nodes within this architecture change frequently. This means that the IP addresses of upstream service nodes also change frequently, making it difficult for downstream CDN nodes to perceive the actual IP addresses of upstream service nodes in real time. When downstream CDN nodes perform origin pull processing, if they directly use the changed IP addresses, the hit rate of downstream CDN nodes hitting upstream service nodes will be low, leading to longer origin pull times and lower origin pull processing efficiency. Summary of the Invention

[0005] The purpose of this application is to provide a data back-to-source system, method, network node, and storage medium to improve the efficiency of back-to-source processing. The specific technical solution is as follows:

[0006] In a first aspect of this application, a data back-to-origin system is provided, comprising: an upstream service node, a central node, and a downstream CDN node; wherein,

[0007] The upstream service node is configured to send a registration request to the central node in response to a startup operation, wherein the registration request includes the identifier and IP address of the upstream service node; and to report the updated IP address to the central node in response to a change in the IP address of the upstream service node.

[0008] The central node is configured to, in response to the registration request, store the correspondence between the identifier and IP address of the upstream service node; and, in response to the upstream service node reporting its IP address, update the IP address in the correspondence stored in the central node.

[0009] The downstream CDN node is used to obtain the correspondence stored by the central node; in response to receiving a user's service request for a target service, it determines the target node identifier of the upstream service node corresponding to the target service requested by the service request; based on the obtained correspondence, it determines the target IP address corresponding to the target node identifier; and based on the target IP address, it performs data back to the origin.

[0010] In one possible implementation, the downstream CDN node is further configured to perform a hash calculation on the identifier of each upstream service node in the stored correspondence relationship to obtain multiple first hash values ​​of the identifier.

[0011] In one possible implementation, determining the target node identifier of the upstream service node corresponding to the target service requested by the service request includes:

[0012] Generate a second hash value for the request identifier of the user service request;

[0013] Among the first hash values ​​stored in the downstream CDN node, find the third hash value that is greater than the second hash value and closest to the second hash value;

[0014] If a third hash value is found, the identifier corresponding to the third hash value is determined as the target node identifier of the upstream service node corresponding to the target service requested by the service request;

[0015] If the third hash value is not found, the smallest first hash value recorded is determined as the third hash value, and the identifier corresponding to the third hash value is determined as the target node identifier.

[0016] In one possible implementation, the central node is further configured to monitor the status of the upstream service node; if the monitored status indicates that the upstream service node has joined the CDN network, the central node obtains the identifier and IP address of the upstream service node and stores the correspondence between the identifier and IP address of the upstream service node; if the monitored status indicates that the upstream service node has left the CDN network, the central node deletes the correspondence between the identifier and IP address of the upstream service node stored therein; if the monitored status indicates that the IP address of the upstream service node has changed, the central node updates the IP address in the correspondence between the identifier and IP address of the upstream service node stored therein.

[0017] In one possible implementation, the downstream CDN node is further configured to send a subscription request to the central node in response to the startup operation, wherein the subscription request is used to subscribe to the correspondence stored by the central node;

[0018] The central node is also used to detect changes in the correspondence stored in the central node and synchronize the changed correspondence to the downstream CDN nodes.

[0019] The downstream CDN node is specifically used to update the correspondence stored by the downstream CDN node according to the correspondence synchronized by the central node.

[0020] In one possible implementation, the identifier of the upstream service node includes: the service name provided by the upstream service node and / or the service version provided by the upstream service node.

[0021] In a second aspect of this application, a data back-to-source method is also provided, applied to a central node, the method comprising:

[0022] In response to a registration request from an upstream service node, the central node stores the correspondence between the identifier and IP address of the upstream service node.

[0023] In response to the upstream service node reporting an updated IP address, the IP address in the correspondence stored in the central node is updated;

[0024] The corresponding relationship stored by the central node is sent to downstream CDN nodes.

[0025] In one possible implementation, the method further includes:

[0026] Monitor the status of the upstream service node;

[0027] If the monitored status indicates that the upstream service node has joined the CDN network, then the identifier and IP address of the upstream service node are obtained from the upstream service node, and the correspondence between the identifier and IP address of the upstream service node is stored in the central node.

[0028] If the monitored status indicates that the upstream service node has exited the CDN network, then the correspondence between the identifier and IP address of the upstream service node stored in the central node is deleted.

[0029] If the monitored status indicates that the IP address of the upstream service node has changed, then the IP address in the mapping relationship between the identifier and IP address of the upstream service node stored in the central node is updated.

[0030] In one possible implementation, the method further includes:

[0031] Receive a subscription request from the downstream CDN node for the correspondence stored in the central node, and respond to the subscription request by sending the correspondence stored in the central node to the downstream CDN node;

[0032] Sending the stored correspondence of the central node to downstream CDN nodes includes:

[0033] After detecting a change in the correspondence stored in the central node, the updated correspondence is synchronized to the downstream CDN nodes.

[0034] In a third aspect of this application, a data back-to-origin method is also provided, applied to a downstream CDN node, the method comprising:

[0035] Obtain the mapping between the identifiers and IP addresses of the upstream service nodes stored in the central node;

[0036] In response to receiving a user's service request for a target service, determine the target node identifier of the upstream service node corresponding to the target service requested by the service request;

[0037] Based on the obtained correspondence, determine the target IP address corresponding to the target node identifier;

[0038] Data is retrieved from the source based on the target IP address.

[0039] In one possible implementation, the method further includes:

[0040] For each upstream service node in the corresponding relationship stored in the downstream CDN node, a hash calculation is performed on the identifier to obtain multiple first hash values ​​for the identifier.

[0041] In one possible implementation, determining the target node identifier of the upstream service node corresponding to the target service requested by the service request includes:

[0042] Generate a second hash value for the request identifier of the service request;

[0043] Among the first hash values ​​stored in the downstream CDN node, find the third hash value that is greater than the second hash value and closest to the second hash value;

[0044] If a third hash value is found, the identifier corresponding to the third hash value is determined as the target node identifier of the upstream service node corresponding to the target service requested by the service request;

[0045] If the third hash value is not found, the smallest first hash value recorded is determined as the third hash value, and the identifier corresponding to the third hash value is determined as the target node identifier.

[0046] In one possible implementation, the method further includes:

[0047] In response to the startup operation, a subscription request for the corresponding relationship stored by the central node is sent to the central node;

[0048] Obtain the corresponding relationship stored by the central node in response to the subscription request;

[0049] The process of obtaining the mapping relationship between the identifiers and IP addresses of upstream service nodes stored in the central node includes:

[0050] Based on the correspondence synchronized by the central node, update the correspondence stored by the downstream CDN nodes.

[0051] In a fourth aspect of this application, a data back-to-source method is also provided, applied to an upstream service node, the method comprising:

[0052] In response to the startup operation, a registration request is sent to the central node, wherein the registration request includes the identifier and IP address of the upstream service node;

[0053] In response to the IP address change of the upstream service node, the updated IP address is reported to the central node.

[0054] In one possible implementation, the identifier of the upstream service node includes: the service name provided by the upstream service node and / or the service version provided by the upstream service node.

[0055] In a fifth aspect of this application, a data back-to-source device is also provided, applied to a central node, the device comprising:

[0056] A storage module is used to store the correspondence between the identifier and IP address of the upstream service node in the central node in response to the registration request of the upstream service node;

[0057] The update module is used to update the IP address in the correspondence stored in the central node in response to the updated IP address reported by the upstream service node.

[0058] The first sending module is used to send the correspondence stored by the central node to downstream CDN nodes.

[0059] In one possible implementation, the device further includes:

[0060] The monitoring module is used to monitor the status of the upstream service node. If the monitored status indicates that the upstream service node has joined the CDN network, the module obtains the identifier and IP address of the upstream service node and stores the mapping between the identifier and IP address of the upstream service node in the central node. If the monitored status indicates that the upstream service node has left the CDN network, the module deletes the mapping between the identifier and IP address of the upstream service node stored in the central node. If the monitored status indicates that the IP address of the upstream service node has changed, the module updates the IP address in the mapping between the identifier and IP address of the upstream service node stored in the central node.

[0061] In one possible implementation, the device further includes:

[0062] The receiving module is configured to receive a subscription request sent by the downstream CDN node for the correspondence stored by the central node, and respond to the subscription request by sending the correspondence stored by the central node to the downstream CDN node.

[0063] The first sending module is specifically used to: after detecting a change in the correspondence stored by the central node, synchronize the changed correspondence to the downstream CDN nodes.

[0064] In a sixth aspect of this application, a data back-to-origin device is also provided, applied to a downstream CDN node, the device comprising:

[0065] The acquisition module is used to obtain the mapping relationship between the identifiers and IP addresses of the upstream service nodes stored in the central node;

[0066] The first determining module is used to determine the target node identifier of the upstream service node corresponding to the target service requested by the user in response to obtaining the user's service request for the target service.

[0067] The second determining module is used to determine the target IP address corresponding to the target node identifier based on the acquired correspondence.

[0068] The origin retrieval module is used to retrieve data from the source based on the target IP address.

[0069] In one possible implementation, the device further includes:

[0070] The calculation module is used to perform a hash calculation on the identifier of each upstream service node in the corresponding relationship stored by the downstream CDN node to obtain multiple first hash values ​​of the identifier.

[0071] The second determining module is specifically used for: generating a second hash value for the request identifier of the service request; searching for a third hash value that is greater than the second hash value and closest to the second hash value in the first hash value stored in the downstream CDN node; if the third hash value is found, determining the identifier corresponding to the third hash value as the target node identifier of the upstream service node corresponding to the target service requested by the service request; if the third hash value is not found, determining the smallest recorded first hash value as the third hash value, and determining the identifier corresponding to the third hash value as the target node identifier.

[0072] In one possible implementation, the device further includes:

[0073] The subscription module is used to send a subscription request for the corresponding relationship stored by the central node to the central node in response to the startup operation; and to obtain the corresponding relationship stored by the central node in response to the subscription request.

[0074] The acquisition module is specifically used to: update the correspondence stored by the downstream CDN nodes according to the correspondence synchronized by the central node.

[0075] In a seventh aspect of this application, a data back-to-source device is also provided, applied to an upstream service node, the device comprising:

[0076] The second sending module is used to send a registration request to the central node in response to the startup operation, wherein the registration request includes the identifier and IP address of the upstream service node;

[0077] The reporting module is used to report the updated IP address to the central node in response to the IP address change of the upstream service node.

[0078] In one possible implementation, the identifier of the upstream service node includes: the service name provided by the upstream service node and / or the service version provided by the upstream service node.

[0079] In an eighth aspect of this application, a network node is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus.

[0080] Memory, used to store computer programs;

[0081] A processor, when executing a program stored in memory, implements the data return method described in the second, third, or fourth aspect above.

[0082] In a ninth aspect of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements the data back-to-source method described in the second, third, or fourth aspects above.

[0083] In a tenth aspect of this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform the data back-to-source method described in the second, third, or fourth aspects above.

[0084] In the technical solution provided in this application, when an upstream service node starts up or its IP address changes, it reports its real-time IP address to the central node. The central node can then obtain the real-time IP address reported by the upstream service node and store the mapping between the unchanging identifier of the upstream service node and its IP address. Downstream CDN nodes can obtain the mapping between the identifiers of each upstream service node and their real-time IP addresses from the central node. Therefore, when performing data back-to-origin processing, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the mapping obtained from the central node, and perform data back-to-origin processing based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improving the hit rate of the downstream CDN node hitting the accurate upstream service node during back-to-origin processing, reducing back-to-origin processing time, and thus improving back-to-origin processing efficiency. Attached Figure Description

[0085] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0086] Figure 1 This is a flowchart illustrating the origin pull process in existing CDN technologies.

[0087] Figure 2 This is a schematic diagram of the structure of CDN in the existing technology;

[0088] Figure 3 A schematic diagram of the data back-to-source system provided in this application embodiment;

[0089] Figure 4 A signaling interaction diagram for the data back-to-source process provided in the embodiments of this application;

[0090] Figure 5 A flowchart illustrating one method for determining a target node identifier provided in an embodiment of this application;

[0091] Figure 6A schematic flowchart illustrating a data return process for the data return system provided in the embodiments of this application;

[0092] Figure 7 A flowchart illustrating a data back-to-source method applied to a central node, as provided in an embodiment of this application;

[0093] Figure 8 A schematic flowchart of a data back-to-origin method applied to downstream CDN nodes provided in an embodiment of this application;

[0094] Figure 9 A flowchart illustrating a data back-to-source method applied to an upstream service node, as provided in an embodiment of this application;

[0095] Figure 10 A schematic diagram of a data back-to-source device applied to a central node, provided in an embodiment of this application;

[0096] Figure 11 A schematic diagram of a data back-to-origin device applied to a downstream CDN node provided in an embodiment of this application;

[0097] Figure 12 A schematic diagram of a data back-to-source device applied to an upstream service node, provided in an embodiment of this application;

[0098] Figure 13 This is a schematic diagram of a network node provided in an embodiment of this application. Detailed Implementation

[0099] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0100] With the widespread adoption of cloud computing and microservice architectures, more and more services are migrating to cloud-native architectures. This means that cloud-native architectures can deploy upstream service nodes capable of providing various services. Cloud-native networks typically involve dynamic deployment of Pods (service instances), frequent network scaling (i.e., frequent additions or removals of network nodes and frequent adjustments to Pod deployments to efficiently utilize resources). The frequent additions or removals of network nodes, and the frequent scheduling of Pods deployed on each network node leading to restarts and shutdowns, result in frequent changes to the IP addresses of these network nodes.

[0101] CDN is an important network content service system that provides users with efficient content distribution services. Origin management is a crucial component of CDN's content distribution service. The origin management process in existing CDN technologies is as follows: Figure 1As shown, when a user requests access to content provided by a service, downstream CDN nodes receive the user's service request and check if they have cached the requested content. If the downstream CDN node does not find the requested content, meaning it does not cache it, it needs to perform origin-fetching processing, requesting the requested content from the upstream service node. If the upstream service node caches the requested content, it can directly provide feedback to the downstream CDN node. If the upstream service node also does not cache the requested content, it can directly request the original content from the origin server. The origin server stores all content that the network can provide to users; downstream CDN nodes are also called cache nodes or CDN nodes; and upstream service nodes are also called origin-fetching nodes or service nodes.

[0102] Figure 1 The image only shows one origin pull process and a partial CDN architecture. A complete CDN architecture in existing technologies is shown below. Figure 2 As shown. Figure 2 In a CDN, there are multiple downstream CDN nodes, multiple upstream service nodes, and an origin server. Downstream CDN nodes can send requests to any of the upstream service nodes, and each upstream service node can request the original content from the origin server.

[0103] When a CDN's transport network adopts a cloud-native architecture, the IP addresses of various network nodes within this architecture change frequently. This means that the IP addresses of upstream service nodes also change frequently, making it difficult for downstream CDN nodes to perceive the actual IP addresses of upstream service nodes in real time. If downstream CDN nodes directly use the changed IP addresses for origin pull processing, the hit rate of downstream CDN nodes hitting upstream service nodes will be low, leading to longer origin pull times and lower processing efficiency.

[0104] To address the aforementioned problems, embodiments of this application provide a data back-to-source system, such as... Figure 3 As shown, the system includes an upstream service node 301, a central node 302, and a downstream CDN node 303. The data origination system may include multiple upstream service nodes 301 or multiple downstream CDN nodes 303. The upstream service node 301, central node 302, and downstream CDN node 303 are all network nodes, which can be servers, desktop computers, etc.

[0105] Upstream service node 301 is used to send a registration request to the central node in response to the startup operation. The registration request includes the identifier and IP address of the upstream service node. In response to a change in the IP address of the upstream service node, it reports the updated IP address to the central node.

[0106] The identifier of upstream service node 301 may include: the service name and / or the service version provided by the upstream service node. The identifier of upstream service node 301 may also be a unique identifier assigned to it by the control server in the network. Each network node in the network has a unique identifier. The IP addresses of each network node in the network can be assigned by a DHCP (Dynamic Host Configuration Protocol) server. The DHCP server can periodically or conditionally assign new IP addresses to each network node according to actual needs.

[0107] When the upstream service node 301 starts up, it can send a request to the DHCP server to obtain an IP address assigned to it by the DHCP server. Then, the upstream service node generates a registration request based on the obtained IP address and its own identifier, and sends the registration request to the central node.

[0108] An IP address change for upstream service node 301 can occur when upstream service node 301 receives a new IP address assigned by a DHCP server. After receiving the newly assigned IP address, upstream service node 301 can report the updated IP address to central node 302.

[0109] Central node 302 is used to respond to registration requests by storing the mapping between the identifiers and IP addresses of upstream service nodes; and to update the stored mapping in response to upstream service nodes reporting their IP addresses.

[0110] When the central node 302 receives a registration request from the upstream service node 301, it can parse the identifier and IP address in the registration request. The central node 302 can store the mapping between the identifier and IP address of the upstream service node 301 in the form of a list.

[0111] For example, if the central node 302 obtains the identifier ID_A and IP address IP_A from the registration request of the upstream service node A, and obtains the identifier ID_B and IP address IP_B from the registration request of the upstream service node B, then the central node 302 can store the correspondence between the identifiers and IP addresses of the upstream service nodes in the form of a list: ID_A: IP_A, ID_B: IP_B.

[0112] When the IP address of upstream service node 301 changes, upstream service node 301 can report the updated IP address to central node 302. Upon receiving the updated IP address reported by upstream service node 301, central node 302 can look up the corresponding identifier of upstream service node 301 in the stored mapping relationship and update the IP address corresponding to the found identifier in the mapping relationship. Afterwards, central node 302 can also send the updated mapping relationship stored by central node 302 to downstream CDN node 303.

[0113] For example, continuing the previous example, the central node 302 stores the following correspondence: ID_A: IP_A, ID_B: IP_B. When central node 302 receives the IP address IP_C reported by upstream service node A, central node 2 can look up the identifier ID_A of upstream service node A in the stored correspondence and update the IP address corresponding to ID_A in the correspondence from IP_A to IP_C. After the update, the correspondence stored by central node 302 is: ID_A: IP_C, ID_B: IP_B.

[0114] Downstream CDN node 303 is used to obtain the mapping relationship of the central node storage; in response to obtaining the user's service request for the target service, it determines the target node identifier of the upstream service node corresponding to the target service requested by the service request; based on the obtained mapping relationship, it determines the target IP address corresponding to the target node identifier; and based on the target IP address, it performs data back to the origin.

[0115] Downstream CDN node 303 can send a request to central node 302 to obtain the corresponding relationship stored in central node 302. After receiving the request from downstream CDN node 303, central node 302 can send the corresponding relationship stored in central node 302 to downstream CDN node 303.

[0116] When a user needs to obtain a specific service, i.e., the target service, they can send a service request for that service to the downstream CDN node 303. Upon receiving the service request, the downstream CDN node 303 first checks if it has cached the requested content. If it has, it can provide that content back to the user. If it doesn't, for example, if the cached content has been removed or expired, the downstream CDN node 303 can determine the target node identifier of the upstream service node for the requested service, allowing for subsequent data retrieval from the origin node to obtain the content stored there. Alternatively, the downstream CDN node 303 can directly determine the target node identifier without checking the cache to perform data retrieval. This improves the accuracy of the content returned to the user.

[0117] Downstream CDN node 303 can store the mapping between request identifiers and upstream service node identifiers. Downstream CDN node 303 can obtain the request identifier carried in the user's service request, and then, based on the mapping stored in downstream CDN node 303, determine the identifier of the upstream service node corresponding to the obtained request identifier, using it as the target node identifier. The request identifier can be the identifier of the target service requested by the user's service request, such as a URI (Uniform Resource Identifier).

[0118] Then, CND node 303 searches for an identifier that matches the target node identifier in the already obtained mapping relationship between the identifiers and IP addresses of the upstream service nodes. After finding an identifier that matches the target node, the IP address corresponding to that identifier in the mapping relationship is determined as the target IP address.

[0119] Then, the downstream CDN node 303 can use the target IP address as the destination address to forward the user's service request to the target IP address in order to obtain the content requested by the user.

[0120] If the upstream target node has previously received a service request for the same content (i.e., the same target service), the target node may have cached the requested content. When the target node receives a user's service request forwarded by a downstream CDN node, it can first check if it has cached the requested content. If the target node has stored the requested content, it can directly send its stored content back to the downstream CDN node. If the target node does not have the requested content stored, it can forward the user's service request to the origin server to obtain the original content requested by the user.

[0121] In the technical solution provided in this application, when an upstream service node starts up or its IP address changes, it reports its real-time IP address to the central node. The central node can then obtain the real-time IP address reported by the upstream service node and store the mapping between the unchanging identifier of the upstream service node and its IP address. Downstream CDN nodes can obtain the mapping between the identifiers of each upstream service node and their real-time IP addresses from the central node. Therefore, when performing data back-to-origin processing, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the mapping obtained from the central node, and perform data back-to-origin processing based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improving the hit rate of the downstream CDN node hitting the accurate upstream service node during back-to-origin processing, reducing back-to-origin processing time, and thus improving back-to-origin processing efficiency.

[0122] To more clearly illustrate the data retrieval process of the aforementioned data retrieval system, embodiments of this application also provide, as follows: Figure 4 The diagram shown is a signaling interaction diagram.

[0123] Figure 4 In the process, when upstream service node 301 starts up, it sends a registration request to central node 302. The registration request may include the identifier and IP address of the upstream service node. When the IP address of the upstream service node changes, it can also report the updated IP address to the central node.

[0124] After receiving a registration request from an upstream service node, the central node can store the mapping between the upstream service node's identifier and IP address based on the identifier and IP address carried in the registration request. Upon receiving an updated IP address reported by the upstream service node, the central node can also respond by updating the stored mapping for that upstream service node's IP address.

[0125] Once the central node stores a new mapping relationship, or after an existing mapping relationship is updated, it can send the new mapping relationship to the downstream CDN node 303.

[0126] Downstream CDN nodes can obtain the corresponding relationships stored in the central node and sent by the central node.

[0127] When a downstream CDN node receives a service request from a user, it first determines the target node identifier of the upstream service node corresponding to the requested service. Then, based on the obtained mapping, the downstream CDN node determines the target IP address corresponding to the target node identifier. Finally, based on the target IP address, the downstream CDN node performs data back-to-origin processing, that is, requests the user's requested service from the upstream service node corresponding to the target node identifier.

[0128] Afterwards, the downstream CDN nodes can feed back the service content of the target service obtained from the upstream service nodes to the user.

[0129] In one possible implementation, the downstream CDN node 303 may store a first hash value of the identifier, which can be used to determine the target node identifier of the target service requested by the service request.

[0130] Specifically, the downstream CDN node 303 can perform a hash calculation on the identifier of each upstream service node in the stored correspondence relationship to obtain multiple first hash values ​​of the identifier.

[0131] The first hash value can be an unsigned integer. For example, the first hash value can be between 0 and 2. 32 Any positive integer between 0 and 2. For each upstream service node identifier in the correspondence stored by the downstream CDN node 303, the downstream CDN node 303 can calculate 100 to 200 first hash values ​​for that identifier.

[0132] Downstream CDN node 303 can use a preset first hash function to generate multiple first hash values ​​for each upstream service node's identifier in the stored correspondence relationship. These identifiers are used as keys. For example, downstream CDN nodes can generate multiple corresponding virtual identifiers for each identifier and then use the first hash function to perform hash mapping on these virtual identifiers, thereby generating multiple first hash values ​​for the identifier of the same upstream service node.

[0133] After generating multiple first hash values, the downstream CDN node 303 can store the first hash value corresponding to the identifier of each upstream service node. The downstream CDN node 303 can also store the generated first hash values ​​on a consistent hash ring so that the target node identifier can be determined later based on the first hash values ​​on the consistent hash ring.

[0134] After generating the first hash value, as follows Figure 5As shown, when the downstream CDN node 303 determines the target node identifier of the upstream service node corresponding to the target service requested by the service request in the following manner, the method includes steps S501-S504.

[0135] Step S501: Generate a second hash value for the request identifier of the service request.

[0136] Downstream CDN node 303 can use a preset second hash function to generate a second hash value for the request identifier of the service request. The request identifier is the same for the same request content; that is, for service requests with the same content, the second hash value generated by downstream CDN node 303 will also be the same.

[0137] Step S502: In the first hash value stored in the downstream CDN node, find the third hash value that is greater than the second hash value and closest to the second hash value; if the third hash value is found, proceed to step S503; if the third hash value is not found, proceed to step S504.

[0138] Downstream CDN node 303 can use methods such as sequential search or binary search to find the third hash value among all stored first hash values. For service requests with the same content, since the second hash values ​​generated by downstream CDN node 303 are the same, the third hash value determined based on the same second hash value will also be the same.

[0139] Step S503: The identifier corresponding to the third hash value is determined as the target node identifier of the upstream service node corresponding to the target service requested by the service request.

[0140] After the downstream CDN node 303 finds the third hash value, it can then find the identifier of the upstream service node corresponding to the third hash value and use this upstream service node identifier as the target node identifier of the service requested. For service requests with the same content, since the determined third hash value is the same, the target node identifier determined based on the third hash value is also the same.

[0141] Step S504: Determine the smallest recorded first hash value as the third hash value, and determine the identifier corresponding to the third hash value as the target node identifier.

[0142] If the downstream CDN node 303 cannot find the third hash value, then the smallest recorded first hash value can be determined as the third hash value. The downstream CDN node can then find the identifier of the upstream service node corresponding to the third hash value and use this identifier as the target node identifier of the service requested.

[0143] In the technical solution provided in this application embodiment, the identifier of the upstream service node is used as the key value of the hash mapping instead of the IP address, which ensures the stability of the method of determining the target node identifier using hash mapping. When the IP address changes frequently, the downstream CDN node can still determine the target node identifier of the upstream service node of the target service requested by the user's service request according to the above hash mapping. Then, the downstream CDN node determines the target IP address of the upstream service node of the target service requested by the user's service request according to the correspondence and performs data back to the origin. In this way, the downstream CDN node can perform hash calculation based on the stable identifier of the upstream service node to obtain a first hash value. Subsequently, it can more accurately determine the target node identifier of the target service requested by the service request based on the first hash value, and thus more accurately determine the target IP address of the upstream service node. This further improves the hit rate of the downstream CDN node to accurately hit the upstream service node during the back-to-origin process, reduces the back-to-origin time, and thus further improves the efficiency of back-to-origin processing.

[0144] Furthermore, in the technical solution provided in this application embodiment, a fixed second hash function is used to determine the second hash value of the service request's request identifier. Then, the same method is used to determine the third hash value based on this second hash value. This ensures that for service requests with the same content, the downstream CDN nodes determine the same third hash value, and consequently, the target node identifier determined based on the third hash value is also the same. In other words, for service requests with the same content, downstream CDN nodes can retrace to the same upstream service node. After requesting the content from the origin server once, the upstream service node can cache the content. Therefore, when downstream CDN nodes request the content multiple times, the upstream service node can directly return the requested content to the downstream CDN nodes without needing to request the original content from the origin server each time. This allows for faster return of the requested content to the user, further improving origin server processing efficiency and enhancing the user experience.

[0145] In one possible implementation, the central node 302 can also monitor the status of the upstream service node, and when different statuses of the upstream service node are detected, update the corresponding relationship stored by the central node in the following three ways.

[0146] 1. If the monitored status indicates that the upstream service node has joined the CDN network, then obtain the identifier and IP address of the upstream service node from the upstream service node, and store the correspondence between the identifier and IP address of the upstream service node in the central node.

[0147] The central node 302 can obtain the network status of each node in the network by sending status information requests to the DHCP server. When the central node 302 receives feedback from the DHCP server that a new upstream service node 301 has joined the CDN network, it can send a request to the DHCP server or the upstream service node 301 to obtain the identifier and IP address of the upstream service node 301. The central node 302 can then store the obtained mapping between the identifier and IP address of the upstream service node 301.

[0148] 2. If the monitored status indicates that the upstream service node has exited the CDN network, then delete the mapping between the upstream service node's identifier and IP address stored in the central node.

[0149] When the central node 302 receives feedback from the DHCP server that an upstream service node 301 has left the CDN network, the central node 302 can delete the mapping between the identifier and IP address of the upstream service node stored in the central node.

[0150] 3. If the monitored status indicates that the IP address of the upstream service node has changed, then update the IP address in the mapping relationship between the identifier and IP address of the upstream service node stored in the central node.

[0151] When the central node 302 receives feedback from the DHCP server that the IP address of the upstream service node 301 has changed, the central node 302 can send a request to the DHCP server or the upstream service node 301 to obtain the IP address of the upstream service node 301. Then, the central node 302 can update the IP address in the mapping between the identifier and IP address of the upstream service node stored in the central node.

[0152] In the technical solution provided in this application embodiment, the central node can actively monitor the network status of upstream service nodes in the network. When the status of an upstream service node changes but is not reported to the central node, the central node can still perceive the status change. This allows the central node to update the stored mappings, further improving the real-time performance and accuracy of the IP addresses of each upstream service node stored by the central node. Consequently, the IP addresses of upstream service nodes obtained by downstream CDN nodes from the central node become more accurate, further improving the hit rate of downstream CDN nodes hitting accurate upstream service nodes during origin pull, reducing origin pull time, and thus further improving origin pull processing efficiency.

[0153] In one possible implementation, the downstream CDN node 303 may also send a subscription request to the central node upon startup, wherein the subscription request is used to subscribe to the mapping relationship stored by the central node. After receiving the subscription request from the downstream CDN node, if the central node detects a change in the mapping relationship stored by the central node during the subscription period of the downstream CDN node, the central node may synchronize the changed mapping relationship with the downstream CDN node; the downstream CDN node updates the mapping relationship stored by the downstream CDN node according to the mapping relationship synchronized by the central node.

[0154] When downstream CDN node 303 starts, it can send a subscription request to central node 302 for the mapping relationships stored by central node 302. Upon receiving the subscription request from downstream CDN node 303, central node 302 can send the mapping relationships it has stored to downstream CDN node 303. Downstream CDN node 303 then obtains and stores the mapping relationships returned by central node 302 in response to the subscription request.

[0155] Subsequently, after detecting a change in the mapping relationship stored by the central node 302, the central node 302 synchronizes the changed mapping relationship with the downstream CDN node 303, that is, it sends the changed mapping relationship to the downstream CDN node 303. The downstream CDN node 303 then updates the mapping relationship stored by the downstream CDN node based on the mapping relationship sent by the central node.

[0156] In the technical solution provided in this application embodiment, when a downstream CDN node starts up, it can actively subscribe to the mapping relationship stored by the central node. Even when the central node is unaware that a downstream CDN node has joined the network, the downstream CDN node can still obtain the mapping relationship stored by the central node. Furthermore, after subscribing to the mapping relationship stored by the central node, the central node will synchronize the updated mapping relationship to the downstream CDN node. This further improves the real-time performance and accuracy of the IP addresses of each upstream service node obtained by the downstream CDN node, thereby further improving the hit rate of the downstream CDN node hitting the correct upstream service node during origin pull, reducing origin pull time, and thus further improving origin pull processing efficiency.

[0157] To more clearly illustrate the data back-to-source system provided in the embodiments of this application, the embodiments of this application also provide, as well as... Figure 6 The flowchart shown is shown.

[0158] Figure 6When upstream service node A and upstream service node B start up, they send registration requests to the Service Registry and Discovery Center (the aforementioned central node). Upon receiving the registration requests from the upstream service nodes, the Service Registry and Discovery Center's service discovery and update interface stores the origin node lists (correspondence) for the identifiers and IP addresses of upstream service node A and upstream service node B, respectively. After storing the origin node lists, the Service Registry and Discovery Center then notifies the downstream service nodes (downstream CDN nodes) of the updated origin node list.

[0159] The downstream service nodes include an origin management module. Upon receiving a notification from the service registration and discovery center, this module updates the origin node list (i.e., the correspondence) stored in the downstream service nodes based on the origin node list included in the notification. The IP addresses in the downstream service nodes' origin node lists are updated to real-time IP addresses. For each upstream service node's identifier in the updated origin node list, the downstream service nodes perform a hash calculation on that identifier to obtain multiple first hash values, and store these first hash values ​​in a consistent hash ring to construct the consistent hash ring.

[0160] When a downstream service node receives a user's service request, it generates a second hash value based on the request identifier in the request. Then, it searches for a third hash value in the first hash value stored in the consistent hash ring that is greater than and closest to the second hash value. After obtaining the third hash value, the downstream service node identifies the identifier corresponding to it as the target node identifier for the requested service. Next, based on the already obtained list of origin nodes, the downstream service node determines the origin IP address corresponding to the target node identifier in the list, i.e., the target IP address, and performs data return to the origin based on this IP address. In other words, according to the origin processing mechanism, the user's service request is forwarded to the origin IP address.

[0161] By applying the technical solution provided in this application, CDN origin pull management based on a cloud-native architecture is optimized. This effectively improves the origin pull processing efficiency and response speed of CDN under a cloud-native architecture, reduces origin pull latency, and enhances user experience. Furthermore, because the accuracy of IP address acquisition during the origin pull process is relatively high, the number of requests forwarded by downstream CDN nodes is reduced, thereby reducing bandwidth consumption and lowering CDN operating costs.

[0162] In addition, by combining CDN with cloud-native architecture, the network possesses the advantages of cloud-native architecture, such as high availability, elastic scaling, and automatic disaster recovery, as well as the advantages of CDN, such as accelerating network response speed, allowing users to receive feedback faster after sending requests.

[0163] Corresponding to the aforementioned data back-to-source system, this application also provides a data back-to-source method, such as... Figure 7 As shown, the method is applied to the central node 302 and includes the following steps S701-S703.

[0164] Step S701: In response to the registration request from the upstream service node, the central node stores the correspondence between the identifier and IP address of the upstream service node.

[0165] Step S702: In response to the upstream service node reporting the updated IP address, update the IP address in the correspondence stored in the central node.

[0166] Step S703: Send the corresponding relationship stored by the central node to the downstream CDN nodes.

[0167] In the technical solution provided in this application, when an upstream service node starts up or its IP address changes, it reports its real-time IP address to the central node. The central node can then obtain the real-time IP address reported by the upstream service node and store the mapping between the unchanging identifier of the upstream service node and its IP address. Downstream CDN nodes can obtain the mapping between the identifiers of each upstream service node and their real-time IP addresses from the central node. Therefore, when performing data back-to-origin processing, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the mapping obtained from the central node, and perform data back-to-origin processing based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improving the hit rate of the downstream CDN node hitting the accurate upstream service node during back-to-origin processing, reducing back-to-origin processing time, and thus improving back-to-origin processing efficiency.

[0168] In one possible implementation, the central node 302 can monitor the status of the upstream service node 301. The data back-to-origin method applied to the central node 302 may further include the following steps: monitoring the status of the upstream service node; if the monitored status indicates that the upstream service node has joined the CDN network, then obtaining the identifier and IP address of the upstream service node from the upstream service node and storing the correspondence between the identifier and IP address of the upstream service node in the central node; if the monitored status indicates that the upstream service node has left the CDN network, then deleting the correspondence between the identifier and IP address of the upstream service node stored in the central node; if the monitored status indicates that the IP address of the upstream service node has changed, then updating the IP address in the correspondence between the identifier and IP address of the upstream service node stored in the central node.

[0169] In one possible implementation, the downstream CDN node 303 can subscribe to the mapping relationship stored by the central node. The data back-to-origin method applied to the central node 302 may further include the following steps: receiving a subscription request for the mapping relationship stored by the central node sent by the downstream CDN node, and responding to the subscription request by sending the mapping relationship already stored by the central node to the downstream CDN node.

[0170] In this case, step S703 above can be implemented as follows: after detecting a change in the correspondence stored in the central node, the changed correspondence is synchronized to the downstream CDN nodes.

[0171] Corresponding to the aforementioned data back-to-source system, this application also provides a data back-to-source method, such as... Figure 8 As shown, this method is applied to downstream CDN node 303 and includes the following steps S801-S804.

[0172] Step S801: Obtain the correspondence between the identifiers and IP addresses of the upstream service nodes stored in the central node;

[0173] Step S802: In response to obtaining the user's service request for the target service, determine the target node identifier of the upstream service node corresponding to the target service requested by the service request.

[0174] Step S803: Based on the obtained correspondence, determine the target IP address corresponding to the target node identifier;

[0175] Step S804: Perform data retrieval based on the target IP address.

[0176] In the technical solution provided in this application, when an upstream service node starts up or its IP address changes, it reports its real-time IP address to the central node. The central node can then obtain the real-time IP address reported by the upstream service node and store the mapping between the unchanging identifier of the upstream service node and its IP address. Downstream CDN nodes can obtain the mapping between the identifiers of each upstream service node and their real-time IP addresses from the central node. Therefore, when performing data back-to-origin processing, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the mapping obtained from the central node, and perform data back-to-origin processing based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improving the hit rate of the downstream CDN node hitting the accurate upstream service node during back-to-origin processing, reducing back-to-origin processing time, and thus improving back-to-origin processing efficiency.

[0177] In one possible implementation, the data back-to-origin method applied to the downstream CDN node 303 may further include the following steps: for each upstream service node in the stored correspondence of the downstream CDN node, perform a hash calculation on the identifier to obtain multiple first hash values ​​of the identifier.

[0178] In this case, step S803 above can be implemented as follows: generate a second hash value for the request identifier of the service request; search for a third hash value that is greater than the second hash value and closest to the second hash value in the first hash value stored in the downstream CDN node; if a third hash value is found, determine the identifier corresponding to the third hash value as the target node identifier of the upstream service node corresponding to the target service requested by the service request; if a third hash value is not found, determine the smallest recorded first hash value as the third hash value, and determine the identifier corresponding to the third hash value as the target node identifier.

[0179] In one possible implementation, the downstream CDN node 303 can subscribe to the mapping relationship stored by the central node. The data back-to-origin method applied to the downstream CDN node 303 may further include the following steps: in response to the start operation, sending a subscription request for the mapping relationship stored by the central node to the central node; obtaining the mapping relationship of the central node stored in response to the subscription request from the central node.

[0180] In this case, step S801 can be implemented as follows: update the correspondence stored in the downstream CDN nodes according to the correspondence synchronized by the central node.

[0181] Corresponding to the aforementioned data back-to-source system, this application also provides a data back-to-source method, such as... Figure 9 As shown, the method is applied to the upstream service node 301 and includes the following steps S901-S902.

[0182] Step S901: In response to the startup operation, a registration request is sent to the central node.

[0183] The registration request includes the identifier and IP address of the service node.

[0184] Step S902: In response to the IP address change of the upstream service node, report the updated IP address to the central node.

[0185] In the technical solution provided in this application, when an upstream service node starts up or its IP address changes, it reports its real-time IP address to the central node. The central node can then obtain the real-time IP address reported by the upstream service node and store the mapping between the unchanging identifier of the upstream service node and its IP address. Downstream CDN nodes can obtain the mapping between the identifiers of each upstream service node and their real-time IP addresses from the central node. Therefore, when performing data back-to-origin processing, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the mapping obtained from the central node, and perform data back-to-origin processing based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improving the hit rate of the downstream CDN node hitting the accurate upstream service node during back-to-origin processing, reducing back-to-origin processing time, and thus improving back-to-origin processing efficiency.

[0186] In one possible implementation, the identifier of the upstream service node may include: the service name provided by the service node and / or the service version provided by the service node.

[0187] Corresponding to the data back-to-source method applied to the central node described above, this application also provides a data back-to-source device, such as... Figure 10 As shown, the device, applied to the central node 302, includes:

[0188] Storage module 1001 is used to respond to the registration request of the upstream service node and store the correspondence between the identifier and IP address of the upstream service node in the central node;

[0189] The update module 1002 is used to update the IP address in the correspondence stored in the central node in response to the updated IP address reported by the upstream service node.

[0190] The first sending module 1003 is used to send the correspondence stored in the central node to the downstream CDN nodes.

[0191] In the technical solution provided in this application, when an upstream service node starts up or its IP address changes, it reports its real-time IP address to the central node. The central node can then obtain the real-time IP address reported by the upstream service node and store the mapping between the unchanging identifier of the upstream service node and its IP address. Downstream CDN nodes can obtain the mapping between the identifiers of each upstream service node and their real-time IP addresses from the central node. Therefore, when performing data back-to-origin processing, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the mapping obtained from the central node, and perform data back-to-origin processing based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improving the hit rate of the downstream CDN node hitting the accurate upstream service node during back-to-origin processing, reducing back-to-origin processing time, and thus improving back-to-origin processing efficiency.

[0192] In one possible implementation, the central node 302 can monitor the status of the upstream service node 301. The data back-to-origin device applied to the central node 302 may further include: a monitoring module, used to monitor the status of the upstream service node; if the monitored status indicates that the upstream service node has joined the CDN network, then the central node obtains the identifier and IP address of the upstream service node and stores the correspondence between the identifier and IP address of the upstream service node; if the monitored status indicates that the upstream service node has left the CDN network, then the central node deletes the correspondence between the identifier and IP address of the upstream service node stored therein; if the monitored status indicates that the IP address of the upstream service node has changed, then the central node updates the IP address in the correspondence between the identifier and IP address of the upstream service node stored therein.

[0193] In one possible implementation, the downstream CDN node 303 can subscribe to the mapping relationship stored by the central node. The data back-to-origin device applied to the central node 302 may further include: a receiving module, used to receive the subscription request for the mapping relationship stored by the central node sent by the downstream CDN node, and to send the mapping relationship already stored by the central node to the downstream CDN node in response to the subscription request.

[0194] The aforementioned first sending module 1003 can be specifically used to: after detecting a change in the correspondence stored in the central node, synchronize the changed correspondence to the downstream CDN nodes.

[0195] Corresponding to the data back-to-origin method applied to downstream CDN nodes described above, embodiments of this application also provide a data back-to-origin device, such as... Figure 11 As shown, the device, applied to downstream CDN node 303, includes:

[0196] The acquisition module 1101 is used to acquire the correspondence between the identifiers and IP addresses of the upstream service nodes stored in the central node;

[0197] The first determining module 1102 is used to determine the target node identifier of the upstream service node corresponding to the target service requested by the user in response to obtaining the user's service request for the target service.

[0198] The second determining module 1103 is used to determine the target IP address corresponding to the target node identifier based on the acquired correspondence.

[0199] The origin retrieval module 1104 is used to retrieve data from the origin based on the target IP address.

[0200] In the technical solution provided in this application, when an upstream service node starts up or its IP address changes, it reports its real-time IP address to the central node. The central node can then obtain the real-time IP address reported by the upstream service node and store the mapping between the unchanging identifier of the upstream service node and its IP address. Downstream CDN nodes can obtain the mapping between the identifiers of each upstream service node and their real-time IP addresses from the central node. Therefore, when performing data back-to-origin processing, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the mapping obtained from the central node, and perform data back-to-origin processing based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improving the hit rate of the downstream CDN node hitting the accurate upstream service node during back-to-origin processing, reducing back-to-origin processing time, and thus improving back-to-origin processing efficiency.

[0201] In one possible implementation, the data back-to-origin device applied to the downstream CDN node 303 may further include: a calculation module, used to perform a hash calculation on the identifier of each upstream service node in the stored correspondence of the downstream CDN node to obtain multiple first hash values ​​of the identifier.

[0202] The aforementioned second determining module 1103 can be specifically used to: generate a second hash value for the request identifier of the service request; search for a third hash value that is greater than the second hash value and closest to the second hash value in the first hash values ​​stored in the downstream CDN node; if a third hash value is found, determine the identifier corresponding to the third hash value as the target node identifier of the upstream service node corresponding to the target service requested by the service request; if a third hash value is not found, determine the smallest recorded first hash value as the third hash value, and determine the identifier corresponding to the third hash value as the target node identifier.

[0203] In one possible implementation, the downstream CDN node 303 can send a subscription request to the central node to subscribe to the correspondence stored by the central node. The data back-to-origin device applied to the downstream CDN node 303 may further include: a subscription module, used to send a subscription request for the correspondence stored by the central node to the central node in response to the start operation; and to obtain the correspondence of the central node's storage as fed back by the central node in response to the subscription request.

[0204] The aforementioned acquisition module 1101 can be specifically used to: update the corresponding relationship of downstream CDN node storage based on the corresponding relationship synchronized by the central node.

[0205] Corresponding to the data back-to-origin method applied to service nodes described above, embodiments of this application also provide a data back-to-origin device, such as... Figure 12 As shown, the device is applied to upstream service node 301 and includes:

[0206] The second sending module 1201 is used to send a registration request to the central node in response to the startup operation, wherein the registration request includes the identifier and IP address of the upstream service node;

[0207] The reporting module 1202 is used to report the updated IP address to the central node in response to an IP address change of the upstream service node.

[0208] In the technical solution provided in this application, when an upstream service node starts up or its IP address changes, it reports its real-time IP address to the central node. The central node can then obtain the real-time IP address reported by the upstream service node and store the mapping between the unchanging identifier of the upstream service node and its IP address. Downstream CDN nodes can obtain the mapping between the identifiers of each upstream service node and their real-time IP addresses from the central node. Therefore, when performing data back-to-origin processing, the downstream CDN node can first determine the target node identifier of the upstream service node, and then determine the target IP address corresponding to the target node identifier based on the mapping obtained from the central node, and perform data back-to-origin processing based on the target. In this way, the downstream CDN node can accurately determine the target IP address of the upstream service node, improving the hit rate of the downstream CDN node hitting the accurate upstream service node during back-to-origin processing, reducing back-to-origin processing time, and thus improving back-to-origin processing efficiency.

[0209] In one possible implementation, the identifier of the upstream service node may include: the service name provided by the upstream service node and / or the service version provided by the upstream service node.

[0210] This application embodiment also provides a network node, such as the aforementioned upstream service node, central node, or downstream CDN node, such as... Figure 13As shown, it includes a processor 1301, a communication interface 1302, a memory 1303, and a communication bus 1304. The processor 1301, the communication interface 1302, and the memory 1303 communicate with each other through the communication bus 1304.

[0211] Memory 1303 is used to store computer programs;

[0212] When the processor 1301 executes the program stored in the memory 1303, it implements any of the data retrieval methods described in the above embodiments.

[0213] The communication bus mentioned in the network nodes above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0214] The communication interface is used for communication between the aforementioned network nodes and other devices.

[0215] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0216] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0217] In another embodiment provided in this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements any of the data retrieval methods in the above embodiments.

[0218] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the data back-to-source methods described above.

[0219] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0220] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0221] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of methods, apparatus, network nodes, storage media, and computer program products are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0222] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A data backsource system, characterized by, The system comprises: an upstream service node, a center node and a downstream content distribution network (CDN) node; wherein The upstream service node is configured to: in response to a start operation, send a registration request to the center node, wherein the registration request comprises an identifier and an IP address of the upstream service node; and in response to a change of the IP address of the upstream service node, report the updated IP address to the center node. The center node is configured to: in response to the registration request, store a correspondence between the identifier and the IP address of the upstream service node in the center node; and in response to the updated IP address reported by the upstream service node, update the IP address in the correspondence stored in the center node. The downstream CDN node is configured to: obtain the correspondence stored in the center node; in response to obtaining a service request for a target service from a user, determine a target node identifier of an upstream service node corresponding to the target service requested by the service request; determine a target IP address corresponding to the target node identifier based on the obtained correspondence; and perform data back source based on the target IP address. The center node is further configured to: monitor a state of the upstream service node; if the monitored state indicates that the upstream service node joins the CDN network, obtain the identifier and the IP address of the upstream service node from the upstream service node, and store a correspondence between the identifier and the IP address of the upstream service node in the center node; if the monitored state indicates that the upstream service node exits the CDN network, delete the correspondence between the identifier and the IP address of the upstream service node stored in the center node; and if the monitored state indicates that the IP address of the upstream service node changes, update the IP address in the correspondence between the identifier and the IP address of the upstream service node stored in the center node.

2. The system of claim 1, wherein The downstream CDN node is further configured to: for each identifier of an upstream service node in the correspondence stored in the downstream CDN node, perform hash calculation on the identifier to obtain a plurality of first hash values of the identifier.

3. The system of claim 2, wherein, The determination of the target node identifier of the upstream service node corresponding to the target service requested by the service request comprises: generating a second hash value of a request identifier of the service request; finding, from the first hash values stored in the downstream CDN node, a third hash value that is closest to the second hash value and greater than the second hash value; if the third hash value is found, determining an identifier corresponding to the third hash value as the target node identifier of the upstream service node corresponding to the target service requested by the service request; if the third hash value is not found, determining a minimum first hash value recorded as the third hash value, and determining an identifier corresponding to the third hash value as the target node identifier.

4. The system of claim 1, wherein The downstream CDN node is further configured to: in response to a start operation, send a subscription request to the center node, wherein the subscription request is used to subscribe to the correspondence stored in the center node. The center node is further configured to synchronize the changed correspondence relationship to the downstream CDN node after detecting that the correspondence relationship stored by the center node is changed. The downstream CDN node is specifically configured to update the correspondence relationship stored by the downstream CDN node according to the correspondence relationship synchronized by the center node.

5. The system of any one of claims 1-4, wherein, The identifier of the upstream service node includes a service name provided by the upstream service node and / or a service version provided by the upstream service node.

6. A data backsource method, characterized by, The center node applied to the data source system in any one of claims 1-5, the method comprises: In response to the registration request of the upstream service node, storing the correspondence relationship between the identifier and the IP address of the upstream service node in the center node; In response to the upstream service node reporting the updated IP address, updating the IP address in the correspondence relationship stored in the center node; Sends the correspondence relationship stored in the center node to the downstream CDN node.

7. A data backsource method, characterized by, The downstream content distribution network CDN node applied to the data source system in any one of claims 1-5, the method comprises: Obtain the correspondence relationship between the identifier and the IP address of the upstream service node stored in the center node; In response to obtaining the service request of the target service of the user, determine the target node identifier of the upstream service node corresponding to the target service requested by the service request; Based on the correspondence relationship obtained, determine the target IP address corresponding to the target node identifier; Based on the target IP address, perform data source.

8. A data backsource method, characterized by, The upstream service node applied to the data source system in any one of claims 1-5, the method comprises: In response to the start operation, send a registration request to the center node, wherein the registration request includes the identifier and the IP address of the upstream service node; In response to the IP address change of the upstream service node, report the updated IP address to the center node.

9. A network node, characterized by: The center node comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; The memory is used to store a computer program; The processor is used to execute the program stored in the memory, and realizes the method in any one of claims 6-8.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to realize the method in any one of claims 6-8. The computer readable storage medium stores a computer program, and the computer program is executed by the processor to realize the method in any one of claims 6-8.

Images