Soul网关学习插件链实现

Soul网关学习插件链实现

做者：沈祥俊

1、引言

插件是 Soul 的灵魂。

Soul 使用了插件化设计思想，实现了插件的热插拔，且极易扩展。内置丰富的插件支持，鉴权，限流，熔断，防火墙等等。

Soul 是如何实现插件化设计的呢？

在探究插件化设计以前，咱们须要先了解下微内核架构（又称插件化架构）。

2、微内核架构

一、架构释义

微内核架构也被称为插件化架构，是一种面向功能进行拆分的可扩展性架构，一般用于实现基于产品的应用。

应用逻辑被分割为独立的插件模块和核心系统，提供了可扩展性、灵活性、功能隔离和自定义处理逻辑的特性。

微内核架构的本质，是将变化封装在插件里面，从而达到快速灵活扩展的目的，而又不影响总体系统的稳定。

二、设计关键点

核心系统设计的关键技术：

• **插件管理：**当前有哪些插件可用？如何加载这些插件？何时加载插件？

  常见的实现方法是插件注册表机制。

• **插件链接：**插件如何链接到核心系统？

  一般由核心系统制定链接规范，而后插件按照规范实现，核心系统按照规范加载便可。

  常见链接机制主要有：OSGi（Eclipse使用）、消息模式、依赖注入（Spring使用）。

• **插件通讯：**插件与插件、插件与核心系统如何通讯？

  通讯必须通过核心系统，所以一般由核心系统提供插件通讯机制。

3、Soul 的插件化设计

参照微内核架构来看，Soul 的 soul-web 模块至关于核心系统，soul-plugin 下的子模块至关于插件模块。

插件管理方面：

soul-bootstrap 模块的 pom 文件充当插件列表， 以硬编码的方式引入各插件。

在容器启动阶段，借助 springboot 的 starter 机制自动扫描并注册插件 bean 到 Spring 容器。

插件链接方面：

借助 springboot 支持的多实例自动注入能力（ObjectProvider plugins），将插件 Bean 列表注入到网关的插件链，实现插件与网关的链接。

插件通讯方面：

先在插件链初始化阶段完成插件排序，而后在插件处理时，借助贯穿整个插件链的 ServerWebExchange 完成向下游插件的定向传参，即某种意义上的插件通讯机制。

4、Soul 的插件化实现

Soul 网关中定义了一条插件链，全部的插件都在这条链上依次处理。

在探究插件链以前，咱们先来看看插件实现。

一、插件实现

Soul 中全部插件最终均继承自 SoulPlugin，其完整继承关系以下所示：

能够看到，Soul 的插件生态极其丰富，正是如此丰富的插件支撑起了 Soul 网关强大的扩展能力。

咱们以经常使用的 DividePlugin 为例，分析插件内部所作工做。

DividePlugin 继承结构：

DividePlugin 继承自 AbstractSoulPlugin，最终实现了 SoulPlugin 接口。

1）先关注 SoulPlugin，该插件接口结构以下：

• execute 方法：处理方法，须要传入 exchange交换区 和 SoulPluginChain插件链
• getOrder 方法：取得序号，用做插件排序
• named 方法：得到插件名
• skip 方法：判断是否跳过本次处理

每次处理时，将先进行 skip 判断，不跳过则执行 excute 处理方法。

2）再来看下 AbstractSoulPlugin，该抽象类结构以下：

重点关注 execute 方法，其核心代码以下：

if (pluginData.getEnable()){
	// 获取插件数据
	final PluginData pluginData = BaseDataCache.getInstance().obtainPluginData(pluginName);
	// 获取选择器数据
	final Collection<SelectorData> selectors = BaseDataCache.getInstance().obtainSelectorData(pluginName);
	final SelectorData selectorData = matchSelector(exchange, selectors);
	// 获取规则
	final List<RuleData> rules = BaseDataCache.getInstance().obtainRuleData(selectorData.getId());
	RuleData rule;
  if (selectorData.getType() == SelectorTypeEnum.FULL_FLOW.getCode()) {
  	//get last
    rule = rules.get(rules.size() - 1);
  } else {
    rule = matchRule(exchange, rules);
  }
  // 执行具体处理
  return doExecute(exchange, chain, selectorData, rule);
}
// 继续执行后续插件处理
return chain.execute(exchange);
复制代码

获取选择器数据和规则，而后传入 doExecute 方法进行具体处理，doExecute 方法为抽象方法，交由子类具体实现。

3）查看插件子类 DividePlugin，其结构以下：

重点关注 doExecute 方法，如下是核心代码：

