目標
- 數據同步原理分析
- 動態(tài)數據流示意
- 源碼解析
數據同步原理分析
在1.x版本中,配置服務依賴zk實現,管理將變更信息push給網關嘁酿。而2.x版本支websocket、http泳叠、zk决记、nacos,通過soul.sync.strategy 指定對應的同步策略,默認使websocket同步策略,可以做到秒級數據同步,但是soul-admin與soul-bootstrap必須使用相同的同步策略美莫。
soul-admin 在用戶發(fā)生配置變更之后,會通過EventPublisher發(fā)出配置變更通知,由EventDispatcher處理該變更通知。然后根據配置的同步策略(http蹬跃、websocket匙瘪、zk、nacos)蝶缀，將配置發(fā)送到對應的事件處理器上辆苔。本次分析的是websocket,則將變更數據主動推送到soul-bootstrap,并且在網關層會有WebSocketDataChangedListener來處理admin的數據推送
動態(tài)數據流示意
從上圖可以看出幾個關鍵的類 DataChangeEvent(發(fā)送事件數據載體)，ApplicationListener<T Extends ApplicationEvent>(Interface to be implemented by application event listeners.)扼劈，DataChangedListener(監(jiān)聽器接口)
源碼解析
soul-admin 數據發(fā)生改變發(fā)送數據變更通知
這里我是用Selector來進行模擬
// 選擇器變更發(fā)送事件,事件類型統(tǒng)一封裝在DataChangeEvent對象
private void publishEvent(final SelectorDO selectorDO, final List<SelectorConditionDTO> selectorConditionDTOs) {
PluginDO pluginDO = pluginMapper.selectById(selectorDO.getPluginId());
List<ConditionData> conditionDataList =
selectorConditionDTOs.stream().map(ConditionTransfer.INSTANCE::mapToSelectorDTO).collect(Collectors.toList());
// publish change event.發(fā)送 DataChangeEvent類封裝的事件包,而我們看DataChangedEvent也是實現 ApplicationEvent
eventPublisher.publishEvent(new DataChangedEvent(ConfigGroupEnum.SELECTOR, DataEventTypeEnum.UPDATE,
Collections.singletonList(SelectorDO.transFrom(selectorDO, pluginDO.getName(), conditionDataList))));
}
DataChangedEventDispatcher 接收到事件
接收到ApplicationEventPublisher發(fā)送來的事件之后觸發(fā)onApplicationEvent執(zhí)行,拿著event.getGroupKey進行比對從listener中找到匹配的事件處理函數,這里面使用了策略模式,動態(tài)根據事件類型匹配對應的處理事件驻啤。
InitializingBean獲取listeners
此處源碼地方有可以優(yōu)化的地方，因為soul默認數據同步方式只允許有一種,所以這里無需使用list,可以根據用戶當前配置的方式進行定位出最終的listener.這樣在事件分發(fā)器那塊就無需for循環(huán)處理了荐吵。
WebSocketClient 處理事件消息
總結
到這里從用戶改變數據,到事件通知,然后通過websocket將數據發(fā)送到soul網關端,至于數據到網關端處理邏輯,下一章再詳細分析骑冗。
