服務降級：在高併發的情況下，防止用戶一直等待，使用服務降級方式進行處理(返回友好的提示給客戶端，fallback回調方法)。當服務不可用的時候(正在等待的時候、網絡延遲、響應時間過長),客戶端會處於一直等待的狀態。顯然一直等待是不合理的，所以我們應該給客戶端返回一個友好的提示，使用fallback(回調方法)進行服務降級處理。
服務降級目的：爲了提高用戶體驗(自定義消息返回給客戶端)，防止服務雪崩效應。比如：連接超時、網絡延遲、服務器響應時間過長等情況。
服務雪崩效應的產生原因：因爲默認情況下，只有一個線程池處理所有的服務接口，所有的請求都會被一個線程池處理。如果大量的請求訪問同一個接口，當達到tomcat默認極限(可以自己設置)，可能會導致其他服務接口無法訪問。
服務隔離：每個服務接口之間互不影響，服務隔離有2種實現方式，線程池方式、信號量。
1.線程池方式：相當於每個接口(服務)都有自己獨立的線程池，不同的線程池之間互不影響，能夠實現服務接口隔離。缺點：CPU內存開銷較大。
2.信號量方式：底層使用原子計數器(atomic)，針對於每個服務都設置自己的獨立的限制閾值。比如設置每個服務接口最多同時訪問的次數，如果超出緩存隊列請求後，自己實現拒絕策略。
服務熔斷：在高併發的情況下，如果達到一定的極限(可以自己設置閾值),如果流量超出了設置的閾值，然後拒絕訪問，保護當前服務。當服務器達到最大的承受能力的之後，直接拒絕訪問服務，然後調用降級方法，返回友好提示。
目的：爲了防止服務宕機(保護服務)，會進行熔斷處理。
產生的原因：服務請求過多，高併發情況下。可以設置閾值進行限制。超出的請求存放在緩存隊列中，如果緩存隊列中線程滿的話，直接拒絕訪問服務，訪問不了服務(熔斷)
服務限流：
1.計算器方式(滑動計數器)：定義一個原子類，針對於某一個服務實現次數記錄，一旦達到閾值之後，這時候可以直接走服務降級(返回一個友好提示給客戶端)。
舉個例子：限制每60秒內只能接受客戶端10個請求，如果超過10個請求則直接拒絕訪問服務。固定速率 10R/M。
滑動窗口計數器算法原理：創建6個獨立的格子，每個格子都有自己獨立的計數器。每個格子獨立計數10秒。
2.令牌桶算法(Token)：令牌桶分爲2個動作，動作1(固定速率往桶中存入令牌)、動作2(客戶端如果想訪問請求，先從桶中獲取token)。guava 提供的RateLimiter類來進行限流處理。
網址：http://ifeve.com/guava-ratelimiter/
1.傳統的方式整合RateLimiter 有很大的缺點：代碼重複量特別大，而且本身不支持註解方式。
2.如果限流代碼可以放在網關中，相當於針對所有的服務接口都實現限流(可以使用排除法進行排除不進行限流的方法)，維護性不是很強。
3.正常的互聯網公司項目，不是所有的服務接口都需要實現限流方法的，一般只真針對於大流量接口。比如：秒殺搶購、12306搶票等。
4.可以手動封裝一個RateLimiter類 註解來解決這個方法。
3. 漏桶算法
以固定速率從桶中流出水滴，以任意速率往桶中放入水滴，桶容量大小是不會發生改變的。
流入：以任意速率往桶中放入水滴。
流出：以固定速率從桶中流出水滴。
水滴：是唯一不重複的標識。
因爲桶中的容量是固定的，如果流入水滴的速率>流出的水滴速率，桶中的水滴可能會溢出。那麼溢出的水滴請求都是拒絕訪問的，或者直接調用服務降級方法。前提是同一時刻。
限流的目的：爲了保護服務，避免服務宕機。