Method for processing data request for service, and related device

Abstract

Provided in the present disclosure are a method for processing a data request for a service, and a related device, which are applied to a target node in a distributed system corresponding to the service. The method comprises: receiving a data request for the service; determining weighting information of the target node and a total request volume of the service; determining a request volume threshold of the target node according to the weighting information and the total request volume; and processing the data request on the basis of the request volume threshold.

Description

Methods and related equipment for processing data requests for services

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202410915480.8, filed on July 9, 2024, entitled "Method and Related Apparatus for Processing Data Requests for Services", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to the field of data processing technology, and in particular to a method and related equipment for processing data requests for services. Background Technology

[0004] A distributed system is a whole composed of multiple computers that work together through network connections, providing users with high-performance, high-availability, and scalable services. Summary of the Invention

[0005] In a first aspect, this disclosure provides a method for processing data requests for a service, applied to a target node in a distributed system corresponding to the service, the method comprising:

[0006] Receive data requests for the service;

[0007] Determine the weight information of the target node and the total number of requests for the service;

[0008] Based on the weight information and the total number of requests, determine the request volume threshold for the target node;

[0009] The data request is processed based on the requested volume threshold.

[0010] A second aspect of this disclosure provides an apparatus for processing data requests for a service, applied to a target node in a distributed system corresponding to the service, the apparatus comprising:

[0011] The receiving module is configured to receive data requests for the service;

[0012] The first determining module is configured to: determine the weight information of the target node and the total number of requests for the service;

[0013] The second determining module is configured to: determine the request volume threshold of the target node based on the weight information and the total number of requests;

[0014] The processing module is configured to process the data request based on the request volume threshold.

[0015] A third aspect of this disclosure provides a computer device including one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and executed by the one or more processors, the programs including instructions for performing the method according to the first aspect.

[0016] A fourth aspect of this disclosure provides a non-volatile computer-readable storage medium containing a computer program that, when executed by one or more processors, causes the processors to perform the method described in the first aspect.

[0017] A fifth aspect of this disclosure provides a computer program product including computer program instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this disclosure or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1A shows a schematic diagram of an exemplary system according to an embodiment of the present disclosure.

[0020] Figure 1B shows a schematic diagram of the rate limiting strategy under ideal conditions.

[0021] Figure 1C shows a schematic diagram of the rate limiting strategy in actual conditions.

[0022] Figure 2A shows a schematic diagram of an exemplary system provided in an embodiment of this disclosure.

[0023] Figure 2B shows a schematic diagram of another exemplary system provided by an embodiment of this disclosure.

[0024] Figure 3 shows a schematic diagram of the hardware structure of a more specific computer device provided in this embodiment.

[0025] Figure 4 shows a flowchart illustrating an exemplary method provided in an embodiment of this disclosure.

[0026] Figure 5 shows a schematic diagram of an exemplary device provided in an embodiment of this disclosure. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0028] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this disclosure should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms "first," "second," and similar terms used in the embodiments of this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0029] Figure 1A shows a schematic diagram of an exemplary system 100 according to an embodiment of the present disclosure.

[0030] As shown in Figure 1A, system 100 may include a client 102 and a server 104.

[0031] Client 102 can refer to the party that actively initiates a request and receives a service response in network communication. For example, client 102 can refer to a software or hardware entity running on a terminal device, such as an application on a personal computer, smartphone, or tablet. Client 102 can obtain the required information or services by communicating with server 104.

[0032] Server 104 can refer to a computer or software providing services in a computer network. It receives requests from client 102, processes these requests, and returns corresponding responses or data to client 102. For example, server 104 can have higher computing power and storage resources to support simultaneous connections and request processing from multiple clients 102.

[0033] In some embodiments, server 104 may include multiple physical devices (e.g., physical devices 1042-1046 in FIG1A). Physical devices 1042-1046 may be computer devices, such as hardware servers. These physical devices may be located in different geographical locations (e.g., computer rooms in different locations) and together provide various services to client 102, supporting the operation of various applications and data storage.

[0034] In some embodiments, server 104 may include a distributed system, which can be a software system built on a network that is highly cohesive and transparent. Optionally, the distributed system may include multiple nodes interconnected by a network, which collaborate to complete one or more tasks.

