基於Sentinel的高可用限流系統設計及實現

一、背景說明

1、爲什麼要限流

拿旅遊景點舉個示例，每個旅遊景點通常都會有最大的接待量，不可能無限制的放遊客進入，比如故宮每天只賣八萬張票，超過八萬的遊客，無法買票進入，因爲如果超過八萬人，景點的工作人員可能就忙不過來，過於擁擠的景點也會影響遊客的體驗和心情，並且還會有安全隱患；只賣N張票，這就是一種限流的手段。

 

軟件架構中的服務限流也是類似，也是當系統資源不夠的時候，已經不足以應對大量的請求，爲了保證服務還能夠正常運行，那麼按照規則，系統會把多餘的請求直接拒絕掉，以達到限流的效果；大家應用都有參與過雙11，當天晚上的客服系統通常都是不讓訪問的，當用戶訪問的時候會提示“爲了更好的提供服務...請於XX時間後再次訪問”等，這個就是被限流了，也是爲了確保用主要業務，如商品瀏覽、購物車、下單、付款等業務可以更順利，減少由於其它非重要系統對主系統的影響。

2、Sentinel的主要特點

多樣化的流量控制 
熔斷降級 
系統負載保護 
實時監控和控制檯

 

3、默認的架構

 

其默認的架構很簡單，應用的註冊和監控數據，都是保存在Sentinel的內存中的，不能夠直接使用於生產。不過也正因爲其簡單，方便大家體驗，纔會受到這麼多用戶的歡迎，並且其提供了許多的擴展點給用戶，大家可以根據自己的應用場景去設計。

 

二、架構設計

 

設計原則：

1）高可用

2）高可擴展

3）高性能

4）支持高併發

三、具體實現

 

1、sentinel-dashboard的修改

1）修改Metric的存儲

將Metric數據由默認存儲到內存中，修改爲存儲到外部Influxdb集羣中，Influxdb集羣理論上支持任意多個Influxdb實例，sentinel-dashboard會根據app對存儲進行sharding，然後將數據存儲到指定的Influxdb實例中，application.properties 中增加類似如下Influxdb的配置：

#Influxdb理論上可以上多個，以英文的逗號分隔不同Influxdb的URL influxdb.url=http://localhost:8086,
http://localhost:18086 
#目前要求所有Influxdb都使用相同的用戶名和密碼 
influxdb.username=admin 
influxdb.password=admin

 

2）修改限流配置的存儲

將限流配置由默認存儲到內存中，修改爲存儲到外部的Zookeeper中，application.properties 中增加類似如下Influxdb的配置：

dynamic.rules.source.type = zookeeper 
zookeeper.config.connectString = 127.0.0.1:2181 
zookeeper.config.sessionTimeout = 30000 
zookeeper.config.connectionTimeout = 10000

注：ZK中需要建立以下節點用於存儲規則：

/SENTINEL-GROUP/APP-MACHINES 
/SENTINEL-GROUP/AUTHORITY-RULES 
/SENTINEL-GROUP/DEGRADE-RULES 
/SENTINEL-GROUP/FLOW-RULES 
/SENTINEL-GROUP/HOT-RULES 
/SENTINEL-GROUP/SYSTEM-RULES

3）修改應用Metric的獲取方式

默認情況下，sentinel-dashbord會定時通過線程的方式到應用端獲取Metric的數據，其架構如下所示：

這種架構會受限於sentinel-dashbord的任務的處理能力，總會有一個上限，當應用達到幾百個、幾千個的時候，sentinel-dashbord的Metric處理能力就會受收非常大的影響，並且sentinel-dashbord本身會存在單點的風險。

爲了增強sentinel-dashbord的處理能力，規避其單點風險，將Metric的獲取方式修改爲應用主動上報的方式，架構如下所示：

說明：

