A method, apparatus, device, and storage medium for request allocation

Abstract

This specification discloses a method, apparatus, device, and storage medium for request allocation. Through an allocation process in two stages, the service call requests of the target calling end can be allocated to the responding ends. Among them, in the first-stage allocation, the service call requests allocated to the responding ends deployed locally in the node device can be determined first. On the basis of ensuring that the responding ends deployed locally in the node device are preferably allocated first, through the second-stage allocation, according to the number of specified calling ends deployed in other node devices where each other responding end is located, it is determined how to allocate the remaining service call requests to other responding ends, so as to achieve the reasonable allocation of each service call request to each responding end.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and particularly to a method, apparatus, device, and storage medium for allocating requests. Background Art

[0002] With the gradual development of Internet technology, the microservices architecture, as a commonly used distributed architecture, has been widely adopted in the process of application service development due to its high availability. In the microservices architecture, an application service can be split into a group of small services (i.e., microservices), and these small services can coordinate and call each other to provide services for users. For example: the application service for user shopping can be split into services such as search and recommendation service, product browsing service, customer service, order management service, etc. Among them, the search and recommendation service can send a service call request to the product browsing service, and display the detailed information of the product for the user through the product browsing service.

[0003] In a distributed system adopting the microservices architecture, there are multiple node devices. The system can deploy each of the above microservices to these node devices to jointly provide services for users through these node devices, thereby enhancing the availability of the system. Among them, the same microservice can be deployed in multiple node devices. For any microservice deployed in a node device, when this microservice initiates a service call request, this microservice is the calling end. Similarly, when this microservice responds to a service call request, this microservice is the responding end. In other words, when a microservice needs to call other microservices, this microservice is the calling end, and when this microservice is called by other microservices, this microservice is the responding end.

[0004] However, currently, the various service call requests generated by the calling end cannot be reasonably allocated to the responding end that can provide the called data to the calling end. Summary of the Invention

[0005] This specification provides a method, apparatus, device, and storage medium for allocating requests to partially solve the problems existing in the prior art.

[0006] This specification adopts the following technical solutions:

[0007] This specification provides a method for allocating requests. The method is applied to a node device and includes:

[0008] Obtain each service call request sent by a target calling end deployed on the node device itself;

[0009] Determine at least some of the service call requests from the various service call requests and allocate them to the responder deployed locally in the node device for providing the called data to the target caller;

[0010] For other responders deployed in other node devices, determine the allocation weight for allocating service call requests to the other responders according to the number of specified callers included in the node device where the other responders are located, and use it as the corresponding allocation weight for the other responders. The other responders are used to provide the called data to the target caller, and the specified caller is used to retrieve data from the other responders;

[0011] Allocate the remaining service call requests to the other responders according to the allocation weight corresponding to the other responders.

[0012] Optionally, determining at least some of the service call requests from the various service call requests and allocating them to the local responder specifically includes:

[0013] Determine a first set of responders for providing the called data to the target caller from each node device, and determine a second set of callers for retrieving data from the responders included in the first set from each node device;

[0014] Determine the probability of allocating each service call request to the responder deployed locally in the node device for providing the called data to the target caller according to the number of responders included in the first set and the number of callers included in the second set;

[0015] Determine at least some of the service call requests from the various service call requests and allocate them to the responder deployed locally in the node device for providing the called data to the target caller according to the probability.

[0016] Optionally, for other responders deployed in other node devices, determining the allocation weight for allocating service call requests to the other responders according to the number of specified callers included in the node device where the other responders are located, and using it as the corresponding allocation weight for the other responders specifically includes:

[0017] Determine a first set of responders for providing the called data to the target caller from each node device, and determine a second set of callers for retrieving data from the responders included in the first set from each node device;

[0018] For other responder ends deployed in other node devices, the number of specified caller ends included in the node device where the other responder end is located, the number of responder ends included in the first set, and the number of caller ends included in the second set are input into a pre-trained weight determination model, so as to determine, through the determination model, the allocation weight for allocating service call requests to the other responder end.

[0019] Optionally, training the weight determination model specifically includes:

[0020] Obtain each sample call request, and determine a first responder end and a second responder end for providing called data to the target caller end. The number of specified caller ends included in the node device where the first responder end is located is different from the number of specified caller ends included in the node device where the second responder end is located;

[0021] Input the number of specified caller ends included in the node device where the first responder end is located, the number of responder ends included in the first set, and the number of caller ends included in the second set into the weight determination model, so as to determine, through the weight determination model, the allocation weight for allocating the sample call request to the first responder end; and