[0035] For example, as shown in Figure 1A, nodes 1042A, 1044A, and 1046A of the distributed system can collaborate to provide a first service, and nodes 1042B, 1044B, and 1046B of the distributed system can collaborate to provide a second service. In the Internet, a service typically refers to a function or set of functions provided to users through a network (such as the Internet) to meet their specific needs. Services on the Internet are extensive and diverse, covering various functions and application scenarios to meet the needs of different users. Some common examples of Internet services may include: search engines, social media, email services, online storage and synchronization, cloud computing services, online retail and e-commerce, video streaming services, music streaming services, online payments, instant messaging and messaging, online news and information, remote work and collaboration tools, content management systems, Internet of Things (IoT) services, and so on.

[0036] In some embodiments, if the distributed system is a distributed storage system, the nodes may also be shards or data shards.

[0037] Optionally, nodes 1042A, 1044A, and 1046A can store the same data and have the same functions. Data requests based on the first service can be processed by any one of nodes 1042A, 1044A, and 1046A. However, the volume of data requests for the first service may be large. If all data requests are distributed to the same node for processing, it may exceed the processing capacity of that node. Therefore, multiple data requests for the first service can be distributed to nodes 1042A, 1044A, and 1046A according to certain rules for processing separately. However, even so, the number of requests that nodes 1042A, 1044A, and 1046A need to process may still exceed the processing capacity of that node.

[0038] In view of this, in some embodiments, a request threshold can be set for each node to limit the flow, which can effectively protect the service from overload in scenarios with sudden traffic surges.

[0039] For example, a rate limiting threshold, LimitQPS, can be pre-defined for the distributed system. LimitQPS represents the maximum number of requests allowed per unit time and can be configured for a single instance or a cluster. For instance, when the number of requests in the distributed system exceeds LimitQPS per unit time, the rate limiting mechanism is triggered. Here, QPS refers to requests per second.

[0040] For example, taking rate limiting for the first service as an example, there are two ways to implement rate limiting mechanisms.

[0041] The first method is a centralized counting and rate limiting approach. This method can count the total real-time traffic (TotalQPS) of a distributed system within a unit of time. This TotalQPS can be calculated by a centralized counting node in the distributed system, which counts the request volume of all nodes corresponding to the first service. The counter value of the centralized counting node is the TotalQPS (total number of requests) of the first service within a unit of time.

[0042] Next, when the number of requests to the first service per unit of time exceeds LimitQPS, for example, when the actual request volume RequestQPS exceeds TotalQPS, the excess will be blocked, thus completing the rate limiting.

[0043] The second method is distributed counting and rate limiting. Assuming there are n nodes corresponding to the first service (for example, 3 in Figure 1A), each node can independently count its own request count (NodeXQPS), without considering the request counts of other nodes. The total number of requests for the first service per unit time is:

[0044] Next, when the number of requests to the first service exceeds LimitQPS within a unit of time, the rate limiting mechanism is triggered. Since request counting is performed separately on each node, rate limiting also needs to be determined separately on each node. The rate limiting condition is: NodeXQPS > TotalQPS / n

[0045] That is, the total real-time traffic TotalQPS is divided by the number of nodes n to obtain the rate limiting threshold LimitQPS for each node, and the portion of the actual request volume NodeXQPS of that node that exceeds the node rate limiting threshold LimitQPS is blocked, thereby completing the rate limiting.

[0046] However, the inventors of this disclosure have discovered that while centralized counting and rate limiting mechanisms can effectively achieve rate limiting, they can only support fewer than 50,000 requests, making them suitable only for situations with low request volumes. Distributed counting and rate limiting mechanisms, on the other hand, do not rely on centralized counting and, combined with the inherent scalability of distributed systems, theoretically can support an unlimited number of requests; however, they suffer from insufficient rate limiting effectiveness.

[0047] Specifically, because each node has different processing capabilities, its weight also differs during traffic allocation, resulting in different traffic proportions allocated to each service node. Furthermore, since the existing rate limiting strategy distributes the total request volume (TotalQPS) evenly across all nodes, when overall traffic increases, nodes with higher weights will trigger the rate limiting mechanism first, causing them to be unable to handle the requests they are capable of processing. Conversely, nodes with lower weights will have to handle more requests than their processing capacity allows.

[0048] For example, suppose the first service corresponds to 5 nodes, and the traffic weight distribution of these 5 nodes is W1:W2:W3:W4:W5=10:20:30:20:20. If the real-time total request volume TotalQPS is 1000, under the aforementioned distributed counting and rate limiting mechanism, the rate limiting threshold LimitQPS for each node is 1000 / 5=200.

