一、概述
这个是之前理解的整体流程图,这两周看下来,其实中间有一些不对的地方,快结束的时候统一改一波,先忽略。
今天主要分析如上图所示,数据同步到网关之后,到插件拿到缓存数据做相关的逻辑,中间的这一块的流程,把配置数据放入相应的JVM缓存里,这个也是soul网关快的最根本原因之一。
二、soul网关里的配置数据种类
从上一节的http同步数据的分组来看,配置数据分为5种
- APP_AUTH :认证鉴权信息,主要是sign插件使用,不是本篇分析的核心
- PLUGIN :插件数据,默认所有的插件都会初始化并同步
- SELECTOT :选择器数据,几个规则的一个分组,根据contextPath做第一道流量筛选,一般一个微服务是一个选择器
- RULE :规则数据,具体的url的匹配规则
- META_DATA :元数据,部分插件才有(dubbo/spring cloud/sofa),主要是为了记录原来的方法信息,主要是dubbo泛化调用用的
全量同步的数据信息展示
如图所示,一个插件有多个选择器,一个选择器对应多种规则。
- 责任链逐个选择插件
- 选择器对流量的第一次筛选
- 规则就是最终的筛选。
三、soul网关的缓存流程
根据上述的数据分类,在数据同步中,我们前些天已经分析,几种同步数据方式都实现的接口集合
- AuthDataSubscriber 对应上面的app_auth信息
- MetaDataSubscriber 对应上面的meta_data信息
- PluginDataSubscriber 对应上面的pluage+selector+rule信息
分析这三个subseriber的前后调用关系,传递的数据从哪里来,怎么存储?怎么使用?
- 初始化相关实现
- soul-spring-boot-starter-sync-data-zookeeper(ZookeeperSyncDataService的构造函数里)
- soul-spring-boot-starter-sync-data-http(HttpSyncDataService的构造函数里)
- soul-spring-boot-starter-sync-data-websocket(WebsocketSyncDataService的构造函数里)
- soul-spring-boot-starter-sync-data-nacos(NacosSyncDataService的构造函数里)
- ZookeeperSyncDataService、HttpSyncDataService、WebsocketSyncDataService、NacosSyncDataService四个service里负责具体的数据的同步
- ZookeeperSyncDataService 使用zk监听节点/路径变更情况,获取增量数据
- WebsocketSyncDataService 监听ws通道,获取增量数据
- HttpSyncDataService 通过轮询根据变更,以拉做推,获取全量数据更新
- NacosSyncDataService 监听五种数据类型,获取增量数据
- 然后看PluginDataSubscriber的具体实现,去做相应的操作
- ZookeeperSyncDataService 根据数据类型,调用onSubscribe、unSubscribe、onSelectorSubscribe、unSelectorSubscribe、onRuleSubscribe、unRuleSubscribe等接口。具体的实现在CommonPluginDataSubscriber里
- WebsocketSyncDataService 里使用WebsocketDataHandler,具体Hander里调用CommonPluginDataSubscriber的方法
- HttpSyncDataService 使用DataRefreshFactory,具体的几个DataRefresh里调用CommonPluginDataSubscriber的方法
- NacosSyncDataService 启动数据监听,具体的几个updatePluginMap里调用CommonPluginDataSubscriber的方法
4. CommonPluginDataSubscriber的统一实现,这些更新缓存的方法
比如
@Override
public void onRuleSubscribe(final RuleData ruleData) {
BaseDataCache.getInstance().cacheRuleData(ruleData);
Optional.ofNullable(handlerMap.get(ruleData.getPluginName())).ifPresent(handler -> handler.handlerRule(ruleData));
}
@Override
public void unRuleSubscribe(final RuleData ruleData) {
BaseDataCache.getInstance().removeRuleData(ruleData);
Optional.ofNullable(handlerMap.get(ruleData.getPluginName())).ifPresent(handler -> handler.removeRule(ruleData));
}
- BaseDataCache就是真正对缓存数据的修改删除
/**
* pluginName -> PluginData.
*/
private static final ConcurrentMap<String, PluginData> PLUGIN_MAP = Maps.newConcurrentMap();
/**
* pluginName -> SelectorData.
*/
private static final ConcurrentMap<String, List<SelectorData>> SELECTOR_MAP = Maps.newConcurrentMap();
/**
* selectorId -> RuleData.
*/
private static final ConcurrentMap<String, List<RuleData>> RULE_MAP = Maps.newConcurrentMap();
- 具体的插件就可以取里面的缓存做逻辑了
四、其他
- CommonPluginDataSubscriber里有个handerMAP,相关的有一系列的操作,这个明天分析一下。
- Auth主要是sign插件使用,后面单独介绍
- MetaData主要是dubbo使用,后面单独介绍
五、小结
- 四种同步方式构造相关SyncDataService服务
- 四种同步方式构初始化后或 ws建链 或 开启轮询 或 开始监听
- 收到变更 或 使用推拉,然后通过subscriber进行数据分发处理(简单工厂)
- 统一使用CommonPluginDataSubscriber更新三个PLUGIN_MAP、SELECTOR_MAP、RULE_MAP 里的数据
- 插件使用缓存数据做相应的逻辑