[0022] Input the number of specified caller ends included in the node device where the second responder end is located, the number of responder ends included in the first set, and the number of caller ends included in the second set into the weight determination model, so as to determine, through the weight determination model, the allocation weight for allocating the sample call request to the second responder end;

[0023] According to the allocation weight for allocating service call requests to the first responder end and the allocation weight for allocating service call requests to the second responder end, determine the number of sample call requests allocated to the first responder end and the number of sample call requests allocated to the second responder end among each sample call request;

[0024] Taking minimizing the difference between the number of sample call requests allocated to the first responder end and the number of sample call requests allocated to the second responder end as the optimization objective, train the weight determination model.

[0025] Optionally, for other responder ends deployed in other node devices, according to the number of specified caller ends included in the node device where the other responder end is located, determine the allocation weight for allocating service call requests to the other responder end as the allocation weight corresponding to the other responder end, specifically including:

[0026] Select any two other responder ends from the other responder ends deployed in other node devices;

[0027] For each selected other responder, determine an allocation weight for allocating a service call request to the other responder according to the number of specified callers included in the node device where the other responder is located.

[0028] This specification provides a request allocation device, which is applied to a node device and includes:

[0029] An acquisition module, configured to acquire each service call request sent by a target caller deployed in the node device itself;

[0030] A first allocation module, configured to determine at least some of the service call requests from the service call requests and allocate them to responders deployed locally in the node device for providing called data to the target caller;

[0031] A determination module, configured to, for other responders deployed in each other node device, determine an allocation weight for allocating a service call request to the other responder according to the number of specified callers included in the node device where the other responder is located, and use it as the allocation weight corresponding to the other responder. The other responder is used to provide called data to the target caller, and the specified caller is used to retrieve data from the other responder;

[0032] A second allocation module, configured to allocate the remaining service call requests to the other responders according to the allocation weight corresponding to the other responders.

[0033] Optionally, the first allocation module is specifically configured to determine a first set of responders for providing called data to the target caller from each node device, and determine a second set of callers for retrieving data from the responders included in the first set from each node device; determine the probability of allocating each service call request to a responder deployed locally in the node device for providing called data to the target caller according to the number of responders included in the first set and the number of callers included in the second set; and determine at least some of the service call requests from the service call requests according to the probability and allocate them to the responders deployed locally in the node device for providing called data to the target caller.

[0034] Optionally, the determining module is specifically configured to determine, from each node device, a first set of responder ends for providing called data to the target calling end, and determine, from each node device, a second set of calling ends for retrieving data from the responder ends included in the first set; for other responder ends deployed in other node devices, input the number of specified calling ends included in the node device where the other responder end is located, the number of responder ends included in the first set, and the number of calling ends included in the second set into a pre-trained weight determination model, so as to determine, by the determination model, the allocation weight for allocating service call requests to the other responder ends.

[0035] This specification provides a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, the above-mentioned request allocation method is implemented.

[0036] This specification provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the above-mentioned request allocation method is implemented.

[0037] The above at least one technical solution adopted in this specification can achieve the following beneficial effects:

[0038] In the request allocation method provided in this specification, first, each service call request sent by the target calling end deployed in the node device itself is obtained, and at least some of the service call requests are determined to be allocated to the responder ends deployed locally in the node device for providing called data to the target calling end. For other responder ends deployed in other node devices, according to the number of specified calling ends included in the node device where the other responder end is located, the allocation weight for allocating service call requests to the other responder ends is determined as the corresponding allocation weight of the other responder end. The other responder ends are used to provide called data to the target calling end, and the specified calling ends are used to retrieve data from the other responder ends. According to the corresponding allocation weight of the other responder ends, the remaining service call requests are allocated to the other responder ends.

[0039] It can be seen from the above method that the service call requests of the target calling end can be allocated to the responder ends through a two-stage allocation process. Among them, in the first-stage allocation, the service call requests allocated to the responder ends deployed locally in the node device can be determined first. On the basis of ensuring that the responder ends deployed locally in the node device are preferentially allocated as much as possible, through the second-stage allocation, according to the number of specified calling ends deployed in the other node devices where each other responder end is located, it is determined how to allocate the remaining service call requests to the other responder ends, so as to realize the reasonable allocation of each service call request to each responder end. Description of the Drawings

[0040] The accompanying drawings described herein are used to provide a further understanding of the present specification and form a part of the present specification. The illustrative embodiments of the present specification and their descriptions are used to explain the present specification and do not constitute an improper limitation of the present specification. In the accompanying

[0041] In the figures:

