在生產環境中使用 Sentinel
生產環境的 Sentinel Dashboard 需要具備下面幾個特性:
- 規則管理及推送，集中管理和推送規則。sentinel-core 提供 API 和擴展接口來接收信息。開發者需要根據自己的環境，選取一個可靠的推送規則方式；同時，
規則最好在控制檯中集中管理。 - 監控，支持可靠、快速的實時監控和歷史監控數據查詢。sentinel-core 記錄秒級的資源運行情況，並且提供 API 來拉取資源運行信息。當機器大於一臺以上的時候，可以通過 Dashboard 來拉取，聚合，並且存儲這些信息。這個時候，Dashboard 需要有一個存儲媒介，來存儲歷史運行情況。
- 權限控制，區分用戶角色，來進行操作。生產環境下的權限控制是非常重要的，理論上只有管理員等高級用戶纔有權限去修改應用的規則。
規則管理及推送
| 推送模式 | 說明 | 優點 | 缺點 |
|---|---|---|---|
| 原始模式 | API 將規則推送至客戶端並直接更新到內存中，擴展寫數據源（WritableDataSource） |
簡單，無任何依賴 | 不保證一致性；規則保存在內存中，重啓即消失。嚴重不建議用於生產環境 |
| Pull 模式 | 擴展寫數據源（WritableDataSource）， 客戶端主動向某個規則管理中心定期輪詢拉取規則，這個規則中心可以是 RDBMS、文件 等 |
簡單，無任何依賴；規則持久化 | 不保證一致性；實時性不保證，拉取過於頻繁也可能會有性能問題。 |
| Push 模式 | 擴展讀數據源（ReadableDataSource），規則中心統一推送，客戶端通過註冊監聽器的方式時刻監聽變化，比如使用 Nacos、Zookeeper 等配置中心。這種方式有更好的實時性和一致性保證。生產環境下一般採用 push 模式的數據源。 |
規則持久化；一致性；快速 | 引入第三方依賴 |
原始模式
如果不做任何修改，Dashboard 的推送規則方式是通過 API 將規則推送至客戶端並直接更新到內存中：
這種做法的好處是簡單，無依賴；壞處是應用重啓規則就會消失，僅用於簡單測試，不能用於生產環境。
Pull模式
pull 模式的數據源（如本地文件、RDBMS 等）一般是可寫入的。 下圖以本地文件爲例。
首先 Sentinel 控制檯通過 API 將規則推送至客戶端並更新到內存中，接着註冊的寫數據源會將新的規則保存到本地的文件中。
然後 其他客戶端會定時的去輪詢本地文件，從而對本地的規則進行變更。
這種實現方法好處是簡單，不引入新的依賴，壞處是無法保證監控數據的一致性。
Push 模式
生產環境下一般更常用的是 push 模式的數據源。
推送規則正確做法應該是 配置中心控制檯/Sentinel 控制檯 → 配置中心 → Sentinel 數據源 → Sentinel，而不是經 Sentinel 數據源推送至配置中心。
監控
Sentinel 會記錄資源訪問的秒級數據（若沒有訪問則不進行記錄）並保存在本地日誌 ${user_home}/logs/csp/${app_name}-${pid}-metrics.log，具體格式如下；
1532415661000|2018-07-24 15:01:01|sayHello(java.lang.String)|12|3|4|2|295
1532415661000：時間戳
2018-07-24 15:01:01：格式化之後的時間戳
sayHello(java.lang.String)：資源名
12：表示到來的數量，即此刻通過 Sentinel 規則 check 的數量（passed QPS）
3：實際該資源被攔截的數量（blocked QPS）
4：每秒結束的資源個數（完成調用），包括正常結束和異常結束的情況（exit QPS）
2：異常的數量
295：資源的平均響應時間（RT）
Sentinel 控制檯可以通過 Sentinel 客戶端預留的 HTTP API 從秒級監控日誌中拉取監控數據，並進行聚合。
目前 Sentinel 控制檯中監控數據聚合後直接存在內存中，未進行持久化，且僅保留最近 5 分鐘的監控數據。若需要監控數據持久化的功能，可以自行擴展實現 MetricsRepository 接口（0.2.0 版本），然後註冊成 Spring Bean 並在相應位置通過 @Qualifier 註解指定對應的 bean name 即可。MetricsRepository 接口定義了以下功能：
save與saveAll：存儲對應的監控數據queryByAppAndResourceBetween：查詢某段時間內的某個應用的某個資源的監控數據listResourcesOfApp：查詢某個應用下的所有資源
實戰
Sentinal使用Nacos數據源
maven依賴
<dependency>
<groupId>com.alibaba.csp</groupId>
<artifactId>sentinel-datasource-nacos</artifactId>
</dependency>
bootstrap.yaml
指定nacos數據源。
spring:
cloud:
sentinel:
# transport:
# dashboard: vm1:8080
# ## 從8719依次+1掃描，直到找到未被佔用端口爲之
# port: 8719
# clientIp: 192.1.17.61
datasource:
ds1:
nacos:
server-addr: vm1:8848
dataId: ${spring.application.name}-flow-rules
groupId: DEFAULT_GROUP
data-type: json
rule-type: flow
ds2:
nacos:
server-addr: vm1:8848
dataId: ${spring.application.name}-degrade-rules
groupId: DEFAULT_GROUP
data-type: json
rule-type: degrade
啓動客戶端
客戶端啓動時，會請求nacos的規則配置。 當nacos更新發布配置時，會主動通知客戶端。
nacos配置流控規則
### sentinel-service-flow-rules
[
{
"controlBehavior" : "1",
"count" : "3",
"grade" : "1",
"limitApp" : "default",
"resource" : "/testA",
"strategy" : "0"
}
]
### sentinel-service-degrade-rules
[
{
"count" : "100",
"grade" : "0",
"resource" : "/testA",
"timeWindow" : "20"
}
]
不論採用什麼配置中心，限流規則都只能通過Nacos界面完成修改才能得到持久化存儲，而在Sentinel Dashboard中修改限流規則雖然可以生效，但是不會被持久化到配置中心。