限流，有個現成的開源項目可以幫助我們來做網關上的限流
用最新的這個版本
在pom.xml加入引用。
在限流的過程中需要存一些信息，可以存在數據庫里 也可以存在redis里。這里我們演示存到數據庫里
比如說配置1分鍾內只能有100個請求。那么當前已經有多少個請求過去了 ，這個是需要記下來的，下一個請求來了 ，把保存的信息再拿出來，然后再去看當前這個請求能不能過。所以需要有存儲。在生產上還是用redis。redis的並發能力比數據庫要高很多。
這里為了看到數據用數據庫
數據庫相關的配置復制過來。
改下名字
下面來做限流相關的配置。
這里也可以緩沖層redis
配置的時候，可以針對這些服務來限流，例如針對token服務，或者針對order服務。
這里是針對所有的請求的默認策略
plicy-list就是針對 某個服務去單獨的限流。
下面配置了針對token的限流規則
order沒有配置，所以按照默認的規則
每個規則下都有四個屬性
refresh-interval:規定時間的窗口，寫1 就是1秒之內可以過多少請求。
limit就是可以過的請求數
quota：這些請求加在一起消耗的時間是多少
下面這樣配置起來就是 1秒之內只能有2個請求。然后這兩個請求的處理時間加起來不能超過1秒。
雖然你請求的次數沒超限，但是你的服務壓力大導致你的服務處理慢的時候，他也會給你把流量限制住。就是這樣一個策略
z
type是根據什么去控制流量。
最簡單的就是根據-url來控制流量
例如 發兩個請求，a的話 1秒內只能有兩個請求，b也是1秒內只能有2個請求。就是這個意思。
如果發一個/user的請求 同樣的路徑，get和post請求意思是不一樣的，get是查詢，post是創建。
這樣就需要這個type：-httpmethod來判斷了。這樣就會把這兩個參數的值混在一起。
同樣是/a的請求 get和post是分別流控。單獨記1秒內過了多少請求。
還有其他的type 例如 -user根據用戶來流控，需要security的支持，一般情況下 不會用。為什么不用，后面再說。
origin，根據ip。每個ip在一秒鍾只能只能發2個請求。這些是可以組合起來交叉用的 。
最終會根據配置生成一個key放到數據庫中。只需要做配置就可以完成流控，大部分情況下不用寫代碼
最終我們用這個默認的
之前在授權的時候50%的幾率不過，這里改成true 每次都過
重新啟動網關
連續多點擊幾次。
429就是請求太多了。我們配置的限流是3秒內只能有2個。
擴展點
數據庫內多了個rate的表
rate_key按照一定規則來生成的。
gateway是網關的名字
order是策略的名字
/orders：POST是請求的路徑和方法
特殊的場景，和業務業管的 可能滿足不了 需求。
例如 優惠券的服務，在使用優惠券的時候，有優惠券的類型。券a的業務處理邏輯比較簡單 一秒鍾可以處理100個。券b的業務邏輯復雜每秒只能處理10個。這時候在同一個服務里面 也就是這個 優惠券的服務里面
需要通過優惠券的類型來決定怎么限流。這個時候上面那種原始的限流就滿足不了 需求了。
限流歸根揭底是你那個key怎么生成的
下面例如 這里配置的是url和mehtod來限流，那么生成的就是根據url和method的生成的key
自己來定義生成的規則，讓這個key生成的時候，可以按照請求中的某一個參數來生成這個key
它的構造函數有兩個參數，我們在子類里面寫上構造函數 也是需要兩個參數，並在構造函數內調用父類的構造函數。super()
覆蓋掉它的key方法。request是請求，route是zuul的路由，policy就是配置的策略。
有了這三個參數，就可以在這里 寫自己的生成key的邏輯，自己來做限流
另外一個可擴展
就是錯誤的處理。默認情況下只要限流生效。就是返回429並返回一些錯誤信息。
在有些情況下 我們需要去做一些記錄。有可能被人攻擊了。如果什么都不做 后面就查不到誰攻擊的
繼承DefaultRateLimitErrorHandler
里面有三個方法。上面兩個是跟限流的數據存取相關。限流的數據要存到數據庫里。然后每個請求進來的時候，拿出來根據規則看這個請求能不能過。
handleSaveError就是往存儲里面去存這個限流的當前信息的時候如果報錯怎么處理。
handleFetch就是從數據庫里面讀出來的時候報錯怎么處理。一般情況下 上面兩個方法 不會去覆蓋它
主要就是handleError這個方法。這個是限流過程中發生了錯誤都會到之類來處理。
可以覆蓋這個方法 自己寫日志等處理
注意
在網關上做限流是有一些問題的
第一：就是耦合的問題，例如優惠券類型的問題，如果后面服務的業務邏輯變了。那么網關的規則也也要改變。網關就要重新部署。例如優惠券的類型 多了一個類型。
應該做到 業務邏輯怎么變，網關不能跟着變，
限流的重量問題。限流只處理從網關進來的請求，不處理微服務之間的請求。
所以在網關這里不要做很細粒度的限流。網關這塊做的是爭對硬件設備的限流。
限流這里的配置類型 有user和role。根據用戶和角色做限流，這些最好不要在網關上做。雖然是可以做。但是最好不在網關上去做。
因為這些東西都涉及到業務。一旦你的業務變化，網關也要跟着變。這個是很麻煩的事
網關上的限流就講這些。