[0042] Figure 1 is a schematic flow chart of a method for allocating a request provided in the present specification;

[0043] Figure 2 is a schematic diagram of a two-stage allocation service call request provided in the present specification;

[0044] Figure 3 is a schematic diagram of a device for allocating a request provided in the present specification;

[0045] Figure 4 is a schematic diagram of an electronic device corresponding to Figure 1 provided in the present specification. Detailed Description of the Preferred Embodiments

[0046] To make the objectives, technical solutions, and advantages of the present specification clearer, the technical solutions of the present specification will be clearly and completely described below in conjunction with the specific embodiments of the present specification and the corresponding accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present specification, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present specification without creative efforts shall fall within the scope of protection of the present specification.

[0047] The following will detail the technical solutions provided in each embodiment of the present specification with reference to the accompanying drawings.

[0048] Figure 1 is a schematic flow chart of a method for allocating a request provided in the present specification, including the following steps:

[0049] S100: Obtain each service call request sent by the target call end deployed by the node device itself.

[0050] In the present specification, the service platform may allocate the service call requests of each call end deployed in each node device (i.e., physical device) of the distributed system to each response end deployed in each node device of the distributed system. Before that, the service platform may, for any one of the node devices deployed with a call end, use the call end deployed by the node device itself as the target call end, and then may obtain each service call request sent by the target call end.

[0051] The above-mentioned distributed system refers to a system that adopts a microservices architecture. After splitting an application service into multiple microservices, it is composed of each microservice deployed in different node devices. Among them, for any microservice deployed in a node device, when this microservice initiates a business call request, this microservice is the calling end. Similarly, when this microservice responds to a business call request, this microservice is the responding end. Here, the microservice is deployed to the node device by deploying a container instance (such as a Docker container) obtained by encapsulating the code for implementing the specified function of the microservice, so as to realize the deployment of the microservice to the node device, and each container instance is a calling end or a responding end.

[0052] It can be seen from the above content that the code corresponding to the same microservice can be deployed in different node devices. It can be understood that this microservice can have multiple clones (that is, container instances obtained by encapsulating the code for implementing the specified function of the microservice), and each clone has the same function. These clones can be deployed in different node devices. When this microservice needs to call other microservices, it can initiate a call request to the clone (i.e., a calling end) of other microservices deployed in any one node device through the clone (i.e., a calling end) deployed in any one node device.

[0053] It should be noted that in a distributed system, the purpose of deploying the same microservice to different node devices is to make more reasonable use of the computing resources of each node device. For example: Suppose there are two node devices A and B. At a certain point in time, the responding end deployed in node device A (i.e., the microservice for responding to business call requests) may be processing a large number of business call requests, resulting in a relatively high occupancy rate of the computing resources of node device A. And at this time, the responding end deployed in node device B may not be assigned business call requests to be processed. In order to reduce the occupancy rate of the computing resources of node device A, a part of the business call requests can be sent to the responding end deployed in node device B, so as to avoid waste caused by the idle computing resources of node device B. Therefore, the same microservice is usually deployed on different node devices so that when this microservice responds to the business call requests of other microservices, the microservices deployed on different node devices can jointly process the business call requests of other microservices.

[0054] In this specification, the execution subject for implementing the request allocation method can be an allocation component module for allocating business call requests in the node device where the target calling end is deployed in a distributed system. For the sake of convenience of description, the following takes the allocation module as the execution subject as an example to illustrate the request allocation method provided in this specification.

[0055] S102: Determine at least some of the service invocation requests from the various service invocation requests and allocate them to the responder deployed locally on the node device where the target invoker is located for providing the invoked data to the target invoker.

[0056] Further, the allocation module may determine a first set of responders for providing the invoked data to the target invoker from each node device, and determine a second set of invokers for retrieving data from the responders included in the first set from each node device.

[0057] Furthermore, based on the number of responders included in the first set and the number of invokers included in the second set, determine the probability of allocating each service invocation request to the responder deployed locally on the node device for providing the invoked data to the target invoker, and based on the determined probability, determine at least some of the service invocation requests from the various service invocation requests and allocate them to the responder deployed locally on the node device for providing the invoked data to the target invoker. Among them, the determination of the probability can refer to the following formula:

[0058]

[0059] In the above formula, Affinity Weight represents the determined probability, M represents the number of invokers included in the second set, N represents the number of responders included in the first set, and n represents the number of responders deployed on the node device where the target invoker is located for providing the invoked data to the target invoker.

