关于后端:dubbo-server请求处理逻辑探究

这篇文章次要聊聊 dubbo 的服务端承受申请解决流程

服务端接口申明及实现如下：

public interface DemoService {String sayHello(String name);
}
public class DemoServiceImpl implements DemoService {
    @Override
    public String sayHello(String name) {return "Hello" + name + ", response from provider:" + RpcContext.getContext().getLocalAddress();}
}

在实在业务解决 sayHello return 语句退出断点能够失去如下调用栈：

33. sayHello:29, DemoServiceImpl (com.alibaba.dubbo.demo.provider)
32. invokeMethod:-1, Wrapper1 (com.alibaba.dubbo.common.bytecode)
31. doInvoke:50, JavassistProxyFactory$1 (com.alibaba.dubbo.rpc.proxy.javassist)
30. invoke:86, AbstractProxyInvoker (com.alibaba.dubbo.rpc.proxy)
29. invoke:52, DelegateProviderMetaDataInvoker (com.alibaba.dubbo.config.invoker)
28. invoke:59, InvokerWrapper (com.alibaba.dubbo.rpc.protocol)
27. invoke:63, ExceptionFilter (com.alibaba.dubbo.rpc.filter)
26. invoke:93, ProtocolFilterWrapper$1 (com.alibaba.dubbo.rpc.protocol)
25. invoke:75, MonitorFilter (com.alibaba.dubbo.monitor.support)
24. invoke:93, ProtocolFilterWrapper$1 (com.alibaba.dubbo.rpc.protocol)
23. invoke:44, TimeoutFilter (com.alibaba.dubbo.rpc.filter)
22. invoke:93, ProtocolFilterWrapper$1 (com.alibaba.dubbo.rpc.protocol)
21. invoke:103, TraceFilter (com.alibaba.dubbo.rpc.protocol.dubbo.filter)
20. invoke:93, ProtocolFilterWrapper$1 (com.alibaba.dubbo.rpc.protocol)
19. invoke:79, ContextFilter (com.alibaba.dubbo.rpc.filter)
18. invoke:93, ProtocolFilterWrapper$1 (com.alibaba.dubbo.rpc.protocol)
17. invoke:155, GenericFilter (com.alibaba.dubbo.rpc.filter)
16. invoke:93, ProtocolFilterWrapper$1 (com.alibaba.dubbo.rpc.protocol)
15. invoke:41, ClassLoaderFilter (com.alibaba.dubbo.rpc.filter)
14. invoke:93, ProtocolFilterWrapper$1 (com.alibaba.dubbo.rpc.protocol)
13. invoke:39, EchoFilter (com.alibaba.dubbo.rpc.filter)
12. invoke:93, ProtocolFilterWrapper$1 (com.alibaba.dubbo.rpc.protocol)
11. reply:149, DubboProtocol$1 (com.alibaba.dubbo.rpc.protocol.dubbo)
10. handleRequest:96, HeaderExchangeHandler (com.alibaba.dubbo.remoting.exchange.support.header)
9. received:176, HeaderExchangeHandler (com.alibaba.dubbo.remoting.exchange.support.header)
8. received:55, DecodeHandler (com.alibaba.dubbo.remoting.transport)
7. run:57, ChannelEventRunnable (com.alibaba.dubbo.remoting.transport.dispatcher)
------ 线程切换
6. received:66, AllChannelHandler (com.alibaba.dubbo.remoting.transport.dispatcher.all)
5. received:101, HeartbeatHandler (com.alibaba.dubbo.remoting.exchange.support.header)
4. received:45, MultiMessageHandler (com.alibaba.dubbo.remoting.transport)
3. received:154, AbstractPeer (com.alibaba.dubbo.remoting.transport)
2. channelRead:116, NettyServerHandler (com.alibaba.dubbo.remoting.transport.netty4)
1. invokeChannelRead:292, AbstractChannelHandlerContext (io.netty.channel)

上面对堆栈进行剖析：

1、netty 底层承受网络音讯逻辑，此时音讯曾经通过了解码和反序列化(默认，能够通过配置 decode.in.io 扭转解码机会)，应用 netty 的 ChannelHandler，具体在 NettyServer 的 doOpen 办法中设置的

2、NettyServerHandler 将 netty 的 channel 转换为了 dubbo 的 Channel 并进行了缓存，而后将申请委托给了其装璜的 handler，从这里咱们能够看出 dubbo 的 channelHandler 解决链条是 NettyServerHandler -> NettyServer -> MultiMessageHandler -> HeartbeatHandler -> AllChannelHandler -> DecodeHandler -> HeaderExchangeHandler -> DubboProtocol 中的匿名类 requestHandler(ExchangeHandlerAdapter)，他们通过装璜着模式组成了一个链表，层层顺次调用

3、NettyServer 继承自 AbstractPeer，这里调用到了父类的 received 办法，这里仅仅只判断了下 channel 是否 close 就将申请转发给了下一层

4、MultiMessageHandler 顾名思义其是将多个申请拆开循环调用后续的 ChannelHandler

5、HeartbeatHandler 解决心跳的处理器，如果是 心跳申请则返回一个心跳相应，如果是心跳相应则什么也不做，其余的一律转发给下一层的 ChannelHandler

6、AllChannelHandler 是默认的申请派发策略实现，即所有事件 (connected/disconnected/Request/Response/ 异样解决) 都提交给业务线程池解决

7、因为 AllChannelHandler 进行了申请派发到业务线程池解决，这里进行了线程切换，将后续解决包装为 ChannelEventRunnable 提交给线程池

8、DecodeHandler 对收到的音讯进行解码，这里不肯定是真的解码，次要看是否配置了参数 decode.in.io，如果为 false 的话会在这里进行解码，否则从步骤 1 就已解码结束

9-10、HeaderExchangeHandler 判断音讯是申请还是相应(因为客户端也是会在这里解决)，如果是申请则调用 handleRequest 拿到实在的调用后果而后返回

11、DubboProtocol$1 是 DubboProtocol 中的匿名外部类 requestHandler，在这里进行了依据申请找对对应的 Invoker 进行实在的业务处理过程

12-27、这里执行了 Invoker 的过滤器逻辑，通过 ProtocolFilterWrapper.buildInvokerChain 逻辑将过滤器 (Filter) 组成了一个 Invoker 链表，最初执行到 InvokerDelegete

28、InvokerWrapper 是 InvokerDelegete 的父类，这里其实是调用的 InvokerDelegete 的 invoke 办法

29、DelegateProviderMetaDataInvoker 就是个 Invoker 的代理类，疏忽就好

30-31、JavassistProxyFactory$1 是 JavassistProxyFactory 的外部类，实现了 JavassistProxy Invoker，将申请代理到具体的业务实现类

32、Wrapper1 是字节码生成的代理类，是 Wrapper 的子类，Wrapper 提供了一些接口申明，不便间接调用，生成的字节码须要有接口能力调用，否则只能用反射，用接口占位能够防止应用反射

33、实在业务解决逻辑