Request resource control method and device, storage medium and electronic equipment

Abstract

The invention provides a request resource control method and device, a storage medium and electronic equipment, and is applied to the technical field of distributed systems. The method comprises the following steps: obtaining a user request carrying control information, wherein the control information comprises a processing time total amount, a calling frequency total amount and a penalty factor corresponding to the user request; when a user request is processed, sub-control information allocated to service calling is dynamically calculated according to the penalty factor, the remaining count of the total amount of processing time and the total amount of calling times, and the dependency attribute and the retry state of service calling; and when the sub-control information satisfies a service calling condition, carrying the sub-control information to initiate service calling, and updating the residual count of the resource quota according to a calling response condition. According to the method, the control information is distributed and transmitted on the whole calling link for request processing, so that the process of request processing and service calling can be effectively controlled, the effective control on the whole link request resources is realized, and the system avalanche risk is reduced.

Description

Technical Field

[0001] This invention relates to the field of distributed systems technology, and in particular to a method, apparatus, storage medium, and electronic device for requesting resources control. Background Technology

[0002] With the development of information technology, distributed systems, especially microservice architecture, have become the mainstream for supporting large-scale Internet applications. In this architecture, a large number of service nodes are interconnected through the network, forming complex call chains with multiple fan-outs and multiple levels, which causes the request volume to amplify layer by layer between services, resulting in a rapid increase in system load.

[0003] However, due to system complexity and resource limitations, anomalies (such as errors and timeouts) frequently occur during request processing. When the service response slows down or requests surge at a certain stage, the subsequent service processing capacity is insufficient, leading to a large number of errors and blockages. Although the automatic retry mechanism ensures business availability, it increases the system load and can easily cause a "avalanche effect," resulting in overall system unavailability and severely impacting user experience and business revenue.

[0004] Therefore, how to effectively control requested resources and prevent distributed systems from experiencing a cascading failure has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of the above problems, the present invention provides a method, apparatus, storage medium, and electronic device for requesting resource control that overcomes or at least partially solves the above problems. The technical solution is as follows:

[0006] A method for controlling resource requests, comprising:

[0007] Obtain a user request carrying control information, wherein the control information includes the total processing time limit, the total number of calls limit, and the penalty factor corresponding to the user request;

[0008] During the process of processing the user request according to the control information, the sub-control information allocated to the current service call is dynamically calculated based on the remaining count of the penalty factor, the total processing time limit, and the total number of calls, as well as the dependency attributes and retry status of the current service call.

[0009] Based on the sub-control information, determine whether the service call conditions are met. If so, initiate the current service call with the sub-control information, and update the remaining counts of the total processing time and the total number of calls according to the response of the current service call.

[0010] Optionally, the step of dynamically calculating the sub-control information allocated to the current service call based on the remaining counts of the penalty factor, the total processing time limit, and the total number of calls, as well as the dependency attributes and retry status of the current service call, includes:

[0011] If the current service call is the first request, a first penalty sub-factor for the current service call is determined based on the dependency attributes of the current service call and the penalty factor.

[0012] The first processing time quota for the current service call is calculated based on the remaining count of the first penalty sub-factor and the total processing time quota.

[0013] Based on the remaining count of the total number of calls, the first call limit for the current service call is calculated.

[0014] Optionally, the service call conditions include, when the current service call is the first request, the first processing time limit is greater than or equal to a preset time threshold, and the first call count limit is greater than or equal to a preset number of times threshold.

[0015] Optionally, the step of dynamically calculating the sub-control information allocated to the current service call based on the remaining counts of the penalty factor, the total processing time limit, and the total number of calls, as well as the dependency attributes and retry status of the current service call, includes:

[0016] If the current service call is a retry request, a second penalty sub-factor for the current service call is determined based on the dependency attributes of the current service call, the penalty factor, and the number of retries.

[0017] The second processing time quota for the current service call is calculated based on the second penalty sub-factor and the remaining count of the total processing time quota obtained at the time of the first request.

[0018] The second call limit for the current service call is calculated based on the actual number of calls made in the previous service call.

[0019] Optionally, the service call conditions include, in the case that the current service call is a retry request, the second processing time limit is greater than or equal to the actual processing time of the previous service call, and the second call count limit is less than or equal to the remaining count of the total call count limit.

[0020] Optionally, when the current service call is the first request, determining the first penalty sub-factor of the current service call based on the dependency attributes of the current service call and the penalty factor includes:

[0021] If the current service call is the first request, and the current service call is a strong dependency call, then the penalty factor is inherited as the first penalty sub-factor; if the current service call is a weak dependency call, then a fixed value is added on the inherited penalty factor to obtain the first penalty sub-factor.

[0022] And / or, in the case that the current service call is a retry request, determining the second penalty sub-factor of the current service call based on the dependency attributes of the current service call, the penalty factor, and the number of retries includes:

[0023] If the current service call is a retry request, and the current service call is a strong dependency call, then the number of retry attempts is added to the penalty factor to obtain a second penalty sub-factor. If the current service call is a weak dependency call, then the number of retry attempts and a fixed value are added to the penalty factor.

[0024] Optionally, the total processing time limit is set based on the performance of the distributed system and user tolerance, and / or. The total number of calls is set based on the number of services in the call chain of the distributed system, and / or the penalty factor is set based on the request source type of the user request.

[0025] A resource request control device includes: a user request acquisition unit, a resource allocation unit, a condition judgment unit, and a resource management unit.

[0026] The user request acquisition unit is used to acquire user requests carrying control information, wherein the control information includes the total processing time, the total number of calls, and the penalty factor corresponding to the user request.

[0027] The resource allocation unit is used to dynamically calculate the sub-control information allocated to the current service call during the process of processing the user request according to the control information, based on the remaining count of the penalty factor, the total processing time limit and the total number of calls, as well as the dependency attributes and retry status of the current service call.

[0028] The condition judgment unit is used to determine whether the service call conditions are met based on the sub-control information; if so, the resource management unit is triggered.

[0029] The resource management unit is used to initiate the current service call carrying the sub-control information, and update the remaining counts of the total processing time and the total number of calls based on the response status of the current service call.

[0030] A computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the requested resource control method.

[0031] An electronic device includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other via the bus; the processor is used to invoke program instructions in the memory to execute the requested resource control method.