[0060] When the allocation module determines the probability of allocating each service invocation request to the responder deployed locally on the node device where the target invoker is located for providing the invoked data to the target invoker, it can be divided into two cases. The first case is when n is not 0, and the second case is when n is 0. When n is not 0, it means that there is a responder deployed on the node device where the target invoker is located for providing the invoked data to the target invoker. Therefore, considering the priority of allocating the service invocation requests of the target invoker to the responder deployed locally on the node device where the target invoker is located for providing the invoked data to the target invoker, it can be through to determine the above probability, where represents taking the minimum value of 1 or as the above probability. Among them, 1 is set according to the actual situation, that is, the determined probability is between 0 and 1 and cannot be higher than 1, The value of may be greater than 1. Therefore, when the determined value is greater than 1, it is considered that the determined probability is 1. In other words, the determined probability is the minimum value of 1 and these two values.

[0061] When n is 0, it indicates that there is no responder deployed in the node device where the target calling end is located to provide the called data to the target calling end. Therefore, for the target calling end, the probability of allocating each service call request to the responder deployed locally in the node device where the target calling end is located to provide the called data to the target calling end is 0.

[0062] It can be seen from the above formula that the allocation module can determine the probability of allocating each service call request of the target calling end to the responder deployed locally in the node device where the target calling end is located to provide the called data to the target calling end according to the number of responders included in the first set and the number of calling ends in the second set.

[0063] Furthermore, after determining the probability of allocating each service call request of the target calling end to the responder deployed locally in the node device where the target calling end is located to provide the called data to the target calling end, the allocation module can allocate at least some of the service call requests of the target calling end to the responder deployed locally in the node device where the target calling end is located to provide the called data to the target calling end according to the determined probability.

[0064] Among them, the way for the allocation module to allocate at least some of the service call requests of the target calling end to the responder deployed locally in the node device where the target calling end is located to provide the called data to the target calling end according to the determined probability can be to generate a random number corresponding to each service call request (the value range of the random number is between 0 and 1), which is represented by k. Compare this random number k with the above probability. If the random number k is less than the above probability, it is determined that the service call request corresponding to the random number k is allocated to the responder deployed locally in the node device where the target calling end is located to provide the called data to the target calling end. For example: Suppose the probability of allocating the service call request to the responder deployed locally in the node device where the target calling end is located to provide the called data to the target calling end is 0.6. If the generated random number k is 0.4, the service call request corresponding to 0.4 can be allocated to the responder deployed locally in the node device where the target calling end is located to provide the called data to the target calling end. If the generated random number k is 0.8, the service call request needs to be allocated to other responders.

[0065] S104: For other responder deployed in each other node device, determine the allocation weight for allocating the service call request to the other responder according to the number of specified callers included in the node device where the other responder is located, as the allocation weight corresponding to the other responder. The other responder is used to provide the called data to the target caller, and the specified caller is used to retrieve data from the other responder.

[0066] As can be seen from the above, the allocation module can, according to the probability determined by the above method, allocate at least part of the service call requests of the target caller to the responder deployed locally in the node device where the target caller is located and used to provide the called data to the target caller. For the remaining service call requests, the allocation module can allocate them to the other responders deployed in each other node device.

[0067] Before this, the allocation module needs to, for each other responder, determine the allocation weight corresponding to the responder according to the number of specified callers deployed in the node device where the other responder is located, and then can, according to the allocation weight, allocate the remaining service call requests to the other responders. Here, the specified caller refers to the caller deployed in the node device where the other responder is located and used to retrieve the service call request from the other responder.

[0068] It should be noted that each caller deployed in each node device of the distributed system will allocate its own service call request through the above method (that is, each caller will allocate a part of its own service call request to the responder deployed on the same node device as itself in the first stage). However, since the number of specified callers in the node device where each responder deployed on each node device of the distributed system is different (that is, there is no caller deployed in the node device where some responders are located, and these responders are not allocated service call requests in the allocation process of the first stage), it may cause some responders to be allocated service call requests in the allocation process of the first stage, while some responders are not allocated service call requests.

[0069] Based on this, in order to make the number of service call requests allocated to each responder deployed in each node device of the distributed system as balanced as possible, the allocation module can, through a preset calculation formula, determine the allocation weight corresponding to each other responder according to the number of callers in the node device where each other responder is located, the number of responders included in the first set, and the number of callers included in the second set.

[0070] However, since a distributed system can continuously adjust the number of container instances corresponding to each microservice in the distributed system (i.e., the number of callers or responders) according to actual requirements. Therefore, the number of responders included in the first set and the number of callers included in the second set determined at different times will change. So, when determining the allocation weight corresponding to each other responder based on the number of specified callers included in the node device where each other responder is located, the number of responders included in the first set, and the number of callers included in the second set, it is necessary to consider the impact of the changes in the number of responders included in the first set and the number of callers included in the second set on the finally determined allocation weight.

