×
广告

dubbo剖析:六 网络通信之 -- 请求响应模型

96
益文的圈
2018.05.07 16:48* 字数 1591

注:文章中使用的dubbo源码版本为2.5.4

零、文章目录

  • Dubbo的三种RPC调用方式
  • 关键类介绍
  • DefaultFuture实现
  • 调用入口流程
  • 服务引用方请求响应模型总结

一、Dubbo的三种RPC调用方式

1.1 异步&无返回值

a)服务引用配置如下:

    <dubbo:reference id="demoService" check="false" interface="com.alibaba.dubbo.demo.DemoService">
        <dubbo:method name="sayHello" async="true" return="false"/>
    </dubbo:reference>
  • async="true"
  • return="false"

b)服务调用方式如下:

String hello = demoService.sayHello("world" + i);
  • 因为使用了异步无返回值的模式,所以hello的值一直为null;

1.2 异步&有返回值

a)服务引用配置如下:

    <dubbo:reference id="demoService" check="false" interface="com.alibaba.dubbo.demo.DemoService">
        <dubbo:method name="sayHello" async="true"/>
    </dubbo:reference>
  • async="true"

b)服务调用方式如下:

demoService.sayHello("world" + i);
Future<String> temp = RpcContext.getContext().getFuture();
String hello = temp.get();
  • 因为使用了异步模式,demoService.sayHello()被调用后立即返回(此时RPC调用结果还未生成,RPC的执行过程不阻塞业务请求线程);
  • 服务引用方业务请求线程可以在合适的时候执行RpcContext.getContext().getFuture()获取RPC调用结果;

1.3 异步变同步

a)服务引用配置如下:

    <dubbo:reference id="demoService" check="false" interface="com.alibaba.dubbo.demo.DemoService">
        <dubbo:method name="sayHello" async="false"/>
    </dubbo:reference>
  • async="false",默认值;

b)服务调用方式如下:

String hello = demoService.sayHello("world" + i);
  • 因为使用了同步模式,demoService.sayHello()被调用后直到收到RPC响应才返回,sayHello()方法返回时得到hello的值,期间业务请求线程被阻塞。

二、关键类介绍

2.1 RPC请求消息封装(Request)

dubbo的交换层定义了RPC请求的封装类Request,它包含了一个RPC请求所具备的关键信息。

public class Request {

    //请求ID生成器,AtomicLong.inc实现
    private static final AtomicLong INVOKE_ID = new AtomicLong(0);

    //RPC调用的请求ID,在单个Client端内全局唯一
    private final long mId;
    
    //RPC请求响应消息协议版本
    private String mVersion;

    //是否为双向请求响应
    private boolean mTwoWay = true;
    
    //实际RPC调用的请求数据,对应了Invocation类,调用参数都封装在这里了
    private Object mData;

    //Request初始化时,生成请求ID
    public Request() {
        mId = newId();
    }

    //请求ID生成方法
    private static long newId() {
        // getAndIncrement()增长到MAX_VALUE时,再增长会变为MIN_VALUE,负数也可以做为ID
        return INVOKE_ID.getAndIncrement();
    }
}

2.2 RPC响应消息封装(Response)

dubbo的交换层定义了RPC响应的封装类Response,它包含了一个RPC响应所具备的关键信息。

public class Response {

    /**
     * ok.
     */
    public static final byte OK = 20;

    /**
     * clien side timeout.
     */
    public static final byte CLIENT_TIMEOUT = 30;

    /**
     * server side timeout.
     */
    public static final byte SERVER_TIMEOUT = 31;

     // ...省略一些状态码...
    
    //RPC调用的请求ID,默认为0,从Request中获取
    private long mId = 0;

    //RPC请求响应消息协议版本
    private String mVersion;

    //响应状态码,默认OK,出现异常时重新设置
    private byte mStatus = OK;

    //响应错误信息
    private String mErrorMsg;
    
    //实际RPC调用的响应数据,对应实际实现类的方法执行结果
    private Object mResult;
}

2.3 RPC调用Future接口(ResponseFuture)

dubbo的交换层定义了RPC调用的响应Future接口ResponseFuture,它封装了请求响应模式,例如提供了将异步网络通信转换成同步RPC调用的关键方法Object get(int timeoutInMillis)

public interface ResponseFuture {

    /**
     * 获取RPC远程执行结果,异步IO转同步RPC的关键方法
     */
    Object get() throws RemotingException;

    /**
     * 获取RPC远程执行结果,异步IO转同步RPC的关键方法
     */
    Object get(int timeoutInMillis) throws RemotingException;

    /**
     * set callback. 响应回调模式
     */
    void setCallback(ResponseCallback callback);

    /**
     * RPC调用是否完成
     */
    boolean isDone();

}

三、DefaultFuture实现

