写点什么

Triple 协议支持 Java 异常回传的设计与实现

作者:Apache Dubbo
  • 2022-12-29
    浙江
  • 本文字数:4112 字

    阅读完需:约 13 分钟

作者:Apache Dubbo Contributor 陈景明

背景

在一些业务场景, 往往需要自定义异常来满足特定的业务, 主流用法是在 catch 里抛出异常, 例如:


public void deal() {  try{   //doSomething      ...  } catch(IGreeterException e) {      ...      throw e;  }   }
复制代码


或者通过 ExceptionBuilder,把相关的异常对象返回给 consumer:


provider.send(new ExceptionBuilders.IGreeterExceptionBuilder()    .setDescription('异常描述信息'); 
复制代码


在抛出异常后, 通过捕获和 instanceof 来判断特定的异常, 然后做相应的业务处理,例如:


try {    greeterProxy.echo(REQUEST_MSG);} catch (IGreeterException e) {    //做相应的处理    ...}
复制代码


在 Dubbo 2.x 版本,可以通过上述方法来捕获 Provider 端的异常。而随着云原生时代的到来, Dubbo 也开启了 3.0 的里程碑。


Dubbo 3.0 的一个很重要的目标就是全面拥抱云原生,在 3.0 的许多特性中,很重要的一个改动就是支持新的一代 Rpc 协议 Triple


Triple 协议基于 HTTP 2.0 进行构建,对网关的穿透性强,兼容 gRPC,提供 Request Response、Request Streaming、Response Streaming、Bi-directional Streaming 等通信模型;从 Triple 协议开始,Dubbo 还支持基于 IDL 的服务定义。


采用 Triple 协议的用户可以在 provider 端生成用户定义的异常信息,记录异常产生的堆栈,triple 协议可保证将用户在客户端获取到异常的 message。


Triple 的回传异常会在 AbstractInvokerwaitForResultIfSync中把异常信息堆栈统一封装成 RpcException,所有来自 Provider 端的异常都会被封装成 RpcException 类型并抛出,这会导致用户无法根据特定的异常类型捕获来自 Provider 的异常,只能通过捕获 RpcException 异常来返回信息,且 Provider 携带的异常 message 也无法回传,只能获取打印的堆栈信息:


    try {        greeterProxy.echo(REQUEST_MSG);    } catch (RpcException e) {        e.printStackTrace();    }
复制代码


自定义异常信息在社区中的呼声也比较高,因此本次改动将支持自定义异常的功能, 使得服务端能抛出自定义异常后被客户端捕获到。

Dubbo 异常处理简介

我们从 Consumer 的角度看一下一次 Triple 协议 Unary 请求的大致流程:


Dubbo Consumer 从 Spring 容器中获取 bean 时获取到的是一个代理接口,在调用接口的方法时会通过代理类远程调用接口并返回结果。


Dubbo 提供的代理工厂类是 ProxyFactory,通过 SPI 机制默认实现的是 JavassistProxyFactoryJavassistProxyFactory 创建了一个继承自 AbstractProxyInvoker 类的匿名对象,并重写了抽象方法 doInvoke。重写后的 doInvoke 只是将调用请求转发给了 Wrapper 类的 invokeMethod 方法,并生成 invokeMethod 方法代码和其他一些方法代码。


代码生成完毕后,通过 Javassist 生成 Class 对象,最后再通过反射创建 Wrapper 实例,随后通过 InvokerInvocationHandler -> InvocationUtil -> AbstractInvoker -> 具体实现类发送请求到 Provider 端。


Provider 进行相应的业务处理后返回相应的结果给 Consumer 端,来自 Provider 端的结果会被封装成 AsyncResult ,在 AbstractInvoker 的具体实现类里,接受到来自 Provider 的响应之后会调用 appResponserecreate 方法,若 appResponse 里包含异常,则会抛出给用户,大体流程如下:



上述的异常处理相关环节是在 Consumer 端,在 Provider 端则是由 org.apache.dubbo.rpc.filter.ExceptionFilter 进行处理,它是一系列责任链 Filter 中的一环,专门用来处理异常。


Dubbo 在 Provider 端的异常会在封装进 appResponse 中。下面的流程图揭示了 ExceptionFilter 源码的异常处理流程:



而当 appResponse 回到了 Consumer 端,会在 InvocationUtil 里调用 AppResponserecreate 方法抛出异常,最终可以在 Consumer 端捕获:


public Object recreate() throws Throwable {    if (exception != null) {    try {        Object stackTrace = exception.getStackTrace();        if (stackTrace == null) {            exception.setStackTrace(new StackTraceElement[0]);        }    } catch (Exception e) {        // ignore    }    throw exception;}return result;}
复制代码

Triple 通信原理

在上一节中,我们已经介绍了 Dubbo 在 Consumer 端大致发送数据的流程,可以看到最终依靠的是 AbstractInvoker 的实现类来发送数据。在 Triple 协议中,AbstractInvoker 的具体实现类是 TripleInvokerTripleInvoker 在发送前会启动监听器,监听来自 Provider 端的响应结果,并调用 ClientCallToObserverAdapteronNext 方法发送消息,最终会在底层封装成 Netty 请求发送数据。


在正式的请求发起前,TripleServer 会注册 TripleHttp2FrameServerHandler,它继承自 Netty 的 ChannelDuplexHandler,其作用是会在 channelRead 方法中不断读取 Header 和 Data 信息并解析,经过层层调用,会在 AbstractServerCallonMessage 方法里把来自 consumer 的信息流进行反序列化,并最终由交由 ServerCallToObserverAdapterinvoke 方法进行处理。


invoke 方法中,根据 consumer 请求的数据调用服务端相应的方法,并异步等待结果;'若服务端抛出异常,则调用 onError 方法进行处理,否则,调用 onReturn 方法返回正常的结果,大致代码逻辑如下:


public void invoke() {    ...    try {        //调用invoke方法请求服务        final Result response = invoker.invoke(invocation);        //异步等待结果        response.whenCompleteWithContext((r, t) -> {            //若异常不为空            if (t != null) {                //调用方法过程出现异常,调用onError方法处理                responseObserver.onError(t);                return;            }            if (response.hasException()) {                //调用onReturn方法处理业务异常                onReturn(response.getException());                return;            }            ...            //正常返回结果            onReturn(r.getValue());        });    }     ...}
复制代码


大体流程如下:


实现版本

了解了上述原理,我们就可以进行相应的改造了,能让 consumer 端捕获异常的关键在于把异常对象以及异常信息序列化后再发送给 consumer 端。常见的序列化协议很多,例如 Dubbo/HSF 默认的 hessian2 序列化;还有使用广泛的 JSON 序列化;以及 gRPC 原生支持的 protobuf(PB) 序列化等等。Triple 协议因为兼容 grpc 的原因,默认采用 Protobuf 进行序列化。上述提到的这三种典型的序列化方案作用类似,但在实现和开发中略有不同。PB 不可由序列化后的字节流直接生成内存对象,而 Hessian 和 JSON 都是可以的。后两者反序列化的过程不依赖“二方包”,其序列化和反序列化的代码由 proto 文件相同,只要客户端和服务端用相同的 proto 文件进行通信,就可以构造出通信双方可解析的结构。


单一的 protobuf 无法序列化异常信息,因此我们采用 Wrapper + PB 的形式进行序列化异常信息,抽象出一个 TripleExceptionWrapperUtils 用于序列化异常,并在 trailer 中采用 TripleExceptionWrapperUtils 序列化异常,大致代码流程如下:



上面的实现方案看似非常合理,已经能把 Provider 端的异常对象和信息回传,并在 Consumer 端进行捕获。但仔细想想还是有问题的:通常在 HTTP2 为基础的通信协议里会对 header 大小做一定的限制,太大的 header size 会导致性能退化严重,为了保证性能,往往以 HTTP2 为基础的协议在建立连接的时候是要协商最大 header size 的,超过后会发送失败。对于 Triple 协议来说,在设计之初就是基于 HTTP 2.0,能无缝兼容 Grpc,而 Grpc header 头部只有 8KB 大小,异常对象大小可能超过限制,从而丢失异常信息;且多一个 header 携带序列化的异常信息意味着用户能加的 header 数量会减少,挤占了其他 header 所能占用的空间。


经过讨论,考虑将异常信息放置在 Body,将序列化后的异常从 trailer 挪至 body,采用 TripleWrapper + protobuf 进行序列化,把相关的异常信息序列化后回传。社区围绕这个问题进行了一系列的争论,读者也可尝试先思考一下:


1.在 body 中携带回传的异常信息,其对应 HTTP header 状态码该设置为多少?


2.基于 http2 构建的协议,按照主流的 grpc 实现方案,相关的错误信息放在 trailer,理论上不存在 body,上层协议也需要保持语义一致性,若此时在 payload 回传异常对象,且 grpc 并没有支持在 Body 回传序列化对象的功能, 会不会破坏 Http 和 grpc 协议的语义?从这个角度出发,异常信息更应该放在 trailer 里。


3.作为开源社区,不能一味满足用户的需求,非标准化的用法注定是会被淘汰的,应该尽量避免更改 Protobuf 的语义,是否在 Wrapper 层去支持序列化异常就能满足需求?


首先回答第二、三个问题:HTTP 协议并没有约定在状态码非 2xx 的时候不能返回 body,返回之后是否读取取决于用户。grpc 采用 protobuf 进行序列化,所以无法返回 exception;且 try catch 机制为 java 独有,其他语言并没有对应的需求,但 Grpc 暂时不支持的功能并一定是 unimplemented,Dubbo 的设计目标之一是希望能和主流协议甚至架构进行对齐,但对于用户合理的需求也希望能进行一定程度的修改。且从 throw 本身的语义出发,throw 的数据不只是一个 error message,序列化的异常信息带有业务属性,根据这个角度,更不应该采用类似 trailer 的设计。至于单一的 Wrapper 层,也没办法和 grpc 进行互通。至于 Http header 状态码设置为 200,因为其返回的异常信息已经带有一定的业务属性,不再是单纯的 error,这个设计也与 grpc 保持一致,未来考虑网关采集可以增加新的 triple-status。


更改后的版本只需在异常不为空时返回相关的异常信息,采用 TripleWrapper + Protobuf 进行序列化异常信息,并在 consumer 端进行解析和反序列化,大体流程如下:


总结

通过对 Dubbo 3.0 新增自定义异常的版本迭代中可以看出,尽管只能新增一个小小的特性,流程下并不复杂,但由于要考虑互通、兼容和协议的设计理念,因此思考和讨论的时间可能比写代码的时间更多。

发布于: 刚刚阅读数: 6
用户头像

Apache Dubbo

关注

还未添加个人签名 2020-07-31 加入

还未添加个人简介

评论

发布
暂无评论
Triple 协议支持 Java 异常回传的设计与实现_Java_Apache Dubbo_InfoQ写作社区