[0032] By employing the above technical solution, this invention provides a request resource control method, apparatus, storage medium, and electronic device. It obtains user requests carrying control information, wherein the control information includes the total processing time limit, the total number of calls limit, and a penalty factor corresponding to the user request. During the processing of the user request according to the control information, sub-control information allocated to the current service call is dynamically calculated based on the remaining counts of the penalty factor, the total processing time limit, and the total number of calls limit, as well as the dependency attributes and retry status of the current service call. Based on the sub-control information, it is determined whether the service call conditions are met. If so, the current service call is initiated carrying the sub-control information, and the remaining counts of the total processing time limit and the total number of calls limit are updated according to the response status of the current service call. This invention, by allocating and transmitting control information throughout the entire request processing call chain, can effectively control the request processing and service call process, preventing unlimited request amplification and retries, thereby achieving effective control over the entire link of request resources and reducing the risk of system overload and cascading failures.

[0033] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0034] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0035] Figure 1 A flowchart illustrating one embodiment of the request resource control method provided by this invention is shown.

[0036] Figure 2 A schematic diagram of a distributed system request call chain provided in an embodiment of the present invention is shown;

[0037] Figure 3 This diagram illustrates the working principle of request-level service call link traffic governance provided in an embodiment of the present invention.

[0038] Figure 4 The diagram shows a specific implementation of step S110 in the resource request control method provided by the present invention.

[0039] Figure 5 This is a flowchart illustrating another specific implementation of step S110 in the resource request control method provided in this embodiment of the invention;

[0040] Figure 6 A schematic diagram of the processing flow of the request resource control method provided in an embodiment of the present invention is shown;

[0041] Figure 7 A schematic diagram of the structure of the resource request control device provided in an embodiment of the present invention is shown. Detailed Implementation

[0042] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0043] With the rapid development of information technology, distributed systems, especially microservice architecture, have become the mainstream technical solution supporting large-scale Internet applications. In this architecture, a large number of service nodes exist within the system, and these services communicate with each other over a network, forming complex multi-fan-out, multi-level call chains. Whenever a user request enters the system, it is often passed and transferred between multiple services, causing the number of requests to amplify layer by layer between services. In high-concurrency scenarios, the number of requests surges, and the overall system load increases rapidly.

[0044] Due to the inherent complexity of distributed systems and the limited network and node resources, the likelihood of exceptions (such as errors and timeouts) occurring during request processing increases significantly. When the service response at a certain stage of the system slows down or the overall number of requests surges, the processing capacity of subsequent services will be unable to meet the demand, resulting in a large number of errors, timeouts, and even blockages in request processing. More seriously, in a distributed call chain, services at each level typically configure automatic retry mechanisms to ensure business availability. This causes existing abnormal traffic to be retried layer by layer between upstream and downstream services, further increasing the system load and creating a "cascading failure effect." The cascading failure effect not only renders the entire distributed system unavailable but also causes significant losses to the platform's user experience, brand reputation, and business revenue.

[0045] To address the "avalanche effect" problem in distributed system architecture design and operation, current main methods include flow limiting, circuit breaking, and automatic scaling.

[0046] Rate limiting: Rate limiting technology sets traffic thresholds. When the traffic entering a service exceeds a preset threshold, the excess traffic is dropped to prevent system overload. Rate limiting can effectively prevent cascading failures when traffic is within the service's actual processing capacity, but its core relies on reasonable threshold settings. Thresholds that are too high will cause rate limiting to fail, while thresholds that are too low may waste available service resources and cause unnecessary request dropping. Furthermore, rate limiting typically does not consider request priority, indiscriminately dropping traffic exceeding the threshold, which may affect the processing of critical business requests.

[0047] Circuit breaking: Circuit breaking mechanisms protect services on a service-by-service basis. When the failure rate or other metrics of the called service exceed a threshold, the caller's circuit breaker disconnects the service connection, suspends request sending, and restores some traffic only after the called service recovers. Circuit breaking technology can isolate faults and prevent single-point failures from spreading globally and causing system cascading failures. However, its shortcomings lie in the fact that circuit breaking mechanisms uniformly discard all requests, failing to further utilize the remaining processing capacity of the called service and making it difficult to guarantee the continuous processing of high-priority requests. Furthermore, circuit breaking technology often operates on a single service-by-service basis, lacking coordination with upstream and downstream services throughout the entire call chain, making it difficult to achieve optimal resource allocation across the entire chain.

[0048] Automatic scaling: Automatic scaling increases service processing capacity by horizontally expanding the number of instances, making it suitable for scenarios with gradual traffic growth. However, the scaling process has a certain delay and is difficult to handle instantaneous overload caused by sudden surges in traffic.

[0049] In addition, some systems may temporarily adjust service configurations, such as reducing timeout periods or disabling automatic retries, to alleviate system pressure. These methods are post-incident investigations and emergency responses, and are inherently delayed, making them difficult to prevent before an avalanche occurs.

[0050] In summary, although rate limiting and circuit breaking are the main technical means to deal with the avalanche of distributed systems, they all have shortcomings such as difficulty in dynamically adjusting thresholds, imperfect request priority management, and inability to coordinate upstream and downstream services, making it difficult to achieve efficient and fine-grained avalanche protection from a global perspective.

[0051] Based on this, this invention provides a request resource control method. Based on the concept of distributed autonomy, it allocates and transmits control information, including processing time limits, call count limits, and penalty factors, throughout the entire request call chain. Each service node dynamically manages request processing and service call processes based on its remaining quota and penalty factor, and allocates corresponding control information to sub-requests for each call. The penalty factor is related to factors such as request quality, dependency strength, and retries. Requests with higher penalty factors receive fewer processing opportunities and resource quotas when the system is overloaded, thereby reducing their consumption of system resources. This mechanism prioritizes abandoning low-quality, weakly dependent, and retry requests, releasing system resources in a timely manner, and effectively preventing distributed system avalanche.

[0052] like Figure 1 The diagram shows a flowchart of one embodiment of the resource request control method provided by this invention. The method may include:

[0053] S100. Obtain a user request carrying control information, wherein the control information includes the total processing time, the total number of calls, and the penalty factor corresponding to the user request.

[0054] Among them, control information is information that constrains and manages the processing of requests in the distributed call chain, ensuring that requests are controlled in terms of resource consumption and the number of calls, thereby preventing system overload.

[0055] In this context, a user request refers to a client request that initiates access to the distributed system, carrying business data. This data is processed by the gateway and various service nodes to ultimately complete the business logic. Upon receiving a user request, the gateway of the distributed system will attach corresponding control information to it.

[0056] The total processing time limit refers to the maximum processing time allowed for a user request throughout the entire call chain. User requests must be completed within this time; otherwise, they will be terminated to avoid occupying system resources for an extended period.