• 默認架構中的Sentinel Dashboard，其只負責維護連接到其本身的應用，包括從這些連上來的應用中獲取Metric數據、往應用推送或從應用中拉取限流配置、檢測應用是否健康等，其負擔着整體調控的作用，由於保存部分數據在內存中，因而其本身是有狀態的，且本身存在着不可擴展的瓶頸；默認情況下，限流配置都是保存到應用App中，存在着重啓應用就丟失敗的風險。新的架構爲高可用的架構，Sentinel Dashboard中不保存數據，所有的限流配置數據都保存在ZK中，其除了對客戶端APP做健康檢查這一操作以下，不會主動與客戶端APP產生任何交互，且其本身不保存任何數據，因面登陸任何一臺Sentinel Dashboard，對可以整個集羣進行操作，即使有Sentinel Dashboard掛掉，也不會影響到數據的收集和報表的查詢。
• Metric數據默認是保存到Sentinel Dashboard內存中的，不便於長期保存，也不方便和其它第三方圖報展示平臺對接，修改爲將Metric數據保存到Influxdb集羣中，Influxdb集羣爲多個Influxdb實例組成的，使用app做爲Hash key，根據一定的Hash規則將數據分佈存儲到不同的Influxdb中。

這種架構不會由於應用的增多導致sentinel-dashbord成爲瓶頸，因爲sentinel-dashbord也是可以水平擴展的，並且Metric是保存在Influxdb的集羣中，因而在任何一臺Sentinel控制檯上都可以查看到所有應用相同的Metric數據。

 

4）修改應用“機器列表”的存儲

應用“機器列表”的存儲默認是保存在內存中，但是在佈署多個Sentinel控制檯的情況下，保存在內存中的應用機器列表只能夠展示連接到當前Sentinel控制檯本身的應用服務器，而不能夠展示連接到其它Sentinel控制檯服務器的機器，在修改爲將機器列表保存爲ZK中後，在任何一臺Sentinel控制檯服務器上，都可以看到所有的應用機器列表。

 

5）修改應用“降級規則”的存儲

修改應用“降級規則”的存儲爲ZK，應用通過接收ZK的通知更新本地的降級規則。

 

原邏輯：

A、默認的“降級規則”邏輯是保存在應用端的，Sentinel控制檯每次都是通過API的方式從應用去拉取，並且只能夠拉取指定應用、指定IP和指定端口的規則，即只能夠拉取一條，如果需要查看應用集羣中不同服務器上的“降級規則”，只能夠一臺臺的執行查詢；

B、修改“降級規則”也只能夠針對應用集羣中的一臺服務器進行修改，Sentinel控制檯在每次有修改的時候主動通過調用應用的API實現規則變化通知，如果要想通知應用集羣中的所有服務器，只能夠一臺臺的去通知，效率非常低下；

現邏輯：

A、Sentinel控制檯從ZK中獲取當前應用的所有降級規則，並進行展示；

B、修改“降級規則”，Sentinel控制檯負責將其寫到ZK，不再主動通過API的方式調用應用進行通知；

C、應用集羣中的服務器，接收ZK配置變化的通知，再更新配置；

D、去掉頁面上針對一臺臺服務器的配置，只保留針對全部服務器的配置，提升操作效率；

 

6）修改應用的“授權規則”

其實現邏輯和“降級規則”基本一致，也都是Sentinel控制檯通過API從應用端獲取配置，更新規則時，再通過調用應用端的API進行主動通知，改造的方式和“降級規則”基本一致；

 

7）修改應用的“熱點（參數）規則”

其實現邏輯和“降級規則”基本一致，也都是Sentinel控制檯通過API從應用端獲取配置，更新規則時，再通過調用應用端的API進行主動通知，改造的方式和“降級規則”基本一致；

 

8）修改應用的“系統規則”

其實現邏輯和“降級規則”基本一致，也都是Sentinel控制檯通過API從應用端獲取配置，更新規則時，再通過調用應用端的API進行主動通知，改造的方式和“降級規則”基本一致；

 

