SpringCloud-gateway原理

1.什麼是gateway（網關）

Spring Cloud Gateway是Spring Cloud官方推出的第二代網關框架，取代Zuul網關。網關作爲流量的，在微服務系統中有着非常作用，網關常見的功能有路由轉發、權限校驗、限流控制等作用。本文首先用官方的案例帶領大家來體驗下Spring Cloud的一些簡單的功能，在後續會使用詳細的案例和源碼解析來詳細講解Spring Cloud Gateway.

2.網關的作用如下：

• 協議轉換，路由轉發

• 流量聚合，對流量進行監控，日誌輸出

• 作爲整個系統的前端工程，對流量進行控制，有限流的作用

• 作爲系統的前端邊界，外部流量只能通過網關才能訪問系統

• 可以在網關層做權限的判斷

• 可以在網關層做緩存

Spring Cloud Gateway作爲Spring Cloud框架的第二代網關，在功能上要比Zuul更加的強大，性能也更好。隨着Spring Cloud的版本迭代，Spring Cloud官方有打算棄用Zuul的意思。在筆者調用了Spring Cloud Gateway的使用和功能上，Spring Cloud Gateway替換掉Zuul的成本上是非常低的，幾乎可以無縫切換。Spring Cloud Gateway幾乎包含了zuul的所有功能。

注：該圖片來自官網
如上圖所示，客戶端向Spring Cloud Gateway發出請求。 如果Gateway Handler Mapping確定請求與路由匹配（這個時候就用到predicate），則將其發送到Gateway web handler處理。 Gateway web handler處理請求時會經過一系列的過濾器鏈。 過濾器鏈被虛線劃分的原因是過濾器鏈可以在發送代理請求之前或之後執行過濾邏輯。 先執行所有“pre”過濾器邏輯，然後進行代理請求。 在發出代理請求之後，收到代理服務的響應之後執行“post”過濾器邏輯。這跟zuul的處理過程很類似。在執行所有“pre”過濾器邏輯時，往往進行了鑑權、限流、日誌輸出等功能，以及請求頭的更改、協議的轉換；轉發之後收到響應之後，會執行所有“post”過濾器的邏輯，在這裏可以響應數據進行了修改，比如響應頭、協議的轉換等。

在上面的處理過程中，有一個重要的點就是講請求和路由進行匹配，這時候就需要用到predicate，它是決定了一個請求走哪一個路由。

3.predicate簡介

Predicate來自於java8的接口。Predicate 接受一個輸入參數，返回一個布爾值結果。該接口包含多種默認方法來將Predicate組合成其他複雜的邏輯（比如：與，或，非）。可以用於接口請求參數校驗、判斷新老數據是否有變化需要進行更新操作。add–與、or–或、negate–非。

Spring Cloud Gateway內置了許多Predict,這些Predict的源碼在org.springframework.cloud.gateway.handler.predicate包中，如果讀者有興趣可以閱讀一下。現在列舉各種Predicate如下圖：

在上圖中，有很多類型的Predicate,比如說時間類型的Predicated（AfterRoutePredicateFactory BeforeRoutePredicateFactory BetweenRoutePredicateFactory），當只有滿足特定時間要求的請求會進入到此predicate中，並交由router處理；cookie類型的CookieRoutePredicateFactory，指定的cookie滿足正則匹配，纔會進入此router;以及host、method、path、querparam、remoteaddr類型的predicate，每一種predicate都會對當前的客戶端請求進行判斷，是否滿足當前的要求，如果滿足則交給當前請求處理。如果有很多個Predicate，並且一個請求滿足多個Predicate，則按照配置的順序第一個生效。

4.限流

在高併發的系統中，往往需要在系統中做限流，一方面是爲了防止大量的請求使服務器過載，導致服務不可用，另一方面是爲了防止網絡攻擊。
常見的限流方式，比如Hystrix適用線程池隔離，超過線程池的負載，走熔斷的邏輯。在一般應用服務器中，比如tomcat容器也是通過限制它的線程數來控制併發的；也有通過時間窗口的平均速度來控制流量。常見的限流緯度有比如通過Ip來限流、通過uri來限流、通過用戶訪問頻次來限流。
一般限流都是在網關這一層做，比如Nginx、Openresty、kong、zuul、Spring Cloud Gateway等；也可以在應用層通過Aop這種方式去做限流。

5.常見的限流算法

• 計數器算法
  計數器算法採用計數器實現限流有點簡單粗暴，一般我們會限制一秒鐘的能夠通過的請求數，比如限流qps爲100，算法的實現思路就是從第一個請求進來開始計時，在接下去的1s內，每來一個請求，就把計數加1，如果累加的數字達到了100，那麼後續的請求就會被全部拒絕。等到1s結束後，把計數恢復成0，重新開始計數。具體的實現可以是這樣的：對於每次服務調用，可以通過AtomicLong#incrementAndGet()方法來給計數器加1並返回最新值，通過這個最新值和閾值進行比較。這種實現方式，相信大家都知道有一個弊端：如果我在單位時間1s內的前10ms，已經通過了100個請求，那後面的990ms，只能眼巴巴的把請求拒絕，我們把這種現象稱爲“突刺現象”

• 漏桶算法
  漏桶算法爲了消除”突刺現象”，可以採用漏桶算法實現限流，漏桶算法這個名字就很形象，算法內部有一個容器，類似生活用到的漏斗，當請求進來時，相當於水倒入漏斗，然後從下端小口慢慢勻速的流出。不管上面流量多大，下面流出的速度始終保持不變。不管服務調用方多麼不穩定，通過漏桶算法進行限流，每10毫秒處理一次請求。因爲處理的速度是固定的，請求進來的速度是未知的，可能突然進來很多請求，沒來得及處理的請求就先放在桶裏，既然是個桶，肯定是有容量上限，如果桶滿了，那麼新進來的請求就丟棄。

在算法實現方面，可以準備一個隊列，用來保存請求，另外通過一個線程池（ScheduledExecutorService）來定期從隊列中獲取請求並執行，可以一次性獲取多個併發執行。
這種算法，在使用過後也存在弊端：無法應對短時間的突發流量。

• 令牌桶算法
  從某種意義上講，令牌桶算法是對漏桶算法的一種改進，桶算法能夠限制請求調用的速率，而令牌桶算法能夠在限制調用的平均速率的同時還允許一定程度的突發調用。在令牌桶算法中，存在一個桶，用來存放固定數量的令牌。算法中存在一種機制，以一定的速率往桶中放令牌。每次請求調用需要先獲取令牌，只有拿到令牌，纔有機會繼續執行，否則選擇選擇等待可用的令牌、或者直接拒絕。放令牌這個動作是持續不斷的進行，如果桶中令牌數達到上限，就丟棄令牌，所以就存在這種情況，桶中一直有大量的可用令牌，這時進來的請求就可以直接拿到令牌執行，比如設置qps爲100，那麼限流器初始化完成一秒後，桶中就已經有100個令牌了，這時服務還沒完全啓動好，等啓動完成對外提供服務時，該限流器可以抵擋瞬時的100個請求。所以，只有桶中沒有令牌時，請求才會進行等待，最後相當於以一定的速率執行。
  
  實現思路：可以準備一個隊列，用來保存令牌，另外通過一個線程池定期生成令牌放到隊列中，每來一個請求，就從隊列中獲取一個令牌，並繼續執行。

6.gateway和zuul的區別