[0057] The total number of calls refers to the maximum number of service calls a user request is allowed to make throughout the entire call chain (including calls to this service and all downstream services). Once this number is exceeded, calls will stop to prevent the call chain from spreading indefinitely.

[0058] The penalty factor is a numerical parameter that reflects the importance or priority of a request. The larger the value, the lower the importance of the request. When the system is overloaded, the processing resources (including processing time and number of calls) for such requests will be reduced first to protect the resources of critical requests.

[0059] Specifically, in this embodiment of the invention, when a user request enters the distributed system gateway, the gateway initializes control information based on system performance and business policies, including the total processing time limit, the total number of calls limit, and the penalty factor. This control information is appended to the user request through a custom request header field, and then the user request carrying the control information is forwarded to the backend service node, thereby realizing the transmission and management of control information.

[0060] Optionally, the total processing time limit can be set based on the performance of the distributed system and the user's tolerance.

[0061] Optionally, the total number of calls can be set based on the number of services in the call chain of the distributed system.

[0062] Optionally, the penalty factor can be set based on the request source type of the user's request.

[0063] As examples, the initialization of control information provided in this embodiment of the invention is generally completed by the gateway of the distributed system after receiving a user request. The gateway adds control information to the request header according to system performance and business requirements. The initialization assignment rules can be as follows: Processing time limit: set according to system performance indicators and user waiting tolerance, for example, the default value is 5000 milliseconds; Call count limit: set based on the number of services in the entire call chain, and allows a certain proportion of retries, for example, 1.5 times the number of services in the call chain; Penalty factor: usually assigned a value of 0 for natural user traffic, and a higher penalty factor, such as 1, can be assigned to non-natural traffic such as channel referrals, to reflect the importance of different requests. At the same time, differentiated processing time limits and call count limits can be set for different functional modules according to specific business requirements to achieve more refined resource control.

[0064] As other examples, the custom request header fields specifically used in embodiments of the present invention may include: X-Mgtv-Timeout: representing the total processing time limit for the request, in milliseconds, used to limit the maximum processing time allowed for the request throughout the entire call chain. X-Mgtv-Max-Calls: representing the total number of calls for the request, in times, limiting the maximum number of service calls allowed during request processing. X-Mgtv-Penalty-Factor: representing the penalty factor for the request, used to reflect the importance or priority of the request; a larger value indicates a lower priority. Furthermore, the actual call count information is passed back through the response header field X-Mgtv-Call-Count, recording the actual number of calls that occurred during request processing, including the current service and all its nested calls.

[0065] S110. During the process of processing user requests according to control information, the sub-control information allocated to the current service call is dynamically calculated based on the remaining counts of the penalty factor, the total processing time limit, and the total number of calls, as well as the dependency attributes and retry status of the current service call.

[0066] The remaining counts of the total processing time and the total number of calls are the current remaining values ​​of the total processing time and the total number of calls during the request processing process. They are dynamically updated as service calls and processing time are consumed, controlling the initiation of subsequent calls and resource allocation.

[0067] The current service call refers to the specific call operation initiated by the current node to a downstream service in the request processing chain, which may be the first call or a retry call.

[0068] Dependency attributes describe the strength of the relationship between the current service call and the overall request processing, and can be divided into strong dependency calls and weak dependency calls. Strong dependency calls indicate that call failure would severely impact request success, requiring priority resource allocation. Weak dependency calls indicate a higher tolerance for call failure, with relatively lenient resource allocation and retry strategies. Dependency attributes can be explicitly marked in the service call chain configuration or scheduling rules to ensure accurate differentiation of call dependency types during the call process for different resource allocations and fault tolerance handling.

[0069] The retry status indicates whether the current service call is a retry after a failure and the number of retries. The more retries, the lower the importance and priority of the request, and the greater the corresponding penalty factor.

[0070] Among them, sub-control information refers to the subset of control information allocated to the current service call, including the processing time limit, call count limit and penalty factor allowed for the service call, which is used to constrain the service call and its subsequent calls to ensure the reasonable allocation and transmission of overall control information in the call chain.

[0071] Specifically, in the process of processing user requests according to control information, if a service call occurs, sub-control information is allocated to the sub-request corresponding to the service call using an allocation algorithm. This allocation algorithm follows the following principles: weak dependency calls are less important than strong dependency calls, retry calls are less important than the first call, and the more retries there are, the lower the importance, thus the larger the penalty factor allocated. The processing time quota and call count quota are reasonably allocated based on the current remaining quota, and the larger the penalty factor, the stricter the resource restriction of the call, and the smaller the allocated processing time quota. For retry calls, the call count quota will refer to the actual consumption of the previous call, thereby realizing precise adjustment and dynamic management of sub-control information.

[0072] S120. Determine whether the service call conditions are met based on the sub-control information. If so, proceed to step S130.

[0073] Understandably, if the sub-control information does not meet the service call conditions, the current service call will not be initiated.

[0074] S130. Initiate the current service call with sub-control information, and update the remaining counts of the total processing time and the total number of calls based on the response status of the current service call.

[0075] The service call condition is used to determine whether the resource quota threshold (such as whether the processing time quota and the number of calls quota are sufficient) is met based on the sub-control information. The service call is only initiated when the condition is met to prevent resource overload and invalid calls.

[0076] The response status of the current service call refers to the result returned after the current service call is completed, including whether the call was successful, the actual processing time consumed, and the number of calls. It is used to dynamically adjust and update the remaining count and guide the allocation of control information for subsequent calls.

[0077] The basic working principle of the request resource control method provided by this invention is to allocate and transmit control information throughout the entire request call chain. Based on this control information, each service in the call chain performs refined management of request processing and service call processes through specific algorithms. As requests are processed, the processing time limit and call count limit decrease layer by layer, while the penalty factor is dynamically adjusted according to the importance of the service call. The importance is determined by factors such as request quality, dependency strength, and retries. Specifically, the allocation algorithm is as follows: the penalty factor is inversely proportional to the probability of initiating a service call and the allocated processing time limit; the larger the penalty factor, the fewer the call opportunities and resource allocations, thereby reducing system resource consumption. Using the request resource control method provided by this invention, when the system load is too high, low-priority requests with higher penalty factors (such as low-quality requests, weak dependency calls, and retry requests) can be prioritized for restriction. Requests with higher penalty factors are suppressed first, and as the problem intensifies, the number of suppressed requests increases, effectively releasing system resources, preventing avalanche effects in distributed systems, and improving system stability and reliability.

