CN110535784B

CN110535784B - Traffic management method and device based on confidence interval and computing equipment

Info

Publication number: CN110535784B
Application number: CN201810563547.0A
Authority: CN
Inventors: 李晶; 袁征; 杨少松; 陈柏盛; 孟丹慧
Original assignee: Beijing Sankuai Online Technology Co Ltd
Current assignee: Beijing Sankuai Online Technology Co Ltd
Priority date: 2018-05-23
Filing date: 2018-05-23
Publication date: 2021-01-15
Anticipated expiration: 2038-05-23
Also published as: CN110535784A

Abstract

The disclosure relates to a traffic management method based on a confidence interval, which comprises the following steps: acquiring a confidence flow range of unit time according to historical data of the flow request of the access party; determining an available token interval per unit time based on the confidence traffic range; and determining the number of issued tokens for the traffic request of the access party in the unit time according to the available token interval. According to the embodiment of the disclosure, the issuing of the token is controlled based on the confidence interval trained through the historical data, and more reasonable traffic control can be realized.

Description

Traffic management method and device based on confidence interval and computing equipment

Technical Field

The present disclosure relates to the field of computer network technologies, and in particular, to a traffic management method and apparatus based on a confidence interval, and a computing device.

Background

In the internet era, a plurality of mature system platforms package website services into a series of computer-recognizable data interfaces which are opened for third-party developers to use, and the platforms are called open platforms. Typically, many third party systems will have access to the open platform at the same time. Therefore, in order to ensure the stable performance of the open platform, it is necessary to reasonably manage and control the traffic from the access system, so as to limit the invocation of the open platform system service by the access system to a reasonable range.

At present, most of open platform systems adopt Hystrix (porcupine) open source components to realize flow management, and the basic realization principle is that corresponding current limiting units are arranged according to different interfaces, a threshold value is set for each current limiting unit according to human experience, and Hystrix can automatically reject the flow exceeding the threshold value.

However, the above traffic management method based on Hystrix estimates the traffic threshold based on human experience, and the consideration factor is limited, and intelligent threshold setting cannot be realized. In addition, this method performs traffic management only for each interface, and cannot support separate threshold setting for different access parties that call the same interface.

Disclosure of Invention

An object of the present disclosure is to provide a traffic management method, apparatus, storage medium, and computing device based on a confidence interval, thereby overcoming, at least to some extent, one or more of the problems due to the limitations and disadvantages of the related art.

Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by practice of the disclosure.

According to a first aspect of the embodiments of the present disclosure, there is provided a traffic management method based on a confidence interval, including: acquiring a confidence flow range of unit time according to historical data of the flow request of the access party; determining an available token interval per unit time based on the confidence traffic range; and determining the number of issued tokens for the traffic request of the access party in the unit time according to the available token interval.

According to a second aspect of the embodiments of the present disclosure, there is provided a traffic management device based on a confidence interval, including: the confidence interval module is set to acquire a confidence flow range of unit time according to historical data of the flow request of the access party; a token calculation module configured to determine an available token interval for the unit time based on the confidence traffic range; and the traffic control module is set to determine the number of issued tokens aiming at the traffic request of the access party in the unit time according to the available token interval.

According to a third aspect of the embodiments of the present disclosure, there is provided a storage medium storing a computer program which, when executed by a processor of a computing device, causes the computing device to perform the traffic management method according to any of the embodiments of the present disclosure.

According to a fourth aspect of embodiments of the present disclosure, there is provided a computing device comprising: a processor; a memory storing instructions executable by the processor; wherein the processor is configured to perform the traffic management method according to any of the embodiments of the present disclosure.

According to the embodiment of the disclosure, the issuing of the token is controlled based on the confidence interval trained through the historical data, and more reasonable traffic control can be realized.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

Fig. 1 is a flow chart of a traffic management method based on confidence intervals according to an embodiment of the present disclosure.

FIG. 2 is a schematic flow chart diagram illustrating step 101 shown in FIG. 1 according to an embodiment of the present disclosure.

FIG. 3 is a schematic flow chart diagram illustrating step 102 shown in FIG. 1 according to one embodiment of the present disclosure.