DefaultFutureResponseFuture接口的实现类,具体实现了接口定义的方法。

3.1 请求响应信息的承载

  • DefaultFuture提供构造方法,在HeaderExchangeChannel.request()中被调用,用于构建RPC调用Future并返回给调用方使用;
  • DefaultFuture中包含以下关键属性,用于承载请求响应信息;
public class DefaultFuture implements ResponseFuture {
    
    //<请求ID,消息通道> 的映射关系
    private static final Map<Long, Channel> CHANNELS = new ConcurrentHashMap<Long, Channel>();
    
    //<请求ID,未完成状态的RPC请求> 的映射关系
    private static final Map<Long, DefaultFuture> FUTURES = new ConcurrentHashMap<Long, DefaultFuture>();

    //RPC调用的请求ID,构造器中从Request获取
    private final long id;

    //消息通道,构造器传入
    private final Channel channel;

    //RPC请求消息,构造器传入
    private final Request request;

    //RPC响应消息
    private volatile Response response;

    //RPC响应回调器
    private volatile ResponseCallback callback;

    //构造器
    public DefaultFuture(Channel channel, Request request, int timeout) {
        this.channel = channel;
        this.request = request;
        this.id = request.getId();
        this.timeout = timeout > 0 ? timeout : channel.getUrl().getPositiveParameter(Constants.TIMEOUT_KEY, Constants.DEFAULT_TIMEOUT);
        // put into waiting map.
        FUTURES.put(id, this);
        CHANNELS.put(id, channel);
    }
}

3.2 RPC执行超时检测

  • DefaultFuture定义了RPC执行超时时间timeout和RPC执行开始时间start,他们都在DefaultFuture构建时被初始化;
  • DefaultFuture中启动了一个后台守护线程,用于周期性执行 “RPC超时检测任务RemotingInvocationTimeoutScan。该任务不断检测 “未完成状态的RPC请求FUTURE” 中哪些已经超时(通过比较System.currentTimeMillis() - starttimeout
  • 对已超时的RPC请求,构建相应的超时响应Response并触发received()方法。
public class DefaultFuture implements ResponseFuture {

    //RPC超时轮询线程,不断轮询超时状态的FUTURES,主动移除并返回超时结果
    static {
        Thread th = new Thread(new RemotingInvocationTimeoutScan(), "DubboResponseTimeoutScanTimer");
        th.setDaemon(true);
        th.start();
    }

    //RPC执行超时时间,构造器传入,默认值1s
    private final int timeout;
    
    //DefaultFuture构建时间
    private final long start = System.currentTimeMillis();

}

3.3 异步网络通信转同步RPC调用

  • DefaultFuture实现了ResponseFuture接口的重要方法get(int timeout),用于同步等待RPC执行结果的返回(成功/异常/超时);
  • DefaultFuture提供了静态方法received(Channel channel, Response response),用于对客户端收到的RPC执行响应Response进行处理。处理逻辑就是讲响应结果放入response并通知在done上组织等待的业务线程,同时通知本次RPC请求绑定的回调器Callback
public class DefaultFuture implements ResponseFuture {

    //响应消息处理互斥锁,get()、doReceived()、setCallback()方法中使用
    private final Lock lock = new ReentrantLock();
    //请求响应模式Condition,通过get()中的await和doReceived()中的signal完成IO异步转RPC同步
    private final Condition done = lock.newCondition();

    //RPC响应消息接收方法
    public static void received(Channel channel, Response response) {
        try {
            DefaultFuture future = FUTURES.remove(response.getId());
            if (future != null) {
                future.doReceived(response);
            } else {
                logger.warn("The timeout response finally returned at "
                        + (new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS").format(new Date()))
                        + ", response " + response
                        + (channel == null ? "" : ", channel: " + channel.getLocalAddress()
                        + " -> " + channel.getRemoteAddress()));
            }
        } finally {
            CHANNELS.remove(response.getId());
        }
    }
    //将响应结果放入response,通知在done上等待的业务线程,并执行invokeCallback方法触发所有绑定的Callbask执行
    private void doReceived(Response res) {
        lock.lock();
        try {
            response = res;
            if (done != null) {
                done.signal();
            }
        } finally {
            lock.unlock();
        }
        if (callback != null) {
            invokeCallback(callback);
        }
    }

    //RPC执行结果同步获取方法,RPC的同步请求模式就依赖此方法完成,依赖done.await同步等待RPC执行结果
    public Object get(int timeout) throws RemotingException {
        if (timeout <= 0) {
            timeout = Constants.DEFAULT_TIMEOUT;
        }
        if (!isDone()) {
            long start = System.currentTimeMillis();
            lock.lock();
            try {
                while (!isDone()) {
                    done.await(timeout, TimeUnit.MILLISECONDS);
                    if (isDone() || System.currentTimeMillis() - start > timeout) {
                        break;
                    }
                }
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            } finally {
                lock.unlock();
            }
            if (!isDone()) {
                throw new TimeoutException(sent > 0, channel, getTimeoutMessage(false));
            }
        }
        return returnFromResponse();
    }

}

3.4 异步网络通信转同步RPC调用的两个关键点

a)发起RPC调用请求的业务线程,是如何同步阻塞等待直到RPC响应返回的?

  • 业务请求线程调用HeaderExchangeClient.request()方法发送RPC请求消息到网络,然后直接调用DefaultFuture.get()方法阻塞等待RPC执行结果;
  • get()阻塞等待的本质:循环检测Response结果是否被设置成功,如果不成功使用Condition.await()阻塞直到结果返回;
  • NettyClient接收到RPC响应消息时,会调用DefaultFuture.received()方法,该方法中触发了Condition.signal()通知业务请求线程解除阻塞等待状态;

b)对于全双工的网络通信,在多线程并发请求响应的情况下,如果找到RPC响应Response对应的RPC请求Request?

  • 对于不同的服务消费者客户端,请求响应自然与其网络通道Channel绑定,不会存在消费者A接收到消费者B的RPC响应的情况;
  • 对于同一服务消费者客户端,在RPC请求Request构建时生成并携带全局唯一自增ID,RPC响应Response会携带该ID返回。消费者客户端只需维护 “唯一ID与RPC请求的关系Map<Long, DefaultFuture> FUTURES”即可定位RPC响应对应的RPC调用上下文;