通過對sentinel-dashbord以上幾點的改造，sentinel-dashbord就可以以集羣的方式進行佈署，水平擴展。

注：當前sentinel-dashboard的版本支持1.7.2-SNAPSHOT～1.8.0-SNAPSHOT的，後續可以在該版本的基礎之上擴展新功能。

Git地址：http://xxx.com/base-component/ld-sentinel/tree/master/ld-sentinel-dashboard

 

2、增加應用Agent

應用Agent包括：

• ld-sentinel-web-spring-boot-starter (支持基於spring boot的web應用限流，自動發現和統計web應用的調用)
• ld-sentinel-web-spring-boot-starter (支持基於spring boot的dubbo應用限流，自動發現和統計dubbo應用的調用)
• ld-sentinel-web-spring-cloud-starter (支持基於spring cloud的應用限流，自動發現和統計web應用的調用和基於Feign的對外調用)
• ld-sentinel-common-spring-boot-starter (使用@SentinelResource註解自定義的應用限流，自動發現和統計註解@SentinelResource自定義的限流使用場景)

應用集成Agent的也很方便，只需要引入對應的maven信賴，在application.properties中做相應的配置即可。

爲了方便應用更方便的集成，項目中包括了對應的示例Example。

 

Git地址：http://xxxx.com/base-component/ld-sentinel/tree/master/ld-sentinel
示例Git地址：http://xxxx.com/base-component/ld-sentinel/tree/master/ld-sentinel-samples

3、增加應用ld-sharding-influxdb

應用ld-sharding-influxdb處於Grafana與Influxdb的中間層，用於處理Grafana從不同的Influxdb sharding庫中查詢數據時的請求拆分，以及結果合併的處理，再將結果統一返回。處理邏輯如下：

1）獲取Grafana請求的所有參數；

2）拆分查詢的SQL語句，並從SQL語句中解析出應用的app名稱，根據應用的app名稱的hash值，與後端總的Influxdb sharding庫數量求與運算，並得到該份數據存儲到後端的真實的Influxdb的連

3）拼裝所的查詢參數，往真實的Influxdb庫發送請求；

4）合併所有SQL的查詢結果，並組裝結果後再返回給Grafana；

application.properties 中增加類似如下Influxdb的配置：

#Influxdb理論上可以上多個，以英文的逗號分隔不同Influxdb的URL 
influxdb.url=http://localhost:8086,http://localhost:18086 
#目前要求所有Influxdb都使用相同的用戶名和密碼 
influxdb.username=admin 
influxdb.password=admin

注：其應用場景目前只適合於查詢條件中包括app參數的查詢，其它的查詢會返回默認的庫；

Git地址：http://xxx.com/base-component/ld-sharding-influxdb

4、Influxdb集羣架構

架構圖示：

每個庫中包含了4個Measurements：

sentinel_metric_dubbo：存放的是dubbo請求的metric
sentinel_metric_web：存放的是web請求的metric
sentinel_metric_other：用於保存非WEB及DUBBO請求的Metric，如使用註解@SentinelResource自定義的限流方式
sentinel_metric_each_last：保留每個應用中的每個請求的最後一份的請求數據

 

Mesurements中保存的數據大致如下：

通過這些維度數據，可以在Grafana中展示Web請求、Dubbo請求及Top耗時請求的不同報表。

 

四、應用的集成

1、環境及版本

1）當前版本

目前ld-sentinel.version的版本號爲：1.0.7

2）Sentinel控制檯地址

測試環境
Nginx登陸地址（後帶了192.168.10.131和192.168.10.132兩個控制檯）：http://192.168.10.130:8080/    sentinel/sentinel
192.168.10.131控制檯：http://192.168.10.131:20440    sentinel/sentinel
192.168.10.132控制檯：http://192.168.10.132:20440    sentinel/sentinel
生產環境
http://sentinel.xxx.com   sentinel/sentinel
預發佈環境
http://172.16.200.8:20440/   sentinel/sentinel