FIG. 4 is a schematic flow chart diagram illustrating step 103 shown in FIG. 1 according to an embodiment of the present disclosure.

Fig. 5 is a schematic block diagram of a traffic management device based on a confidence interval according to an embodiment of the present disclosure.

Fig. 6 is a schematic block diagram of a traffic management device based on a confidence interval according to another embodiment of the present disclosure.

FIG. 7 is a schematic block diagram of a computing device according to an embodiment of the present disclosure.

Detailed Description

The principles and spirit of the present invention will be described with reference to a number of exemplary embodiments. It is understood that these embodiments are given solely for the purpose of enabling those skilled in the art to better understand and to practice the invention, and are not intended to limit the scope of the invention in any way. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

As will be appreciated by one skilled in the art, embodiments of the present invention may be embodied as a system, apparatus, device, method, or computer program product. Accordingly, the present disclosure may be embodied in the form of: entirely hardware, entirely software (including firmware, resident software, micro-code, etc.), or a combination of hardware and software.

According to the embodiment of the invention, a traffic management method and device based on a confidence interval, a medium and a computing device are provided.

The principles and spirit of the present invention are explained in detail below with reference to several representative embodiments of the invention.

Fig. 1 is a flowchart illustrating a traffic management method based on confidence interval according to an embodiment of the present disclosure, wherein the method of the embodiment includes the following steps 101-103. In one embodiment, the method of the present embodiment may be performed by, but is not limited to being performed by, any open platform device (e.g., a server).

In step 101, a confidence traffic range per unit time is obtained according to historical data of an access party traffic request.

The traditional Hystrix-based traffic management method is based on artificial experience to perform threshold estimation on each interface method, the consideration factors are limited, and intelligent setting of the threshold cannot be realized. In addition, traffic management based on Hystrix only controls each interface individually, and different access parties calling one interface method simultaneously cannot perform different threshold value configurations.

In one embodiment, the method of the present disclosure records data of each traffic request of each access party, so that step 101 may predict the upper and lower flow limit values of each current limiting unit in a unit time in the future based on machine learning algorithm according to the recorded historical data, so as to guide the normal flow range of each current limiting unit in the unit time in the future. The unit time herein may be arbitrarily set as needed, for example, to one minute, one quarter, one hour, and the like. The current limiting units herein may be provided, for example, corresponding to the interface methods of the open platform, and each interface method may correspond to one current limiting unit.

In another embodiment, the method of the present disclosure may record the historical traffic request data by differentiating different access parties, so that not only the corresponding confidence traffic ranges may be predicted for each current limiting unit, but also the corresponding confidence traffic ranges may be predicted for different access parties for the same current limiting unit, thereby implementing more accurate traffic management and control.

In step 102, an available token interval per time unit is determined based on the confidence traffic range.

The confidence traffic range obtained in step 101 represents a prediction of traffic demand of the current limiting unit in a future period of time, and in order to further manage traffic based on the prediction, the embodiment of the present disclosure adopts a token issuing mechanism based on the confidence traffic range to allow or reject a traffic request.

In one embodiment, corresponding token buckets may be set for different flow limiting units, and the available token intervals per token bucket per unit time may be set based on the confidence traffic range in step 102. For example, the upper limit value of the traffic of the confidence traffic range corresponds to the upper limit number of the available token intervals, and can be used to determine the total number of tokens in a unit time for each token bucket; the lower limit value of the flow corresponds to the lower limit number of the available token interval, and can be used for monitoring the low-flow use condition and giving an alarm.

In step 103, the number of issued tokens for the traffic request of the access party in unit time is determined according to the available token interval.

Taking the application of the method disclosed by the present disclosure to the open platform as an example, when receiving a traffic request from an access party, the open platform records data of the request on the one hand to be used as a basis for predicting a traffic range of the trusted channel in future unit time, and on the other hand, performs traffic control in current unit time based on the available token interval obtained through step 102.

For example, when receiving a traffic request from an access party, the open platform determines whether a current limiting unit (i.e., an interface) to which the request is directed has remaining tokens in a token bucket in the current unit time, and if so, normally issues tokens to allow the current traffic request, and deducts the corresponding number of tokens, otherwise, rejects the current traffic request and gives an alarm.