[0049] As shown in Figure 1B, in an ideal state, the traffic allocated to each node is average, and the above-mentioned rate limiting mechanism can ensure that each node is effectively rate-limited.

[0050] However, as mentioned earlier, since each node has different processing capabilities, the weight of each node is also different when allocating traffic, so the proportion of traffic allocated to each service node is also different.

[0051] Therefore, based on the weight of each node, the traffic allocated to each node is as follows:

[0052] Among them, the weights of nodes 1 to 5 are W1 to W5, namely: 10, 20, 30, 20, 20.

[0053] Thus, when the total request volume (TotalQPS) = 1000, the actual traffic allocated to node 3 is 300QPS = 1000 * PS * 30 / (10 + 20 + 30 + 20 + 20). Since 300 > 200, node 3 will have 100 QPS of requests rate-limited, as shown in Figure 1C. However, this 100 QPS of requests represents the actual traffic that node 3 can handle (node ​​3's actual processing capacity).

[0054] In view of this, this disclosure provides a method for processing data requests for a service.

[0055] Figure 2A shows a schematic diagram of an exemplary system 200 provided in an embodiment of this disclosure.

[0056] As shown in Figure 2A, system 200 further includes a configuration center 202. The configuration center can be a system for centrally managing configuration information, used to store, read, and update configuration files or configuration data in a distributed system. Configuration center 202 can store configuration files or configuration datasets for convenient unified management and maintenance. Furthermore, configuration center 202 can support dynamically updating configuration files during program execution without restarting services or applications. In addition, when configuration files change, configuration center 202 can notify relevant services or applications in real time so that they can obtain the latest configuration information. In some embodiments, the configuration information includes configuration information for each node in the distributed system, such as weight information, and the total request volume (TotalQPS) for each service.

[0057] For example, client 102 may send data request 204 for the first service to server 104. After receiving data request 204, server 104 determines that data request 204 is for the first service and may distribute data request 204 among nodes 1042A to 1046A, for example, to node 1042A.

[0058] It is understandable that the number of data requests to the primary service may be very large within a certain period of time, so a rate limiting mechanism needs to be set up.

[0059] Therefore, in some embodiments, node 1042A can determine its own weight information and the total number of requests for the first service, and determine the request volume threshold of node 1042A based on the weight information and the total number of requests, and then process the data request 204 based on the request volume threshold.

[0060] In this way, the request threshold for node 1042A is determined based on the weight information and the total number of requests, making the request threshold for node 1042A related to its weight information, thereby achieving a more effective rate limiting strategy to a certain extent.

[0061] In some embodiments, the weight information of node 1042A can be obtained from the configuration center 202 of the distributed system at second time intervals.

[0062] Understandably, to implement a complete rate limiting strategy, each node needs to know its assigned request threshold (i.e., the rate limiting threshold). However, the node's weight is not fixed but dynamically changes depending on the physical device on which the node resides.

[0063] As shown in Figure 1A, since physical device 1042 can deploy multiple nodes corresponding to multiple services, for example, physical device 1042 can deploy node 1042A corresponding to a first service and node 1042B corresponding to a second service. Furthermore, the number of nodes deployed on physical device 1042 can also change dynamically. Nodes deployed on physical device 1042 will compete for the hardware resources of physical device 1042 (e.g., computing resources and input / output (I / O) resources). Therefore, the processing power of nodes deployed on physical device 1042 can change dynamically, and correspondingly, the weight information reflecting their processing power can also change dynamically, for example, dynamically according to the hardware resources of the physical device. In some embodiments, the weight information of a node can also be jointly determined based on the hardware resources of the physical device on which the node is deployed and the number of nodes for other services deployed on that physical device, thereby achieving better weight allocation.

[0064] Furthermore, as mentioned earlier, configuration center 202 can store configuration information for each node in the distributed system, such as weight information and the total QPS for each service. Moreover, configuration center 202 can support dynamic updates to configuration files (e.g., node weight information) during program execution without requiring a service or application restart.

[0065] Therefore, in this embodiment, node 1042A can obtain its weight information 206 from configuration center 202 according to the second time interval, as shown in Figure 2A.

[0066] As an optional embodiment, node 1042A can also obtain the total request volume 208 corresponding to the first service from configuration center 202 according to the second time interval. This allows it to determine the request volume threshold of node 1042A based on weight information 206 and the total request volume 208, and to determine how to process data request 204 according to this threshold. For example, if the actual request volume of node 1042A is greater than the request volume threshold, data request 204 can be temporarily stored in a message queue until the actual request volume of node 1042A is less than the request volume threshold, at which point the data request 204 is retrieved from the message queue and processed. If the actual request volume of node 1042A is less than or equal to the request volume threshold, node 1042A can process the data request 204 and return the processing result to client 102.

[0067] However, as mentioned earlier, the weight information of each node is obtained from the configuration center, and since node 1042 needs to compete for resources with other nodes on the same physical device, this weight information can change dynamically. Therefore, node 1042A cannot know its assigned weight information in real time, but can only obtain its weight information from the configuration center 202 at second time intervals.

[0068] However, the inventors of this disclosure discovered that the value of the second time interval directly affects the accuracy of rate limiting. If the value of the second time interval is set too large, the updated weight information will not be obtained in a timely manner. In other words, when the weight information is adjusted, node 1042A cannot obtain the adjusted weight information, thus leading to inaccurate rate limiting. Therefore, generally, setting the second time interval to less than or equal to 1 second can ensure relatively effective rate limiting. However, if the value of the second time interval is set too small, it will put a large query load on the configuration center 202.

[0069] In some embodiments, as shown in FIG2B, system 200 may further include service discovery 210. Service discovery refers to using a registry center to record information about all services in a distributed system, so that other services can quickly find and use these registered services by their names.

[0070] Furthermore, the inventors of this disclosure have discovered that in a distributed system, before an upstream service accesses a downstream service, it needs to obtain all node information corresponding to all downstream instances of the downstream service and the weight information corresponding to each node through service discovery 210, and then distribute traffic according to the weight information.

[0071] For example, in a live streaming service, when a user activates the live chat function, the corresponding voice service needs to be invoked. In this scenario, the upstream service can be the live streaming service, and the downstream service can be the voice service. When the live streaming service accesses the voice service, it can obtain all node information corresponding to the voice service and the weight information of each node through service discovery 104 on the server side, and then distribute traffic based on this information.

[0072] Therefore, in some embodiments, as shown in FIG2B, before accessing the first service, the client 102 can obtain information on all nodes corresponding to the first service and their weight information from the service discovery 210. When generating the data request 204, the client 102 can add the weight information of node 1042A after the data request 204 before sending it to the server 104. In this way, after receiving the data request 204, node 1042A can determine its own weight information 206 by parsing the data request 204.

[0073] In this way, the real-time weight information 206 of node 1042A can be obtained by parsing data request 204, thus eliminating the need to retrieve the weight information 206 from configuration center 202. Simultaneously, since the frequency of change in the total number of service requests is relatively low, node 1042A can retrieve the total number of requests corresponding to the first service from configuration center 202 at an even lower frequency. Therefore, in some embodiments, node 1042A can retrieve the total number of requests for the first service from the configuration center 202 of the distributed system at a first time interval. Compared to the second time interval, the first time interval can be set to be relatively large, for example, 10 to 30 seconds, thereby significantly reducing the query pressure on configuration center 202.

[0074] In some embodiments, each node may correspond to a weight value, which can be an absolute value. The weight of the node can be represented by increasing or decreasing this absolute value. This approach facilitates weight value configuration; however, it also makes the total weight value of all nodes corresponding to the service uncertain. Therefore, the weight information 206 may further include the weight value of each node and the total weight value of all nodes corresponding to the service. Accordingly, when calculating the request threshold (i.e., the rate limiting threshold) for node 1042A, the request threshold for node 1042A can be determined based on the weight value of node 1042A, the total weight value of the first service, and the total number of requests.

[0075] For example, the request volume threshold NodeLimitQPS for a node can be calculated using the following formula: NodeLimitQPS = TotalLimitQPS * WeightNodeX / TotalWeight

[0076] In this context, TotalLimitQPS is the total number of requests (TotalQPS); TotalWeight is the sum of weight values; and WeightNodeX is the weight value of the Xth node.

[0077] As can be seen from the above embodiments, the method for processing service data requests provided in this disclosure reduces rate limiting in a distributed system by combining node weights with rate limiting threshold allocation. This solves the problem of inaccurate rate limiting when using distributed counters for rate limiting in distributed systems that use weighted traffic allocation. In some embodiments, by reducing the optimization approach of obtaining weights from the configuration center by passing weight information on the call chain, the problem of inaccurate rate limiting caused by dynamic changes in node weights in a distributed environment can be greatly reduced. The optimization effect depends on the difference between the maximum and minimum weights of nodes; the larger the difference in weights between different nodes, the more obvious the optimization effect.

[0078] Based on the same inventive concept, this disclosure also provides a computer device.

[0079] Figure 3 shows a schematic diagram of the hardware structure of a more specific computer device 300 provided in this embodiment. This computer device 300 can be used to implement the scheduling node 206 of Figure 2A. In some embodiments, the computer device 300 can also be used to implement the client 202, storage system 204, master node 2042, and slave nodes 2044 and 2046 of Figure 2A. As shown in Figure 3, the computer device 300 may include: a processor 302, a memory 304, a network interface 306, a peripheral interface 308, and a bus 310. The processor 302, memory 304, network interface 306, and peripheral interface 308 are interconnected within the electronic device via the bus 310.

[0080] Processor 302 may be a central processing unit (CPU), a graphics processor, a neural network processor (NPU), a microcontroller (MCU), a programmable logic device, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or one or more integrated circuits. Processor 302 can be used to perform functions related to the techniques described in this application. In some embodiments, processor 302 may also include multiple processors integrated into a single logic component. As shown in FIG3, processor 302 may include multiple processors 302a, 302b, and 302c.

[0081] Memory 304 can be configured to store data (e.g., instruction sets, computer code, intermediate data, etc.). As shown in FIG3, the data stored in the memory may include program instructions and data to be processed. Processor 302 can also access the program instructions and data stored in the memory and execute the program instructions to operate on the data to be processed. Memory 304 may include volatile storage devices or non-volatile storage devices. In some embodiments, memory 304 may include random access memory (RAM), read-only memory (ROM), optical disk, magnetic disk, hard disk, solid-state drive (SSD), flash memory, memory stick, etc.

[0082] Network interface 306 can be configured to provide communication with other external devices to computer device 300 via a network. This network can be any wired or wireless network capable of transmitting and receiving data. For example, the network can be a wired network, a local wireless network (e.g., Bluetooth, WiFi, Near Field Communication (NFC), etc.), a cellular network, the Internet, or a combination thereof. It is understood that the type of network is not limited to the specific examples described above. In some embodiments, network interface 306 may include any combination of any number of network interface controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips, etc.

[0083] Peripheral interface 308 can be configured to connect computer device 300 to one or more peripheral devices to enable information input and output. For example, peripheral devices may include input devices such as keyboard, mouse, touchpad, touch screen, microphone, and various sensors, as well as output devices such as monitor, speaker, vibrator, and indicator lights.

[0084] Bus 310 can be configured to transfer information between various components of computer device 300 (e.g., processor 302, memory 304, network interface 306, and peripheral interface 308), such as internal buses (e.g., processor-memory bus), external buses (USB port, PCI-E bus), etc.

[0085] It should be noted that although the above host architecture only shows processor 302, memory 304, network interface 306, peripheral interface 308, and bus 310, in specific implementations, the architecture of the computer device 300 may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the architecture of the above computer device 300 may only include the components necessary for implementing the embodiments of this application, and does not necessarily include all the components shown in the figures.

[0086] Based on the same inventive concept, embodiments of this disclosure also provide a method for processing data requests for services.

[0087] Figure 4 shows a flowchart of an exemplary method 400 provided in an embodiment of this disclosure. The method 400 can be implemented by nodes 1042A to 1046A, nodes 1042B to 1046B of Figures 2A and 2B, or by system 200, or by computer device 300 of Figure 3, and may further include the following steps.

[0088] In step 402, a data request for the service (e.g., the first service) is received (e.g., data request 204 of Figure 2A or Figure 2B).

[0089] In step 404, the weight information of the target node (e.g., node 1042A in Figure 2A or Figure 2B) (e.g., weight information 206 in Figure 2A or Figure 2B) and the total number of requests for the service (e.g., total number of requests 208 in Figure 2A or Figure 2B) are determined.

[0090] In step 406, the request threshold of the target node is determined based on the weight information and the total number of requests.

[0091] In step 408, the data request is processed based on the request volume threshold.

[0092] The method for processing data requests for services disclosed herein determines the request threshold of a node based on weight information and the total number of requests, such that the request threshold of a node is related to its weight information, thereby achieving a more effective rate limiting strategy to a certain extent.

[0093] In some embodiments, the data request (e.g., data request 204 in FIG2B) includes the weight information of the target node;

[0094] Determining the weight information of the target node includes:

[0095] The data request is parsed to determine the weight information of the target node.

[0096] In this way, there is no need to obtain weight information from configuration center 202, reducing the query volume of configuration center 202.

[0097] In some embodiments, determining the total number of requests for the service includes: obtaining the total number of requests for the service from the configuration center of the distributed system at first time intervals, thereby obtaining a more accurate total number of requests and ensuring more effective rate limiting.

[0098] Optionally, provided that the weight information is obtained from the data request, the first time interval is 10 to 30 seconds, which can reduce the query volume of the configuration center 202 and at the same time ensure relatively effective rate limiting.

[0099] In some embodiments, determining the weight information of the target node includes: obtaining the weight information of the target node from the configuration center of the distributed system at a second time interval, thereby obtaining more accurate weight information and ensuring more effective rate limiting. Optionally, the second time interval is less than or equal to 1 second, thereby obtaining more accurate weight information and ensuring more effective rate limiting.

[0100] In some embodiments, the service corresponds to multiple nodes of the distributed system (e.g., nodes 1042A to 1046A in Figure 2A or Figure 2B), the multiple nodes are deployed in different physical devices (e.g., physical devices 1042 to 1046 in Figure 2A or Figure 2B), each node corresponds to a weight value, and the weight information includes the weight value of each node and the sum of the weight values ​​of the multiple nodes;

[0101] Determining the request volume threshold of the target node based on the weight information and the total number of requests includes: determining the request volume threshold of the target node based on the weight value of the target node, the sum of the weight values, and the total number of requests.

[0102] In this way, while ensuring that the weight value can be adjusted relatively easily, the request volume threshold can be calculated relatively accurately.

[0103] In some embodiments, the physical device is used to deploy multiple nodes of multiple services (e.g., physical device 1042 of Figure 2A or Figure 2B deploys nodes 1042A and 1042B); the weight information of the target node is determined according to the hardware resources of the physical device on which the target node is deployed, so that the weight information matches the processing capability of the node, ensuring that the system operates more stably.

[0104] In some embodiments, the weight information of the target node is determined based on the hardware resources of the physical device on which the target node is deployed and the number of nodes of other services deployed on the physical device, thereby achieving better weight allocation.

[0105] In some embodiments, the data request comes from an upstream service of the service, and the upstream service obtains the weight information from the service discovery of the distributed system. By passing weight information on the call chain, the optimization approach of obtaining weight from the configuration center is reduced, which can greatly reduce the problem of inaccurate rate limiting caused by dynamic changes in node weights in the distributed environment. The optimization effect depends on the difference between the maximum and minimum weights of the nodes. The larger the difference in weights between different nodes, the more obvious the optimization effect.

[0106] It should be noted that the method of this disclosure embodiment can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of this disclosure embodiment, and the multiple devices will interact with each other to complete the method described.

[0107] It should be noted that the above description describes some embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0108] Based on the same inventive concept, corresponding to any of the methods in the above embodiments, this disclosure also provides an apparatus for processing data requests for services. Figure 5 shows a schematic diagram of an exemplary apparatus 500 provided in an embodiment of this disclosure.