3）Sentinel Grafana地址

測試環境
http://192.168.10.131:3000/  admin/admin
生產環境
http://grafana.xxx.com/d/ECS1u69Zz/sentinel-metric-all?orgId=1

4）Influxdb地址

測試環境
Influxdb 133：http://192.168.10.133:8086  admin/admin
Influxdb 134：http://192.168.10.134:8086  admin/admin
Sharding Influxdb（後帶了192.168.10.133和192.168.10.133兩個Influxdb）：http://192.168.10.132:20430  admin/admin
生產環境
Sharding Influxgh：http://sharding-influxdb.xxx.com

2、基於Spring boot的web應用

1）應用引入ld-sentinel-web-spring-boot-starter

		<dependency>
		    <groupId>xxx</groupId>
		    <artifactId>ld-sentinel-web-spring-boot-starter</artifactId>
		    <version>${ld-sentinel.version}</version>
		</dependency>

2）application.properties增加配置

核心配置

#[應用必填]應用的名稱，也可以在JVM參數中通過-Dproject.name指定，優先讀取配置文件中的，讀取不到再讀取JVM參數中的配置
spring.application.name=sentinel-webmvc-sample
#[應用選填]ZK的連接配置（如果不配置，系統會自動判斷當前是測試環境還是生產環境，並使用相應的配置）
#sentinel.zookeeperAddress = 192.168.10.185:2181
#Sentinel相關的配置項
#[應用選填]Sentinel控制檯地址（如果不配置，系統會自動判斷當前是測試環境還是生產環境，並使用相應的配置）
#sentinel.sentinelServer = 192.168.10.130:8080
[應用選填]當前應用往Sentinel控制檯註冊的端口
#該端口目前主要用於控制檯檢查應用是否還健康，如果未設置則默認使用54321端口，如果本地啓動了多個連接Sentinel控制檯的應用，
#導致該端口被其它應用佔用了，爲了確保應用的順利啓動和正常運行，則會使用30000~40000的隨機端口。
#生產環境強烈建議設置，否則不利用應用端口的管理，應用的每次重啓，在Sentinel控制檯都會顯示原來端口的應用不可用
#注：如果應用運行於容器中，該端口要映射出來
sentinel.apiPort=54321

注：

如果不配置ＺＫ和Sentinel控制檯地址，系統會自動判斷當前是測試環境還是生產環境，並使用相應的配置；如果有配置則使用配置的值覆蓋默認的值。

3）高級應用

A、URL排除：自定義UrlCleaner

包中已經默認實現了URL排的類：com.xxx.sentinel.web.ExcludeUrlCleaner，爲了使用該規則，只需要在application.properties增加如下配置：

#需要排除Sentinel統計的URL的前綴，多個Rest URL以英文逗號分隔
#sentinel.excludeUrlPrefix = 

注：如果實現了自定義UrlCleaner，並且在應用啓動時，通過com.xxx.sentinel.web.WebConfigManager註冊到了系統中，類似如下：

WebConfigManager.setUrlCleaner(new TestUrlCleaner());

則默認的ExcludeUrlCleaner就會不生效。

B、配合授權規則，自定義來源處理

針對WEB應用，默認是不會獲取來源的，也即在Sentinel控制檯配置了針對WEB應用的“授權規則”也不會生效，因爲Sentinel不知道根據什麼規則來判斷來源，需要應用的使用方自定義來源的處理。

來源可以是從一個URL參數中獲取，也可以從請求的Header屬性中獲取；來源可以是一個應用的名稱，也可以是一個IP地址等，這些Sentinel留給了我們充足的想像空間，讓我們自由的發揮實現，只需要實現com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.RequestOriginParser接口，根據當前的應用場景具體處理即可。

以下是一個從URL中獲取一個參數來判斷來源的實例：