FIG. 2 is a schematic flow chart of the step 101 shown in FIG. 1 according to an embodiment of the present disclosure, and as shown in the figure, the step 101 of the present embodiment includes the following

sub-steps

201 and 203. In one embodiment, the steps of the present embodiment may be performed by, but are not limited to being performed by, any open platform device (e.g., a server).

In step 201, a request to obtain a confidence traffic range is received.

The confidence traffic range is obtained based on historical data per unit time, so that, in one embodiment, after the current traffic request per unit time completes recording, a prediction of the confidence traffic range for a future unit time (e.g., the same time period on the next day) may be triggered. Embodiments of the present disclosure are also not so limited, and step 201 may also be triggered based on manual operation, for example.

In addition, for the case that there is no historical data as a basis, for example, at the initial start-up stage of the system, the embodiment of the present disclosure may also obtain the confidence flow rate range through manual input by a maintenance person or an automatic default configuration of the system, which also falls within the protection scope of the present disclosure.

In step 202, an upper limit model and a lower limit model are respectively established according to the confidence in the acquisition request.

Traffic ranges trained based on historical data are too broad to achieve efficient traffic management. To this end, step 202 builds the upper and lower limit models, respectively, based on the confidence levels set in the confidence flow range calculation request, with lower confidence levels resulting in narrower flow ranges and higher confidence levels resulting in wider flow ranges. In one embodiment, the confidence may be 0.95, and it is identified that 95% of the traffic is expected to fall in this interval, and the higher the confidence, the higher the probability that the real traffic will eventually fall in the interval.

In one embodiment, a GBR (Gradient Boosting regression) upper limit model with a loss function of quantile and a GBR lower limit model with a loss function of quantile may be established. Both the upper and lower limit models described herein are used to characterize the relationship between the input, which is the characteristic data that affects the flow, and the output, which is the flow of the flow restriction unit. In this embodiment, the upper limit model and the lower limit model are both based on the GBR basic model with a loss function of quantile, and the difference between the upper limit model and the lower limit model is that the parameters are different. For example, for an example with a confidence value of 0.95, the confidence value of the upper limit model is 0.95, and the confidence value of the corresponding lower limit model is 1-0.95 — 0.05.

In step 203, based on the upper limit model and the lower limit model, fitting is performed by using historical data, and a flow upper limit value and a flow lower limit value which meet the confidence degree are obtained respectively.

Based on the upper limit model and the lower limit model obtained in step 202, the historical data of the flow request can be used for fitting in step 203 to obtain an upper flow limit and a lower flow limit which meet the confidence level, and the two values are combined to obtain a confidence flow range. The purpose of data fitting is to find a certain expression relationship between input and output, that is, a process of solving unknown parameters of the model, and the process of fitting using historical data in step 203 can be understood as that values of unknown parameters in the upper limit model and the lower limit model are finally calculated according to the continuous iterative fitting of historical data features affecting flow and historical real flow.

According to the embodiment of the disclosure, the confidence flow range of the future unit time is trained and predicted based on the historical data of the flow request, so that the intelligent setting of the flow threshold value can be realized, and the problem that the consideration factor is limited due to the fact that the threshold value is set according to human experience is avoided.

FIG. 3 is a schematic flow chart of the step 102 shown in FIG. 1 according to an embodiment of the present disclosure, wherein the step 102 of the embodiment includes the following

sub-steps

301 and 304. In one embodiment, the steps of the present embodiment may be performed by, but are not limited to being performed by, any open platform device (e.g., a server).

In step 301, a corresponding confidence flow range is obtained according to the flow limiting unit.

As mentioned above, the current limiting units may be configured for different interface methods, and accordingly, step 101 may calculate corresponding confidence flow ranges for different current limiting units. Taking the application of the method disclosed in the present disclosure to an open platform as an example, when the flow monitoring in the previous unit time is finished, the open platform may obtain a corresponding confidence flow range according to the flow limiting unit in step 301, and use the confidence flow range as a basis for subsequently setting the token bucket.

In step 302, it is determined whether the current limiting unit uses the above confidence flow range, if so, go to step 303, otherwise, the upper limit number of the available token interval is set to the preset maximum number.

