为什么需要修改?
可能是因为在项目开始前,并没有制定标准的规范,而且开发人员对Http基本知识了解。服务端无论有没有出现异常,又或者是权限不足,一律将Http的响应码设置为200,导致无法正常使用OpenFeign以及无法适配第三方应用(依赖Http响应码)。
后端开发人员对Http基本知识存在欠缺
我在进入公司时,调试接口时发现很多的接口响应码都是200,无论处理这个请求时,有没有抛出异常,Http响应码都是200。我在看代码时,很多的处理逻辑和下面差不多。
java
代码解读
复制代码
// Controller 目前不讨论返回Json字符串对不对
@PostMapping("/addMarsNoticeToGM")
public String addMarsNoticeToGM(HttpServletRequest request, @RequestBody Notice notice) {
return noticeService.postNotice(notice);
}
// Service
@Override
public String postNotice(Notice notice) {
int row = noticeMapper.insert(notice);
if (row != 0) {
return ResultEnum.useResultEnum(ResultEnum.REQUESTSUCCESS);
}
// 将结果转换成json字符
return ResultEnum.useResultEnum(ResultEnum.PROGRAMERROR);
}
在项目中,并没有对异常进行统一的处理,没有在发生异常时,设置Http响应码。客户端那边判断请求是否成功,是通过对响应体中的code
字段进行(该code不是Http中的响应码),如果code不等于200,那么客户端就认为请求被成功的处理了。
客户端开发
公司一直是做单机游戏,很多人对Http基本上没有任何了解,比如不知道请求头有什么用,不同的Http响应码代表的意义。貌似在处理请求响应时,只对成功的请求进行处理,如果将Http响应码设置成非200- 299
,可能会导致客户端无法使用。而且客户端已经迭代了几个版本,响应码问题只能由后端兼容。
后端使用OpenFeign进行通信
后端使用的是Spring Cloud Alibaba,各个服务之间是使用OpenFeign进行通信(之前后端开发人员没有使用过)。使用OpenFeign进行服务间调用时,如果被调用者未能成功处理请求并且Http响应码为200,那么会导致此调用未能进入OpenFeign的Fallback中。因为OpenFeign认为这个调用是成功的,这样会导致调用者需要额外的代码来对响应体进行判断和处理,这样是不对并且不推荐的。
java
代码解读
复制代码
// feign.AsyncResponseHandler#handleResponse
void handleResponse(CompletableFuture<Object> resultFuture,
String configKey,
Response response,
Type returnType,
long elapsedTime) {
// copied fairly liberally from SynchronousMethodHandler
boolean shouldClose = true;
try {
// 如果Http响应码是200~299,则认为该调用是成功的
if (response.status() >= 200 && response.status() < 300) {
if (isVoidType(returnType)) {
resultFuture.complete(null);
} else {
final Object result = decode(response, returnType);
shouldClose = closeAfterDecode;
resultFuture.complete(result);
}
// 开启dismiss404并且Http响应码是404时,正常处理
} else if (dismiss404 && response.status() == 404 && !isVoidType(returnType)) {
final Object result = decode(response, returnType);
shouldClose = closeAfterDecode;
resultFuture.complete(result);
} else {
// 否则其它的Http响应码都当作异常处理
resultFuture.completeExceptionally(errorDecoder.decode(configKey, response));
}
} catch (final IOException e) {
if (logLevel != Level.NONE) {
logger.logIOException(configKey, logLevel, e, elapsedTime);
}
resultFuture.completeExceptionally(errorReading(response.request(), response, e));
} catch (final Exception e) {
resultFuture.completeExceptionally(e);
} finally {
if (shouldClose) {
ensureClosed(response.body());
}
}
}
从上面的源码中可以看到,OpenFeign判断此次调用是否成功是便是通过Http的响应码来判断的。如果响应码没有在200~299
范围内(404需要根据条件开启),OpenFeign会抛出异常。
如果设置了熔断(以Sentinel为例),那么该异常会被com.alibaba.cloud.sentinel.feign.SentinelInvocationHandler#invoke
捕获,从而调用我们自己的FallbackFactory
进行异常处理。
所以如果项目使用了OpenFeign类似的框架进行服务间调用,被调用者如果未能成功处理请求(异常或执行业务逻辑失败),正确设置Http响应码是必须的。
需要解决的问题
基于上述的描述,目前需要解决的问题有:
- 不影响客户端,客户端接口还是需要将Http响应码设置为
200
(无论是否抛出异常) - 使OpenFeign能够正常工作
- 第三方应用接口的响应码不能进行修改
网关
网关作为业务系统的入口和出口,不仅仅作为简单的门户使用,还充当着很多的角色。在Spring Cloud Gateway
中,网关可以对请求进行修改,比如操作Cookie、Header、请求体等。
因为所有的请求都需要经过网关发送回客户端,所以上面三个问题我们都可以通过网关进行解决,这三个问题的解决方案为:
OpenFeign
为了能够正常使用OpenFeign,我们首先需要知道,通过OpenFeign调用其它服务时,正常来说是不经过网关的。OpenFeign会从注册中心中根据serviceId
获取被调用这的IP和端口,最终是通过IP:Port/Uri
去访问其它服务,不会经过网关。
所以,我们可以让各个服务正确的设置Http响应码,如果在处理请求时抛出了异常,就设置Http响应码为500。这样便能使OpenFeign能够正常工作。
客户端和第三方应用接口
目前项目的接口主要分为管理后台接口、游戏客户端接口、第三方应用接口(团队文档系统等)。因为游戏客户端的接口,不管请求是否成功,Http响应码都必须是200
。而管理后台和第三方应用都能正确处理Http响应码,第三方应用对接口要求严格,比如权限不足就必须返回403。
我最终是默认将所有请求的Http响应码都修改为200,增加配置项,可以手动的配置哪些接口不需要对响应码进行修改。这样便可以兼顾游戏客户端,管理后台,第三方应用。
而且因为OpenFeign的调用不会经过网关,所以在网关中将Http响应码设置为200并不会影响到OpenFengin的正常使用。
代码
在Spring Cloud Gateway中修改响应码很简单,只需要创建一个ModifyResponseStatusFilter,实现GlobalFilter接口就可以了,该接口采用的是责任链模式。
但是需要注意修改的时机,如果响应已经写回给客户端了,那么在此之后,便不能对响应码进行修改。
在Gateway中,会存在很多的GloablFilter。我们可以实现Ordered接口,通过合理的返回org.springframework.core.Ordered#getOrder
值,便可以控制自己的Filter在哪个Filter之前或之后执行。getOrder()的返回值越小,GolbalFilter#filter
方法便会越早执行并且响应会越晚经过。
源码分析
设置响应码的方法为exchange.getResponse().setStatusCode()
,setStatusCode方法源码如下:
java
代码解读
复制代码
private final AtomicReference<State> state = new AtomicReference<>(State.NEW);
@Override
public boolean setStatusCode(@Nullable HttpStatus status) {
if (this.state.get() == State.COMMITTED) {
return false;
}
else {
this.statusCode = (status != null ? status.value() : null);
return true;
}
}
protected Mono<Void> doCommit(@Nullable Supplier<? extends Mono<Void>> writeAction) {
Flux<Void> allActions = Flux.empty();
if (this.state.compareAndSet(State.NEW, State.COMMITTING)) {
....
}
....
return allActions.then();
}
通过源码可以知道,调用setStatusCode
修改Http响应码,必须在status的值变为State.COMMITTED
之前设置才有效。status是使用doCommit
方法进行修改的,而doCommit是在NettyWriteResponseFilter这个过滤器中被调用,其源码为:
java
代码解读
复制代码
public class NettyWriteResponseFilter implements GlobalFilter, Ordered {
@Override
public int getOrder() {
return -1;
}
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
return chain.filter(exchange)
.doOnError(throwable -> cleanup(exchange))
.then(Mono.defer(() -> {
....
return (isStreamingMediaType(contentType)
// writeAndFlushWith和writeWith都会调用doCommit,具体看AbstractServerHttpResponse
? response.writeAndFlushWith(body.map(Flux::just))
: response.writeWith(body));
})).doOnCancel(() -> cleanup(exchange));
}
}
从源码中可以看到,NettyWriteResponseFilter的getOrder方法的返回值为-1,也就是说,我们如果要在自己的ModifyResponseStatusFilter中成功的调用exchange.getResponse().setStatusCode()
修改Http响应码,就必须保证ModifyResponseStatusFilter在NettyWriteResponseFilter之前执行,所以只需要保证ModifyResponseStatusFilter#getOrder() > NettyWriteResponseFilter#getOrder()
值就可以了。
最终代码
java
代码解读
复制代码
public class XcyeGatewayProperties {
/**
* 网关会自动将所有返回的响应码转换为200,如果存在不需要转换的请求头,请在此排除,支持ant模式
*/
private List<String> excludeAdapterResponseStatusUriList;
}
java
代码解读
复制代码
public class ModifyResponseStatusFilter implements GlobalFilter, Ordered {
@Resource
private XcyeGatewayProperties xcyeGatewayProperties;
private final AntPathMatcher pathMatcher = new AntPathMatcher();
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
return chain.filter(exchange).then(Mono.fromRunnable(() -> {
String methodName = exchange.getRequest().getMethodValue();
URI uri = exchange.getRequest().getURI();
String path = methodName + ":" + uri.getPort() + ":" + uri.getPath();
HttpStatus statusCode = exchange.getResponse().getStatusCode();
String uriPath = uri.getPath();
List<String> excludeAdapterResponseStatusUriList = xcyeGatewayProperties.getExcludeAdapterResponseStatusUriList();
if (excludeAdapterResponseStatusUriList != null && !excludeAdapterResponseStatusUriList.isEmpty()) {
for (String excludeUri : excludeAdapterResponseStatusUriList) {
if (!excludeUri.startsWith("/")) {
excludeUri = "/" + excludeUri;
}
if (pathMatcher.matches(excludeUri, uriPath)) {
return;
}
}
}
boolean status = exchange.getResponse().setStatusCode(HttpStatus.NOT_FOUND);
log.info("请求 {} 返回的原始响应状态码为: {}, ModifyResponseStatusFilter修改响应状态码为200的状态为 {}", path, statusCode.value(), status);
}));
}
@Override
public int getOrder() {
return NettyWriteResponseFilter.WRITE_RESPONSE_FILTER_ORDER + 1;
}
}
最后
对请求和响应进行修改,是网关最基础的功能。上面在网关中修改Http响应码我个人是不推荐,客户端和服务端之间的Http通信以及响应体结构等,我觉得一开始就应该规定好,并且要符合标准,否则的话,随着项目的迭代,后续都不知道会存在什么问题,而且应该越早改正。