Soul网关源码阅读（五）—— Soul网关初探
Soul网关源码阅读（五）—— Soul网关初探
概述
之前我们大概分析了数据同步的逻辑，知道了后端服务是怎么将api信息注册到admin，再由admin同步到soul网关的。
这一篇我们分析一下soul网关的基本结构，并大概介绍一下soul网关如何接受请求并且转发的。
因为我们的soul网关是并没有将提供的接口信息写死在配置文件的，所有提供的接口api都是通过admin同步过来，并动态加载到服务的。
所以这里我们主要需要思考一个问题：
- 从admin同步过来的后端服务的接口api，是如何注册到soul网关并形成api接口，使其服务化的？（类似Servlet的功能）
源码分析
接着上一篇的思路，我们分析了从admin同步过来的数据，存放在BaseDataCache类的一个Hashmap的缓存里面，那么soul网关必定需要加载这些缓存数据到它的服务框架中，使其具有接口服务的能力。
查看网关的启动项目Soul-bootstrap的代码，发现只有一个简单的启动了类，并没有web相关的业务逻辑。查看pom依赖，可以看到其依赖了一个soul-spring-boot-starter-gateway模块，该模块是一个spring-boot-starter类型的模块使其具有自动配置的功能。查看soul-spring-boot-starter-gateway的依赖，发现其依赖了soul-web模块，soul-web模块才是soul网关处理核心逻辑的地方。
soul-web模块才是soul网关的核心，包括处理插件、请求路由和转发等逻辑。
继续查看soul-web模块的依赖，发现其果然依赖了BaseDataCache所在的soul-plugin-base模块。
搜索BaseDataCache的使用引用，发现一个抽象类AbstractSoulPlugin中的execute方法对其进行了使用。
查看AbstractSoulPlugin的实现，会发现所有插件都实现了这个类，且都实现了doExecute这个抽象方法，我们先看一下这个方法的定义：
/**
* this is Template Method child has Implement your own logic.
*
* @param exchange exchange the current server exchange {@linkplain ServerWebExchange}
* @param chain chain the current chain {@linkplain ServerWebExchange}
* @param selector selector {@linkplain SelectorData}
* @param rule rule {@linkplain RuleData}
* @return {@code Mono} to indicate when request handling is complete
*/
protected abstract Mono<Void> doExecute(ServerWebExchange exchange, SoulPluginChain chain, SelectorData selector, RuleData rule);
这个接口说：这是一个模版方法，子类需要实现自己的逻辑，它几个参数也值得分析一下：
-
ServerWebExchange：SpringWebFlux中的类。
官方的定义是：
Contract for an HTTP request-response interaction. Provides access to the HTTP request and response and also exposes additional server-side processing related properties and features such as request attributes.
HTTP请求-响应交互的协议。提供对HTTP请求和响应的访问。
-
SoulPluginChain：插件链表,只有一个execute方法，用于执行一个插件的逻辑，并流转到下一个插件，类似于WebFilter。
-
SelectorData:选择器数据
-
RuleData：规则数据
这里又学习了一个新的设计模式，是一个责任链模式，类似SpringMvc中的FilterChain，每个插件执行自己的业务逻辑，以此往下执行。
我们选择Divide插件的实现来看一下：
@Override
protected Mono<Void> doExecute(final ServerWebExchange exchange, final SoulPluginChain chain, final SelectorData selector, final RuleData rule) {
final SoulContext soulContext = exchange.getAttribute(Constants.CONTEXT);
assert soulContext != null;
final DivideRuleHandle ruleHandle = GsonUtils.getInstance().fromJson(rule.getHandle(), DivideRuleHandle.class);
final List<DivideUpstream> upstreamList = UpstreamCacheManager.getInstance().findUpstreamListBySelectorId(selector.getId());
if (CollectionUtils.isEmpty(upstreamList)) {
log.error("divide upstream configuration error： {}", rule.toString());
Object error = SoulResultWrap.error(SoulResultEnum.CANNOT_FIND_URL.getCode(), SoulResultEnum.CANNOT_FIND_URL.getMsg(), null);
return WebFluxResultUtils.result(exchange, error);
}
final String ip = Objects.requireNonNull(exchange.getRequest().getRemoteAddress()).getAddress().getHostAddress();
DivideUpstream divideUpstream = LoadBalanceUtils.selector(upstreamList, ruleHandle.getLoadBalance(), ip);
if (Objects.isNull(divideUpstream)) {
log.error("divide has no upstream");
Object error = SoulResultWrap.error(SoulResultEnum.CANNOT_FIND_URL.getCode(), SoulResultEnum.CANNOT_FIND_URL.getMsg(), null);
return WebFluxResultUtils.result(exchange, error);
}
// set the http url
String domain = buildDomain(divideUpstream);
String realURL = buildRealURL(domain, soulContext, exchange);
exchange.getAttributes().put(Constants.HTTP_URL, realURL);
// set the http timeout
exchange.getAttributes().put(Constants.HTTP_TIME_OUT, ruleHandle.getTimeout());
exchange.getAttributes().put(Constants.HTTP_RETRY, ruleHandle.getRetry());
return chain.execute(exchange);
}
通过postman调用对http的请求，通过打断点进行分许：
可以看到doExecute的核心逻辑是：
从缓存中获取上下文信息，包括http地址、端口号、路由、参数等一切信息，并封装到ServerWebExchange中（前面了解到他是一个协议，现在看来它就是一个请求交换器），然后执行execute方法，并传给下一个插件执行进行处理。
查看SoulWebHandler的execute方法：
@Override
public Mono<Void> execute(final ServerWebExchange exchange) {
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();
});
}
他将当前执行的plugin与要执行的plugin类型做了比对，如果类型不同则跳过，如果相同则执行对应plugin实现的execute方法。逐步调试发现，最终执行的Plugin逻辑是WebClientResponsePlugin。
@Override
public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
return chain.execute(exchange).then(Mono.defer(() -> {
ServerHttpResponse response = exchange.getResponse();
ClientResponse clientResponse = exchange.getAttribute(Constants.CLIENT_RESPONSE_ATTR);
if (Objects.isNull(clientResponse)
|| response.getStatusCode() == HttpStatus.BAD_GATEWAY
|| response.getStatusCode() == HttpStatus.INTERNAL_SERVER_ERROR) {
Object error = SoulResultWrap.error(SoulResultEnum.SERVICE_RESULT_ERROR.getCode(), SoulResultEnum.SERVICE_RESULT_ERROR.getMsg(), null);
return WebFluxResultUtils.result(exchange, error);
}
if (response.getStatusCode() == HttpStatus.GATEWAY_TIMEOUT) {
Object error = SoulResultWrap.error(SoulResultEnum.SERVICE_TIMEOUT.getCode(), SoulResultEnum.SERVICE_TIMEOUT.getMsg(), null);
return WebFluxResultUtils.result(exchange, error);
}
response.setStatusCode(clientResponse.statusCode());
response.getCookies().putAll(clientResponse.cookies());
response.getHeaders().putAll(clientResponse.headers().asHttpHeaders());
return response.writeWith(clientResponse.body(BodyExtractors.toDataBuffers()));
}));
}
从中获取到后端服务返回的数据结果。
由此我们有理由推测WebFlux的调用逻辑如下：
至此我们我们soul网关的调用逻辑大概试水了一下，还有很多地方不是很清楚的地方，后面再深入学习。
思考总结
今天接着初步分析了一下soul网关的转发调用逻辑，其核心是基于webFlux的web框架，这个技术框架是之前没有怎么接触过的，因此话费了很多时间去调试，还有很多概念不是很清楚。但是，经过今天的学习我们接触了WebFlux这种不同与Servlet的web框架，知道了其大致原理。明天我们将专门学习一下SpringWebFlux的原理，希望有所收获。