/**
 * 授權規則處理示例： <br>
 * 針對配置了授權規則的資源，僅允許在授權規則定義的白名單之內的APP進行訪問，在黑名單之中的、或者沒有定義的APP訪問時，全部都拒絕
 * @author fenglibin
 */
public class WhiteAppRequestOriginParser implements RequestOriginParser {
	private static final String BLACK = "BLACK";
	@Override
	public String parseOrigin(HttpServletRequest request) {
		String app = request.getParameter("app");
		if (app == null || app.trim().length() == 0) {
			return BLACK;
		}
		return app;
	}
}

 

然後com.xxx.sentinel.web.WebConfigManager將該實現註冊到Sentinel中，代碼操作如下：

WebConfigManager.setOriginParser(new WhiteAppRequestOriginParser());

如果在Sentinel控制檯的授權規則做了如下截圖的配置：

則表示/hello2這個接口，只有參數中帶了"app=app2"的請求才可以訪問，其它的全部都會被Block掉。

 

C、自定義異常處理

Sentinel中的流控異常BlockException分爲以下幾種：

FlowException
AuthorityException
DegradeException
ParamFlowException
SystemBlockException

默認的情況下，都是返回以下429代碼的異常：

	@Override
	public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {		
		// Return 429 (Too Many Requests) by default.
        response.setStatus(429);
        StringBuffer url = request.getRequestURL();
        if ("GET".equals(request.getMethod()) && StringUtil.isNotBlank(request.getQueryString())) {
            url.append("?").append(request.getQueryString());
        }
        PrintWriter out = response.getWriter();
        out.print("[LD]You request are blocked. Come back later.");
        out.flush();
        out.close();
	}

也可以針對不同的異常類型，做個性化的異常處理，異常處理類需要實現接口com.alibaba.csp.sentinel.slots.block.BlockException，然後通過com.xxx.sentinel.web.exception.WebBlockExeptionManager註冊應用中：

//設置違返授權規則的被Block的異常處理
WebBlockExeptionManager.setAuthorityExceptionHandler(authorityExceptionHandler);
//設置違返降級規則的被Block的異常處理
WebBlockExeptionManager.setDegradeExceptionHandler(degradeExceptionHandler);
//設置違返熱點參數規則的被Block的異常處理
WebBlockExeptionManager.setParamFlowExceptionHandler(paramFlowExceptionHandler);
//設置違返系統規則的被Block的異常處理
WebBlockExeptionManager.setSystemBlockExceptionHandler(systemBlockExceptionHandler);
//設置違返限流規則的被Block的異常處理
WebBlockExeptionManager.setFlowExceptionHandler(flowExceptionHandler);

也可以統一設置所有的異常處理：

WebBlockExeptionManager.setDefaultExceptionHandler(defaultExceptionHandler);

注：設置了默認限流後，原來已有的所有限流異常處理器都會被替換爲當前的默認處理器，如果還需要單獨對不同的場景使用不同的異常處理器的，需要在後面重新設置相應異常的限流異常處理器。

 

３、基於Spring Cloud的應用

1）應用引入ld-sentinel-web-spring-cloud-starter

		<dependency>
		    <groupId>xxx</groupId>
		    <artifactId>ld-sentinel-web-spring-cloud-starter</artifactId>
		    <version>${ld-sentinel.version}</version>
		</dependency>

基於Spring Cloud應用的核心配置、高級應用（URL排除、配合授權規則自定義來源處理、自定義異常處理）與前面基於Spring Boot應用的處理是一致的。

4、基於Spring boot的dubbo應用

1）應用引入ld-sentinel-web-spring-boot-starter

       <dependency>
            <groupId>xxx</groupId>
	    	<artifactId>ld-sentinel-dubbo-spring-boot-starter</artifactId>
            <version>${ld-sentinel.version}</version>
        </dependency>

2）application.properties增加配置

核心配置

