流量限制方法和系統(tǒng)的制作方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及應(yīng)用服務(wù)技術(shù)領(lǐng)域，特別是涉及一種流量限制方法和系統(tǒng)。
【背景技術(shù)】
[0002]隨著互聯(lián)網(wǎng)的發(fā)展，WEB(互聯(lián)網(wǎng))服務(wù)器承擔(dān)著越來越大的請求量。WEB服務(wù)器的穩(wěn)定性是提供可靠服務(wù)的基本保證。對WEB服務(wù)器實(shí)施流量限制可以有效地保護(hù)WEB服務(wù)器，保證服務(wù)器不會過載，從而提高服務(wù)質(zhì)量，增強(qiáng)服務(wù)提供者的競爭力。
[0003]目前的限流技術(shù)一般采用速率限制，直接采用漏桶算法或者令牌桶算法(Tokenbucket)來實(shí)現(xiàn)流量限制。令牌桶算法是一種經(jīng)典的網(wǎng)絡(luò)流量整形和流量限制算法，可以平滑網(wǎng)絡(luò)流量同時(shí)又允許一定程度的突發(fā)流量。令牌桶算法通常以恒定速率向大小固定的令牌桶注入令牌，以達(dá)到防止網(wǎng)絡(luò)擁塞的目的。其中一個(gè)典型的實(shí)現(xiàn)是Google Guava的RateLimiter (速率限制器)。在實(shí)現(xiàn)過程中，發(fā)明人發(fā)現(xiàn)傳統(tǒng)技術(shù)中至少存在如下問題:
[0004]以速率作為流量限制有一個(gè)隱藏的前提是后臺服務(wù)能夠在限定的時(shí)間內(nèi)完成請求，才可以用固定的速率來放行請求。當(dāng)后端響應(yīng)延遲變大的時(shí)候，請求被堆積在WEB服務(wù)器中，此時(shí)收到的請求速率并沒有變化。但由于WEB服務(wù)器的內(nèi)存等資源被堆積的請求占用不能釋放，一方面會消耗大量的內(nèi)存和線程資源，另一方面WEB服務(wù)器的接受請求的速率會變慢。而類似RateLimiter的技術(shù)方案并不能有效的緩解WEB服務(wù)器的壓力。

【發(fā)明內(nèi)容】

