dubbo源码之一次RPC请求的生死之旅(基于Dubbo 2.7.8)-平芜编程栈

1. 全景图：从宏观到微观

在钻入代码之前，我们需要先在脑海中建立一张全景图。一次同步的 RPC 调用，大致可以分为三个阶段：

消费端（Consumer）：动态代理 -> 负载均衡 -> 封装请求 -> 编码发送 -> 同步阻塞等待。
服务端（Provider）：解码接收 -> 线程池派发 -> 过滤器链 -> 反射调用 -> 封装响应 -> 编码发送。
消费端（Consumer）：接收响应 -> 唤醒等待线程 -> 提取结果。

本文将略过配置加载和服务发现细节，通过核心链路代码将上述过程串联起来。

2. 第一阶段：消费端发起请求（Consumer）

当我们代码中执行 demoService.sayHello("world") 时，实际上是在调用 Dubbo 生成的代理对象。

2.1 动态代理入口

Dubbo 默认使用 Javassist 生成代理。所有的方法调用都会被转发到 InvokerInvocationHandler。

源码位置：org.apache.dubbo.rpc.proxy.InvokerInvocationHandler

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // ... 省略 Object 类方法的处理 // 将参数封装为 RpcInvocation RpcInvocation invocation = new RpcInvocation(method, serviceModel, args); invocation.setTargetServiceUniqueName(invoker.getUrl().getServiceKey()); // invoker 是一层层包装的，这里开始进入链式调用 return invoker.invoke(invocation).recreate(); }

2.2 集群容错与负载均衡 (Cluster)

这里的 invoker 对象通常是 MockClusterInvoker 包装下的 FailoverClusterInvoker（默认故障转移策略）。

源码位置：org.apache.dubbo.rpc.cluster.support.FailoverClusterInvoker