#[應用必填]應用的名稱，也可以在JVM參數中通過-Dproject.name指定，優先讀取配置文件中的，讀取不到再讀取JVM參數中的配置
spring.application.name = ld-sentinel-dubbo-sample
#[應用選填]ZK的連接配置（如果不配置，系統會自動判斷當前是測試環境還是生產環境，並使用相應的配置）
sentinel.zookeeperAddress = 192.168.10.185:2181
#[應用選填]Sentinel控制檯地址（如果不配置，系統會自動判斷當前是測試環境還是生產環境，並使用相應的配置）
sentinel.sentinelServer = 192.168.10.130:8080
[應用選填]當前應用往Sentinel控制檯註冊的端口
#該端口目前主要用於控制檯檢查應用是否還健康，如果未設置則默認使用54321端口，如果本地啓動了多個連接Sentinel控制檯的應用，
#導致該端口被其它應用佔用了，爲了確保應用的順利啓動和正常運行，則會使用30000~40000的隨機端口。
#生產環境強烈建議設置，否則不利用應用端口的管理，應用的每次重啓，在Sentinel控制檯都會顯示原來端口的應用不可用
#注：如果應用運行於容器中，該端口要映射出來
#sentinel.apiPort=54321

3）高級應用

A、Dubbo應用與Web應用有點不同：

不需要自定義UrlCleaner，因爲Sentinel會使用類名加方法做爲Sentinel的資源名稱；

不需要自定義處理來源，Sentinel會使用Dubbo Consumer的名稱做爲來源，如下配置：

<dubbo:application name="dubbo-consumer"/>

中的名稱"dubbo-consumer"會被用於來源，如果需要對其使用配置授權規則，則可以在Sentinel控制檯中的授權規則針對該參數進行處理。

B、自定義異常處理

同WEB中的Block異常一樣，Sentinel中Dubbo的流控異常也分爲以下幾種：

FlowException
AuthorityException
DegradeException
ParamFlowException
SystemBlockException

Dubbo中可以分別定義Provider和Consumer的Block異常處理，將Provider和Consumer的異常處理類，分別使用DubboBlockExeptionManager.DubboProviderFallbackConfig和DubboBlockExeptionManager.DubboConsumerFallbackConfig將其註冊到Sentinel中：

Provider異常處理設置：

//設置違返授權規則的被Block的異常處理
DubboBlockExeptionManager.DubboProviderFallbackConfig.setAuthorityDubboFallback(authorityDubboFallback);
//設置違返降級規則的被Block的異常處理
DubboBlockExeptionManager.DubboProviderFallbackConfig.setDegradeDubboFallback(degradeDubboFallback);
//設置違返限流規則的被Block的異常處理
DubboBlockExeptionManager.DubboProviderFallbackConfig.setFlowDubboFallback(flowDubboFallback);
//設置違返熱點參數規則的被Block的異常處理
DubboBlockExeptionManager.DubboProviderFallbackConfig.setParamFlowDubboFallback(paramFlowDubboFallback);
//設置違返系統規則的被Block的異常處理
DubboBlockExeptionManager.DubboProviderFallbackConfig.setSystemDubboFallback(systemDubboFallback);

Consumer異常處理設置：

//設置違返授權規則的被Block的異常處理
DubboBlockExeptionManager.DubboConsumerFallbackConfig.setAuthorityDubboFallback(authorityDubboFallback);
//設置違返降級規則的被Block的異常處理
DubboBlockExeptionManager.DubboConsumerFallbackConfig.setDegradeDubboFallback(degradeDubboFallback);
//設置違返限流規則的被Block的異常處理
DubboBlockExeptionManager.DubboConsumerFallbackConfig.setFlowDubboFallback(flowDubboFallback);
//設置違返熱點參數規則的被Block的異常處理
DubboBlockExeptionManager.DubboConsumerFallbackConfig.setParamFlowDubboFallback(paramFlowDubboFallback);
//設置違返系統規則的被Block的異常處理
DubboBlockExeptionManager.DubboConsumerFallbackConfig.setSystemDubboFallback(systemDubboFallback);

