前言

不知道你有沒有這樣的經(jīng)歷，線上的系統(tǒng)突然來了很大的流量，有可能是黑客的攻擊，也有可能是業(yè)務量遠遠大于你的預估，如果你的系統(tǒng)沒有做任何的防護措施，這時候系統(tǒng)負載過高，系統(tǒng)資源慢慢耗盡，接口響應越來越慢，直至不可用，這又導致了調(diào)用你接口的上游系統(tǒng)發(fā)生資源耗盡的情況，最終導致系統(tǒng)雪崩。想想就知道，這是一個災難性的后果，那么有什么方法呢？

面對這種突發(fā)流量的場景，核心思路就是要優(yōu)先保證優(yōu)核心業(yè)務和優(yōu)先保證絕大部分用戶。常見的應對手段有四種，降級、熔斷、限流和排隊，下面我會一一講解。

1. 降級

降級指系統(tǒng)將某些業(yè)務或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能，優(yōu)先保證核心功能。

比如淘寶雙11零點搶購的時候你會發(fā)現(xiàn)商品的退貨功能不可以使用了。又比如論壇可以降級為只能看帖子，不能發(fā)帖子；也可以降級為只能看帖子和評論，不能發(fā)評論；

常見的實現(xiàn)降級的方式有兩種：

• 系統(tǒng)后門降級

簡單來說，就是系統(tǒng)預留了后門用于降級操作。例如，系統(tǒng)提供一個降級URL，當訪問這個URL時，就相當于執(zhí)行降級指令，具體的降級指令通過URL的參數(shù)傳入即可。這種方案有一定的安全隱患，所以也會在URL中加入密碼這類安全措施。

系統(tǒng)后門降級的方式實現(xiàn)成本低，但主要缺點是如果服務器數(shù)量多，需要一臺一臺去操作，效率比較低，這在故障處理爭分奪秒的場景下是比較浪費時間的。

• 獨立降級系統(tǒng)

為了解決系統(tǒng)后門降級方式的缺點，我們可以將降級操作獨立到一個單獨的系統(tǒng)中，實現(xiàn)復雜的權限管理、批量操作等功能。

基本架構如下：

2. 熔斷

熔斷是指按照一定的規(guī)則，比如1分鐘內(nèi)60%的請求響應錯誤就停掉對外部接口的訪問，防止某些外部接口故障導致自己的系統(tǒng)處理能力急劇下降或者出故障。

熔斷和降級是兩個比較容易混淆的概念，因為單純從名字上看，好像都有禁止某個功能的意思。但它們的內(nèi)涵是不同的，因為降級的目的是應對系統(tǒng)自身的故障，而熔斷的目的是應對依賴的外部系統(tǒng)故障的情況。

關于服務熔斷的實現(xiàn)，比較主流的有兩種方案，??Spring Cloud Netflix Hystrix??和阿里的??Sentinel??,我們公司的項目用的是??Sentinel??。

• Hystrix是一個用于處理分布式系統(tǒng)的延遲和容錯的一個開源庫，在分布式系統(tǒng)里，許多依賴不可避免的會調(diào)用失敗，比如超時、異常等，Hystrix能保證在一個依賴出現(xiàn)問題的情況下，不會導致整體服務失敗，避免級聯(lián)故障，以提高分布式系統(tǒng)的穩(wěn)定性。
• Sentinel 是阿里中間件團隊開源的，面向分布式服務架構的輕量級高可用流量控制組件，主要以流量為切入點，從流量控制、熔斷降級、系統(tǒng)負載保護等多個維度來幫助用戶保護服務的穩(wěn)定性。

3. 限流

每個系統(tǒng)都有服務的上線，所以當流量超過服務極限能力時，系統(tǒng)可能會出現(xiàn)卡死、崩潰的情況，所以就有了降級和限流。限流其實就是：當高并發(fā)或者瞬時高并發(fā)時，為了保證系統(tǒng)的穩(wěn)定性、可用性，系統(tǒng)以犧牲部分請求為代價或者延遲處理請求為代價，保證系統(tǒng)整體服務可用。

限流一般都是系統(tǒng)內(nèi)實現(xiàn)的，常見的限流方式可以分為兩類：基于請求限流和基于資源限流。

• 基于請求限流

基于請求限流指從外部訪問的請求角度考慮限流，常見的方式有兩種。

第一種是限制總量，也就是限制某個指標的累積上限，常見的是限制當前系統(tǒng)服務的用戶總量，例如：某個直播間限制總用戶數(shù)上限為100萬，超過100萬后新的用戶無法進入；某個搶購活動商品數(shù)量只有100個，限制參與搶購的用戶上限為1萬個，1萬以后的用戶直接拒絕。