[0109] Referring to Figure 5, the device 500 includes:

[0110] The receiving module 502 is configured to receive data requests for the service;

[0111] The first determining module 504 is configured to: determine the weight information of the target node and the total number of requests for the service;

[0112] The second determining module 506 is configured to: determine the request volume threshold of the target node based on the weight information and the total number of requests;

[0113] The processing module 508 is configured to process the data request based on the request volume threshold.

[0114] In some embodiments, the data request includes weight information of the target node; the first determining module 504 is configured to: parse the data request to determine the weight information of the target node.

[0115] In some embodiments, the first determining module 504 is configured to: obtain the total number of service requests from the configuration center of the distributed system at a first time interval.

[0116] In some embodiments, the first determining module 504 is configured to: obtain the weight information of the target node from the configuration center of the distributed system at a second time interval.

[0117] In some embodiments, the service corresponds to multiple nodes in the distributed system, the multiple nodes are deployed in different physical devices, each node corresponds to a weight value, and the weight information includes the weight value of each node and the sum of the weight values ​​of the multiple nodes;

[0118] The second determining module 506 is configured to: determine the request volume threshold of the target node based on the weight value of the target node, the sum of the weight values, and the total number of requests.

[0119] In some embodiments, the physical device is used to deploy multiple nodes of multiple services; the weight information of the target node is determined based on the hardware resources of the physical device on which the target node is deployed.