也可以統一設置：

//統一設置Dubbo Provider的異常處理
DubboBlockExeptionManager.DubboProviderFallbackConfig.setDefaultDubboFallback(defaultDubboFallback);
//統一設置Dubbo Consumer的異常處理
DubboBlockExeptionManager.DubboConsumerFallbackConfig.setDefaultDubboFallback(defaultDubboFallback);

注：設置了默認限流後，原來已有的所有限流異常處理器都會被替換爲當前的默認處理器，如果還需要單獨對不同的場景使用不同的異常處理器的，需要在後面重新設置相應異常的限流異常處理器。

 

5、基於@SentinelResource實現自定限流的Spring boot應用

1）應用引入ld-sentinel-web-spring-boot-starter

        <dependency>
            <groupId>xxx</groupId>
	    	<artifactId>ld-sentinel-common-spring-boot-starter</artifactId>
            <version>${ld-sentinel.version}</version>
        </dependency>

2）application.properties增加配置

核心配置

#[應用必填]應用的名稱，也可以在JVM參數中通過-Dproject.name指定，優先讀取配置文件中的，讀取不到再讀取JVM參數中的配置
spring.application.name = ld-sentinel-common-sample
#[應用選填]ZK的連接配置（如果不配置，系統會自動判斷當前是測試環境還是生產環境，並使用相應的配置）
sentinel.zookeeperAddress = 192.168.10.185:2181
#[應用選填]Sentinel控制檯地址（如果不配置，系統會自動判斷當前是測試環境還是生產環境，並使用相應的配置）
sentinel.sentinelServer = 192.168.10.130:8080
[應用選填]當前應用往Sentinel控制檯註冊的端口
#該端口目前主要用於控制檯檢查應用是否還健康，如果未設置則默認使用54321端口，如果本地啓動了多個連接Sentinel控制檯的應用，
#導致該端口被其它應用佔用了，爲了確保應用的順利啓動和正常運行，則會使用30000~40000的隨機端口。
#生產環境強烈建議設置，否則不利用應用端口的管理，應用的每次重啓，在Sentinel控制檯都會顯示原來端口的應用不可用
#注：如果應用運行於容器中，該端口要映射出來
#sentinel.apiPort=54321

6、Sentinel擴展配置項（配置到application.properties中）

#Sentinel擴展配置項

#日誌輸出路徑，Sentinel默認會將日誌輸出到用戶目錄{@code ${user.home}/logs/csp/}下，默認值爲logs/csp
#sentinel.logDir = logs/csp

#默認的日誌文件名沒有包括PID，但如果在同一臺服務器上運行了多個實例，可能需要在日誌文件中加上PID用於區分不同的日誌文件，默認值爲true
#sentinel.logUsePid = true

#應用端與控制檯的心臺檢測時間，默認爲10秒鐘
#sentinel.heartbeatIntervalMS = 10000
#指定客戶端ＩＰ地址，在有些多網卡的場景，獲取的ＩＰ不正確，可以通過手動指定ＩＰ的方式
#sentinel.heartBeatClientHost = 192.168.0.1

五、Grafana報表的展示

1、說明

通過Grafana展示存儲於Influxdb中的Metrics數據，操作方便且美觀，不過其同一個報表不能夠智能路由到不同的Influxdb中查詢，因爲需要一箇中間應用，ld-sharding-influxdb就是基本這樣場景的特定應用，GIT地址：http://xxx.com/base-component/ld-sharding-influxdb，其會根據應用的app，將請求路由到不同的Influxdb中，並將結果進行彙總後再返回給前端的Grafana。

2、使用ld-sharding-influxdb的步驟

1）啓動ld-sharding-influxdb；

2）在Grafana中配置數據源，其配置方式和配置其它Influxdb數據源的方式一致，只需要將URL設置爲ld-sharding-influxdb的地址和端口即可，如下所示：

3）報表選擇該數據源；

3、報表展示樣式