点击上方蓝色“Java关发”，关注并选择“设为星标”
持之以恒，贵在坚持，每天进步一点点！
前文提示
传输层是RPC通信的核心，担任网络数据传输的重要职责。
一. 传输层领域模型
传输层的领域模型长啥样呢？传输层的作用就是传输数据，既然发送数据那就必然有数据发送方（称之为客户端），数据接收方（称之为服务端），同时还有个问题，数据发送，我往哪儿发送呢？数据接受，我从哪儿接收呢？肯定需要一个东西作为数据的中转站，这个中转站，将其称为通道，在客户端与服务端连接后，产生了通道。于是乎我们得到了下面这个领域模型，里面有三个东西。client、channel、server。
这样就结束了吗？再仔细想想，中间这一个通道够不够？我们的client与server可能是分别运行在两台机器中，他们能拿到同一个通道吗？显然是不可以。同时还有另外一个问题，客户端可能只有一个吗？会不会有两个发送者在某段时间都想接受者发送数据呢？答案肯定是会的。由此模型进化一下变成这样：
好了，我们的模型似乎有模有样了，东西现在有了，下一步就是要拿这些个东西干嘛呢？你说干嘛呢？
发送数据
接受数据
OK，下一步就是想一下谁来发送数据。谁来接收数据。我们的选择似乎不多，client、channel、server。细想一下客户端和服务端都需要发送数据，那我们干脆把发送数据的任务落实到channel上，这样client与server都可以使用channel来发送数据，岂不是很棒棒。
好了，数据发送了出去，那么如何接收呢？这里其实有个问题，那就是在客户端发送数据时，服务端不知道客户端发送了数据。为了解决这个问题，服务端会不断循环判断这个通道是否有数据。而这个操作由于要与网卡交互，所以这个操作通常是借助操作系统完成的。接收到数据，肯定要对数据进行处理。自然而然，我们可以在增加一个东东来进行接受数据的处理。所以模型编程了下面这个样子：
途中channelHandler就是对接受数据处理的接口，由于客户端和服务端接受数据的处理方式不同，所以分别需要自己的channelHandler。由此，我们可以得出类设计图：lanlan
二. Dubbo类设计解析
上图是dubbo传输层相关api接口，去掉了几个接口，只保留了核心类。
1.Client与RemotingServer
Clinet和RemotingServer即为领域模型中的客户端服务端模型。它俩之间的交互即为建立链接。
2.channel
在客户端与服务端建立链接后，产生了channel。所以可以看到Client和RemotingServer都有一根线连接到Channel，表明客户端服务端都持有Channel属性对象，细心的你可能发现Client是一条实线，这是dubbo再设计时Client是继承了Channel。
3.ChannelHandler
有了Channel后，我们可以接收对方传来的数据。拿到数据我们处理呀，所以ChannelHandler自然就登场了。接收数据的处理逻辑通常是由客户端和服务端定义的，所以可以看到ChannelHandler是与Client和RemotingServer连接起来。
4.编解码
由于在channelHandler中我们拿到的数据都是字节，这需要转换为我们语义化的对象数据，由此，我们还需要编解码Codec对象，编解码首先的获取字节数据，并且害得有一个存储字节数据的容器。由此存储字节数据的容器ChannelBuffer便随之而来。
5.门面接口
有了上面的几个东东，视乎我们的模型就可以运转起来。先new 服务端对象，在new 客户端对象，在建立连接等等要经过一系列繁琐的操作，才能把整个模型跑起来，十分麻烦。由此引入了门面模式，提供一个快捷友好的API来运行起我们的客户端以及服务端。而在Dubbo传输层中，这个东西就是Transporters，注意是Transporters不是Transporter。
文章末尾
预知RPC之设计如何，且听下回分解。