[0120] In some embodiments, the weight information of the target node is determined based on the hardware resources of the physical device on which the target node is deployed and the number of nodes of other services deployed on the physical device.

[0121] In some embodiments, the data request originates from an upstream service of the service, and the upstream service obtains the weight information from the service discovery of the distributed system.

[0122] In some embodiments, the first time interval is 10 to 30 seconds.

[0123] In some embodiments, the second time interval is less than or equal to 1 second.

[0124] For ease of description, the above apparatus is described in terms of its functions, divided into various modules. Of course, in implementing this disclosure, the functions of each module can be implemented in one or more software and / or hardware.

[0125] The apparatus of the above embodiments is used to implement the corresponding method 400 in any of the foregoing embodiments and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0126] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method 400 as described in any of the above embodiments.

[0127] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0128] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to perform the method 400 as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0129] Based on the same inventive concept, corresponding to the method 400 of any of the above embodiments, this disclosure also provides a computer program product, which includes a computer program. In some embodiments, the computer program is executable by one or more processors to cause the processors to perform the method 400. Corresponding to the execution entity for each step in each embodiment of method 400, the processor executing the corresponding step may belong to the corresponding execution entity.

[0130] The computer program product of the above embodiments is used to cause the processor to execute the method 400 as described in any of the above embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0131] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the framework of this disclosure, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this disclosure as described above, which are not provided in detail for the sake of brevity.

