在之前的兩篇教程中我們分別介紹瞭如何將Sentinel的限流規則儲存到Nacos和Apollo中。同時,在文末的思考中,我都指出了這兩套整合方案都存在一個不足之處:不論採用什麼配置中心,限流規則都只能通過Nacos介面或Apollo介面來完成修改才能得到持久化儲存,而在Sentinel Dashboard中修改限流規則雖然可以生效,但是不會被持久化到配置中心。而在這兩個配置中心裡儲存的資料是一個Json格式,當儲存的規則越來越多,對該Json配置的可讀性與可維護性會變的越來越差。所以,下面我們就來繼續探討這個不足之處,並給出相應的解決方案。本文以Apollo儲存為例,下一篇介紹Nacos的改在示例。
問題分析
在實際操作之前,我們先通過下圖瞭解一下之前我們所實現的限流規則持久化方案的配置資料流向圖:
藍色箭頭
代表了限流規則由配置中心
發起修改的更新路徑橙色箭頭
代表了限流規則由Sentinel Dashboard
發起修改的更新路徑
從圖中可以很明顯的看到,Sentinel Dashboard
與業務服務之間本身是可以互通獲取最新限流規則的,這在沒有整合配置中心來儲存限流規則的時候就已經存在這樣的機制。最主要的區別是:配置中心的修改都可以實時的重新整理到業務服務,從而被Sentinel Dashboard
讀取到,但是對於這些規則的更新到達各個業務服務之後,並沒有一個機制去同步到配置中心,作為配置中心的客戶端也不會提供這樣的逆向更新方法。
改造方案
關於如何改造,現來解讀一下官方文件中關於這部分的說明:
要通過 Sentinel 控制檯配置叢集流控規則,需要對控制檯進行改造。我們提供了相應的介面進行適配。
從 Sentinel 1.4.0 開始,我們抽取出了介面用於向遠端配置中心推送規則以及拉取規則:
- DynamicRuleProvider
: 拉取規則 - DynamicRulePublisher
: 推送規則 對於叢集限流的場景,由於每個叢集限流規則都需要唯一的 flowId,因此我們建議所有的規則配置都通過動態規則源進行管理,並在統一的地方生成叢集限流規則。
我們提供了新版的流控規則頁面,可以針對應用維度推送規則,對於叢集限流規則可以自動生成 flowId。使用者只需實現 DynamicRuleProvider 和 DynamicRulePublisher 介面,即可實現應用維度推送(URL: /v2/flow)。
這段內容什麼意思呢?簡單的說就是Sentinel Dashboard
通過DynamicRuleProvider
和DynamicRulePublisher
兩個介面來獲取和更新應用的動態規則。預設情況下,就如上一節中Sentinel Dashboard
與各業務服務之間的兩個箭頭,一個介面負責獲取規則,一個介面負責更新規則。
所以,只需要通過這兩個介面,實現對配置中心中儲存規則的讀寫,就能實現Sentinel Dashboard
中修改規則與配置中心儲存同步的效果。
具體的配置資料流向圖如下:
其中,綠色箭頭為公共公共部分,即:不論從培中心修改,還是從Sentinel Dashboard
修改都會觸發的操作。這樣的話,從上圖的兩處修改起點看,所有涉及的部分都能獲取到一致的限流規則了。
程式碼實現
下面繼續說說具體的程式碼實現,這裡參考了Sentinel Dashboard
原始碼中關於Apollo實現的測試用例。但是由於考慮到與Spring Cloud Alibaba的結合使用,略作修改。
第一步:修改pom.xml
中的Apollo OpenAPi的依賴,將<scope>test</scope>
註釋掉,這樣才能在主程式中使用。
<dependency>
<groupId>com.ctrip.framework.apollo</groupId>
<artifactId>apollo-openapi</artifactId>
<version>1.2.0</version>
<!--<scope>test</scope>-->
</dependency>
第二步:找到resources/app/scripts/directives/sidebar/sidebar.html
中的這段程式碼:
<li ui-sref-active="active">
<a ui-sref="dashboard.flowV1({app: entry.app})">
<i class="glyphicon glyphicon-filter"></i> 流控規則
</a>
</li>
修改為:
<li ui-sref-active="active">
<a ui-sref="dashboard.flow({app: entry.app})">
<i class="glyphicon glyphicon-filter"></i> 流控規則
</a>
</li>
第三步:在com.alibaba.csp.sentinel.dashboard.rule
包下新建一個apollo包,用來編寫針對Apollo的擴充套件實現。
第四步:建立Apollo的配置類,定義Apollo的portal訪問地址以及第三方應用訪問的授權Token(通過Apollo管理員賬戶登入,在“開放平臺授權管理”功能中建立),具體程式碼如下:
@Configuration
public class ApolloConfig {
@Bean
public Converter<List<FlowRuleEntity>, String> flowRuleEntityEncoder() {
return JSON::toJSONString;
}
@Bean
public Converter<String, List<FlowRuleEntity>> flowRuleEntityDecoder() {
return s -> JSON.parseArray(s, FlowRuleEntity.class);
}
@Bean
public ApolloOpenApiClient apolloOpenApiClient() {
ApolloOpenApiClient client = ApolloOpenApiClient.newBuilder()
.withPortalUrl("https://apollo.xxx.com") // TODO 根據實際情況修改
.withToken("open api token") // TODO 根據實際情況修改
.build();
return client;
}
}
第五步:實現Apollo的配置拉取實現。
@Component("flowRuleApolloProvider")
public class FlowRuleApolloProvider implements DynamicRuleProvider<List<FlowRuleEntity>> {
@Autowired
private ApolloOpenApiClient apolloOpenApiClient;
@Autowired
private Converter<String, List<FlowRuleEntity>> converter;
@Value("${env:DEV}")
private String env;
@Override
public List<FlowRuleEntity> getRules(String appName) throws Exception {
// flowDataId對應
String flowDataId = "sentinel.flowRules";
OpenNamespaceDTO openNamespaceDTO = apolloOpenApiClient.getNamespace(appName, env, "default", "application");
String rules = openNamespaceDTO
.getItems()
.stream()
.filter(p -> p.getKey().equals(flowDataId))
.map(OpenItemDTO::getValue)
.findFirst()
.orElse("");
if (StringUtil.isEmpty(rules)) {
return new ArrayList<>();
}
return converter.convert(rules);
}
}
getRules
方法中的appName
引數是Sentinel中的服務名稱,這裡直接通過這個名字獲取Apollo配置是由於Apollo中的專案AppId與之一致,如果存在不一致的情況,則需要自己做轉換。- 這裡注入了一個
env
屬性,主要由於我們在使用Apollo的時候,通過啟動引數來控制不同環境。所以這樣就能在不同環境區分不同的限流配置了。 - 這裡的
flowDataId
對應各個微服務應用中定義的spring.cloud.sentinel.datasource.ds.apollo.flowRulesKey
配置,即:Apollo中使用了什麼key來儲存限流配置。 - 其他如Cluster、Namepsace都採用了預設值:default和application,這個讀者有特殊需求可以做對應的修改。
第六步:實現Apollo的配置推送實現。
@Component("flowRuleApolloPublisher")
public class FlowRuleApolloPublisher implements DynamicRulePublisher<List<FlowRuleEntity>> {
@Autowired
private ApolloOpenApiClient apolloOpenApiClient;
@Autowired
private Converter<List<FlowRuleEntity>, String> converter;
@Value("${env:DEV}")
private String env;
@Override
public void publish(String app, List<FlowRuleEntity> rules) throws Exception {
String flowDataId = "sentinel.flowRules";
AssertUtil.notEmpty(app, "app name cannot be empty");
if (rules == null) {
return;
}
OpenItemDTO openItemDTO = new OpenItemDTO();
openItemDTO.setKey(flowDataId);
openItemDTO.setValue(converter.convert(rules));
openItemDTO.setComment("modify by sentinel-dashboard");
openItemDTO.setDataChangeCreatedBy("apollo");
apolloOpenApiClient.createOrUpdateItem(app, env, "default", "application", openItemDTO);
// Release configuration
NamespaceReleaseDTO namespaceReleaseDTO = new NamespaceReleaseDTO();
namespaceReleaseDTO.setEmergencyPublish(true);
namespaceReleaseDTO.setReleaseComment("release by sentinel-dashboard");
namespaceReleaseDTO.setReleasedBy("apollo");
namespaceReleaseDTO.setReleaseTitle("release by sentinel-dashboard");
apolloOpenApiClient.publishNamespace(app, env, "default", "application", namespaceReleaseDTO);
}
}
- 這裡的大部分內容,如:env、flowDataId、app說明與上一步中的實現一致
openItemDTO.setDataChangeCreatedBy("apollo");
和namespaceReleaseDTO.setReleasedBy("apollo");
這兩句需要注意一下,必須設定存在並且有許可權的使用者,不然會更新失敗。
第七步:修改com.alibaba.csp.sentinel.dashboard.controller.v2.FlowControllerV2
中DynamicRuleProvider
和DynamicRulePublisher
注入的Bean,改為上面我們編寫的針對Apollo的實現:
@Autowired
@Qualifier("flowRuleApolloProvider")
private DynamicRuleProvider<List<FlowRuleEntity>> ruleProvider;
@Autowired
@Qualifier("flowRuleApolloPublisher")
private DynamicRulePublisher<List<FlowRuleEntity>> rulePublisher;
程式碼示例
本文介紹內容的客戶端程式碼,示例讀者可以通過檢視下面倉庫中的alibaba-sentinel-dashboard-apollo
專案:
- Github:https://github.com/dyc87112/SpringCloud-Learning/
- Gitee:https://gitee.com/didispace/SpringCloud-Learning/
如果您對這些感興趣,歡迎star、follow、收藏、轉發給予支援!