Dubbo数据包

今日给咱们带来一篇关于DubboIO交互的文章，本文是一位搭档所写，用风趣的文字把枯燥的知识点写出来，通俗易懂，十分有意思，所以刻不容缓找作者授权然后分享给咱们：
一些风趣的问题
Dubbo是一个优秀的RPC结构，其中有错综复杂的线程模型，本篇文章笔者从自己浅陋的认知中，来剖析Dubbo的整个IO进程。在开端之前，咱们先来看如下几个问题：
事务办法履行之后，数据包就发出去了吗？
netty3和netty4在线程模型上有什么区别？
数据包到了操作系统socketbuffer，阅历了什么？
Provider打出的log耗时很小，而Consumer端却超时了，怎样能够排查到问题？
数据包在物理层是一根管道就直接发过去吗？
Consumer事务线程await在Condition上，在哪个时机被唤醒？
……
接下来笔者将用Dubbo2.5.3作为Consumer，2.7.3作为Provider来叙述整个交互进程，笔者站在数据包视角，用第一人称来叙述，系好安全带，咱们动身咯。

有意思的游览
1、Dubbo2.5.3Consumer端建议请求
我是一个数据包，出生在一个叫Dubbo2.5.3Consumer的小镇，我的任务是是传递信息，一起也喜爱出门游览。
某一天，我行将被发送出去，据说是要去一个叫Dubbo2.7.3Provider的当地。
这一天，事务线程建议建议办法调用，在FailoverClusterInvoker#doInvoke我挑选了一个Provider，然后通过各种ConsumerFilter，再通过Netty3的pipeline，终究通过NioWorker#scheduleWriteIfNecessary办法，我来到了NioWorker的writeTaskQueue行列中。
当我回头看主线程时，发现他在DefaultFuture中的Condition等待，我不知道他在等什么，也不知道他要等多久。
我在writeTaskQueue行列排了一会队，看到netty3IOworker线程在永不停歇的履行run办法，咱们都称这个为死循环。
终究，我很走运，NioWorker#processWriteTaskQueue挑选了我，我被写到操作系统的Socket缓冲区，我在缓冲区等待，横竖时刻充足，我回味一下今日的游览，期间我辗转了两个游览团，分别叫主线程和netty3IOworker线程，嗯，两个游览团服务都不错，功率很高。
干脆我把今日的见闻记载下来，绘制成一张图，当然不重要的当地我就忽略了。
2、操作系统发送数据包
我在操作系统socket缓冲区，通过了许多神奇的工作。
在一个叫传输层的当地给我追加上了目标端口号、源端口号
在一个叫网络层的当地给我追加上了目标IP、源IP，一起通过目标IP与掩码做与运算，找到“下一跳”的IP
在一个叫数据链路层的当地通过ARP协议给我追加上了“下一跳”的目标MAC地址、源MAC地址
最有意思的是，咱们坐的都是一段一段缆车，每换一个缆车，就要修改目标MAC地址、源MAC地址，后来问了同行的数据包小伙伴，这个形式叫“下一跳”，一跳一跳的跳过去。这里有许多数据包，体型大的单独一个缆车，体型小的几个挤一个缆车，还有一个可怕的工作，体型再大一点，要分拆做多个缆车（尽管这对咱们数据包没啥问题），这个叫拆包和粘包。期间咱们通过交换机、路由器，这些当地玩起来很Happy。
当然也有不愉快的工作，就是拥堵，目的地缆车满了，来不及被拉走，只能等待咯。
3、在Provider端的阅历
好不容易，我来到了目的地，我坐上了一个叫“零拷贝”号的快艇，迅速到了netty4，netty4果然富丽堂皇，通过NioEventLoop#processSelectedKeys，再通过pipeline中的各种入站handler，我来到了AllChannelHandler的线程池，当然我有许多挑选，可是我随意选了一个目的地，这里会阅历解码、一系列的Filter，才会来的目的地“事务办法”，NettyCodecAdapter#InternalDecoder解码器很厉害，他能够处理拆包和粘包。
在AllChannelHandler的线程池中我会停留一会，所以我也画了一张图，记载旅程。
自此，我的游览完毕，新的故事将由新的数据包续写。
4、Provider端产生了新的数据包
我是一个数据包，出生在一个叫Dubbo2.7.3Provider的小镇，我的任务是去唤醒命中注定的线程，接下来我会开端一段游览，去一个叫Dubbo2.5.3Consumer的当地。
在Provider事务办法履行之后
由事务线程通过io.netty.channel.AbstractChannelHandlerContext#writeAndFlush
再通过io.netty.util.concurrent.SingleThreadEventExecutor#execute履行addTask
将任务放入行列io.netty.util.concurrent.SingleThreadEventExecutor#taskQueue
我便跟随着io.netty.channel.AbstractChannelHandlerContext$WriteTask等待NioEventLoop发车，等待的进程中，我记载了走过的脚步。
在这里，我看到NioEventLoop是一个死循环，不停地从任务行列取任务，履行任务AbstractChannelHandlerContext.WriteAndFlushTask，然后指引咱们到socket缓冲区等候，永不知疲倦，我似乎领会到他身上有一种倔强的、寻求极致的匠人精力。
通过io.netty.channel.AbstractChannel.AbstractUnsafe#write，我抵达了操作系统socket缓冲区。在操作系统层面和大多数数据包相同，也是做缆车抵达目的地。
5、抵达dubbo2.5.3Consumer端
抵达dubbo2.5.3Consumer端，我在操作系统socket缓冲区等了一会，同样是坐了“零拷贝”号快艇，抵达了真正的目的地dubbo2.5.3Consumer，在这里我发现，NioWorker#run是一个死循环，然后履行NioWorker#processSelectedKeys，通过NioWorker#read方式读出来，我就抵达了AllChannelHandler的线程池，这是一个事务线程池。
我在这里等待一会，等任务被调度，我看见com.alibaba.dubbo.remoting.exchange.support.DefaultFuture#doReceived被履行了，一起Condition的signal被履行了。我在远处看到了一个被堵塞线程被唤醒，我似乎明白，因为我的到来，唤醒了一个沉睡的线程，我想这应该是我生命的意义。
至此，我的任务也完成了，本次旅程完毕。
总结netty3和netty4的线程模型
咱们根据两个数据包的自述，来总结一下netty3和netty4的线程模型。
1、netty3写进程
2、Netty4的读写进程
阐明：这里没有netty3的读进程，netty3读进程和netty4相同，pipeline是由IO线程履行。
总结：netty3与netty4线程模型的区别在于写进程，netty3中pipeline由事务线程履行，而netty4无论读写，pipeline一致由IO线程履行。
netty4中ChannelPipeline中的Handler链一致由I/O线程串行调度，无论是读还是写操作，netty3中的write操作时由事务线程处理Handler链。netty4中能够下降线程之间的上下文切换带来的时刻耗费，可是netty3中事务线程能够并发履行Handler链。如果有一些耗时的Handler操作会导致netty4的功率低下，可是能够考虑将这些耗时操作放在事务线程最早履行，不放在Handler里处理。因为事务线程能够并发履行，同样也能够提高功率。
一些疑难问题排查
有遇到一些比较典型的疑难问题，例如当Provider容许的didi.log耗时正常，而Consumer端超时了，此刻有如下排查方向，didi.log的Filter其实处于十分里层，往往不能反映实在的事务办法履行情况。
Provider除了事务方向履行外，序列化也有或许是耗时的，所以能够用arthas监控最外侧办法org.apache.dubbo.remoting.transport.DecodeHandler#received，扫除事务办法耗时高的问题
Provider中数据包写入是否耗时，监控io.netty.channel.AbstractChannelHandlerContext#invokeWrite办法
通过netstat也能查看当前tcpsocket的一些信息，比方Recv-Q,Send-Q，Recv-Q是现已到了接受缓冲区，可是还没被应用代码读走的数据。Send-Q是现已到了发送缓冲区，可是对方还没有回复Ack的数据。这两种数据正常一般不会堆积，如果堆积了，或许就有问题了。
看ConsumerNioWorker#processSelectedKeys（dubbo2.5.3）办法是否耗时高。
直到终究整个链路的所有细节……问题肯定是能够解决的。
尾声
在整个交互进程中，笔者省略线程栈调用的一些细节和源代码的细节，例如序列化与反序列化，dubbo怎样读出完好的数据包的，事务办法履行前那些Filter是怎样排序和散布的，netty的Reactor形式是怎么完成的。这些都是十分风趣的问题……