[0132] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this disclosure, the provided drawings may or may not show well-known power / ground connections to integrated circuit (IC) chips and other components. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this disclosure, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this disclosure will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuitry) have been set forth to describe exemplary embodiments of this disclosure, it will be apparent to those skilled in the art that the embodiments of this disclosure may be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0133] Although this disclosure has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0134] This disclosure is intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

A method for processing data requests for a service, applied to a target node in a distributed system corresponding to the service, the method comprising: Receive data requests for the service; Determine the weight information of the target node and the total number of requests for the service; Based on the weight information and the total number of requests, determine the request volume threshold for the target node; The data request is processed based on the requested volume threshold. The method as described in claim 1, wherein, The data request includes the weight information of the target node; Determining the weight information of the target node includes: The data request is parsed to determine the weight information of the target node. The method as described in claim 2, wherein, Determining the total number of requests for the service includes: The total number of service requests is obtained from the configuration center of the distributed system at a first time interval. The method as described in claim 1, wherein, Determining the weight information of the target node includes: The weight information of the target node is obtained from the configuration center of the distributed system at the second time interval. The method as described in any one of claims 1 to 4, wherein, The service corresponds to multiple nodes in the distributed system. These multiple nodes are deployed on different devices. Each node corresponds to a weight value. The weight information includes the weight value of each node and the sum of the weight values ​​of the multiple nodes. Based on the weight information and the total number of requests, the request volume threshold for the target node is determined, including: The request threshold for the target node is determined based on the weight value of the target node, the sum of the weight values, and the total number of requests. The method of claim 5, wherein, The device is used to deploy multiple nodes for multiple services; The weight information of the target node is determined based on the hardware resources of the device deployed on the target node. The method of claim 6, wherein, The weight information of the target node is determined based on the hardware resources of the device on which the target node is deployed and the number of nodes of other services deployed on the device. The method as described in claim 2, wherein, The data request originates from an upstream service of the service, and the upstream service obtains the weight information from the service discovery of the distributed system. The method as described in claim 3, wherein, The first time interval is 10 to 30 seconds. The method as described in claim 4, wherein, The second time interval is less than or equal to 1 second. An apparatus for processing data requests for a service, applied to a target node in a distributed system corresponding to the service, the apparatus comprising: The receiving module is configured to receive data requests for the service; The first determining module is configured to: determine the weight information of the target node and the total number of requests for the service; The second determining module is configured to: determine the request volume threshold of the target node based on the weight information and the total number of requests; The processing module is configured to process the data request based on the request volume threshold. A computer device includes one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and executed by the one or more processors, the programs including instructions for performing the method according to any one of claims 1 to 10. A non-volatile computer-readable storage medium containing a computer program, which, when executed by one or more processors, causes the processors to perform the method of any one of claims 1 to 10. A computer program product includes computer program instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 10.

Images