Dubbo服务端各个Handler，filter，invoker的执行过程和作用

dubbo服务调用的本质就是让远程调用变得跟本地调用一样简单，所以这中间的收发数据，应答，包括各种执行链路，过滤链，都是dubbo内部帮你封装好的。

        dubbo服务导出的时候会构造一个Invoker（代理对象），那这个Invoker众所周知就是一个执行器，只要传入对应的Invocation，就会去执行对应的被代理对象要执行的那个方法

        PROXYFACTORY_FACTORY默认使用的是JavassistProxyFactory，这里面的逻辑就一目了然，直接通过wrapper.invokeMethod()，中间传进去的参数分别代表着，被代理类，方法名，参数类型，参数，然后再通过反射就可以得到被代理类所要执行的那个方法；所以这是最终要执行的逻辑，但是dubbo底层是用nettyServer启动的，netty里面有很多Handler代表着框架本身的业务逻辑，所以要把这些Handler走一遍先

        所以要先研究一下NettyServer启动的时候到底放入了多少个Handler，最外层的Handler又是哪个，服务调用的入口又在哪里;

        在下面启动nettyServer的过程中，会发现第一个传入的是requestHandler，可以看到这是ExchangeHandlerAdapter类型的

往下走就会看到handler外面包装了两层，分别是HeaderExchangeHandler和DecodeHandler

然后又会将handler放到一个dispatch里面，这个dispatch是跟dubbo里线程模型相关的东西，默认可以配置成all，代表着所有请求进来到这层都会封装成异步请求，也可以配置成direct,或者message，分别有他们的对应类，所以这边默认走的是AllDispatcher，那在这一层的话又封装了三个Handler，分别是AllChannelHandler,HeartbeatHandler,MultiMessageHandler

最后走到NettyServer.doOpen方法的时候，会将这些Handler在外面再包装一层NettyServerHandler，最后再塞到pipeline里面，然后再去启动dubbo

至此为止可以看到最外到内的Handler分别是NettyServerHandler->MultiMessageHandler->HeartBearHandler->AllChannelHandler->DecodeHandler->HeaderExchangeHandler->ExchangeHandlerAdapter，所以第一时间接收到消息的是NettyServerHandler，根据netty的reactor线程模型，接收到之后便会调用其里面的channelRead方法，然后再层层往下掉，以下是各个Handler的作用，可以自己去看下对应的receive方法

1. NettyServerHandler：接收数据，然后会执行handler.received(channel, msg);执行下一个Handler的receive方法

2. MultiMessageHandler：判断接收到的数据是否是MultiMessage，如果是则获取MultiMessage中的 单个Message，传递给HeartbeatHandler进⾏处理

3. HeartbeatHandler：判断是不是⼼跳消息，如果是不是则把Message传递给AllChannelHandler

4. AllChannelHandler：把接收到的Message封装为⼀个ChannelEventRunnable对象，扔给线程池进⾏处理

5. ChannelEventRunnable：在ChannelEventRunnable的run⽅法中会调⽤DecodeHandler处理

Message

6. DecodeHandler：按Dubbo协议的数据格式，解析当前请求的path，version，⽅法，⽅法参数等等，然后把解析好了的请求交给HeaderExchangeHandler

7. HeaderExchangeHandler：处理Request数据，⾸先构造⼀个Response对象，然后调⽤

ExchangeHandlerAdapter得到⼀个CompletionStageFuture，然后给future通过whenComplete绑

定⼀个回调函数，当future执⾏完了之后，就可以从回调函数中得到ExchangeHandlerAdapter的执⾏结果，并把执⾏结果设置给Response对象，通过channel发送出去。

8. ExchangeHandlerAdapter：从本机已经导出的Exporter中根据当前Request所对应的服务key，去寻找Exporter对象，从Exporter中得到Invoker，然后执⾏invoke⽅法，此Invoker为

ProtocolFilterWrapper$CallbackRegistrationInvoker

Invoker链:

        最开始构造的Invoker(本文第一张图片)时候就会返回AbstractProxyInvoker，然后会在外面包装一层DelegateProviderMetaDataInvoker，然后执行到dubboProtocol.export()的时候，因为Spi机制，就会执行到ProtocolFilterWrapper这个类里面的export

        
       ProtocolFilterWrapper.export方法执行之前会先调用其buildInvokerChain在外面包装一层 

 CallbackRegistrationInvoker（用于在执行完Handler之后构造过滤链）

这样的话，invoker链就构造完了，下面是几个invoker的主要逻辑

1.CallbackRegistrationInvoker：执行完Handler之后会调用到这里负责执⾏过滤器链，并且在执⾏完了之后回调每个过滤器的onResponse或onError⽅法

2.DelegateProviderMetaDataInvoker：过滤器链结束，调⽤下⼀个Invoker

3.AbstractProxyInvoker：在服务导出时，根据服务接⼝，服务实现类对象⽣成的，它的invoke⽅法就 会执⾏服务实现类对象的⽅法，得到结果

在buildInvokerChain方法中也会顺带着去构造过滤链，然后在执行CallbackRegistrationInvoker.invoke方法的时候就会挨个去掉用

1.EchoFilter：判断当前请求是不是⼀个回升测试，如果是，则不继续执⾏过滤器链了（服务实现者 Invoker也不会调⽤了）

2.ClassLoaderFilter：设置当前线程的classloader为当前要执⾏的服务接⼝所对应的classloader

3.GenericFilter：把泛化调⽤发送过来的信息包装为RpcInvocation对象

4.ContextFilter：设置RpcContext.getContext()的参数

5.TraceFilter：先执⾏下⼀个invoker的invoke⽅法，调⽤成功后录调⽤信息

6.TimeoutFilter：调⽤时没有特别处理，只是记录了⼀下当前时间，当整个filter链都执⾏完了之后回调TimeoutFilter的onResponse⽅法时，会判断本次调⽤是否超过了timeout

7.MonitorFilter：记录当前服务的执⾏次数

8.ExceptionFilter：调⽤时没有特别处理，在回调onResponse⽅法时，对不同的异常进⾏处理，详解Dubbo的异常处理