[0078] For ease of understanding, this section combines... Figure 2 and Figure 3 For example: Figure 2 The diagram shown is a schematic representation of a distributed system request call chain provided in an embodiment of the present invention. Figure 3 The diagram illustrates the working principle of request-level service call link traffic management provided in an embodiment of the present invention. Figure 2As shown, after a user initiates a request, the gateway forwards the request to service A. Service A then calls services B and E in sequence. Service B in turn calls services C and D, and service E calls services D and F. The call chain formed during request processing is shown by the red line in the diagram. Figure 2 The request call chain shown is as follows: Figure 3 As shown, each service in the chain, upon receiving a request, will time the request processing and count the number of service calls. When the remaining processing time or call count is insufficient, the service will stop processing. When a service call occurs (downward dashed arrow), the caller will allocate corresponding processing time and call count quotas to the callee. When the service call returns (upward dashed arrow), the callee will feed back the actual number of calls to the caller, realizing dynamic management of sub-control information.

[0079] This invention provides a request resource control method, comprising: obtaining a user request carrying control information, wherein the control information includes a total processing time limit, a total number of calls limit, and a penalty factor corresponding to the user request; during the processing of the user request according to the control information, dynamically calculating sub-control information allocated to the current service call based on the remaining counts of the penalty factor, the total processing time limit, and the total number of calls limit, as well as the dependency attributes and retry status of the current service call; determining whether the service call conditions are met based on the sub-control information; if so, initiating the current service call carrying the sub-control information; and updating the remaining counts of the total processing time limit and the total number of calls limit based on the response status of the current service call. This invention, by allocating and transmitting control information throughout the entire request processing call chain, can effectively control the request processing and service call process, prevent unlimited request amplification and retries, thereby achieving effective control over the entire link of request resources and reducing the risk of system overload and cascading failures.

[0080] Optional, based on Figure 1 The method shown is as follows: Figure 4 The diagram shows a specific implementation of step S110 in the resource request control method provided by this invention. Step S110 may specifically include:

[0081] S400. If the current service call is the first request, determine the first penalty sub-factor of the current service call based on the dependency attributes and penalty factor of the current service call.

[0082] Specifically, in embodiments of the present invention, when the current service call is the first request, the first penalty sub-factor of the current service call can be calculated based on its dependency attributes and the penalty factor in the user request, by inheriting the penalty factor or by adding a fixed value on top of it.

[0083] Optionally, in the above Figure 4 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, step S400 may specifically include:

[0084] If the current service call is the first request, and the current service call is a strong dependency call, then the inherited penalty factor is used as the first penalty sub-factor. If the current service call is a weak dependency call, then a fixed value is added to the inherited penalty factor to obtain the first penalty sub-factor.

[0085] Specifically, in embodiments of the present invention, when the current service call is the first request, the dependency attributes of the call are first read to determine whether it is a strong dependency call or a weak dependency call. If it is a strong dependency call, the first penalty sub-factor of the current service call directly inherits the penalty factor of the current user request; if it is a weak dependency call, a fixed value (e.g., 1 or a larger value such as 2) is added to the inherited penalty factor of the current user request. This adjustment reflects that strong dependency calls are more important to request processing and are usually intolerant of failure, while weak dependency calls are more fault-tolerant, and therefore have a correspondingly larger penalty factor.

[0086] This invention, when a service call is the first request, distinguishes between strong and weak dependency calls based on their dependency attributes and employs different penalty sub-factor determination strategies for each. Strong dependency calls inherit the original penalty factor to ensure strict and prioritized resource allocation. For weak dependency calls, a fixed value is added to the penalty factor to appropriately increase the penalty intensity and limit resource consumption. This enables more precise resource control and balanced scheduling, effectively distinguishes the importance of different service calls, prevents weak dependency calls from excessively consuming limited processing time and call count limits, thereby ensuring the stability and priority execution of core strong dependency calls and improving the quality and efficiency of distributed service calls.

[0087] S410. Calculate the first processing time quota for the current service call based on the remaining count of the first penalty sub-factor and the total processing time quota.

[0088] Specifically, in this embodiment of the invention, the remaining count of the total processing time quota can be allocated according to the inverse proportional relationship of the first penalty factor, so as to ensure that the larger the penalty factor is, the smaller the allocated processing time quota is, thus limiting the time it occupies system resources.

[0089] S420. Calculate the first call limit for the current service call based on the remaining count of the total call limit.

[0090] Specifically, in this embodiment of the invention, the remaining count of the total number of calls can be obtained by subtracting the number of calls already used from the total number of calls, and the remaining count of the total number of calls can be used as the first call limit for the current service call.

[0091] In the first request, this invention determines a first penalty sub-factor based on the call's dependency attributes and penalty factor. Then, by combining the remaining processing time and call count limit, it calculates a reasonable first processing time limit and first call count limit. This ensures that resource allocation satisfies the priority and importance of service calls while effectively controlling the overall resource consumption of the request. As a result, it not only improves the distributed system's adaptability and fault tolerance to different service calls, but also prevents excessive resource consumption, ensuring the timeliness and reliability of the overall request processing, and ultimately achieving more efficient and stable distributed service call management.

[0092] Optionally, in the above Figure 4 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, the service call conditions may include, when the current service call is the first request, a first processing time limit greater than or equal to a preset time threshold, and a first call count limit greater than or equal to a preset number of times threshold.

[0093] Specifically, in this embodiment of the invention, it can determine whether the first processing time limit is greater than or equal to a preset time threshold. If so, proceed to the next step; otherwise, it indicates that the processing time limit is insufficient, and no service call is initiated. This embodiment of the invention can also determine whether the first call count limit is greater than or equal to a preset call count threshold. If so, proceed to the next step; otherwise, it indicates that the call count limit is insufficient, and no service call is initiated.

[0094] Optionally, embodiments of the present invention can also set corresponding preset time thresholds according to the service call region type. For example, the threshold set for calls within the same region can be 50 milliseconds, and the threshold set for calls across regions can be 100 milliseconds.

[0095] Optionally, the preset number of times threshold can be 1.

[0096] This invention, by setting the service call conditions to require that, when the current service call is the first request, the first processing time limit is not less than a preset time threshold and the first call count limit is not less than a preset count threshold, can effectively prevent service call failures or anomalies caused by insufficient resource allocation, improve the success rate and stability of service calls, and ensure that each service call can obtain the minimum processing time and call count guarantee before starting, thus avoiding the impact on the execution of the overall request chain and user experience caused by the adjustment of scheduling algorithms or penalty factors, which may result in some service call resources being too low.