[0071] Based on this, in order to improve the accuracy of the determined allocation weight, the allocation module can input the number of specified callers included in the node device where each other responder is located, the number of responders included in the first set, and the number of callers included in the second set into a pre-trained weight determination model for each other responder deployed in each other node device, so as to determine the allocation weight for allocating the service call request to this other responder through the weight determination model.

[0072] Among them, the training method of the above weight determination model can be to obtain each sample call request, and determine the first responder and the second responder for providing the called data to the target caller. The number of specified callers included in the node device where the first responder is located is different from the number of specified callers included in the node device where the second responder is located.

[0073] Furthermore, the number of specified callers included in the node device where the first responder is located, the number of responders included in the first set, and the number of callers included in the second set can be input into the weight determination model, so as to determine the allocation weight for allocating the sample call request to the first responder through the weight determination model. And the number of specified callers included in the node device where the second responder is located, the number of responders included in the first set, and the number of callers included in the second set can be input into the weight determination model, so as to determine the allocation weight for allocating the sample call request to the second responder through the weight determination model.

[0074] Thus, according to the allocation weight for allocating the service call request to the first responder and the allocation weight for allocating the service call request to the second responder, the number of sample call requests allocated to the first responder and the number of sample call requests allocated to the second responder among each sample call request can be determined. Taking minimizing the difference between the number of sample call requests allocated to the first responder and the number of sample call requests allocated to the second responder as the optimization goal, the weight determination model is trained.

[0075] In the above content, the number of calling ends in the node device where the first response end is located is different from the number of specified calling ends included in the node device where the second response end is located. Preferably, the number of specified calling ends included in the node device where the first response end is located is not zero, while the number of specified calling ends included in the node device where the second response end is located is zero.

[0076] It should be noted that the above sample call requests may refer to all service call requests of each calling end deployed in each node device of the distributed system. The determined number of sample call requests allocated to the first response end and the number of sample call requests allocated to the second response end may refer to that each calling end deployed in each node device of the distributed system is used as the target calling end, and after determining at least part of the service call requests from the sample call requests of each calling end and allocating them, and then allocating the remaining sample call requests according to the determined allocation weights, the number of sample call requests allocated to the first response end and the number of sample call requests allocated to the second response end during the two allocations of each calling end are determined.

[0077] In the above training process, preferably, the first response end and the second response end are the first response end with the number of specified calling ends included in the node device where it is located not being zero and the second response end with the number of specified calling ends included in the node device where it is located being zero. Through the above training process, after allocating each service call request to each response end according to the determined allocation weights, the number of service call requests allocated to the first response end with the number of specified calling ends included in the node device where it is located not being zero and the second response end with the number of specified calling ends included in the node device where it is located being zero are also as close as possible, so as to achieve load balancing of each response end deployed in each node device of the distributed system through the two-stage allocation process.

[0078] Furthermore, in order to improve the accuracy of the allocation weights determined by the above weight model, the distributed system can also use the number of response ends included in the node device where the other response end is located as an input to increase the parameter space for weight model fitting. Specifically, the distributed system can input the number of specified calling ends included in the node device where the other response end is located, the number of response ends included in the first set, the number of calling ends included in the second set, and the number of response ends included in the node device where the other response end is located into the pre-trained weight determination model to determine the allocation weights for allocating service call requests to the other response end through the weight determination model.

[0079] In addition, it can be seen from the above that when allocating the remaining service call requests to each other responder, it is necessary to determine the allocation weight of each other responder. Moreover, since the number of responders included in the first set and the number of callers included in the second set will change, therefore, when allocating the remaining service call requests for the target caller each time, it is necessary to re-determine the allocation weight, which affects the allocation efficiency of the service call requests.

[0080] Based on this, the allocation module can also select any two other responders from the other responders deployed in each other node device. For each selected other responder, according to the number of callers included in the node device where the other responder is located, determine the allocation weight for allocating service call requests to this other responder, and then, according to the determined allocation weight, allocate the remaining service call requests to these two other responders.

[0081] S106: Allocate the remaining service call requests to the other responders according to the allocation weight corresponding to the other responders.

[0082] The allocation module can allocate the remaining service call requests to the other responders according to the allocation weight corresponding to each other responder.

