当前位置：首页 > 知识库 > 正文

快手3元一万粉 - 24小时快手自助下单平台抢置顶,快手刷双击自助下单秒刷蚂蚁ly易支付

2218329273
知识库
2023-01-08 11:01:04
494

背景

在一些业务场景, 往往需要自定义异常来满足特定的业务, 主流用法是在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 的回传异常会在 AbstractInvoker 的 waitForResultIfSync

中把异常信息堆栈统一封装成 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 机制默认实现的是 JavassistProxyFactory，

JavassistProxyFactory 创建了一个继承自 AbstractProxyInvoker 类的匿名对象，

并重写了抽象方法 doInvoke。

重写后的 doInvoke 只是将调用请求转发给了 Wrapper 类的 invokeMethod 方法，

并生成 invokeMethod 方法代码和其他一些方法代码。

代码生成完毕后，通过 Javassist 生成 Class 对象，

最后再通过反射创建 Wrapper 实例，随后通过 InvokerInvocationHandler -> InvocationUtil -> AbstractInvoker -> 具体实现类发送请求到Provider端。

Provider 进行相应的业务处理后返回相应的结果给 Consumer 端，来自 Provider 端的结果会被封装成 AsyncResult ，在 AbstractInvoker 的具体实现类里，

接受到来自 Provider 的响应之后会调用 appResponse 到 recreate 方法，若 appResponse 里包含异常，

则会抛出给用户，大体流程如下：

上述的异常处理相关环节是在 Consumer 端，在 Provider 端则是由 org.apache.dubbo.rpc.filter.ExceptionFilter 进行处理，

它是一系列责任链 Filter 中的一环，专门用来处理异常。

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

而当 appResponse 回到了 Consumer 端，会在 InvocationUtil 里调用 AppResponse 的 recreate 方法抛出异常，

最终可以在 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 的具体实现类是 TripleInvoker ，

TripleInvoker 在发送前会启动监听器，监听来自 Provider 端的响应结果，

并调用 ClientCallToObserverAdapter 的 onNext 方法发送消息，

最终会在底层封装成 Netty 请求发送数据。

在正式的请求发起前，TripleServer 会注册 TripleHttp2FrameServerHandler，

它继承自 Netty 的 ChannelDuplexHandler，

其作用是会在 channelRead 方法中不断读取 Header 和 Data 信息并解析，

经过层层调用，

会在 AbstractServerCall 的 onMessage 方法里把来自 consumer 的信息流进行反序列化，

并最终由交由 ServerCallToObserverAdapter 的 invoke 方法进行处理。

在 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 文件进行通信，

就可以构造出通信双方可解析的结构。