[0097] Optional, based on Figure 4 The method shown is as follows: Figure 5The diagram shows another specific implementation of step S110 in the resource request control method provided in this embodiment of the invention. Step S110 may specifically include:

[0098] S500. If the current service call is a retry request, determine the second penalty sub-factor of the current service call based on the dependency attributes, penalty factor, and number of retries of the current service call.

[0099] Specifically, in embodiments of the present invention, when the current service call is a retry request, a second penalty sub-factor of the current service call can be calculated based on its dependency attributes, the penalty factor in the user request, and the number of retries, by superimposing the number of retries and a fixed value on the basis of the inherited penalty factor.

[0100] Optionally, in the above Figure 5 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, step S500 may specifically include:

[0101] If the current service call is a retry request, and the current service call is a strong dependency call, then the number of retries is added to the inherited penalty factor to obtain a second penalty sub-factor. If the current service call is a weak dependency call, then the number of retries and a fixed value are added to the inherited penalty factor.

[0102] Specifically, in the embodiments of the present invention, when the current service call is a retry request, the penalty factor at the time of the first request is first obtained and adjusted according to the number of retries. If the current service call is a strong dependency call, the number of retries is added on the basis of the inherited penalty factor. If it is a weak dependency call, the number of retries and a fixed value are added on the basis of the inherited penalty factor, thereby reflecting the principle that the more retries there are, the lower the importance of the service call and the larger the penalty factor.

[0103] This invention further incorporates dynamic adjustment of the penalty sub-factor based on the number of retries during the retry request phase. This more accurately reflects the resource sensitivity and priority reduction issues caused by multiple attempts in retry calls. In particular, by differentiating between strong and weak dependency calls, and adding either the number of retries to the basic penalty factor or adding the number of retries to a fixed value, the differential calculation of the penalty sub-factor is refined. This not only reflects the importance of strongly dependent services but also reasonably limits the resource consumption of weakly dependent services. This facilitates dynamic and precise control over resource allocation and priority management for service calls, effectively avoiding resource waste and system performance degradation caused by retry requests, and improving the overall stability and efficiency of service calls.

[0104] S510. Calculate the second processing time quota for the current service call based on the second penalty sub-factor and the remaining count of the total processing time quota obtained during the first request.

[0105] Specifically, embodiments of the present invention may adopt an inverse proportional allocation method, using the remaining count of the total processing time quota obtained at the time of the first request as the base to calculate the second processing time quota available for the current retry call, so as to ensure that the larger the penalty factor, the smaller the allocated processing time quota, and reasonably limit the occupation of system resources by retry requests.

[0106] S520. Determine the second call limit for the current service call based on the actual number of calls made in the previous service call.

[0107] Specifically, in this embodiment of the invention, the actual number of calls in the previous request can be determined as the second number of calls available for the current service call.

[0108] This invention, based on the mechanism of dynamically determining a penalty sub-factor through dependency attributes and a penalty factor during the initial request, and rationally allocating processing time and call count limits accordingly, further extends to retry requests. By adjusting the penalty factor in conjunction with the number of retry attempts, it can more accurately reflect the decreasing importance of retry calls, thereby dynamically adjusting the processing time and call count limits allocated to retry requests. This not only effectively protects the resources for the initial request but also reasonably limits the resource consumption of retry requests, avoiding excessive consumption of system resources and degradation of service quality due to frequent retries. Simultaneously, calculating the current call count limit based on the actual number of previous service calls better ensures the continuity and rationality of call counts, effectively improving the resource scheduling accuracy of service calls and the overall stability and performance of the system, promoting the efficient and reliable operation of distributed service calls.

[0109] Optionally, in the above Figure 5 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, the service call conditions may include, in the case that the current service call is a retry request, the second processing time quota is greater than or equal to the actual processing time of the previous service call, and the second call count quota is less than or equal to the remaining count of the total call count quota.

[0110] Specifically, in this embodiment of the invention, it can determine whether the second processing time limit is greater than or equal to the actual processing time of the previous service call. If so, proceed to the next step; otherwise, it indicates that the processing time limit is insufficient, and the service call is not initiated. This embodiment of the invention can also determine whether the second call count limit is less than or equal to the remaining count of the total call count limit. If so, proceed to the next step; otherwise, it indicates that the call count limit is insufficient, and the service call is not initiated.

[0111] The embodiments of the present invention require that the second processing time limit is not less than the previous actual processing time and the second call count limit does not exceed the remaining count of the total call count limit. This can effectively prevent call failure due to insufficient allocation of retry request resources, while avoiding excessive consumption of processing time and call count resources by retry requests, ensuring that retry calls are executed reasonably within the resource allowance, and improving the success rate of service calls and system stability.

[0112] To facilitate understanding of the control information allocation algorithm provided in this embodiment of the invention, examples are given here in conjunction with Tables 1, 2, and 3: Taking a strongly dependent call with a penalty factor of Q and a remaining processing time of T as an example, Table 1 is the condition table for initiating a service call (only conditions related to processing time quota are given in the table, assuming sufficient call quota), and Table 2 is the penalty factor Q. i The allocation table, Table 3 shows the processing time quota T. i The allocation table is as follows: First, as the penalty factor increases, the conditions for initiating service calls become more stringent, thus the penalty factor allocated to the call increases accordingly, and the processing time allowance decreases significantly. Second, as the number of retries increases, the conditions for service calls also become more demanding, with the allocated penalty factor increasing accordingly and the processing time allowance decreasing accordingly. Therefore, it can be concluded that when the processing capacity of a distributed system decreases, leading to an increase in request processing time, requests with larger penalty factors, more retries, and lower importance will be prioritized for suppression. Furthermore, as the system load increases, the number of suppressed requests continuously increases. This embodiment of the invention, through this dynamic priority adjustment mechanism, can effectively release resources, prevent service avalanche phenomena, and ensure the stability and continuous availability of the overall distributed system.

[0113] Table 1

[0114] Punishment factor Q Initial request (i=0) First retry (i=1) Second retry (i=2) Third retry (i=3) Fourth retry (i=4) Q=0 T / 2>50ms <![CDATA[T / 3>=t0]]> <![CDATA[T / 4>=t1]]> <![CDATA[T / 5>=t2]]> <![CDATA[T / 6>=t3]]> Q=1 T / 3>50ms <![CDATA[T / 4>=t0]]> <![CDATA[T / 5>=t1]]> <![CDATA[T / 6>=t2]]> <![CDATA[T / 7>=t3]]> Q=2 T / 4>50ms <![CDATA[T / 5>=t0]]> <![CDATA[T / 6>=t1]]> <![CDATA[T / 7>=t2]]> <![CDATA[T / 8>=t3]]> Q=3 T / 5>50ms <![CDATA[T / 6>=t0]]> <![CDATA[T / 7>=t1]]> <![CDATA[T / 8>=t2]]> <![CDATA[T / 9>=t3]]>

