基于Alibaba Nacos和Sentinel，實作灰階路由和流量防護一體化的解決方案，釋出在最新的 Nepxion Discovery 5.4.0 版，具體參考：
源碼首頁，請通路
源碼首頁 指南首頁，請通路 指南首頁 文檔首頁，請通路 文檔首頁 Nepxion Discovery架構在實作灰階釋出和路由功能前提下，結合Nacos和Sentinel，對流量再實施一層防護措施，更能達到企業級的流量安全控制的目的。它的功能包括：- 封裝遠端配置中心和本地規則檔案的讀取邏輯，即優先讀取遠端配置，如果不存在或者規則錯誤，則讀取本地規則檔案。動态實作遠端配置中心對于規則的熱重新整理
- 封裝NacosDataSource和ApolloDataSource，支援Nacos和Apollo兩個遠端配置中心，零代碼實作Sentinel功能。更多的遠端配置中心，請參照Sentinel官方的DataSource并自行內建
- 支援原生的流控規則、降級規則、授權規則、系統規則、熱點參數流控規則
- 支援擴充LimitApp的機制，通過動态的Http Header方式實作組合式防護機制，包括基于服務名、基于灰階組、基于灰階版本、基于灰階區域、基于機器位址和端口等防護機制，支援自定義任意的業務參數組合實作該功能，例如，根據傳入的微服務灰階版本号+使用者名，組合在一起進行熔斷
- 支援微服務側Actuator、Swagger和Rest三種方式的規則寫入
- 支援控制台側基于微服務名的Actuator、Swagger和Rest三種方式的批量規則寫入
- 支援開關關閉上述功能spring.application.strategy.sentinel.enabled=true，預設是關閉的
[Nacos] 阿裡巴巴中間件部門開發的新一代集服務注冊發現中心和配置中心為一體的中間件。它是建構以“服務”為中心的現代應用架構 (例如微服務範式、雲原生範式) 的服務基礎設施，支援幾乎所有主流類型的“服務”的發現、配置和管理，更靈活和容易地建構、傳遞和管理微服務平台
[Sentinel] 阿裡巴巴中間件部門開發的新一代以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個次元保護服務的穩定性的分布式系統的流量防衛兵。它承接了阿裡巴巴近10年的雙十一大促流量的核心場景，例如秒殺（即突發流量控制在系統容量可以承受的範圍）、消息削峰填谷、叢集流量控制、實時熔斷下遊不可用應用等
環境搭建及依賴引入
服務端在Discovery架構原有依賴的基礎上，再引入如下依賴
<dependency>
<groupId>com.nepxion</groupId>
<artifactId>discovery-plugin-strategy-starter-service-sentinel</artifactId>
<version>${discovery.version}</version>
</dependency>
<dependency>
<groupId>com.nepxion</groupId>
<artifactId>discovery-plugin-strategy-sentinel-starter-nacos</artifactId>
<!-- <artifactId>discovery-plugin-strategy-sentinel-starter-apollo</artifactId> -->
<version>${discovery.version}</version>
</dependency> 原生Sentinel注解
參照下面代碼，為接口方法增加@SentinelResource注解，value為sentinel-resource，blockHandler和fallback是防護其作用後需要執行的方法
@RestController
@ConditionalOnProperty(name = DiscoveryConstant.SPRING_APPLICATION_NAME, havingValue = "discovery-guide-service-b")
public class BFeignImpl extends AbstractFeignImpl implements BFeign {
private static final Logger LOG = LoggerFactory.getLogger(BFeignImpl.class);
@Override
@SentinelResource(value = "sentinel-resource", blockHandler = "handleBlock", fallback = "handleFallback")
public String invoke(@PathVariable(value = "value") String value) {
value = doInvoke(value);
LOG.info("調用路徑：{}", value);
return value;
}
public String handleBlock(String value, BlockException e) {
return value + "-> B server sentinel block, cause=" + e.getClass().getName() + ", rule=" + e.getRule() + ", limitApp=" + e.getRuleLimitApp();
}
public String handleFallback(String value) {
return value + "-> B server sentinel fallback";
}
} 原生Sentinel規則
Sentinel在配置中心訂閱的Key格式，如下：
1. Nacos的Key格式：Group為中繼資料中配置的[組名]，Data Id為[服務名]-[規則類型]
2. Apollo的Key格式：[組名]-[服務名]-[規則類型] Sentinel規則的用法，請參照Sentinel官方文檔
流控規則
增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-flow，規則内容如下：
[
{
"resource": "sentinel-resource",
"limitApp": "default",
"grade": 1,
"count": 1,
"strategy": 0,
"refResource": null,
"controlBehavior": 0,
"warmUpPeriodSec": 10,
"maxQueueingTimeMs": 500,
"clusterMode": false,
"clusterConfig": null
}
] 如圖所示
降級規則
增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-degrade，規則内容如下：
[
{
"resource": "sentinel-resource",
"limitApp": "default",
"count": 2,
"timeWindow": 10,
"grade": 0,
"passCount": 0
}
] 
授權規則
增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則内容如下：
[
{
"resource": "sentinel-resource",
"limitApp": "discovery-guide-service-a",
"strategy": 0
}
] 系統規則
增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-system，規則内容如下：
[
{
"resource": null,
"limitApp": null,
"highestSystemLoad": -1.0,
"highestCpuUsage": -1.0,
"qps": 200.0,
"avgRt": -1,
"maxThread": -1
}
] 熱點參數流控規則
增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-param-flow，規則内容如下：
[
{
"resource": "sentinel-resource",
"limitApp": "default",
"grade": 1,
"paramIdx": 0,
"count": 1,
"controlBehavior": 0,
"maxQueueingTimeMs": 0,
"burstCount": 0,
"durationInSec": 1,
"paramFlowItemList": [],
"clusterMode": false
}
] 基于灰階路由和Sentinel-LimitApp擴充的防護機制
該方式對于上面5種規則都有效，這裡以授權規則展開闡述
授權規則中，limitApp，如果有多個，可以通過“,”分隔。"strategy": 0 表示白名單，"strategy": 1 表示黑名單
基于服務名的防護機制
修改配置項Sentinel Request Origin Key為服務名的Header名稱，修改授權規則中limitApp為對應的服務名，可實作基于服務名的防護機制
配置項，該配置項預設為n-d-service-id，可以不配置
spring.application.strategy.service.sentinel.request.origin.key=n-d-service-id 增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則内容如下，表示所有discovery-guide-service-a服務允許通路discovery-guide-service-b服務
[
{
"resource": "sentinel-resource",
"limitApp": "discovery-guide-service-a",
"strategy": 0
}
] 基于灰階組的防護機制
修改配置項Sentinel Request Origin Key為灰階組的Header名稱，修改授權規則中limitApp為對應的組名，可實作基于組名的防護機制
配置項
spring.application.strategy.service.sentinel.request.origin.key=n-d-service-group 增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則内容如下，表示隸屬my-group組的所有服務都允許通路服務discovery-guide-service-b
[
{
"resource": "sentinel-resource",
"limitApp": "my-group",
"strategy": 0
}
] 基于灰階版本的防護機制
修改配置項Sentinel Request Origin Key為灰階版本的Header名稱，修改授權規則中limitApp為對應的版本，可實作基于版本的防護機制
spring.application.strategy.service.sentinel.request.origin.key=n-d-service-version 增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則内容如下，表示版本為1.0的所有服務都允許通路服務discovery-guide-service-b
[
{
"resource": "sentinel-resource",
"limitApp": "1.0",
"strategy": 0
}
] 基于灰階區域的防護機制
修改配置項Sentinel Request Origin Key為灰階區域的Header名稱，修改授權規則中limitApp為對應的區域，可實作基于區域的防護機制
spring.application.strategy.service.sentinel.request.origin.key=n-d-service-region 增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則内容如下，表示區域為dev的所有服務都允許通路服務discovery-guide-service-b
[
{
"resource": "sentinel-resource",
"limitApp": "dev",
"strategy": 0
}
] 基于機器位址和端口的防護機制
修改配置項Sentinel Request Origin Key為灰階區域的Header名稱，修改授權規則中limitApp為對應的區域值，可實作基于機器位址和端口的防護機制
spring.application.strategy.service.sentinel.request.origin.key=n-d-service-address 增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則内容如下，表示位址和端口為192.168.0.88:8081和192.168.0.88:8082的服務都允許通路服務discovery-guide-service-b
[
{
"resource": "sentinel-resource",
"limitApp": "192.168.0.88:8081,192.168.0.88:8082",
"strategy": 0
}
] 自定義業務參數的組合式防護機制
通過适配類實作自定義業務參數的組合式防護機制
// 版本号+使用者名，實作組合式熔斷
public class MyServiceSentinelRequestOriginAdapter extends DefaultServiceSentinelRequestOriginAdapter {
@Override
public String parseOrigin(HttpServletRequest request) {
String version = request.getHeader(DiscoveryConstant.N_D_SERVICE_VERSION);
String user = request.getHeader("user");
return version + "&" + user;
}
} 在配置類裡@Bean方式進行适配類建立
@Bean
public ServiceSentinelRequestOriginAdapter ServiceSentinelRequestOriginAdapter() {
return new MyServiceSentinelRequestOriginAdapter();
} 增加服務discovery-guide-service-b的規則，Group為discovery-guide-group，Data Id為discovery-guide-service-b-sentinel-authority，規則内容如下，表示版本為1.0且傳入的Http Header的user=zhangsan，同時滿足這兩個條件下的所有服務都允許通路服務discovery-guide-service-b
[
{
"resource": "sentinel-resource",
"limitApp": "1.0&zhangsan",
"strategy": 0
}
] 運作效果
- 當傳遞的Http Header中user=zhangsan，當全鍊路調用中，API網關負載均衡discovery-guide-service-a服務到1.0版本後再去調用discovery-guide-service-b服務，最終調用成功
- 當傳遞的Http Header中user=lisi，不滿足條件，最終調用在discovery-guide-service-b服務端被拒絕掉
- 當傳遞的Http Header中user=zhangsan，滿足條件之一，當全鍊路調用中，API網關負載均衡discovery-guide-service-a服務到1.1版本後再去調用discovery-guide-service-b服務，不滿足version=1.0的條件，最終調用在discovery-guide-service-b服務端被拒絕掉
基于Swagger的Sentinel規則推送
分為基于單個服務執行個體和基于服務名對應的多個服務執行個體的Sentinel規則推送
基于單個服務執行個體的Sentinel規則推送
直接通路該服務執行個體的Swagger首頁即可
基于服務名對應的多個服務執行個體的Sentinel規則推送
需要開啟discovery-console服務，并通路其Swagger首頁即可
本文作者：任浩軍， 10 多年開源經曆，Github ID：@HaojunRen，Nepxion 開源社群創始人，Nacos Group Member，Spring Cloud Alibaba & Nacos & Sentinel Committer ，曾就職于平安銀行平台架構部，負責銀行 PaaS 系統基礎服務架構研發。
王偉華， 10 餘年 Java 開發，Github ID：@vipweihua，對微服務架構研究多年，目前更多關注于微服務中的網關、限流熔斷、灰階路由等，現就職于平安銀行平台架構部，從事銀行 PaaS 系統基礎服務架構研發。