目标
- 分析一个被soul网关代理的http接口的处理流程
- 总结
soul网关代理的http接口的处理流程
- 准备工作
启动soul-admin和soul网关，然后启动一个springMvc的rest服务，并且rest服务所暴露的接口有soul网关代理，具体的搭建网关和soul-admin流程可以参考往期文章或者直接去soul官网
- 测试soul网关代理和直连
通过soul网关代理
直连
可以看到都能够获取到想要的结果，下面我们就看一下soul网关是怎样完成请求转发和响应的流程
-
源码分析
-
- 入手
一开始，我们很懵逼，网关就集成了一些插件，并且yml配置也看不到任何暴露程序入口痕迹，只能看到配置了网关监听的端口号，这时候还是老办法，看pom文件吧，pom文件中插件的依赖我们不用关心，之前的文档也大概分析了某些插件，这时候我们主要关注的其实就是soul-spring-boot-starter-gateway这个依赖包，打开这个依赖包，我们可以看到一个类都没有，这是spring.factories就是我们的关注点了，可以看到其内容是provides: soul-web，我们就知道了，这是要家在soul-web这个包，话不多说，直接看soul-web。
-
- 还是那个soul-web
我是直接打开的网关的依赖包，当然也可以直接看soul项目中的源码，可以看到这里边指出能够EnableAutoConfiguration的配置类是SoulConfiguration
下面是SoulConfiguration的代码，可以看到初始化了SoulWebHandler，DispatcherHandler，PluginDataSubscriber等等，看到这里，我觉得请求的接收十有八九是SoulWebHandler，DispatcherHandler来处理的，因为PluginDataSubscriber之前我们分析过，它是用来订阅插件数据变更的通知的，其他初始化的Bean多是些过滤器暂时先不考虑。
@Configuration
@ComponentScan("org.dromara.soul")
@Import(value = {ErrorHandlerConfiguration.class, SoulExtConfiguration.class, SpringExtConfiguration.class})
@Slf4j
public class SoulConfiguration {
/**
* Init SoulWebHandler.
*
* @param plugins this plugins is All impl SoulPlugin.
* @return {@linkplain 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);
}
/**
* init dispatch handler.
*
* @return {@link DispatcherHandler}.
*/
@Bean("dispatcherHandler")
public DispatcherHandler dispatcherHandler() {
return new DispatcherHandler();
}
/**
* Plugin data subscriber plugin data subscriber.
*
* @param pluginDataHandlerList the plugin data handler list
* @return the plugin data subscriber
*/
@Bean
public PluginDataSubscriber pluginDataSubscriber(final ObjectProvider<List<PluginDataHandler>> pluginDataHandlerList) {
return new CommonPluginDataSubscriber(pluginDataHandlerList.getIfAvailable(Collections::emptyList));
}
...
}
话不多说，赶紧看看SoulWebHandler，DispatcherHandler代码，打开DispatcherHandler，发现这个东西是spring的，既然是spring的那肯定不是我们自己定义的用来接收请求的，但是又不知道他是干啥的，赶紧查一下，DispatcherHandler在spring webflux中相当于springmvc的DispatcherServlet，多一跳过它直接看SoulWebHandler；
-
-
- SoulWebHandler分析
-
下面是SoulWebHandler部分代码，我们一部分一部分分析，首先该类实现了WebHandler接口，这又是个啥？？赶紧查查，原来这是springwebflux定义的Web请求必要的一些处理行为的接口，其实在看这篇源码之前，我也简单了解下了springwebfulx，但其实还是不是很透彻，总之实现了这个接口并重写他的handle方法，那么handle方法就是用来处理Web请求的，可以看到在初始化SoulWebHandler的时候，将SoulPlugin列表也初始化了，并且还初始化了一个Scheduler，这里就不得不说到spring webfulx所配合的Reactor了，Scheduler其实就是Reactor并行运行的调度器，关于Reactor的知识，这里先不说了，免得跑题，接下来看handle方法，可以看出来它是将插件的列表作为参数初始化DefaultSoulPluginChain进行执行的。
下面是DefaultSoulPluginChain代码，其核心的是execute，这里又是使用到了响应式编程Mono.defer，其中的逻辑是，遍历插件列表，插件满足skip条件时跳过，否则执行，这其实是一个责任链的设计模式，这其中skip方法设计的很有意思，是通过SoulContext来判断是否需要skip
我们跳过其他的插件，直接看处理请求转发的插件，以下是我配置的所有插件，先看名字再猜哪个是处理请求转发的嘛，因为是Http请求嘛，那就是WebClientPlugin插件呗。
-
-
- WebClientPlugin分析
-
直接上代码，代码比较多，这里核心的处理方法是execute，其他各个方法的作用在代码中已经标出来了，这里执行插件列表用到的责任链模式特别巧妙，当所有的插件执行完成，这一整个请求就执行完了，但请注意，插件的执行顺序也是固定的，比如限流插件肯定要在WebClientPlugin之前执行
@Slf4j
public class WebClientPlugin implements SoulPlugin {
private final WebClient webClient;
/**
* Instantiates a new Web client plugin.
*
* @param webClient the web client
*/
public WebClientPlugin(final WebClient webClient) {
this.webClient = webClient;
}
@Override
public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
final SoulContext soulContext = exchange.getAttribute(Constants.CONTEXT);
assert soulContext != null;
String urlPath = exchange.getAttribute(Constants.HTTP_URL);
if (StringUtils.isEmpty(urlPath)) {
Object error = SoulResultWrap.error(SoulResultEnum.CANNOT_FIND_URL.getCode(), SoulResultEnum.CANNOT_FIND_URL.getMsg(), null);
return WebFluxResultUtils.result(exchange, error);
}
long timeout = (long) Optional.ofNullable(exchange.getAttribute(Constants.HTTP_TIME_OUT)).orElse(3000L);
int retryTimes = (int) Optional.ofNullable(exchange.getAttribute(Constants.HTTP_RETRY)).orElse(0);
log.info("The request urlPath is {}, retryTimes is {}", urlPath, retryTimes);
HttpMethod method = HttpMethod.valueOf(exchange.getRequest().getMethodValue());
// 请求转发
WebClient.RequestBodySpec requestBodySpec = webClient.method(method).uri(urlPath);
return handleRequestBody(requestBodySpec, exchange, timeout, retryTimes, chain);
}
@Override
public int getOrder() {
return PluginEnum.DIVIDE.getCode() + 1;
}
@Override
public String named() {
return "webClient";
}
// 是否跳过该插件
@Override
public Boolean skip(final ServerWebExchange exchange) {
final SoulContext soulContext = exchange.getAttribute(Constants.CONTEXT);
assert soulContext != null;
return !Objects.equals(RpcTypeEnum.HTTP.getName(), soulContext.getRpcType())
&& !Objects.equals(RpcTypeEnum.SPRING_CLOUD.getName(), soulContext.getRpcType());
}
// 构造Http请求头
private MediaType buildMediaType(final ServerWebExchange exchange) {
return MediaType.valueOf(Optional.ofNullable(exchange
.getRequest()
.getHeaders().getFirst(HttpHeaders.CONTENT_TYPE))
.orElse(MediaType.APPLICATION_JSON_VALUE));
}
// 构造Http请求参数
private Mono<Void> handleRequestBody(final WebClient.RequestBodySpec requestBodySpec,
final ServerWebExchange exchange,
final long timeout,
final int retryTimes,
final SoulPluginChain chain) {
return requestBodySpec.headers(httpHeaders -> {
httpHeaders.addAll(exchange.getRequest().getHeaders());
httpHeaders.remove(HttpHeaders.HOST);
})
.contentType(buildMediaType(exchange))
.body(BodyInserters.fromDataBuffers(exchange.getRequest().getBody()))
.exchange()
.doOnError(e -> log.error(e.getMessage()))
.timeout(Duration.ofMillis(timeout))
.retryWhen(Retry.onlyIf(x -> x.exception() instanceof ConnectTimeoutException)
.retryMax(retryTimes)
.backoff(Backoff.exponential(Duration.ofMillis(200), Duration.ofSeconds(20), 2, true)))
.flatMap(e -> doNext(e, exchange, chain));
}
// 执行下一个责任链
private Mono<Void> doNext(final ClientResponse res, final ServerWebExchange exchange, final SoulPluginChain chain) {
if (res.statusCode().is2xxSuccessful()) {
exchange.getAttributes().put(Constants.CLIENT_RESPONSE_RESULT_TYPE, ResultEnum.SUCCESS.getName());
} else {
exchange.getAttributes().put(Constants.CLIENT_RESPONSE_RESULT_TYPE, ResultEnum.ERROR.getName());
}
exchange.getAttributes().put(Constants.CLIENT_RESPONSE_ATTR, res);
return chain.execute(exchange);
}
}
总结
好了，一个Http请求的具体代理流程大致就分析完了，实际上还是留下了很多细节，比如说如何判断skip，插件列表的执行顺序，Reactor的API的具体说明等等，这些只能是慢慢分析了，有一点很重要，就是在分析这个流程时，一定要对Spring WebFlux，Reactor的API有一定的了解，不然理解起来很费劲。