[0115] Table 2

[0116] Punishment factor Q Initial request (i=0) First retry (i=1) Second retry (i=2) Third retry (i=3) Fourth retry (i=4) Q=0 0 1 2 3 4 Q=1 1 2 3 4 5 Q=2 2 3 4 5 6 Q=3 3 4 5 6 7

[0117] Table 3

[0118] Punishment factor Q Initial request (i=0) First retry (i=1) Second retry (i=2) Third retry (i=3) Fourth retry (i=4) Q=0 T / 2 T / 3 T / 4 T / 5 T / 6 Q=1 T / 3 T / 4 T / 5 T / 6 T / 7 Q=2 T / 4 T / 5 T / 6 T / 7 T / 8 Q=3 T / 5 T / 6 T / 7 T / 8 T / 9

[0119] To facilitate understanding of the overall flow of the request resource control method provided in the embodiments of the present invention, this section combines... Figure 6 Explanation: Figure 6The diagram illustrates the processing flow of the request resource control method provided in this embodiment of the invention. In the request processing initialization phase: upon receiving a request, control information is first extracted from the request header, including processing time allowance T, call count allowance N, and penalty factor Q. A timing or countdown mechanism is started. If the processing time allowance T is exhausted and the request is not completed, processing is terminated. The actual call count n=1 (representing the call of this service itself) is initialized. Service call process: for each service call, different allocation and judgment mechanisms are used depending on whether it is the first request or a retry request: 1. First request: Read the remaining processing time T of the current countdown timer. Calculate the penalty factor Q0 to be allocated: strong dependency call: Q0=Q; weak dependency call: Q0=Q+1 (can be adjusted to a larger value according to the actual situation, such as Q0=Q+2).

[0120] Calculate the allocated quota: processing time quota T0: T0 = T / (Q0 + 2), call count quota N0: N0 = Nn. Determine if the allocated quota is sufficient: Condition: T0 ≥ 50ms and N0 ≥ 1. If the quota is insufficient, proceed to subsequent request processing steps without initiating a service call. If the quota is sufficient, initiate a service call and write T0, N0, and Q0 into the request header. Receive the service call response, obtain the actual call count n0 from the response header, and add it to n (n = n + n0). 2. When retrying a request (retry count i): Calculate the penalty factor Q to be allocated. i Strong dependency call: Q i =Q+i; Weak dependency call: Q i =Q + i + 1 (or a larger adjustment value). Calculate the quota to be allocated: Processing time quota T i :T i =T / (Q i +2), the number of calls and the limit N i :N i =n i -1 (takes the actual number of calls from the previous request). Determine if the allocable quota is sufficient: Condition: T i ≥t i-1 And Nn≥N i If the available credit is insufficient, the process will proceed to subsequent request processing steps without initiating a service call. If the available credit is sufficient, a service call will be initiated, and the T parameter will be included in the request header. i N i Q i Receive the service call response and obtain the actual number of calls, n, from the response header. i And accumulate it into n (n=n+n) iContinuous request processing: After receiving the service call response, continue processing the current request. If further service calls are needed (such as retrying on failure or making a new call), repeat the above service call process. Request processing completion: After processing is complete, return the actual number of calls accumulated in this request chain to the caller through the response header, so that upstream services can be aware of resource consumption.

[0121] To facilitate understanding of the specific application process of the request resource control method provided in the embodiments of the present invention in a distributed system, Figure 2 Taking the distributed system request call chain shown as an example, assume that request ⑤ is a weak dependency call, while the rest are strong dependency calls. The requests shown in this example represent natural user traffic; if it is low-quality traffic such as channel referrals, the penalty factor can be adjusted accordingly based on actual needs.

[0122] As examples, in a normally operating distributed system, assume that the lowest-level service CDF takes 300ms to process each request, and that all services have a processing time of 100ms before and after each call. When the gateway forwards a user request (request ①), it adds the following three custom fields to the request header and assigns the following values: X-Mgtv-Timeout:5000 (processing time limit: 5000ms), X-Mgtv-Max-Calls:10 (call limit: 10 times), X-Mgtv-Penalty-Factor:0 (penalty factor: 0, representing natural user traffic). The relevant data for each request is shown in Table 4, which illustrates the system's normal operating conditions: the request processing time for each service remains normal, with no failures or retries. The data in the four columns of "Call Initiation Condition," "Penalty Factor," "Processing Time Limit," and "Call Limit" are calculated based on the allocation algorithm described in the scheme; the remaining columns reflect the actual operating conditions of the system. During normal system operation, the allocated processing time and call count are sufficient to ensure that all requests are processed smoothly without any anomalies (all call requests are completed successfully). Furthermore, these parameters are automatically calculated and allocated by the algorithm, eliminating the need for precise manual configuration.

[0123] Table 4

[0124] ask Serve Total remaining time Invocation conditions Punishment factor Processing time limit Call count limit Actual number of calls Actual processing time Processing results ① A / / 0 5000ms 10 times 7 times 2100ms success ② B 4900ms Established 0 2450ms 9 times 3 times 900ms success ③ C 4800ms Established 0 2400ms 8 times 1 time 300ms success ④ D 4400ms Established 0 2200ms 7 times 1 time 300ms success ⑤ E 3900ms Established 1 1300ms 6 times 3 times 900ms success ⑥ D 3800ms Established 1 1267ms 5 times 1 time 300ms success ⑦ F 3400ms Established 1 1133ms 4 times 1 time 300ms success