public Result doInvoke(Invocation invocation, final List<Invoker<T>> invokers, LoadBalance loadbalance) { // 1. 获取重试次数，默认 retries="2" (共调3次) int len = getUrl().getMethodParameter(methodName, RETRIES_KEY, DEFAULT_RETRIES) + 1; for (int i = 0; i < len; i++) { // 2. 负载均衡选择一个 Invoker (例如 DubboInvoker) Invoker<T> invoker = select(loadbalance, invocation, copyInvokers, invoked); try { // 3. 执行调用 Result result = invoker.invoke(invocation); return result; } catch (RpcException e) { // 发生异常，循环继续，即“重试” } } }

2.3 过滤器链 (Filter Chain)

在选定具体的 DubboInvoker 之前，请求会经过一系列 Filter（如 ConsumerContextFilter、MonitorFilter）。这是通过 ProtocolFilterWrapper 构建的责任链模式。

2.4 协议层发送 (Protocol)

请求最终到达 DubboInvoker，这里是 Dubbo 协议的核心。

源码位置：org.apache.dubbo.rpc.protocol.dubbo.DubboInvoker

protected Result doInvoke(final Invocation invocation) throws Throwable { // 获取 ExchangeClient (封装了 Netty Client) ExchangeClient currentClient = clients[index.getAndIncrement() % clients.length]; // 区分单向调用、异步调用、同步调用 boolean isAsync = RpcUtils.isAsync(getUrl(), invocation); boolean isOneway = RpcUtils.isOneway(getUrl(), invocation); if (isOneway) { // 单向调用，只发不回 currentClient.send(inv, getUrl().getMethodParameter(methodName, SENT_KEY, false)); return AsyncRpcResult.newDefaultAsyncResult(invocation); } else if (isAsync) { // 异步调用 ResponseFuture future = currentClient.request(inv, timeout); // ... 返回 Future } else { // 【核心重点】同步调用 (默认) RpcContext.getContext().setFuture(null); // 发送请求，获得 DefaultFuture return (Result) currentClient.request(inv, timeout).get(); } }

2.5 交换层与同步等待 (Exchange)

currentClient.request 会调用 HeaderExchangeChannel.request。这是实现“同步转异步”的关键。

源码位置：org.apache.dubbo.remoting.exchange.support.DefaultFuture

// 发送请求 public ResponseFuture request(Object request, int timeout) throws RemotingException { // 1. 创建请求对象，自动生成全局唯一 Request ID Request req = new Request(); req.setData(request); // 2. 创建 DefaultFuture，映射关系：Request ID -> Future DefaultFuture future = newDefaultFuture(channel, req, timeout); // 3. 通过 Netty 发送数据 channel.send(req); return future; }

紧接着，DubboInvoker 调用了 future.get()，线程在此阻塞。

// DefaultFuture.java public Object get(int timeout) throws RemotingException { // 使用 Condition.await 进行阻塞，等待服务端响应唤醒 if (!done) { long start = System.currentTimeMillis(); lock.lock(); try { while (!done) { done.await(timeout, TimeUnit.MILLISECONDS); // 超时检查逻辑... } } finally { lock.unlock(); } } return returnFromResponse(); }

3. 第二阶段：服务端处理请求（Provider）

网络报文经过 TCP 传输到达服务端，Netty 接收到字节流。

3.1 线程派发 (Thread Model)

Netty 的 IO 线程（Worker Group）负责解码，解码后的消息会经过 AllChannelHandler（默认策略），将请求派发到 Dubbo 的业务线程池中去执行，避免阻塞 IO 线程。

源码位置：org.apache.dubbo.remoting.transport.dispatcher.all.AllChannelHandler

public void received(Channel channel, Object message) throws RemotingException { // 获取业务线程池 ExecutorService executor = getExecutorService(); try { // 将请求包装成 ChannelEventRunnable 丢给线程池执行 executor.execute(new ChannelEventRunnable(channel, handler, ChannelState.RECEIVED, message)); } catch (Throwable t) { // 线程池满的拒绝策略（报错） } }

3.2 交换层处理 (Exchange)

业务线程拿到请求后，层层传递，到达 HeaderExchangeHandler.received。它区分这是请求（Request）还是响应（Response）。

源码位置：org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeHandler

public void received(Channel channel, Object message) { if (message instanceof Request) { handleRequest(channel, (Request) message); } else if (message instanceof Response) { handleResponse(channel, (Response) message); } } void handleRequest(Channel channel, Request req) { Response res = new Response(req.getId()); // 继续调用后续 Handler (DubboProtocol) Object result = handler.reply(channel, req.getData()); res.setResult(result); // 发送响应回客户端 channel.send(res); }

3.3 协议层与反射调用 (Protocol)

handler.reply 最终会调用到 DubboProtocol.requestHandler。在这里，根据 ServiceKey 找到服务端暴露的 Exporter。

源码位置：org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol

// 匿名内部类 requestHandler public CompletableFuture<Object> reply(ExchangeChannel channel, Object message) { Invocation inv = (Invocation) message; // 查找 Exporter Invoker<?> invoker = getInvoker(channel, inv); // 执行调用链 (Filter -> 实现类) return invoker.invoke(inv); }

最终，JavassistProxyFactory 生成的 Wrapper 类会直接通过方法名调用你写的 ServiceImpl 代码。

4. 第三阶段：响应返回与唤醒（Consumer）

服务端 channel.send(res) 将结果发回给消费端。

4.1 响应接收

消费端的 Netty IO 线程收到响应报文，同样经过解码，最终到达 HeaderExchangeHandler.received。这次走的是 handleResponse 分支。

static void handleResponse(Channel channel, Response response) { // 核心：调用 DefaultFuture.received DefaultFuture.received(channel, response); }

4.2 唤醒线程

Dubbo 怎么知道这个响应对应哪个请求？Request ID。

源码位置：org.apache.dubbo.remoting.exchange.support.DefaultFuture

public static void received(Channel channel, Response response) { // 1. 根据 Response 中的 ID 从 Map 中移除并获取对应的 Future DefaultFuture future = FUTURES.remove(response.getId()); if (future != null) { // 2. 触发唤醒逻辑 future.doReceived(response); } } private void doReceived(Response res) { lock.lock(); try { response = res; done = condition.signal(); // 唤醒之前阻塞在 get() 方法的线程 } finally { lock.unlock(); } }

4.3 结果返回

被唤醒的消费端线程从 get() 方法中苏醒，拿到 response.getResult()，经过动态代理层层返回，最终你的 demoService.sayHello 拿到了返回值。

5. 架构师总结

回顾整个流程，Dubbo 2.7.8 的核心设计精髓在于：

分层架构：每一层（Proxy, Cluster, Protocol, Exchange, Transport）职责清晰，互不干扰。
异步转同步：利用 DefaultFuture 和 Request ID 机制，在 Netty 异步通讯的基础上实现了对上层业务的同步阻塞假象，降低了开发复杂度。
线程模型：IO 线程与业务线程分离（AllDispatcher），保证了高并发下 Netty IO 的吞吐量，防止业务逻辑阻塞网络读写。

面试与调优建议：