Sentinel
在項目配置檔案中添加配置
打開控制台dashboard頁面需要下載下傳Sentinel-dashboard.jar，并啟動該spring boot項目。控制頁面預設為：localhost:8080 密碼和使用者名都為：sentinel
Sentinel控制台調用的AIP：
localhost:8719/api
Dashboard頁面所有的資訊都是通過這個位址進行擷取的
打開對應的服務面闆，點選簇點鍊路 進入配置頁面。選擇對應的資源名稱，點選流控按鈕開始配置。
在面闆中直接配置即可
配置完成後會顯示配置記錄資訊：
當通路請求數量超過設定的門檻值時，預設傳回的資訊為：
此資訊可以自定義
tips：沒有做持久化的Sentinel每次重新開機都不會儲存做過的配置，所有的配置在無持久化的情況下都是儲存在記憶體中的
自定義RestObject，傳回結果部分資訊存在此對象中：
編寫一個類實作<code>BlockExceptionHandler</code>接口：
當超過限流設定的門檻值時，傳回資訊：
如果需要限流以後傳回一個頁面則需要更改<code>MyBlockExceptionHandler</code>中的部分代碼：
關聯設定：
鍊路：
對入口資源監聽，超過設定門檻值限制本資源的通路。入口資源為所屬組名
異常比例：範圍為0.0 - 1.0，總請求數量*異常比例的請求數會進入服務降級時間為時間視窗設定的時間
異常數：
通過@SentinelResource注解對方法加入Sentinel監控：
設定的發生熔斷時，調用的類：MyFallbackClass
blockHandler = "block",blockHandlerClass = MyBlockHanlderClass.class處理限流
fallback = "fallback",fallbackClass = MyFallbackClass.class 處理降級
在這裡，發生熔斷時調用MyFallbackClass中的fallback2方法
設定規則：
超過門檻值則顯示：
如果設定如下：
則表示，當設定的參數值為5時，它的門檻值為2。超過門檻值進行限流服務降級。
白名單：可以調用；黑名單：不能調用
對于黑白名單的辨別可以放在參數、header中。
對于下列設定：
則請求為：
localhost:9000/app?origin=order
對于這裡的源origin，我們需要實作一個解析類，将其中的源名傳回，如果和設定的流程應用名相同，并且設定為黑名單則該請求無法通路。傳回：
解析類：
請求中的origin字段也可以變為其他的，但是需要和解析類中的擷取的字段一緻即可（猜測）。如果使用origin_header,則請求中就不應該再帶有origin=order,而是應該将該資訊放入到請求header中去。
微服務啟動後，暴露很多http接口，Sentinel-Dashboard通過調用這些接口（localhost:8719/api）進行對微服務的操控。
tips: Sentinel的一些配置
這種方式用的比較少：
MyFallbackClass：
也可使用blockHandler+blockHandlerClass，規則與fallback+fallbackClass一緻。需要注意的是：在MyBlockHandlerClass和MyFallbackClass中的所有被調用的方法都要定義為Static類型!!!
這樣Sentinel可以對RestTemplate的調用進行保護（限流，權限......）注意注解中需要的是降級還是限流。
限流-->blockHandler+blockHandlerClass
降級-->fallback+fallbackClass
第一種方法-配置fallback：
EchoServiceFallback：
第二種方法-配置fallbackFactory：
EchoServiceFallbackFactory.class：
pull 模式的資料源（如本地檔案、RDBMS 等）一般是可寫入的。使用時需要在用戶端注冊資料源：将對應的讀資料源注冊至對應的 RuleManager，将寫資料源注冊至 transport 的 <code>WritableDataSourceRegistry</code> 中。以本地檔案資料源為例：
本地檔案資料源會定時輪詢檔案的變更，讀取規則。這樣我們既可以在應用本地直接修改檔案來更新規則，也可以通過 Sentinel 控制台推送規則。以本地檔案資料源為例，推送過程如下圖所示：
首先 Sentinel 控制台通過 API 将規則推送至用戶端并更新到記憶體中，接着注冊的寫資料源會将新的規則儲存到本地的檔案中。使用 pull 模式的資料源時一般不需要對 Sentinel 控制台進行改造。
這種實作方法好處是簡單，不引入新的依賴，壞處是無法保證監控資料的一緻性。
實操：自定義類FileDataSourceInit：
然後在項目的 <code>resources/META-INF/services</code> 目錄下建立檔案，名為 <code>com.alibaba.csp.sentinel.init.InitFunc</code> ，内容為：
優點
簡單易懂
沒有多餘依賴（比如配置中心、緩存等）
缺點
由于規則是用 FileRefreshableDataSource 定時更新的，是以規則更新會有延遲。如果FileRefreshableDataSource定時時間過大，可能長時間延遲；如果FileRefreshableDataSource過小，又會影響性能；
規則存儲在本地檔案，如果有一天需要遷移微服務，那麼需要把規則檔案一起遷移，否則規則會丢失。
我們提供了 ZooKeeper, Apollo, Nacos 等的動态資料源實作。以 ZooKeeper 為例子，如果要使用第三方的配置中心作為配置管理，您需要做下面的幾件事情:
實作一個公共的 ZooKeeper 用戶端用于推送規則，在 Sentinel 控制台配置項中需要指定 ZooKeeper 的位址，啟動時即建立 ZooKeeper Client。
我們需要針對每個應用（appName），每種規則設定不同的 path（可随時修改）；或者約定大于配置（如 path 的模式統一為 <code>/sentinel_rules/{appName}/{ruleType}</code>，e.g. <code>sentinel_rules/appA/flowRule</code>）。
規則配置頁需要進行相應的改造，直接針對應用次元進行規則配置；修改同個應用多個資源的規則時可以批量進行推送，也可以分别推送。Sentinel 控制台将規則緩存在記憶體中（如 <code>InMemFlowRuleStore</code>），可以對其進行改造使其支援應用次元的規則緩存（key 為 appName），每次添加/修改/删除規則都先更新記憶體中的規則緩存，然後需要推送的時候從規則緩存中擷取全量規則，然後通過上面實作的 Client 将規則推送到 ZooKeeper 即可。
應用用戶端需要注冊對應的讀資料源以監聽變更，可以參考 相關文檔。
從 Sentinel 1.4.0 開始，Sentinel 控制台提供 <code>DynamicRulePublisher</code> 和 <code>DynamicRuleProvider</code> 接口用于實作應用次元的規則推送和拉取，并提供了相關的示例。Sentinel 提供應用次元規則推送的示例頁面（<code>/v2/flow</code>），使用者改造控制台對接配置中心後可直接通過 v2 頁面推送規則至配置中心。改造詳情可參考 應用次元規則推送示例。
部署多個控制台執行個體時，通常需要将規則存至 DB 中，規則變更後同步向配置中心推送規則。
實操：
在元件中有的話就可以不用添加
ds1為自定義名字，需要報紙配置資訊中的一緻
Data id ：nacos-discovery-consumer.json 項目名稱.json
Group：DEFAULT_GROUP
配置格式：JSON
配置内容：根據上圖的格式，自行配置。count = QPS 配置
流程：從Nacos讀取配置，緩存到本地。Sentinel 從本地讀取配置完成持久化操作。