Taking the method disclosed by the present disclosure applied to an open platform as an example, the operation parameters of the open platform can be set based on external input, and the setting objects may include, but are not limited to, whether to adopt traffic control, whether each current limiting unit belongs to a core service, and the like.

In the process of implementing the traffic management method disclosed by the present disclosure, an access party may stop adopting traffic control at a specific stage as described above when the generated traffic is unpredictable at the initial access stage or during a stress test process, or when a problem occurs in a token calculation process, or in some other system operation scenarios, so as to cancel a calculation result using a token.

Here, in step 302, it may be determined whether the current throttling unit is to use the calculation result of the confidence flow rate range based on the set operation parameters, and if not, the upper limit number of the available token interval may be directly set to a preset maximum number, otherwise, the flow is continued.

In one embodiment, the preset maximum number may be set based on external input, so that human intervention may be introduced in the flow monitoring, enabling intervention and adjustability of the flow monitoring.

In step 303, it is determined whether the access party has access right to the current limiting unit, if yes, the process goes to step 304, otherwise, the upper limit number of the available token interval is set to zero.

Taking the application of the method disclosed by the invention to an open platform as an example, different access parties can set different access rights for different interface methods due to the difference of platform system updating or platform and access party cooperation protocols. Here, in the case where different token buckets are set for each access party, the upper limit of the token bucket may be set according to whether each access party has an access right to the current limiting unit in step 303. For an access party that does not have access to the current limiting unit, step 303 sets the upper limit number of available token intervals corresponding to the access party to zero.

In step 304, an upper and lower number of available token intervals are set based on the confidence traffic range.

After the determination in

steps

302 and 303, it may be determined that the current throttling unit uses the confidence traffic range, and the access party has access right to the current throttling unit, so that in step 304, the upper limit number and the lower limit number of the available token interval may be set for the access party based on the confidence traffic range obtained in step 301. In one embodiment, the upper limit value of the traffic of the confidence traffic range corresponds to the upper limit number of the available token interval, and can be used for determining the total token number of the token bucket in unit time; the lower limit value of the flow corresponds to the lower limit number of the available token interval, and can be used for monitoring the low-flow use condition and giving an alarm.

In one embodiment, step 304 is based on setting the available token interval according to the confidence flow range, and may also introduce a reference to an external input, for example, an upper limit number and/or a lower limit number of the available token interval may be set in combination with a manually input adjustment value, so that human intervention may be introduced in flow monitoring, enabling intervention and adjustability of flow monitoring.

As can be seen from the above flow, the sequence between

steps

302 and 303 may be interchanged, that is, it may be determined whether the access party has access right to the current limiting unit, and if yes, it may be determined whether the current limiting unit uses the above confidence traffic range, which also falls within the scope of the embodiments of the present disclosure.

According to the embodiment of the disclosure, the upper limit number and the lower limit number of the available token interval are set based on the confidence traffic range, so that more accurate traffic monitoring can be realized.

In addition, the access authority of the access party can be considered in combination when the available token interval is set, so that different threshold values can be set for different access parties, and more flexible traffic monitoring can be realized.

In addition, when the available token interval is set, external input parameters can be combined and referred, so that human intervention can be introduced into flow monitoring, and intervention and adjustability of flow monitoring can be realized.

FIG. 4 is a schematic flow chart of the step 103 shown in FIG. 1 according to an embodiment of the present disclosure, wherein the step 103 of the embodiment includes the following

sub-steps

401 and 404. In one embodiment, the steps of the present embodiment may be performed by, but are not limited to being performed by, any open platform device (e.g., a server).

In step 401, a corresponding flow limiting unit is determined according to the flow request.

In one embodiment, as described in step 103 of the embodiment shown in fig. 1, when a traffic request of an access party is received, data of the request may be recorded on the one hand as a basis for subsequently predicting a traffic range of a built-in signal per unit time in the future, and on the other hand, traffic control per unit time is performed on the current basis of an available token interval that has been obtained.

Since the available token intervals are set for different flow limiting units, step 401 may determine the flow limiting unit to which it is directed according to the traffic request, for example, determine the interface method that it calls.

In one embodiment, when the available token interval is set by both the current limiting unit and the access party, step 401 may further include determining the corresponding access party according to the traffic request.

