【剖析 | SOFARPC 框架】系列之 SOFARPC 同步异步实现剖析-CSDN博客

SOFA

Scalable Open Financial Architecture

是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。

本文为《剖析 | SOFARPC 框架》第四篇。《剖析 | SOFARPC 框架》系列由 SOFA 团队和源码爱好者们出品

前言

这一篇，我们为大家带来了开发过程中，最常接触到的同步异步调用解析。本文会介绍下同步异步的使用场景，以及 SOFARPC 中的代码实现机制，为了方便大家理解和阅读代码。不会过多的设计代码实现细节，更多的还是希望大家从中有所收获，并能够独立阅读核心代码。

原理剖析

SOFARPC 以基于 Netty 实现的网络通信框架 SOFABolt 用作远程通信框架，使用者不用关心如何实现私有协议的细节，直接使用内置 RPC 通信协议，启动客户端与服务端，同时注册用户请求处理器即可完成远程调用：

SOFARPC 服务调用提供同步 Sync、异步 Future、回调 Callback 以及单向 Oneway 四种调用类型：

先提供一张整体的图，后面每个方式原理介绍的时候，会进行更加详细的解释。读者可以重点阅读以下部分的图示，根据阻塞时间的长短，会有不同的标识。

Sync 同步调用

同步调用是指的客户端发起调用后，当前线程会被阻塞，直到等待服务端返回结果或者出现了超时异常，再进行后续的操作，是绝大多数 RPC 的默认调用方式，无需进行任何设置即可。

这种调用方式，当前线程发起调用后阻塞请求线程，需要在指定的超时时间内等到响应结果才能完成本次调用。如果超时时间内没有得到响应结果，那么会抛出超时异常。Sync 同步调用模式最常用，注意要根据对端的处理能力合理设置超时时间。

如上图所示，这里主要描述了客户端的处理逻辑，其中客户端线程和 RPC 内部部分处理并不在一个线程里。所以这里客户端线程包含其中一部分操作，后文的图中也是类似，红色的树状框表示客户端的线程阻塞。

我们可以看到，客户端在代码片段 2 中，发起 RPC 调用，那么除非本次 RPC 彻底完成，或者 RPC 在指定时间内抛出超时异常，否则红框一直阻塞，导致代码片段 3 没有机会执行。

Future 异步调用

客户端发起调用后不会同步等待服务端的结果，而是获取到 RPC 框架给到的一个 Future 对象，调用过程不会阻塞线程，然后继续执行后面的业务逻辑。服务端返回响应结果被 RPC 缓存，当客户端需要响应结果的时候需要主动获取结果，获取结果的过程阻塞线程。

如上图所示，代码片段 2 发起 RPC 调用后，RPC 框架会立刻返回一个 Future 对象。给到代码片段 2，代码片段 2 可以选择等待结果，或者也可以继续执行代码片段 3，等代码片段3 执行完成后，再获取 Future 中的值。

Callback 回调调用

客户端提前设置回调实现类，在发起调用后不会等待结果，但是注意此时是通过上下文或者其他方式向 RPC 框架注册了一个 Callback 对象，结果处理是在新的线程里执行。RPC在获取到服务端的结果后会自动执行该回调实现。

如图所示，客户端代码段 2 发起 RPC 调用后，并不关心结果，此时也不会有结果。只是将自己的一个 Callback 对象传递给 RPC 框架，RPC 框架发起调用后，立即返回。之后自己等待调用结果，在有了调用结果，或者超过业务配置的超时时间后，将响应结果或者超时的异常，进行 callback 的回调。一般的，一个 callback 的结果需要包含两个部分：

public interface InvokeCallback {

    /**
     * Response received.
     * 
     * @param result
     */
    public void onResponse(final Object result);

    /**
     * Exception caught.
     * 
     * @param e
     */
    public void onException(final Throwable e);
}复制代码

如果是正常返回，则 RPC 框架回调用户传入 callback 对象的 onResponse 方法，如果是框架层的异常，比如超时，那么会调用 onException 方法。

Oneway 单向调用

客户端发送请求后不会等待服务端返回的结果，并且会忽略服务端的处理结果，

当前线程发起调用后，用户并不关心调用结果，只要请求已经发出就完成本次调用。单向调用不关心响应结果，请求线程不会被阻塞，使用 Oneway 调用需要注意控制调用节奏防止压垮接收方。注意 Oneway 调用不保证成功，而且发起方无法知道调用结果。

因此通常用于可以重试，或者定时通知类的场景，调用过程是有可能因为网络问题、机器故障等原因导致请求失败，业务场景需要能接受这样的异常场景才能够使用。

以上介绍的调用方式比较

源码剖析

下面我们以 SOFARPC 中的 BOLT 协议为基础，介绍一些 RPC 框架下面的代码层面的设计。主要介绍代码结构和相互的调用关系：

对 BOLT 的包装主要在

com.alipay.sofa.rpc.transport.bolt.BoltClientTransport复制代码