四、调用入口流程

dubbo剖析:五 请求发送与接收 中讲到,服务引用方调用dubbo的代理对象发起RPC请求时,最终会执行到DubboInvoker.doInvoke()方法:

    protected Result doInvoke(final Invocation invocation) throws Throwable {
        
        //入参构建及获取ExchangeClient
        RpcInvocation inv = (RpcInvocation) invocation;
        ExchangeClient currentClient;
        if (clients.length == 1) {
            currentClient = clients[0];
        } else {
            currentClient = clients[index.getAndIncrement() % clients.length];
        }

        try {
            boolean isAsync = RpcUtils.isAsync(getUrl(), invocation);
            boolean isOneway = RpcUtils.isOneway(getUrl(), invocation);
            int timeout = getUrl().getMethodParameter(methodName, Constants.TIMEOUT_KEY, Constants.DEFAULT_TIMEOUT);
            //case1. 异步,无返回值
            if (isOneway) { 
                boolean isSent = getUrl().getMethodParameter(methodName, Constants.SENT_KEY, false);
                currentClient.send(inv, isSent);
                RpcContext.getContext().setFuture(null);
                return new RpcResult();
            } 
            //case2. 异步,有返回值
            else if (isAsync) {   
                ResponseFuture future = currentClient.request(inv, timeout);
                RpcContext.getContext().setFuture(new FutureAdapter<Object>(future));
                return new RpcResult();
            } 
            //case3. 异步转同步(默认的通信方式)
            else {   
                RpcContext.getContext().setFuture(null);
                return (Result) currentClient.request(inv, timeout).get();
            }
        } catch (TimeoutException e) {
            throw new RpcException(RpcException.TIMEOUT_EXCEPTION, "Invoke remote method timeout. method: " + invocation.getMethodName() + ", provider: " + getUrl() + ", cause: " + e.getMessage(), e);
        } catch (RemotingException e) {
            throw new RpcException(RpcException.NETWORK_EXCEPTION, "Failed to invoke remote method: " + invocation.getMethodName() + ", provider: " + getUrl() + ", cause: " + e.getMessage(), e);
        }
    }
  • case1.异步&无返回值:直接调用ExchangeClient.send()方法,不需要请求响应模式的封装;
  • case2.异步&有返回值:调用ExchangeClient.request()方法后,将ResponseFuture放入RPC请求上下文中,直接返回;
  • case3.异步转同步:调用ExchangeClient.request()方法后,直接继续调用ResponseFuture.get()同步等待获取RPC执行结果;

五、服务引用方请求响应模型总结

服务引用方请求响应模型总结
  • 蓝色代表“发送RPC请求”过程,由业务请求线程执行,通过NettyChannel将请求数据放入Netty的IO任务队列后,构建ResponseFuture并返回。此时RPC请求发送及响应接收并未真正完成;
  • 紫色是基于Netty的网络消息收发过程,通过当前网络通道绑定的NioEventLoop线程轮询完成;
  • 橙色代表“接收RPC响应”过程,该过程在 Dubbo业务线程池 中执行,处理RPC响应消息并交由ResponseFuture触发接收响应的逻辑;
  • 绿色代表“获取RPC调用结果”过程,由业务请求线程执行,阻塞直到从ResponseFuture中获取到RPC响应结果;
dubbo剖析
Web note ad 1