In step 402, it is determined whether the total number of requests of the current limiting unit in unit time exceeds the upper limit number of the available token interval, if yes, go to step 403, otherwise, issue a token to allow the current traffic request and deduct the corresponding token.

According to the determination result in step 401, step 402 may obtain an available token interval corresponding to the current throttling unit, and further determine whether the total number of requests of the current throttling unit in unit time exceeds an upper limit number of the available token interval, for example, determine whether there are remaining tokens in a token bucket of the current throttling unit.

In an embodiment, when the available token interval is set according to both the current limiting unit and the access party, step 402 may also obtain an available token interval corresponding to the current access party under the current limiting unit, and further determine whether the total number of requests of the access party to the current limiting unit in a unit time exceeds an upper limit number of the available token interval, for example, determine whether there are remaining tokens in a token bucket corresponding to the current limiting unit and the access party.

In one embodiment, when the setting of the available token intervals in step 102 takes into account the access rights of the access parties to each current limiting unit, the access parties that have no access rights to the current limiting unit may be set with an upper limit number of-1 available token intervals, for example. Accordingly, step 402 may further include a determination of whether the remaining token is less than zero, and if so, the current traffic request may be directly rejected without a subsequent determination, otherwise, the flow may proceed to step 403.

In step 403, it is determined whether the current limiting unit belongs to the core service, if yes, the standby token is used to allow the current traffic request, otherwise, the current traffic request is rejected.

Taking the application of the method disclosed by the present disclosure to an Open platform as an example, the Open-auth interface of the Open platform can be set based on external input, for example, whether each current limiting unit belongs to a core service is set.

When it is determined in step 403 that the current traffic request is directed to the current throttling unit belongs to the core service, even if it is determined in step 402 that the total number of requests of the current throttling unit in a unit time exceeds the upper limit number of the available token intervals, in other words, even if there are no tokens remaining in the corresponding token bucket, in order to ensure normal operation of the core service, the standby token can be used to allow the current traffic request. The standby token may be set uniformly based on the performance margin of the entire system, or may be set separately based on the importance of each core service, for example, and the embodiment of the disclosure is not limited thereto.

On the other hand, when it is determined in step 403 that the current flow limiting unit for which the current flow request is directed does not belong to the core service, since it is determined in step 402 that the total number of requests of the flow limiting unit in the unit time exceeds the upper limit number of the available token intervals, in other words, since there are no tokens remaining in the corresponding token bucket, the current flow request can be directly rejected and an alarm can be given.

In step 404, the token usage number of the current limiting unit is acquired at the end of the unit time, and when the token usage number is determined to be lower than the lower limit number of the available token intervals, a notification is sent to the alarm receiver corresponding to the current limiting unit.

Unlike the Hystrix method which can only process flows exceeding a threshold, the embodiment of the disclosure can monitor and process low-flow conditions in addition to monitoring the upper flow limit according to the above steps.

In one embodiment, the token usage of each current limiting unit may be counted at the end of the unit time, and if it is determined that the token usage number of a certain current limiting unit in the unit time is lower than the lower limit number of the available token interval, it indicates that the access traffic of the current limiting unit does not reach the predicted lower limit of the normal traffic range, so step 404 may send an alarm to an alarm receiver corresponding to the current limiting unit, thereby playing roles of prompting an exception and preventing a fault.

In addition, although the step 404 is only described in the embodiment of fig. 4, the embodiments of the present disclosure are not limited thereto, and the step 404 may be combined with any of the foregoing embodiments or their combined embodiments according to the needs of the usage scenario, and such a combination manner should fall within the scope of the embodiments of the present disclosure.

According to the embodiment of the disclosure, different strategies can be adopted for exceeding the traffic by distinguishing the core service from the non-core service, so that more flexible traffic control is realized, for example, traffic rejection can be performed decoupled from a transaction system. In other words, based on the embodiments of the present disclosure, traffic management for core services and non-core services can be performed in a unified configuration platform, not in an actual functional system, and thus, no modification of the functional system is required. The functional system may focus on business logic processing and need not process logic that is a core service or not.

In addition, according to the embodiment of the present disclosure, not only the flow exceeding the threshold value but also the low flow condition can be monitored.

The example embodiment also provides a traffic management device based on the confidence interval.