[0083] Among them, the allocation method can be to directly allocate the remaining service call requests to the other responder with a higher allocation weight. In addition, the distributed system can also allocate each of the remaining service call requests to each other responder according to the allocation weight of each other responder.

[0084] To illustrate the above content in detail, this specification also provides a schematic diagram of allocating service call requests by the above method, as Figure 2 shown.

[0085] Figure 2 This is a schematic diagram of allocating service call requests in two stages provided in this specification.

[0086] From Figure 2It can be seen that when allocating the service call requests of the target calling end, the probability of allocating each service call request of the target calling end to the responder deployed locally in the node device where the target calling end is located for providing the called data to the target calling end can be determined through the first-stage allocation, and at least some of the service call requests among the service call requests can be allocated to the responder deployed locally in the node device where the target calling end is located for providing the called data to the target calling end according to the determined probability. For the remaining service call requests, two other responders can be randomly selected from the other responders deployed in each other node device through the second-stage allocation, and then the allocation weight corresponding to each of the two other responders can be determined through the weight determination model, and then the remaining service call requests can be allocated to these two other responders according to the determined allocation weights.

[0087] It can be seen from the above content that the allocation module can allocate the service call requests of the target calling end to the responders through a two-stage allocation process. Among them, in the first-stage allocation, the partial service call requests allocated to the responder deployed locally in the node device for providing the called data to the target calling end can be determined first. On the basis of ensuring that the allocation is preferably made to the responder deployed locally in the node device where the target calling end is located for providing the called data to the target calling end, through the second-stage allocation, the remaining service call requests are allocated to each other responder according to the number of specified calling ends included in the other node device where each other responder is located.

[0088] In addition, for the calling end, when the responder that the calling end needs to access is in the same node device as the calling end, the service call request sent by the calling end to the responder does not need to be transmitted through remote communication, so the processing efficiency of the service call request is relatively high. However, when there are more requests that need to be processed by the responder, in order to avoid the excessive occupancy rate of the computing resources of a node device, other responders on different node devices from the calling end need to be used to process the call service request, so the service call request needs to be sent to other responders through remote communication, which reduces the processing efficiency of the service call request.

[0089] Therefore, since the allocation module can preferably allocate to the responder deployed locally in the node device where the target calling end is located for providing the called data to the target calling end, the problem of reduced processing efficiency of the service call request caused by remote communication can be avoided.

[0090] The above is the method for allocating requests provided by one or more embodiments of this specification. Based on the same concept, this specification also provides a corresponding device for allocating requests, as Figure 3 shown.

[0091] Figure 3 is a schematic diagram of a device for allocating requests provided by this specification, including:

[0092] An obtaining module 301, configured to obtain each service call request sent by a target calling end deployed by the node device itself;

[0093] A first allocation module 302, configured to determine at least some of the service call requests from the service call requests and allocate them to a responder deployed locally in the node device for providing called data to the target calling end;

[0094] A determining module 303, configured to, for other responders deployed in each other node device, determine an allocation weight for allocating service call requests to the other responders according to the number of specified calling ends included in the node device where the other responders are located, as the allocation weight corresponding to the other responders, where the other responders are used to provide called data to the target calling end, and the specified calling end is used to retrieve data from the other responders;

[0095] A second allocation module 304, configured to allocate the remaining service call requests to the other responders according to the allocation weight corresponding to the other responders.

[0096] Optionally, the first allocation module 302 is specifically configured to determine a first set of responders for providing called data to the target calling end from each node device, and determine a second set of calling ends for retrieving data from the responders included in the first set from each node device; determine the probability of allocating each service call request to a responder deployed locally in the node device for providing called data to the target calling end according to the number of responders included in the first set and the number of calling ends included in the second set; and determine at least some of the service call requests from the service call requests and allocate them to a responder deployed locally in the node device for providing called data to the target calling end according to the probability.

[0097] Optionally, the determining module 303 is specifically configured to determine, from each node device, a first set of responder ends for providing called data to the target calling end, and determine, from each node device, a second set of calling ends for retrieving data from the responder ends included in the first set; for other responder ends deployed in other node devices, input the number of specified calling ends included in the node device where the other responder end is located, the number of responder ends included in the first set, and the number of calling ends included in the second set into a pre-trained weight determination model, so as to determine, through the determination model, the allocation weight for allocating service call requests to the other responder ends.

[0098] Optionally, the apparatus further includes: a training module 305

