soul网关系列(十一):探寻soul网关项目的缓存流程(上)

最新推荐文章于 2022-02-18 10:52:35 发布

置顶 HDGM3

最新推荐文章于 2022-02-18 10:52:35 发布

阅读量987

点赞数 2

分类专栏： # soul网关系列

本文链接：https://blog.csdn.net/bo_book/article/details/113206408

版权

soul网关系列专栏收录该内容

17 篇文章 6 订阅

订阅专栏

一、概述

在这里插入图片描述
这个是之前理解的整体流程图，这两周看下来，其实中间有一些不对的地方，快结束的时候统一改一波，先忽略。
今天主要分析如上图所示，数据同步到网关之后，到插件拿到缓存数据做相关的逻辑，中间的这一块的流程，把配置数据放入相应的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();