Fig. 5 is a schematic block diagram of a traffic management device based on a confidence interval according to an embodiment of the present disclosure. As shown, the apparatus of the present embodiment includes but is not limited to: a confidence interval module 51, a token calculation module 52 and a traffic policing module 53.

The confidence interval module 51 is arranged to obtain confidence traffic ranges per unit time based on historical data of access side traffic requests.

The token computation module 52 is arranged to determine an available token interval per time unit based on the confidence flow range.

The traffic policing module 53 is arranged to determine the number of tokens issued for a traffic request per unit time for an access party in dependence on the available token interval.

Fig. 6 is a schematic block diagram of a traffic management device based on a confidence interval according to another embodiment of the present disclosure. As shown in fig. 6, on the basis of the embodiment shown in fig. 5, the apparatus of this embodiment further includes, but is not limited to: an access module 54, an access setting module 55, a rights management module 56, and a monitoring alarm module 57; confidence interval module 51 includes, but is not limited to: a confidence request unit 511, a model construction unit 512, and a data fitting unit 513; the token computation module 52 includes, but is not limited to: a confidence acquisition unit 521, a current limit reference unit 522, a permission judgment unit 523 and a token interval unit 524; traffic management module 53 includes, but is not limited to: a request analysis unit 531, a token count unit 532, a service judgment unit 533, a token issuance unit 534, and a token statistics unit 535.

The access module 54 is configured to receive a traffic request of an access party, send the request to the confidence interval module 51 for processing, obtain a token from the traffic control module 53 based on the request, perform subsequent processing on the traffic request if the obtaining is successful, and reject the current traffic request if the obtaining is failed. In one embodiment, access module 54 may correspond to an Open-auth module of an Open platform.

The access setting module 55 is arranged to control the access module 54 to set whether it is to adopt the calculation result of the confidence interval module 51, if so, the token calculation module 52 sets the available token interval based on the calculation result of the confidence interval module 51, otherwise, the token calculation module 52 may directly set the upper limit number of the available token interval to the preset maximum number.

The rights management module 56 is arranged to manage access rights of an access party to the current limiting unit. The token calculation module 52 can inquire the access authority through the authority management module 56 when setting the available token interval, and if the access party is determined to have the access authority to the current limiting unit, the available token interval is set based on the calculation result of the confidence interval module 51; otherwise, the token calculation module 52 may directly set the upper limit number of the available token interval to 0, so as to reject the subsequent traffic request of the access party.

The monitoring alarm module 57 is configured to trigger a corresponding alarm according to the management result of the flow management module 53. For example, the monitoring alarm module 57 may be notified of the triggering of an alarm when the token issuance unit 534 denies the traffic request; for another example, when the unit time is over, if the token counting unit 535 determines that the token usage number is lower than the lower limit of the available token interval, the monitoring alarm module 57 may also be triggered to notify the alarm recipient corresponding to the current limiting unit.

The confidence request unit 511 is arranged to receive an acquisition request for a confidence traffic range.

The model construction unit 512 is arranged to build an upper limit model and a lower limit model, respectively, depending on the confidence in the acquisition request.

The data fitting unit 513 is configured to fit using the historical data based on the upper limit model and the lower limit model, resulting in an upper flow limit value and a lower flow limit value, respectively, that meet the above confidence level.

The confidence obtaining unit 521 is arranged to obtain the corresponding confidence flow range according to the flow limiting unit.

The current-limiting reference unit 522 is used to determine the setting result of the access setting module 55 on the access module 54, and determine whether to use the confidence traffic range acquired by the confidence acquiring unit 521.

The permission judging unit 523 is configured to determine the current limiting unit access permission set by the permission management module 56 for the access party.

The token interval unit 524 is configured to set an available token interval in accordance with the output results of the confidence acquiring unit 521, the current limit reference unit 522, and the authority judging unit 523 in a comprehensive manner. For example, when the current limit reference unit 522 determines that the current limit unit does not use the above-described confidence flow rate range, the token interval unit 524 sets the upper limit number of available token intervals to a preset maximum number. For example, when the authority judgment unit 523 determines that the access side has no access authority to the current limiter unit, the token interval unit 524 sets the upper limit number of available token intervals to zero. For another example, when the current limit reference unit 522 determines that the current limit unit uses the above-mentioned confidence traffic range and the authority judgment unit 523 determines that the access party has an access authority to the current limit unit, the token interval unit 524 sets the upper limit number and the lower limit number of the available token intervals based on the confidence traffic range acquired by the confidence acquisition unit 521.