[0005]基于此，有必要針對保障WEB服務(wù)器穩(wěn)定運(yùn)行的問題，提供一種流量限制方法和系統(tǒng)。
[0006]為了實(shí)現(xiàn)上述目的，本發(fā)明技術(shù)方案的實(shí)施例為:
[0007]—方面，提供了一種流量限制方法，包括以下步驟:
[0008]根據(jù)匹配規(guī)則將請求與配置給當(dāng)前后臺服務(wù)的令牌桶進(jìn)行匹配；
[0009]若匹配成功，基于該請求向該令牌桶申請令牌；
[0010]若匹配失敗，返回空值，并判斷配置給各后臺服務(wù)的令牌桶是否均已匹配完畢；
[0011]若未匹配完畢，將下一個(gè)配置有令牌桶的后臺服務(wù)作為當(dāng)前后臺服務(wù)，返回根據(jù)匹配規(guī)則將請求與配置給當(dāng)前后臺服務(wù)的令牌桶進(jìn)行匹配的步驟；
[0012]若匹配完畢，反饋匹配失敗信號。
[0013]另一方面，提供了一種流量限制系統(tǒng)，包括連接WEB服務(wù)器的匹配單元；
[0014]匹配單元用于根據(jù)匹配規(guī)則將請求與配置給當(dāng)前后臺服務(wù)的令牌桶進(jìn)行匹配；并在匹配成功時(shí)，基于該請求向該令牌桶申請令牌；
[0015]匹配單元還用于在匹配失敗時(shí)，返回空值，并判斷配置給各后臺服務(wù)的令牌桶是否均已匹配完畢:在判斷未匹配完畢時(shí)，將下一個(gè)配置有令牌桶的后臺服務(wù)作為當(dāng)前后臺服務(wù)，并根據(jù)匹配規(guī)則將請求與配置給當(dāng)前后臺服務(wù)的令牌桶進(jìn)行匹配；在判斷匹配完畢時(shí)，反饋匹配失敗信號。
[0016]上述技術(shù)方案具有如下有益效果:
[0017]因?yàn)楸景l(fā)明的流量限制方法和系統(tǒng)對令牌桶算法進(jìn)行了改造，對應(yīng)每一種不可靠的后臺服務(wù)配置令牌桶，所以不同于傳統(tǒng)令牌桶算法，本發(fā)明中的令牌不以恒定速率注入，而是由令牌桶自己歸還，克服了 WEB服務(wù)器接受請求的速率變慢的問題，進(jìn)而使本發(fā)明的流量限制方法和系統(tǒng)能夠通過多令牌桶隔離不可靠的后臺服務(wù)，在后端響應(yīng)時(shí)間不確定的情況下，保障WEB服務(wù)器的穩(wěn)定運(yùn)行，堆積的請求不會令服務(wù)器出現(xiàn)掛死或者宕機(jī)的現(xiàn)象，從而更好的控制WEB服務(wù)器的并發(fā)請求數(shù)，使得服務(wù)器更加穩(wěn)定可靠。
【附圖說明】
[0018]通過附圖中所示的本發(fā)明的優(yōu)選實(shí)施例的更具體說明，本發(fā)明的上述及其它目的、特征和優(yōu)勢將變得更加清晰。在全部附圖中相同的附圖標(biāo)記指示相同的部分，且并未刻意按實(shí)際尺寸等比例縮放繪制附圖，重點(diǎn)在于示出本發(fā)明的主旨。
[0019]圖1為本發(fā)明流量限制方法和系統(tǒng)一應(yīng)用場景圖；
[0020]圖2為本發(fā)明流量限制方法和系統(tǒng)的運(yùn)行示意圖；
[0021]圖3為本發(fā)明流量限制方法實(shí)施例1的流程示意圖；
[0022]圖4為本發(fā)明流量限制方法實(shí)施例1中請求與令牌桶進(jìn)行匹配步驟的流程示意圖；
[0023]圖5為本發(fā)明流量限制方法實(shí)施例1中基于請求向匹配成功的令牌桶申請令牌的流程示意圖；
[0024]圖6為本發(fā)明流量限制方法實(shí)施例2的流程示意圖；
[0025]圖7為本發(fā)明流量限制系統(tǒng)實(shí)施例1的系統(tǒng)結(jié)構(gòu)示意圖；
[0026]圖8為本發(fā)明流量限制系統(tǒng)實(shí)施例1中匹配單元的系統(tǒng)結(jié)構(gòu)示意圖；
[0027]圖9為本發(fā)明流量限制系統(tǒng)實(shí)施例1中基于請求向匹配成功的令牌桶申請令牌的系統(tǒng)結(jié)構(gòu)示意圖。
【具體實(shí)施方式】
[0028]為了便于理解本發(fā)明，下面將參照相關(guān)附圖對本發(fā)明進(jìn)行更全面的描述。附圖中給出了本發(fā)明的首選實(shí)施例。但是，本發(fā)明可以以許多不同的形式來實(shí)現(xiàn)，并不限于本文所描述的實(shí)施例。相反地，提供這些實(shí)施例的目的是使對本發(fā)明的公開內(nèi)容更加透徹全面。
[0029]除非另有定義，本文所使用的所有的技術(shù)和科學(xué)術(shù)語與屬于本發(fā)明的技術(shù)領(lǐng)域的技術(shù)人員通常理解的含義相同。本文中在本發(fā)明的說明書中所使用的術(shù)語只是為了描述具體的實(shí)施例的目的，不是旨在于限制本發(fā)明。本文所使用的術(shù)語“及/或”包括一個(gè)或多個(gè)相關(guān)的所列項(xiàng)目的任意的和所有的組合。
[0030]圖1為本發(fā)明流量限制方法和系統(tǒng)的應(yīng)用場景圖。
[0031]如圖1所示，WEB服務(wù)器根據(jù)不同的請求需要訪問不同的后臺服務(wù)。這些后臺服務(wù)可能是內(nèi)部提供的服務(wù)，也可能是第三方提供的服務(wù)。當(dāng)某些服務(wù)不能保證響應(yīng)時(shí)延的時(shí)候，請求會被堆積在WEB服務(wù)器內(nèi)部。
[0032]假設(shè)WEB服務(wù)器每秒收到200個(gè)請求，其中100個(gè)請求屬于后臺服務(wù)_1。如果后臺服務(wù)-1的響應(yīng)變得很緩慢，假設(shè)30秒才能夠返回結(jié)果，那么就會有大約3000個(gè)關(guān)于后臺服務(wù)-1的請求同時(shí)堆積在WEB服務(wù)器中。如果WEB服務(wù)器的并發(fā)數(shù)小于3000，持續(xù)的壓力就有可能導(dǎo)致服務(wù)器出現(xiàn)各種問題，最后出現(xiàn)掛死或者宕機(jī)現(xiàn)象。即使WEB服務(wù)器的容量大于3000，大量堆積的關(guān)于后臺服務(wù)-1的請求占據(jù)了服務(wù)器的資源，其他服務(wù)的請求得不到響應(yīng)，對服務(wù)器的吞吐量也會造成巨大的影響。
[0033]而傳統(tǒng)技術(shù)中的RateLimiter不能有效的解決上述場景所出現(xiàn)的問題。當(dāng)請求被堆積在WEB服務(wù)器的時(shí)候，收到的請求速率并沒有變化。相反由于WEB服務(wù)器的內(nèi)存等資源被堆積的請求占用不能釋放，WEB服務(wù)器的接受請求的速率會變慢。因此，我們需要一種更有效的方法和系統(tǒng)來保護(hù)WEB服務(wù)器。
[0034]為了保障WEB服務(wù)器的穩(wěn)定運(yùn)行，本發(fā)明提供了一種流量限制方法和系統(tǒng)，圖2為本發(fā)明流量限制方法和系統(tǒng)的運(yùn)行示意圖；
[0035]本發(fā)明基于改造的令牌桶算法提出了一種多令牌桶的解決方案，具體如圖2所示，每個(gè)令牌桶對應(yīng)著一種不可靠的后臺服務(wù)。根據(jù)實(shí)際的請求情況設(shè)置每個(gè)令牌桶的容量，使所有令牌桶的總?cè)萘坎淮笥赪EB服務(wù)器容量。其中，不可靠的后臺服務(wù)一般是第三方平臺提供的接口或者內(nèi)部新開發(fā)的服務(wù)器，例如各省的彩鈴平臺或短信平臺等，一般無法控制這種服務(wù)平臺的響應(yīng)時(shí)間，或者要求這種第三方平臺去優(yōu)化系統(tǒng)，使得響應(yīng)內(nèi)部請求的時(shí)間達(dá)到要求，即不能保證響應(yīng)時(shí)延的后臺服務(wù)，因此在實(shí)際應(yīng)用中，需要為WEB服務(wù)器系統(tǒng)提供保護(hù)措施。
[0036]在一個(gè)具體的實(shí)施例中，可以針對一段時(shí)間內(nèi)的在線系統(tǒng)外部請求數(shù)量做統(tǒng)計(jì)，并以此為依據(jù)估算系統(tǒng)的令牌桶容量。而根據(jù)在線系統(tǒng)的數(shù)據(jù)做出統(tǒng)計(jì)得到的令牌桶容量，這個(gè)容量一旦設(shè)定一般不對其做更改。一般而言，WEB服務(wù)器系統(tǒng)的請求量會在某個(gè)范圍內(nèi)波動，因此在設(shè)置令牌桶容量的容量后，也無須進(jìn)行更改。
[0037]基于以上內(nèi)容，本發(fā)明提供了一種流量限制方法實(shí)施例1，具體如下所述:
[0038]本發(fā)明基于改造的令牌桶算法提出了一種多令牌