文章目录
前言
在前一篇文章《Soul网关源码学习（8）- 代理转发入口 SoulWebHandler》 中，我们详细分析了网关的入口 SoulWebHandler，并且就代码中使用的几个技术进行了扩展延申学习。如果小伙伴看过前面两篇关于 soul 代理转发流程的介绍文章，都应该知道请求进入 SoulWebHandler 之后，下一站就是天后了！噗！开玩笑的！是 GlobalPlugin ！
GlobalPlugin
GlobalPlugin 到底是干什么的？
请求解析！这是我对 GlobalPlugin 功能的一个理解。Soul 对外统一使用 Http 接口，所以单纯的直接转发无法实现对不同协议的代理，比如，你总不能直接把 Http 请求转给 dubbo服务器吧，那样 dubbo 服务根本无法识别，需要 soul 通过客户端的请求和控制台配置的元数据进行匹配和结合才能实现。所以这里总结一下其功能：
- 通过 Http 的请求信息匹配相应的元数据，并且添加到 ServerWebExchange 属性中。元数据是 soul 对具体目标服务接口的描述信息，比如 App Name、MethodName、Path等，像 dubbo 的泛化调用就需要使用到元数据，否则仅仅靠客户端请求信息是无法完成代理的。
- 通过分析 Http 请求信息 和 上面获取的元数据构建 SoulContext 对象，并且存储到 ServerWebExchange（Spring WebFlux 的请求上下文） 的属性中，通过后者在整个 请求流程中传递。
SoulContext 的构建
SoulContext 按照字面理解就是 Soul 请求的上下文，它的层次在 ServerWebExchange 之上，毕竟 SoulContext 就存储在 ServerWebExchange 的属性中。
// GlobalPlugin execute 方法中的代码
exchange.getAttributes().put(Constants.CONTEXT, soulContext);
它主要存储一些与目标服务协议相关的信息，比如 Http 目标服务的 HttpMethod、参数、真实Url，又或者 Dubbo 目标服务的服务名称，接口名称、接口参数等待。
SoulContext 的构建代码：
@Override
public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
...
// 如果不是 websocket 请求 通过 SoulContextBuilder 构建
if (StringUtils.isBlank(upgrade) || !"websocket".equals(upgrade)) {
soulContext = builder.build(exchange);
} else {
// websocket
final MultiValueMap<String, String> queryParams = request.getQueryParams();
soulContext = transformMap(queryParams);
}
// 存储到 ServerWebExchange 属性中
exchange.getAttributes().put(Constants.CONTEXT, soulContext);
return chain.execute(exchange);
}
上面代码逻辑很简单，通过 Http header "upgrade " 来判断是否是 webSocket 请求，从而选择不同的构建方法。
我们这里主要看非 webSocket 的构建逻辑：
@Override
public SoulContext build(final ServerWebExchange exchange) {
final ServerHttpRequest request = exchange.getRequest();
String path = request.getURI().getPath();
//获取元数据，并且存到 ServerWebExchange 属性中
MetaData metaData = MetaDataCache.getInstance().obtain(path);
if (Objects.nonNull(metaData) && metaData.getEnabled()) {
exchange.getAttributes().put(Constants.META_DATA, metaData);
}
//通过请求信息和元数据共同构建 soulContext 对象并且返回
return transform(request, metaData);
}
从上面的代码和注释中，可以看到一个关键单词就是 MetaData。
MetaData 的获取
-
首先，MetaData 是什么？
MetaData 可以在 soul admin 中直接查看，其实就是对每个被代理接口的具体描述（例如：dubbo 泛化调用就需要用到），普通 Http 的 MetaData 是空的，这个可以参考一下官方文档说明。 -
MetaData 来自哪里？
源头来自服务注册中心，网关服务获取的是本地副本！Soul Admin 通过配置的服务注册中心，获取到相应的接口描述信息（比如 dubbo 注册在 zookeeper 的接口信息），然后同步到网关服务端，服务端再缓存在本地 JVM 中。数据的同步可能是推或者拉的模式，这个后面“数据同步”相关文章再分析。
PS：源头来自服务注册中心，目前是我推测的，我还没深入看这部分源码（这部分代码应该在 soul admin 中，目前优先解读 soul 服务端）。但是这些信息来自注册中心可能性最大，毕竟网关代理具体的微服务时，需要配置相应的注册中心。后面我回去看这部分代码，求证了再回来修改这里了。
// 从本地缓存中获取 MetaData MetaData metaData = MetaDataCache.getInstance().obtain(path);
生成 SoulContext 对象
SoulContext 对象是通过 DefaultSoulContextBuilder#transform(ServerHttpRequest,MetaData) 方法构建的，代码比较长但是逻辑很简单，所以这里就不贴了，就和开头说的一样，其属性都是通过解析 request 和 MetaData中获取的，因此都是一些 set 操作。
总结
本篇文章，详细介绍了 GlobalPlugin 的作用，通过解析客户端请求，匹配缓存里的元数据，为后续的流程操作提供必要的信息。GlobalPlugin 是所有协议代理都会经过的插件节点，再往后，流程就可能会因为协议的不同而出现分叉了，这也是后面的文章的主要内容。