In another embodiment, the token interval unit 524 is further arranged to adjust the available token interval based on the received user input.

The request analysis unit 531 is arranged to determine a corresponding flow limiting unit based on the flow request.

The token counting unit 532 is configured to determine whether the total number of requests per unit time of the current limiting unit exceeds the upper limit number of available token intervals, for example, whether there are remaining tokens in the token bucket corresponding to the current limiting unit.

The service decision unit 533 is arranged to determine whether the current limiting unit belongs to a core service.

The token issuance unit 534 is configured to control issuance of tokens in accordance with the output results of the token counting unit 532 and the service judgment unit 533 in combination. For example, when the token counting unit 532 determines that the total number of requests of the current limiting unit in a unit time does not exceed the upper limit number of the available token interval, the token issuing unit 534 issues a token to allow the current traffic request and informs the token counting unit 532 to deduct the corresponding token. For another example, when the service judging unit 533 determines that the current flow limiting unit belongs to the core service, the token issuing unit 534 uses the standby token to allow the traffic request. For another example, when the token counting unit 532 determines that the total number of requests of the current limiting unit in a unit time exceeds the upper limit number of the available token interval, and the service judging unit 533 determines that the current limiting unit does not belong to the core service, the token issuing unit 534 rejects issuing the token, so as to achieve the effect of rejecting the flow request, and simultaneously, the monitoring alarm module 57 may also be notified to trigger the alarm.

The token statistics unit 535 is configured to obtain the number of token uses corresponding to each current limiting unit at the end of the unit time, and to trigger the monitoring alarm module 57 to send a notification to the alarm recipient corresponding to each current limiting unit when it is determined that the number of token uses is below the lower limit number of the available token intervals.

With regard to the apparatus in the above-described embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units. The components shown as modules or units may or may not be physical units, i.e. may be located in one place or may also be distributed over a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the disclosed solution. One of ordinary skill in the art can understand and implement it without inventive effort.

Through the description of the above embodiments, those skilled in the art will readily understand that the above described exemplary embodiments may be implemented by software, or by software in combination with necessary hardware.

For example, in an example embodiment, there is also provided a computer readable storage medium, on which a computer program is stored, which when executed by a processor, may implement the steps of the method described in any of the above embodiments. The detailed description of the steps of the method can refer to the detailed description in the foregoing embodiments, and the detailed description is omitted here. The computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

In another example embodiment, a computing device is also provided, where the computing device may be a mobile terminal such as a mobile phone and a tablet computer, and may also be a terminal device such as a desktop computer and a server, which is not limited in this example embodiment. FIG. 7 shows a schematic diagram of a computing device 70 in an example embodiment according to the present disclosure. For example, computing device 70 may be provided as a mobile terminal. Referring to fig. 7, the device 70 includes a processing component 71 that further includes one or more processors, and memory resources, represented by memory 72, for storing instructions, such as applications, that are executable by the processing component 71. The application programs stored in memory 72 may include one or more modules that each correspond to a set of instructions. Furthermore, the processing component 71 is configured to execute instructions to perform the method of any of the embodiments described above and any combination thereof. The steps of the method can refer to the detailed description in the foregoing method embodiments, and are not repeated herein.

Computing device 70 may also include a power component 73 configured to perform power management of computing device 70, a wired or wireless network interface 74 configured to connect computing device 70 to a network, and an input output (I/O) interface 75. Computing device 70 may operate based on an operating system stored in memory 72, such as Android, IOS, or the like.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

While the present disclosure has been described with reference to several exemplary embodiments, it is understood that the terminology used is intended to be in the nature of words of description and illustration, rather than of limitation. As the present disclosure may be embodied in several forms without departing from the spirit or essential characteristics thereof, it should also be understood that the above-described embodiments are not limited by any of the details of the foregoing description, but rather should be construed broadly within its spirit and scope as defined in the appended claims, and therefore all changes and modifications that fall within the meets and bounds of the claims, or equivalences of such meets and bounds are therefore intended to be embraced by the appended claims.