[0125] As another example, when the processing capacity of a distributed system decreases, such as when service D in the distributed system encounters an anomaly, it may lead to slower processing speed and a certain probability of error. For ease of understanding and calculation, assume that the processing time of service D for a request increases to 600ms, and that the request is eventually completed successfully after one retry following an error. When the gateway forwards a user request (request ①), it adds the following three custom fields to the request header and assigns the following values: X-Mgtv-Timeout:5000 (processing time limit: 5000ms), X-Mgtv-Max-Calls:10 (call limit: 10 times), X-Mgtv-Penalty-Factor:0 (penalty factor: 0, representing natural user traffic). The relevant data for each request can be seen in Table 5, which shows the performance of service D under the abnormal situation of slower processing and a probability of error. The four columns of "call initiation condition", "penalty factor", "processing time limit", and "call limit" in the table are calculated according to the allocation algorithm described in the scheme, while the other columns reflect the actual operation of the system. As shown in Table 5, retry requests for ⑥ and ⑤ were the first to be abandoned due to their penalty factor reaching the highest value of 2. Since request ⑤ is a weak dependency, its failure and abandonment of retry did not affect the successful execution of request ①. For the three requests with a penalty factor of 1, although they were not abandoned, their allocated processing time was significantly reduced. Therefore, if the processing speed of service D further slows down, these requests will be the first to time out and be abandoned. When the processing capacity of a service in the system decreases, the system will prioritize abandoning requests with higher penalty factors (i.e., requests with lower importance, such as low-quality requests, weak dependency requests, and retry requests), thereby releasing limited resources in a timely manner and preventing a cascading failure. The relevant parameters are automatically calculated and allocated by the algorithm, without relying on precise manual settings. Simultaneously, upstream and downstream services in the call chain coordinate and cooperate to ensure the overall system achieves globally optimal results. For example, the abnormal situation of service D indirectly suppresses service A's retry request to service E, demonstrating this collaborative optimization mechanism.

[0126] Table 5

[0127] ask Serve Total remaining time Invocation conditions Punishment factor Processing time limit Call count limit Actual number of calls Actual processing time Processing results ① A / / 0 5000ms 10 times 7 times 2900ms success ② B 4900ms Established 0 2450ms 9 times 4 times 1800ms success ③ C 4800ms Established 0 2400ms 8 times 1 time 300ms success ④ D 4400ms Established 0 2200ms 7 times 1 time 600ms fail ④ Retry D 3800ms Established 1 1267ms 1 time 1 time 600ms success ⑤ E 3000ms Established 1 1000ms 5 times 2 times 800ms fail ⑥ D 2900ms Established 1 967ms 4 times 1 time 600ms fail ⑥ Retry D 2300ms Not valid 2 575ms 1 time / / / ⑤ Retry E 2200ms Not valid 2 550ms 2 times / / /

[0128] This invention, through the allocation and transmission of control information throughout the entire request processing chain, achieves collaborative cooperation between upstream and downstream services and dynamically regulates request processing and service call flows using this control information. When system processing capacity is insufficient, it can prioritize abandoning low-quality requests, weakly dependent requests, and retry requests—reduced in importance—to promptly release system resources, effectively preventing avalanche effects in the distributed system, and maximizing the retention and processing of highly important requests. Simultaneously, it avoids the cumbersome and uncertainties of configuring rate limiting thresholds, error rate thresholds, timeout periods, and retry counts for each service individually in traditional methods. It achieves automatic algorithm calculation and allocation without manual intervention, possesses adaptive characteristics, effectively prevents failures, and reduces reliance on post-event remedial measures. Under normal operating conditions, this mechanism does not negatively impact the performance and functionality of the distributed system. Furthermore, upstream and downstream services allocate and adjust control information layer by layer throughout the call chain, cooperating with each other to replace significant losses in local services with small-scale global losses, achieving optimal overall system stability. In summary, this invention, through request-level service call chain traffic governance, provides a smart, efficient, and secure traffic governance solution for distributed systems.

[0129] Although the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous.

[0130] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0131] Corresponding to the above method embodiments, this invention also provides a resource request control device, the structure of which is as follows: Figure 7 As shown, it may include: a user request acquisition unit 10, a resource allocation unit 20, a condition judgment unit 30, and a resource management unit 40.

[0132] User request acquisition unit 10 is used to acquire user requests carrying control information, wherein the control information includes the total processing time, the total number of calls, and the penalty factor corresponding to the user request.

[0133] Resource allocation unit 20 is used to dynamically calculate the sub-control information allocated to the current service call during the process of processing user requests according to control information, based on the remaining counts of the penalty factor, the total processing time limit, and the total number of calls, as well as the dependency attributes and retry status of the current service call.

[0134] The condition judgment unit 30 is used to determine whether the service call conditions are met based on the sub-control information. If so, the resource management unit 40 is triggered.

[0135] Resource management unit 40 is used to initiate the current service call with sub-control information and update the remaining counts of the total processing time and the total number of calls based on the response status of the current service call.

[0136] Optionally, the resource allocation unit 20 can be specifically used to determine the first penalty sub-factor of the current service call based on the dependency attributes and penalty factor of the current service call when the current service call is the first request; calculate the first processing time quota of the current service call based on the first penalty sub-factor and the remaining count of the total processing time quota; and calculate the first call count quota of the current service call based on the remaining count of the total call count quota.

[0137] Optionally, the service invocation conditions include, if the current service invocation is the first request, that the first processing time limit is greater than or equal to a preset time threshold, and that the first invocation count limit is greater than or equal to a preset count threshold.

[0138] Optionally, the resource allocation unit 20 can be specifically used to determine the second penalty sub-factor of the current service call based on the dependency attributes, penalty factor and retry count of the current service call when the current service call is a retry request; calculate the second processing time quota of the current service call based on the second penalty sub-factor and the remaining count of the total processing time quota obtained at the first request; and calculate the second call count quota of the current service call based on the actual number of calls of the previous service call.

[0139] Optionally, the service call conditions include, in the case that the current service call is a retry request, the second processing time limit is greater than or equal to the actual processing time of the previous service call, and the second call count limit is less than or equal to the remaining count of the total call count limit.

[0140] Optionally, the resource allocation unit 20 can be specifically used to, when the current service call is the first request, if the current service call is a strong dependency call, inherit the penalty factor as the first penalty sub-factor, and if the current service call is a weak dependency call, add a fixed value on the basis of the inherited penalty factor to obtain the first penalty sub-factor.

[0141] Optionally, the resource allocation unit 20 can be specifically used to, in the case of a retry request, if the current service call is a strong dependency call, add the number of retries on the basis of the inherited penalty factor to obtain a second penalty sub-factor, and if the current service call is a weak dependency call, add the number of retries and a fixed value on the basis of the inherited penalty factor.

[0142] Optionally, the total processing time limit can be set based on the performance of the distributed system and the user's tolerance.

[0143] Optionally, the total number of calls can be set based on the number of services in the call chain of the distributed system.

[0144] Optionally, the penalty factor can be set based on the request source type of the user's request.