[0099] The training module 305 is specifically configured to obtain each sample call request, and determine a first responder end and a second responder end for providing called data to the target calling end, where the number of specified calling ends included in the node device where the first responder end is located is different from the number of specified calling ends included in the node device where the second responder end is located; input the number of specified calling ends included in the node device where the first responder end is located, the number of responder ends included in the first set, and the number of calling ends included in the second set into the weight determination model, so as to determine, through the weight determination model, the allocation weight for allocating the sample call request to the first responder end; and input the number of specified calling ends included in the node device where the second responder end is located, the number of responder ends included in the first set, and the number of calling ends included in the second set into the weight determination model, so as to determine, through the weight determination model, the allocation weight for allocating the sample call request to the second responder end; determine, according to the allocation weight for allocating service call requests to the first responder end and the allocation weight for allocating service call requests to the second responder end, the number of sample call requests allocated to the first responder end and the number of sample call requests allocated to the second responder end among each sample call request; and use minimizing the difference between the number of sample call requests allocated to the first responder end and the number of sample call requests allocated to the second responder end as an optimization objective to train the weight determination model.

[0100] Optionally, the determining module 303 is specifically configured to select any two other responder ends from other responder ends deployed in other node devices; for each selected other responder end, determine the allocation weight for allocating service call requests to the other responder end according to the number of specified calling ends included in the node device where the other responder end is located.

[0101] This specification also provides a computer-readable storage medium storing a computer program that can be used to execute the above-mentioned Figure 1 request allocation method provided.

[0102] This specification also provides Figure 4 a schematic structural diagram of an electronic device corresponding to Figure 1 . As Figure 4 , at the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory. Of course, it may also include other hardware required for other services. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it to implement the above-mentioned Figure 1 request allocation method. Of course, in addition to the software implementation method, this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, and can also be hardware or logic devices.

[0103] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements to method flows). However, with the development of technology, many method flow improvements today can be regarded as direct improvements to hardware circuit structures. Almost all designers obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement to a method flow cannot be implemented using a hardware entity module. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is an integrated circuit whose logic function is determined by the user programming the device. Designers can program themselves to "integrate" a digital system onto a single PLD, without having to ask a chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compilers used in program development and writing. The original code before compilation also has to be written in a specific programming language, which is called a Hardware Description Language (HDL). There is not just one type of HDL, but many types, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones currently are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also be aware that by simply performing some logical programming on the method flow using the above-mentioned several hardware description languages and programming it into an integrated circuit, it is easy to obtain the hardware circuit that implements the logical method flow.

[0104] The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program code (such as software or firmware) executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of the controller include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, it is entirely possible to logically program the method steps to enable the controller to be implemented in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, and embedded microcontrollers to achieve the same function. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as either software modules for implementing the method or structures within the hardware component.

[0105] The systems, devices, modules, or units illustrated in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0106] For the convenience of description, the above devices are described by dividing them into various units according to their functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0107] Those skilled in the art should understand that the embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer-usable program code.

[0108] This specification is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the specification. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processors of general-purpose computers, special-purpose computers, embedded processors, or other programmable application detection devices to generate a machine, such that the instructions executed by the processors of the computer or other programmable application detection devices generate means for implementing the functions specified in one Figure 1 flow or multiple flows and / or blocks Figure 1 block or multiple blocks.

[0109] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable application detection device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means that implement the functions specified in one Figure 1 flow or multiple flows and / or blocks Figure 1 block or multiple blocks.

[0110] These computer program instructions can also be loaded onto a computer or other programmable application detection device, such that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one Figure 1 flow or multiple flows and / or blocks Figure 1 block or multiple blocks.

[0111] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0112] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash memory (flash RAM). The memory is an example of computer-readable media.

[0113] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. 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 technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0114] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0115] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems or computer program products. Therefore, this specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0116] This specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0117] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other, and the key point of each embodiment is to illustrate the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for the relevant parts, reference can be made to the partial description of the method embodiment.

[0118] The above are only the embodiments of this specification and are not used to limit this specification. For those skilled in the art, various modifications and changes can be made to this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included within the scope of the claims of this specification.

Claims

1. A method for request allocation, which is applied to a node device, and the method includes: Obtain each service call request sent by a target call end deployed in the node device itself; Determine at least some of the service call requests from the service call requests and allocate them to a responder deployed locally in the node device for providing called data to the target call end; For other responders deployed in each other node device, determine an allocation weight for allocating service call requests to the other responders according to the number of specified call ends included in the node device where the other responders are located, and use it as the corresponding allocation weight for the other responders. The other responders are used to provide called data to the target call end, and the specified call end refers to a microservice deployed in the node device where the other responder is located for sending service call requests to the other responder; Allocate the remaining service call requests to the other responders according to the allocation weight corresponding to the other responders.