业务方并不直接使用 BOLT 定义的一些类型，而是使用 RPC 定义的一些类型。这些类型被适配到 BOLT 的类型上，使得 RPC 框架对用户提供了统一的 API，和底层是否采用 BOLT 不强相关。

Sync 同步调用

SOFARPC 中的的同步调用是由 Bolt 通信框架来实现的。核心代码实现在

com.alipay.remoting.BaseRemoting#invokeSync
com.alipay.remoting.rpc.protocol.RpcResponseProcessor#doProcess复制代码

使用时无需特殊配置。

Future 异步调用

使用 Future 异步调用 SOFABoot 配置服务引用需要设置

<sofa:global-attrs type="future"/>复制代码

元素的 type 属性声明调用方式为 future：

如上设置为 Future 调用的方式。客户端获取响应结果有两种方式：

1. 通过 SofaResponseFuture 直接获取结果。第一个参数是获取结果的超时时间，第二个参数表示是否清除线程上下文中的结果。

String result =(String)SofaResponseFuture.getResponse(timeout,true);复制代码

2. 获取原生 Futrue，该种方式获取JDK原生的 Future，参数表示是否清除线程上下文中的结果。因为响应结果放在JDK原生的 Future，需要通过JDK Future的get()方法获取响应结果。

Future future = SofaResponseFuture.getFuture(true);复制代码

当前线程发起调用得到 RpcResponseFuture 对象，当前线程继续执行下一次调用。在任意时刻使用RpcResponseFuture 对象的 get() 方法来获取结果，如果响应已经回来此时就马上得到结果；如果响应没有回来则阻塞住当前线程直到响应回来或者超时时间到。

Callback 回调调用

目前支持 bolt 协议。客户端回调类需要实现

com.alipay.sofa.rpc.core.invoke.SofaResponseCallback复制代码

接口

使用 SOFABoot的话配置

<sofa:global-attrs type="callback" callback-ref="callback"/>复制代码

如上设置是服务级别的设置，也可以进行调用级别的设置：

RpcInvokeContext.getContext().setResponseCallback(sofaResponseCallbackImpl);复制代码

当前线程发起调用则本次调用马上结束执行下一次调用。发起调用时需要注册回调，该回调需要分配异步线程池以待响应回来后在回调的异步线程池来执行回调逻辑。

Oneway 单向调用

使用 Oneway 单向调用 SOFABoot 配置服务引用需要设置

<sofa:global-attrs type="oneway"/>复制代码

元素的type属性声明调用方式 oneway

技术实现

超时计算

在同步中，有个很重要的事情就是超时计算。同步 Sync/异步Future/回调Callback三种通信模型，通过采用HashedWheelTimer 进行超时控制，对这部分感兴趣的，可以参考蚂蚁通信框架实践，这里不再重复说明。

这里画出一张超时的时间图，对 SOFARPC 中 Tracer 中的超时中涉及到的时间点做一个介绍。

通过这张图中的介绍，加上 SOFATracer 的日志打印，我们可以在实际的线上环境中，判断出来，哪一部分耗时比较严重，来定位一些超时的问题。

对于 SOFARPC 框架的使用方来说，很多时候是非常关心超时时间的，因为超时时间如果设置时间过长，会阻塞业务线程，极端场景下，可能会拖垮整个系统。RPC框架允许用户设置不同级别的超时时间来控制。

/**
 * 决定超时时间
 *
 * @param request        请求
 * @param consumerConfig 客户端配置
 * @param providerInfo   服务提供者信息
 * @return 调用超时
 */

private int resolveTimeout(SofaRequest request, ConsumerConfig consumerConfig, ProviderInfo providerInfo) {
    // 先去调用级别配置
    Integer timeout = request.getTimeout();
    if (timeout == null) {
        // 取客户端配置（先方法级别再接口级别）
        timeout = consumerConfig.getMethodTimeout(request.getMethodName());
        if (timeout == null || timeout < 0) {
            // 再取服务端配置
            timeout = (Integer) providerInfo.getDynamicAttr(ATTR_TIMEOUT);
            if (timeout == null) {
                // 取框架默认值
                timeout = getIntValue(CONSUMER_INVOKE_TIMEOUT);
            }
        }
    }
    return timeout;
}复制代码

目前，我们

1. 先取调用级别，这个是通过调用线程上下文可以设置的。

2. 然后取客户端配置的消费者超时时间，先取方法级别配置，如果没有，取接口级别。

3. 如果还是没有取到，这时候，我们取服务提供方的超时时间，这个会通过注册中心传递下来。

4. 最终，我们取默认的超时时间，目前这个超时时间是3s。

注意，在真实的场景下，超时控制实际上是一个比较有挑战的事情，一旦出现 JVM层面的 STW，时间控制就会变得不够准确。因此，如果系统层面存在某些性能问题，也会影响超时的计算，这时候，会看到，已经超过了超时时间，但是客户端并没有及时终止。