今天准备讲一点简单的东西。我们知道，不管是我们去做框架还是应用程序本身，都或多或少会有些全局处理的逻辑，比如API用户鉴权，再比如统一异常处理。那我们就来看下soul网关中对于请求的全局处理部分又包括那些。
在soul网关代码中大致可以找出来如下几个全局处理的逻辑：
-
GlobalPlugin-全局插件 -
GlobalErrorHandler-全局异常处理 -
SoulWebHandler-soul网关web请求处理 -
CrossFilter-跨域支持过滤器 -
FileSizeFilter-文件大小限制过滤器 -
ExcludeFilter-URL排除过滤器 -
WebSocketParamFilter-websocket请求参数过滤器
GlobalPlugin-全局插件
- 因为是插件，所以我们只需要重点看
excute方法
public Mono execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
final ServerHttpRequest request = exchange.getRequest();
final HttpHeaders headers = request.getHeaders();
final String upgrade = headers.getFirst("Upgrade");
// 构造soul上下文
SoulContext soulContext;
// 非websocket的处理
if (StringUtils.isBlank(upgrade) || !"websocket".equals(upgrade)) {
soulContext = builder.build(exchange);
} else {
// websocket的处理
final MultiValueMap queryParams = request.getQueryParams();
soulContext = transformMap(queryParams);
}
exchange.getAttributes().put(Constants.CONTEXT, soulContext);
return chain.execute(exchange);
}
- 从代码看出来，该全局插件就为了做一件事情，构造网关上下文
soulContext，构造完成后，并将其存放到请求exchange对象中，从而实现在整个请求流程中将网关上下文的传递。 - 再来细看一下，构造网关上下文的实现部分。
public SoulContext build(final ServerWebExchange exchange) {
final ServerHttpRequest request = exchange.getRequest();
String path = request.getURI().getPath();
// 根据当前的请求路径从缓存中获取到metaData
MetaData metaData = MetaDataCache.getInstance().obtain(path);
// 原始metaData放到exchange中
if (Objects.nonNull(metaData) && metaData.getEnabled()) {
exchange.getAttributes().put(Constants.META_DATA, metaData);
}
// 将metaData转换为SoulContext
return transform(request, metaData);
}
- 获取元数据的逻辑需要提一下。首先，元数据是缓存于
MetaDataCache中的META_DATA_MAP中；其次是根据当前请求的路径去获取其metaData。获取metaData的逻辑如下：先使用请求路径作为key，从META_DATA_MAP中get，如果存在，则直接返回metaData；否则就需要先去遍历所有的META_DATA_MAP，用其key去和当前请求路径去做匹配，这里的匹配算法为Spring的AntPathMatcher。这个大家就比较熟悉了，在与我们在各种Controller中用的RequestMapping的请求匹配规则是一致的。 - 其核心的
build逻辑就是根据request中的一些参数，以及此次请求的metaData转换成SoulContext类的实例。这个逻辑代码虽然长，但不复杂，这里就不展开了。
小结
-
GlobalPlugin的依赖类图
GlobalPlugin - 从图中可以看出，
SoulContext的数据是通过SoulContextBuilder接口对应的实现类DefaultSoulContextBuilder构造，当创建类的实例存在比较复杂的构造逻辑时，可以参考此类实现 -
GlobalPlugin做为全局的逻辑，在整个插件链中是第一个执行的，因为后续的其他插件，或多或少都会有依赖SoulContext对象，通过插件执行顺序order=0实现插件链的第一个调用
GlobalErrorHandler-全局异常处理
- 顾名思义，
GlobalErrorHandler就只是一个全局的异常处理器，逻辑是不会复杂的^_^ - 首先该类继承了
DefaultErrorWebExceptionHandler，这里spring框架中提供的默认异常处理。 - 整个源码看下来，主要是为了
override了DefaultErrorWebExceptionHandler中实现的一些异常处理逻辑：getErrorAttributes、getRoutingFunction、getHttpStatus。 - 在
GlobalErrorHandler中，所有未被处理并且进入到exceptionHandler中的异常，都会被转化为INTERNAL_SERVER_ERROR，状态返回码为500，且返回带错误简略信息的response，json对象
SoulWebHandler-soul网关web请求处理
-
SoulWebHandler继承至org.springframework.web.server.WebHandler - 是网关插件链初始化并执行插件链
DefaultSoulPluginChain处理的入口
CrossFilter-跨域支持过滤器
-
soul网关中的跨域支持，并没有自己直接使用spring框架自带的org.springframework.web.cors.reactive.CorsWebFilter - 这里的实现也挺简单
public Mono filter(final ServerWebExchange exchange, final WebFilterChain chain) {
ServerHttpRequest request = exchange.getRequest();
// 判断是否为跨域请求，判断的逻辑：是否有origin参数，若有，再判断当前请求的全路径是否与origin一致
// 如果判断为跨域请求，则在reponse的header头中添加一些跨域支持的参数
if (CorsUtils.isCorsRequest(request)) {
ServerHttpResponse response = exchange.getResponse();
HttpHeaders headers = response.getHeaders();
headers.add("Access-Control-Allow-Origin", ALLOWED_ORIGIN);
headers.add("Access-Control-Allow-Methods", ALLOWED_METHODS);
headers.add("Access-Control-Max-Age", MAX_AGE);
headers.add("Access-Control-Allow-Headers", ALLOWED_HEADERS);
headers.add("Access-Control-Expose-Headers", ALLOWED_EXPOSE);
headers.add("Access-Control-Allow-Credentials", "true");
// 判断是否为optins请求，若是直接返回请求成功；否则会继续执行过滤器链
if (request.getMethod() == HttpMethod.OPTIONS) {
response.setStatusCode(HttpStatus.OK);
return Mono.empty();
}
}
return chain.filter(exchange);
}
- 需要显示配置
soul.cross.enabled开启
FileSizeFilter-文件大小限制过滤器
- 看下该过滤器的几个特性
- 只针对带文件的表单数据
multipart/form-data的请求生效 - 需要显示开启，配置
soul.file.enabled=true使用 - 默认支持的文件大小限制为
10M，超过该值，则会直接报错；该参数可配置，配置项soul.fileMaxSize
- 只针对带文件的表单数据
- 关键源码
public Mono filter(@NonNull final ServerWebExchange exchange, @NonNull final WebFilterChain chain) {
MediaType mediaType = exchange.getRequest().getHeaders().getContentType();
// 只针对带文件的表单数据的请求，会有文件大小限制
if (MediaType.MULTIPART_FORM_DATA.isCompatibleWith(mediaType)) {
ServerRequest serverRequest = ServerRequest.create(exchange,
messageReaders);
return //先将请求中的body转换为DataBuffer
serverRequest.bodyToMono(DataBuffer.class)
.flatMap(size -> {
// dataBuffer的容量是否大于最大的文件大小，若大则直接返回异常
if (size.capacity() > BYTES_PER_MB * fileMaxSize) {
// 。。。。
}
// 因上面已经读取了body数据，在io流中body体是不能读取多次的
// 需要重新生成一个新的ServerHttpRequest对象包装原有的body数据，并传递到程序后面的请求中
BodyInserter, ReactiveHttpOutputMessage> bodyInsert = BodyInserters.fromPublisher(Mono.just(size), DataBuffer.class);
HttpHeaders headers = new HttpHeaders();
headers.putAll(exchange.getRequest().getHeaders());
headers.remove(HttpHeaders.CONTENT_LENGTH);
CachedBodyOutputMessage outputMessage = new CachedBodyOutputMessage(
exchange, headers);
return bodyInsert.insert(outputMessage, new BodyInserterContext())
.then(Mono.defer(() -> {
// ServerHttpRequest的装饰，用传入的CachedBodyOutputMessage替换原有Request的body
ServerHttpRequest decorator = decorate(exchange, outputMessage);
// 在原来exchange的基础上，重新构造了新的exchange对象
return chain.filter(exchange.mutate().request(decorator).build());
}));
});
}
return chain.filter(exchange);
}
ExcludeFilter-url排除过滤器
- 该过滤器功能是将当前请求
url与网关中配置的url排除列表进行匹配，如果匹配成功，则请求结束，直接返回给请求客户端 - 通过
soul.exclude进行配置 - 可以用在将某些后台请求直接从网关下线掉
WebSocketParamFilter-websocket请求参数过滤器
- 这个是最简单的
>_<，就做了一件事：校验webscoket请求必传的一些参数