2. The method according to claim 1, where determining at least some of the service call requests from the service call requests and allocating them to the local responder specifically includes: Determine a first set of responders for providing called data to the target call end from each node device, and determine a second set of call ends for retrieving data from the responders included in the first set from each node device; Determine the probability of allocating each service call request to a responder deployed locally in the node device for providing called data to the target call end according to the number of responders included in the first set and the number of call ends included in the second set; Determine at least some of the service call requests from the service call requests according to the probability and allocate them to a responder deployed locally in the node device for providing called data to the target call end.

3. The method according to claim 1, where for other responders deployed in each other node device, determine an allocation weight for allocating service call requests to the other responders according to the number of specified call ends included in the node device where the other responders are located, and use it as the corresponding allocation weight for the other responders, specifically includes: Determine a first set of responders for providing called data to the target call end from each node device, and determine a second set of call ends for retrieving data from the responders included in the first set from each node device; For other responders deployed in each other node device, input the number of specified call ends included in the node device where the other responders are located, the number of responders included in the first set, and the number of call ends included in the second set into a pre-trained weight determination model to determine the allocation weight for allocating service call requests to the other responders through the determination model.

4. The method according to claim 3, training the weight determination model, specifically includes: Obtain each sample call request, and determine a first responder and a second responder for providing called data to the target call end, where the number of specified call ends included in the node device where the first responder is located is different from the number of specified call ends included in the node device where the second responder is located; Input the number of specified call ends included in the node device where the first responder is located, the number of responders included in the first set, and the number of call ends included in the second set into the weight determination model, so as to determine, through the weight determination model, the allocation weight for allocating the sample call request to the first responder; And Input the number of specified call ends included in the node device where the second responder is located, the number of responders included in the first set, and the number of call ends included in the second set into the weight determination model, so as to determine, through the weight determination model, the allocation weight for allocating the sample call request to the second responder; According to the allocation weight for allocating the service call request to the first responder and the allocation weight for allocating the service call request to the second responder, determine the number of sample call requests allocated to the first responder and the number of sample call requests allocated to the second responder among the respective sample call requests; Take minimizing the difference between the number of sample call requests allocated to the first responder and the number of sample call requests allocated to the second responder as the optimization objective, and train the weight determination model.

5. The method according to claim 3, for other responders deployed in other node devices, determine the allocation weight for allocating the service call request to the other responder according to the number of specified call ends included in the node device where the other responder is located, and use it as the corresponding allocation weight of the other responder, specifically including: Select any two other responders from the other responders deployed in each other node device; For each selected other responder, determine the allocation weight for allocating the service call request to the other responder according to the number of specified call ends included in the node device where the other responder is located.

6. An allocation device for requests, the device is applied in a node device, including: An acquisition module, configured to acquire each service call request sent by a target call end deployed in the node device itself; A first allocation module, configured to determine that at least part of the service call requests are allocated to a responder deployed locally in the node device for providing called data to the target call end; A determination module, configured to determine, for other responder deployed in each other node device, an allocation weight for allocating a service call request to the other responder according to the number of specified callers included in the node device where the other responder is located, as the allocation weight corresponding to the other responder, where the other responder is used to provide called data to the target caller, and the specified caller refers to a microservice deployed in the node device where the other responder is located and used to send a service call request to the other responder; A second allocation module, configured to allocate the remaining service call requests to the other responder according to the allocation weight corresponding to the other responder.

7. The apparatus according to claim 6, wherein the first allocation module is specifically configured to determine, from each node device, a first set of responders for providing called data to the target caller, and determine, from each node device, a second set of callers for retrieving data from the responders included in the first set; determine a probability of allocating each service call request to a responder deployed locally in the node device and used to provide called data to the target caller according to the number of responders included in the first set and the number of callers included in the second set; and determine, according to the probability, at least some of the service call requests to be allocated to the responder deployed locally in the node device and used to provide called data to the target caller.

8. The apparatus according to claim 6, wherein the determination module is specifically configured to determine, from each node device, a first set of responders for providing called data to the target caller, and determine, from each node device, a second set of callers for retrieving data from the responders included in the first set; for other responders deployed in each other node device, input the number of specified callers included in the node device where the other responder is located, the number of responders included in the first set, and the number of callers included in the second set into a pre-trained weight determination model, so as to determine, through the determination model, an allocation weight for allocating a service call request to the other responder.

9. A computer-readable storage medium, storing a computer program, where when the computer program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.

10. An electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, where when the processor executes the program, the method according to any one of claims 1 to 5 is implemented.

Images