第二種是限制時間量，也就是限制一段時間內(nèi)某個指標的上限，例如1分鐘內(nèi)只允許10000個用戶訪問；每秒請求峰值最高為10萬。

無論是限制總量還是限制時間量，共同的特點都是實現(xiàn)簡單，但在實踐中面臨的主要問題是比較難以找到合適的閾值。例如系統(tǒng)設定了1分鐘10000個用戶，但實際上6000個用戶的時候系統(tǒng)就扛不住了；或者達到1分鐘10000用戶后，其實系統(tǒng)壓力還不大，但此時已經(jīng)開始丟棄用戶訪問了。

即使找到了合適的閾值，基于請求限流還面臨硬件相關的問題。例如一臺32核的機器和64核的機器處理能力差別很大，閾值是不同的，可能有的技術人員以為簡單根據(jù)硬件指標進行數(shù)學運算就可以得出來，實際上這樣是不可行的，64核的機器比32核的機器，業(yè)務處理性能并不是2倍的關系，可能是1.5倍，甚至可能是1.1倍。

為了找到合理的閾值，通常情況下可以采用性能壓測來確定閾值，但性能壓測也存在覆蓋場景有限的問題，可能出現(xiàn)某個性能壓測沒有覆蓋的功能導致系統(tǒng)壓力很大；另外一種方式是逐步優(yōu)化：先設定一個閾值然后上線觀察運行情況，發(fā)現(xiàn)不合理就調(diào)整閾值。

基于上述的分析，根據(jù)閾值來限制訪問量的方式更多的適應于業(yè)務功能比較簡單的系統(tǒng)，例如負載均衡系統(tǒng)、網(wǎng)關系統(tǒng)、搶購系統(tǒng)等。

• 基于資源限流

基于請求限流是從系統(tǒng)外部考慮的，而基于資源限流是從系統(tǒng)內(nèi)部考慮的，也就是找到系統(tǒng)內(nèi)部影響性能的關鍵資源，對其使用上限進行限制。常見的內(nèi)部資源包括連接數(shù)、文件句柄、線程數(shù)和請求隊列等。

例如，采用Netty來實現(xiàn)服務器，每個進來的請求都先放入一個隊列，業(yè)務線程再從隊列讀取請求進行處理，隊列長度最大值為10000，隊列滿了就拒絕后面的請求；也可以根據(jù)CPU的負載或者占用率進行限流，當CPU的占用率超過80%的時候就開始拒絕新的請求。

基于資源限流相比基于請求限流能夠更加有效地反映當前系統(tǒng)的壓力，但實際設計時也面臨兩個主要的難點：如何確定關鍵資源，以及如何確定關鍵資源的閾值。

通常情況下，這也是一個逐步調(diào)優(yōu)的過程：設計的時候先根據(jù)推斷選擇某個關鍵資源和閾值，然后測試驗證，再上線觀察，如果發(fā)現(xiàn)不合理，再進行優(yōu)化。

4. 排隊

排隊這種方式，想必大家在熟悉不過了。大家在12306買火車票的時候，是不是會告訴你在排隊中，等待一段時間后才會鎖定車票，付款。年底時，全中國那么多人買票，12306就是通過排隊機制來搞定的。但是也有缺點，那就是用戶體驗沒那么好。

由于排隊需要臨時緩存大量的業(yè)務請求，單個系統(tǒng)內(nèi)部無法緩存這么多數(shù)據(jù)，一般情況下，排隊需要用獨立的系統(tǒng)去實現(xiàn)，例如使用Kafka這類消息隊列來緩存用戶請求。

• 排隊模塊

負責接收用戶的搶購請求，將請求以先入先出的方式保存下來。每一個參加秒殺活動的商品保存一個隊列，隊列的大小可以根據(jù)參與秒殺的商品數(shù)量（或加點余量）自行定義。

• 調(diào)度模塊

負責排隊模塊到服務模塊的動態(tài)調(diào)度，不斷檢查服務模塊，一旦處理能力有空閑，就從排隊隊列頭上把用戶訪問請求調(diào)入服務模塊，并負責向服務模塊分發(fā)請求。這里調(diào)度模塊扮演一個中介的角色，但不只是傳遞請求而已，它還擔負著調(diào)節(jié)系統(tǒng)處理能力的重任。我們可以根據(jù)服務模塊的實際處理能力，動態(tài)調(diào)節(jié)向排隊系統(tǒng)拉取請求的速度。

• 服務模塊

負責調(diào)用真正業(yè)務來處理服務，并返回處理結果，調(diào)用排隊模塊的接口回寫業(yè)務處理結果。

總結

最后我們通過一個表格在總結以下上面4種保證服務高可用的手段。

參考：??https://freegeektime.com/100006601/10312/??