// 获取网关上下文和规则处理器
final SoulContext soulContext = exchange.getAttribute(Constants.CONTEXT);
final DivideRuleHandle ruleHandle = GsonUtils.getInstance().fromJson(rule.getHandle(), DivideRuleHandle.class);
// 获取上游列表
final List<DivideUpstream> upstreamList = UpstreamCacheManager.getInstance().findUpstreamListBySelectorId(selector.getId());
// 选择待分发的目标上游
final String ip = Objects.requireNonNull(exchange.getRequest().getRemoteAddress()).getAddress().getHostAddress();
DivideUpstream divideUpstream = LoadBalanceUtils.selector(upstreamList, ruleHandle.getLoadBalance(), ip);
// 设置 http url 
String domain = buildDomain(divideUpstream);
String realURL = buildRealURL(domain, soulContext, exchange);
exchange.getAttributes().put(Constants.HTTP_URL, realURL);
// 设置 http timeout
exchange.getAttributes().put(Constants.HTTP_TIME_OUT, ruleHandle.getTimeout());
exchange.getAttributes().put(Constants.HTTP_RETRY, ruleHandle.getRetry());
return chain.execute(exchange);
复制代码

很明显，divide 插件只是完成目标上游服务的待分发，即根据选择器和规则找到对应服务，再经过负载均衡策略分配上游服务实例。

而调用上游服务的工做是由其余相应的 client 类插件完成。

二、插件链实现

借由插件链，Soul 将众多插件整合到一块儿进行统一调度处理。

插件链继承结构：

能够看到，Soul 中插件链 SoulPluginChain 仅有一个默认实现类 DefaultSoulPluginChain。

1）DefaultSoulPluginChain 类结构以下：

其持有经过构造方法传入的插件链，看看 execute 方法：

public Mono<Void> execute(final ServerWebExchange exchange) {
    // 反应式编程语法：Mono.defer
  	return Mono.defer(() -> {
        if (this.index < plugins.size()) {
            SoulPlugin plugin = plugins.get(this.index++);
            // 判断是否须要调过
          	Boolean skip = plugin.skip(exchange);
            if (skip) {
                return this.execute(exchange);
            }
          	// 依次执行插件处理逻辑
            return plugin.execute(exchange, this);
        }
        return Mono.empty();
    });
}
复制代码

依次处理插件链上的插件，执行插件处理逻辑。

DefaultSoulPluginChain 是 SoulWebHandler 的内部类，看下 SoulWebHandler 的实现。

2）SoulWebHandler 结构以下：

SoulWebHandler 是 web 请求处理的起点，在此建立并开始插件链的处理。

同 DefaultSoulPluginChain 同样，SoulWebHandler 也是持有经过构造方法传入的插件链。

看看 handle 方法：

public Mono<Void> handle(@NonNull final ServerWebExchange exchange) {
    MetricsTrackerFacade.getInstance().counterInc(MetricsLabelEnum.REQUEST_TOTAL.getName());
    Optional<HistogramMetricsTrackerDelegate> startTimer = MetricsTrackerFacade.getInstance().histogramStartTimer(MetricsLabelEnum.REQUEST_LATENCY.getName());
    return new DefaultSoulPluginChain(plugins).execute(exchange).subscribeOn(scheduler)
            .doOnSuccess(t -> startTimer.ifPresent(time -> MetricsTrackerFacade.getInstance().histogramObserveDuration(time)));
}
复制代码

handle 方法负责插件链执行指标度量的采集，经过在 DefaultSoulPluginChain 执行时加订阅实现，DefaultSoulPluginChain 在此处完成初始化。

全局查找 SoulWebHandler 构造方法，定位到 SoulConfiguration 的 soulWebHandler 方法。

3）SoulConfiguration 结构以下：

SoulConfiguration 是 Soul 的核心配置类，负责自动装配网关所需的核心 bean 对象。

如装配 SoulWebHandler：

@Bean("webHandler")
public SoulWebHandler soulWebHandler(final ObjectProvider<List<SoulPlugin>> plugins) {
    // 获取可用的插件
  	List<SoulPlugin> pluginList = plugins.getIfAvailable(Collections::emptyList);
    // 插件重排
  	final List<SoulPlugin> soulPlugins = pluginList.stream()
            .sorted(Comparator.comparingInt(SoulPlugin::getOrder)).collect(Collectors.toList());
    soulPlugins.forEach(soulPlugin -> log.info("load plugin:[{}] [{}]", soulPlugin.named(), soulPlugin.getClass().getName()));
    return new SoulWebHandler(soulPlugins);
}
复制代码

注意此处的插件列表通过了一次重排，重排顺序参见 PluginEnum。

4）初始化 SoulWebHandler

soul-bootstrap 启动的过程当中，全部插件是怎么造成 ObjectProvider<List> plugins，而后初始化 SoulWebHandler 的呢？

SoulWebHandler 所在的配置类经过配置 @ComponentScan("org.dromara.soul")，通知 spring 扫描 org.dromara.soul 包。

借助 springboot 的 starter 机制，将 spring.factories 里指定的配置类自动加载到容器。

最后，借助 spring4.3 开始支持的 ObjectProvider，实现容器内插件 bean 的集合式注入，最终造成咱们看到的插件链。

总结

本篇从微内核架构提及，并以此为框架分析 Soul 的插件化设计，再结合源码实现，基本理清了 Soul 中插件式设计的实现。

须要注意：

1）由 SoulConfiguration 自动装配 SoulWebHandler，此时 SoulWebHandler 持有插件列表，但未初始化插件链。

2）待调用 handle 方法处理请求时，才初始化插件链进入插件处理。