Claims

1. A traffic management method based on confidence interval comprises the following steps:

acquiring a confidence flow range of unit time according to historical data of the flow request of the access party; if receiving access party flow requests corresponding to different access parties of the same current limiting unit, obtaining the confidence flow range matched with the corresponding access parties;

determining an available token interval per unit time based on the confidence traffic range; and

determining the number of tokens issued for the traffic request of the access party in the unit time according to the available token interval;

wherein the determining the available token interval per unit time based on the confidence traffic range comprises:

obtaining a corresponding confidence flow range according to the flow limiting units, wherein the flow limiting units respectively correspond to different interfaces;

when the current limiting unit is determined not to use the confidence flow range, setting the upper limit number of the available token interval as a preset maximum number;

when the access party is determined not to have the access right to the current limiting unit, setting the upper limit number of the available token interval to be zero;

and when the current limiting unit is determined to use the confidence traffic range and the access party has access right to the current limiting unit, setting an upper limit number and a lower limit number of the available token intervals based on the confidence traffic range.

2. The method of claim 1, wherein said obtaining a confidence traffic range per unit time based on historical data of access side traffic requests comprises:

receiving an acquisition request of the confidence flow range;

respectively establishing an upper limit model and a lower limit model according to the confidence in the acquisition request; and

and fitting by using the historical data based on the upper limit model and the lower limit model to respectively obtain a flow upper limit value and a flow lower limit value which accord with the confidence coefficient.

3. The method of claim 1, further comprising: adjusting the available token interval based on the received user input.

4. The method of claim 1, wherein said determining the number of tokens issued for the traffic requests of the access party per unit time according to the available token interval comprises:

determining corresponding current limiting units according to the flow requests, wherein the current limiting units correspond to different interfaces respectively; and

and issuing tokens to allow the traffic requests and deduct corresponding tokens when determining that the total number of the requests of the current limiting unit in the unit time does not exceed the upper limit number of the available token interval.

5. The method of claim 4, wherein said determining the number of tokens issued for the traffic requests of the access party per unit time according to the available token interval further comprises:

when the total number of requests of the current limiting unit in the unit time is determined to exceed the upper limit number of the available token interval and the current limiting unit belongs to preset core service, using a standby token to allow the traffic requests; and

and rejecting the flow request when the total number of the requests exceeds the upper limit number of the available token interval and the current limiting unit does not belong to the preset core service.

6. The method of any of claims 1-2 and 4-5, further comprising:

obtaining the token use number corresponding to each current limiting unit when the unit time is over, wherein the current limiting units correspond to different interfaces respectively; and

and when the token use number is determined to be lower than the lower limit number of the available token interval, sending a notice to an alarm receiving party corresponding to each current limiting unit.

7. A traffic management device based on confidence intervals, comprising:

the confidence interval module is set to acquire a confidence flow range of unit time according to historical data of the flow request of the access party; if receiving access party flow requests corresponding to different access parties of the same current limiting unit, obtaining the confidence flow range matched with the corresponding access parties;

a token calculation module configured to determine an available token interval for the unit time based on the confidence traffic range; and

the flow control module is set to determine the number of tokens issued for the flow request of the access party in the unit time according to the available token interval;

wherein the token interval unit determines the available token interval per unit time based on the confidence traffic range, and comprises:

when the current limiting reference unit determines that the current limiting unit does not use the confidence flow range, setting the upper limit number of the available token interval as a preset maximum number;

when the authority judging unit determines that the access party has no access authority to the current limiting unit, the upper limit number of the available token interval is set to be zero;

and when the current limiting reference unit determines that the current limiting unit uses the confidence flow range and the authority judging unit determines that the access party has access authority to the current limiting unit, setting the upper limit number and the lower limit number of the available token interval based on the confidence flow range.

8. A storage medium storing a computer program which, when executed by a processor of a computing device, causes the computing device to perform the method of any of claims 1-6.

9. A computing device, comprising:

a processor;

a memory storing instructions executable by the processor;

wherein the processor is configured to perform the method of any one of claims 1-7.