[0145] This invention provides a request resource control device, which is used to: obtain a user request carrying control information, wherein the control information includes the total processing time limit, the total number of calls limit, and a penalty factor corresponding to the user request; during the process of processing the user request according to the control information, dynamically calculate sub-control information allocated to the current service call based on the remaining counts of the penalty factor, the total processing time limit, and the total number of calls limit, as well as the dependency attributes and retry status of the current service call; determine whether the service call conditions are met based on the sub-control information, and if so, initiate the current service call carrying the sub-control information, and update the remaining counts of the total processing time limit and the total number of calls limit according to the response status of the current service call. This invention, by allocating and transmitting control information throughout the entire request processing call chain, can effectively control the request processing and service call process, prevent unlimited request amplification and retries, thereby achieving effective control over the entire link of request resources and reducing the risk of system overload and cascading failure.

[0146] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0147] The resource request control device includes a processor and a memory. The user request acquisition unit 10, resource allocation unit 20, condition judgment unit 30, and resource management unit 40 are all stored as program units in the memory. The processor executes the program units stored in the memory to realize the corresponding functions.

[0148] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and by adjusting kernel parameters, control information can be allocated and transmitted throughout the entire request processing call chain. This effectively controls the request processing and service call process, thereby achieving effective control over all request resources and reducing the risk of system cascading failures.

[0149] This invention provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the requested resource control method.

[0150] This invention provides a processor for running a program, wherein the program executes the request resource control method during runtime.

[0151] This invention provides an electronic device, which includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other via the bus; the processor is used to call program instructions in the memory to execute the aforementioned request resource control method. The electronic device described herein may be a server, PC, PAD, mobile phone, etc.

[0152] The present invention also provides a computer program product that, when executed on an electronic device, is suitable for executing a program that initializes a method for requesting resource control.

[0153] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, electronic devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0154] In a typical configuration, an electronic device includes one or more processors (CPUs), memory, and a bus. The electronic device may also include input / output interfaces, network interfaces, etc.

[0155] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM, and memory includes at least one memory chip. Memory is an example of computer-readable media.

[0156] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0157] In the description of this invention, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

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

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

[0160] The above are merely embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the present invention.

Claims

1. A method of requesting resource control, characterized by, The method comprises: obtaining a user request carrying control information, wherein the control information comprises a total amount of processing time corresponding to the user request, a total amount of calling times, and a penalty factor; in the process of processing the user request according to the control information, dynamically calculating sub-control information allocated to a current service call according to the penalty factor, the remaining count of the total amount of processing time and the total amount of calling times, and the dependency attribute and retry state of the current service call; judging whether a service call condition is met based on the sub-control information, and if yes, initiating the current service call carrying the sub-control information, and updating the remaining count of the total amount of processing time and the total amount of calling times according to the response of the current service call.

2. The method of claim 1, wherein, The dynamically calculating sub-control information allocated to the current service call according to the penalty factor, the remaining count of the total amount of processing time and the total amount of calling times, and the dependency attribute and retry state of the current service call comprises: in the case that the current service call is a first request, determining a first penalty sub-factor of the current service call according to the dependency attribute of the current service call and the penalty factor; calculating a first processing time amount of the current service call according to the first penalty sub-factor and the remaining count of the total amount of processing time; calculating a first calling time amount of the current service call according to the remaining count of the total amount of calling times.

3. The method of claim 2, wherein, The service call condition comprises, in the case that the current service call is a first request, that the first processing time amount is greater than or equal to a preset time threshold, and the first calling time amount is greater than or equal to a preset number threshold.

4. The method according to claim 2 or 3, characterized in that, The dynamically calculating sub-control information allocated to the current service call according to the penalty factor, the remaining count of the total amount of processing time and the total amount of calling times, and the dependency attribute and retry state of the current service call comprises: in the case that the current service call is a retry request, determining a second penalty sub-factor of the current service call according to the dependency attribute of the current service call, the penalty factor and the retry number; calculating a second processing time amount of the current service call according to the second penalty sub-factor and the remaining count of the total amount of processing time obtained when the first request is made; calculating a second calling time amount of the current service call according to the actual calling number of the previous service call.

5. The method of claim 4, wherein, The service call condition comprises, in the case that the current service call is a retry request, that the second processing time amount is greater than or equal to the actual processing time of the previous service call, and the second calling time amount is less than or equal to the remaining count of the total amount of calling times.

6. The method of claim 4, wherein, The determining the first penalty sub-factor of the current service call according to the dependency attribute of the current service call and the penalty factor in the case that the current service call is a first request comprises: In a case where the current service call is a first request, if the current service call is a strong dependency call, the penalty factor is inherited as a first penalty sub-factor, and if the current service call is a weak dependency call, a fixed value is superimposed on the basis of the penalty factor to obtain the first penalty sub-factor; And / or, in a case where the current service call is a retry request, a second penalty sub-factor of the current service call is determined according to a dependency attribute of the current service call, the penalty factor and a retry number, including: In a case where the current service call is a retry request, if the current service call is a strong dependency call, the retry number is superimposed on the basis of the penalty factor to obtain the second penalty sub-factor, and if the current service call is a weak dependency call, the retry number and a fixed value are superimposed on the basis of the penalty factor.

7. The method of claim 1, wherein, The total amount of processing time is set according to the performance of the distributed system and the user tolerance, and / or the total amount of call number is set according to the number of services of the call link of the distributed system, and / or the penalty factor is set according to the request source type of the user request.

8. A request resource control apparatus characterized by comprising: Including: a user request obtaining unit, a resource allocation unit, a condition judgment unit and a resource management unit, The user request obtaining unit is used to obtain a user request carrying control information, wherein the control information includes a total amount of processing time, a total amount of call number and a penalty factor corresponding to the user request; The resource allocation unit is used to dynamically calculate and allocate sub-control information of a current service call according to the penalty factor, the remaining count of the total amount of processing time and the total amount of call number, and the dependency attribute and retry state of the current service call in the process of processing the user request according to the control information; The condition judgment unit is used to judge whether the service call condition is met based on the sub-control information, and if so, trigger the resource management unit; The resource management unit is used to initiate the current service call carrying the sub-control information, and update the remaining count of the total amount of processing time and the total amount of call number according to the response of the current service call.

9. A computer-readable storage medium having stored thereon a program, characterized in that, The program is executed by the processor to realize the request resource control method in any one of claims 1 to 7.

10. An electronic device, comprising: The electronic device includes at least one processor, and at least one memory connected with the processor; wherein the processor, the memory complete mutual communication through the bus; the processor is used to call the program instruction in the memory, to execute the request resource control method in any one of claims 1 to 7.

Images