我是靠谱客的博主 拉长硬币,最近开发中收集的这篇文章主要介绍借助Gateway网关层对服务端各类异常做统一处理,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

异常的种类

网关层的异常分为以下两种:

  • 调用请求异常 通常由调用请求直接抛出的异常,比如在订单服务中直接报错throw new RuntimeException("error")
  • 网关层异常 由网关层触发的异常,比如Gateway通过服务发现找不到可用节点,或者任何网关层内部的问题。这部分异常通常是在实际调用请求发起之前发生的。

在以上两种问题中,我认为网关层只应该关注第二个点,也就是自身异常。在实际应用中我们应该尽量保持网关层的“纯洁性”并且做好职责划分,Gateway只要做好路由的事情,不要牵扯到具体业务层的事儿,最好也不要替调用请求的异常操心。对于业务调用中的异常情况,如果需要采用统一格式封装调用异常,那就交给每个具体服务去定义结构,让各自业务方和前端页面协调好异常消息的结构。

但是在实际项目中,不能保证每个接口都实现了异常封装,如果想给前台页面一个统一风格的JSON格式异常结构,那就需要让Gateway做一些分外的事儿,比如拦截Response并修改返回值。(我还是强烈建议让服务端自己定义异常结构,因为Gateway本身不应该对这些异常做额外封装只是原封不动的返回)

Gateway已经将网关层直接抛出的异常(没有调用远程服务之前的异常)做了结构化封装,对于POST的调用来说其本身也会返回结构化的异常信息,但是对于GET接口的异常来说,则是直接返回一个HTML页面,前端根本无法抓取具体的异常信息。所以我们今天就主要聚焦在如何处理调用请求异常。

服务调用异常

我们定义一个主动抛出异常的GET接口,然后通过网关层发起调用,会发现默认返回了HTML的异常页面。
在这里插入图片描述

当我们使用常规的全局异常处理方式会发现根本不起作用,这是为什么呢?因为我们目前使用的Greenwich版本底层是基于WebFlux来实现的,并不是Pure Servlet应用,因此常规的手段在这里不起作用。那么接下来,我就带大家通过添加一个过滤器,来处理异常调用,并且将返回值改为JSON格式。

改造客户端异常

我们先来看一看Gateway网关层异常情况下的返回数据

{
    "timestamp": "2019-10-26T15:13:29.870+0000",
    "path": "/gateway/error",
    "status": 500,
    "error": "Internal Server Error",
    "message": "Unable to find instance for FEIGN-SERVICE-PROVIDER"
}

看起来干净整洁,那我们是否可以在网关层对服务端返回的异常做一番改造,也呈现类似的效果呢?接下来,我们就运用最开始Eureka章节中学到的装饰器编程模式+代理模式,给Gateway加一层特效,改变ResponseBody中的数据结构,顺带也体验一下如何将编程模式运用到实际需求中。

代理模式 - BodyHackerFunction接口

在最开始我们先定义一个代理模式的接口

public interface BodyHackerFunction extends BiFunction<ServerHttpResponse, Publisher<? extends DataBuffer>, Mono<Void>> {
}

这里引入代理模式是为了将装饰器和具体业务代理逻辑拆分开来,在装饰器中只需要依赖一个代理接口,而不需要和具体的代理逻辑绑定起来。

装饰器模式 - BodyHackerDecrator

接下来我们定义一个装饰器类,这个装饰器继承自ServerHttpResponseDecorator类,我们这里就用装饰器模式给Response Body的构造过程加上一层特效。

public class BodyHackerHttpResponseDecorator extends ServerHttpResponseDecorator {

    /**
     * 负责具体写入Body内容的代理类
     */
    private BodyHackerFunction delegate = null;

    public BodyHackerHttpResponseDecorator(BodyHackerFunction bodyHandler, ServerHttpResponse delegate) {
        super(delegate);
        this.delegate = bodyHandler;
    }

    @Override
    public Mono<Void> writeWith(Publisher<? extends DataBuffer> body) {
        return delegate.apply(getDelegate(), body);
    }

}

这个装饰器的构造方法接收一个BodyHancker代理类,其中的关键方法writeWith就是用来向Response Body中写入内容的。这里我们覆盖了该方法,使用代理类来托管方法的执行,而在整个装饰器类中看不到一点业务逻辑,这就是我们常说的单一职责。

创建Filter
@Component
@Slf4j
public class ErrorFilter implements GatewayFilter, Ordered {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        final ServerHttpRequest request = exchange.getRequest();
        BodyHackerFunction delegate = // TODO 这里定义写入Body的逻辑

        // 将装饰器当做Response返回
        BodyHackerHttpResponseDecorator responseDecorator = 
            new BodyHackerHttpResponseDecorator(delegate, exchange.getResponse());
            
        return chain.filter(exchange.mutate().response(responseDecorator).build());
    }

    @Override
    public int getOrder() {
        // WRITE_RESPONSE_FILTER的执行顺序是-1,我们的Hacker在它之前执行
        return -2;
    }

}

在这个Filter中,我们定义了一个装饰器类BodyHackerHttpResponseDecorator,同时声明了一个匿名内部类(代码TODO部分),实现了BodyHackerFunction代理类的Body替换逻辑,并且将这个代理类传入了装饰器。这个装饰器将直接参与构造Response Body。

我们还覆盖了getOrder方法,是为了确保我们的filter在默认的Response构造器之前执行。

改造Response Body

这里就是上一步中标注TODO的部分

BodyHackerFunction delegate = (resp, body) -> Flux.from(body)
       .flatMap(orgBody -> {
            // 原始的response body
            byte[] orgContent = new byte[orgBody.readableByteCount()];
            orgBody.read(orgContent);
            
            String content = new String(orgContent);
            log.info("original content {}", content);

            // 如果500错误,则替换
            if (resp.getStatusCode().value() == 500) {
                content = String.format("{"status": %d,"path":"%s"}",
                        resp.getStatusCode().value(),
                        request.getPath().value());
            }

            // 告知客户端Body的长度,如果不设置的话客户端会一直处于等待状态不结束
            HttpHeaders headers = resp.getHeaders();
            headers.setContentLength(content.length());
            return resp.writeWith(Flux.just(content)
                    .map(bx -> resp.bufferFactory().wrap(bx.getBytes())));
        }).then();

我们对500的HTTP Status做了特殊定制,使用我们自己的JSON内容替换了原始内容,同学们可以根据需要向JSON中加入其它参数。对于其他非500 Status的Response来说,我们还是返回初始的Body。

这里有个需要注意的地方就是记得在header中设置content-length,让客户端知道Response中内容的长度,否则的话客户端会认为传输未结束,一直等在那里。

使用Filter

上面步骤都完成以后,接着我们就可以将这个filter应用在指定的路由规则中,或者定义成global filter,对所有路由规则生效。经过这次的改造,远程服务抛出的异常也在网关层做了统一处理,从HTML页面转为了JSON格式的数据。

最后

以上就是拉长硬币为你收集整理的借助Gateway网关层对服务端各类异常做统一处理的全部内容,希望文章能够帮你解决借助Gateway网关层对服务端各类异常做统一处理所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(27)

评论列表共有 0 条评论

立即
投稿
返回
顶部