dubbo的transporter层

介绍

先来看下Dubbo的整体架构图。Transporter在倒数第二层。我用黄色线框框出来的区域。

Transporter层，属于网络传输层，是Mina，Netty，Grizzly这几个服务器的抽象。

为什么要单独抽象出一个Transporter层，而不是在Exchange层直接对Netty或者Mina引用？这个问题其实不难理解，Netty或者Mina对外接口和调用方式都不一样，如果在Exchange层直接对Mina做引用，对于Exchange层来讲，就依赖了具体而不是抽象，过几天想要换成Netty，就需要对Exchange层做大量的修改。这样不符合开闭原则。

Transporter层的设计，还是桥梁模式的实现。在 GoF 的《设计模式》一书中，桥接模式是这么定义的：“Decouple an abstraction from its implementation so that the two can vary independently。”翻译成中文就是：“将抽象和实现解耦，让它们可以独立变化。”

这个模式比较隐晦，挺难理解的。什么是抽象，什么是实现？它这里面的抽象指的不是抽象类或者接口。实现也不是指的具体实现类。

我这边来解释下Transporter层是怎么提现桥梁模式的，声明下：这只是我个人的理解和观点，并非官方给出。

Transporter层的的抽象是指，Dubbo抽象了一整套适合Dubbo的网络传输层的"类库"。比如：看下Transporter的接口代码。

@SPI("netty")// 默认使用netty服务器
public interface Transporter {
   
	
  	// 抽象出了bind行为，这个行为要完成服务端口暴露的动作，并且返回Server抽象
  	// 无论netty，mina，grizzly或者其他的一些服务器暴露接口的动作叫啥名字，这边都被抽象成了bind
  	// Exchange层只需要给URL和handler就可以完成端口暴露的动作
    Server bind(URL url, ChannelHandler handler) throws RemotingException;
		
  	// 抽象出了connect行为，这个行为要完成客户端与服务端的连接动作，并且返回Client抽象
  	// 无论netty，mina，grizzly或者其他的一些服务器做客户端连接时叫啥名字，这边都被抽象成了connect
  	// Exchange层只需要给URL和handler就可以完成端口暴露的动作
    Client connect(URL url, ChannelHandler handler) throws RemotingException;
}

Dubbo为每个服务器都做了Transporter的适配。看下面的类图结构。

除此之外，还有Server，Client，EndPoint等都是Transporter层做出的抽象。看下：

// 对交互两端的抽象，分别是服务端和客户端。
public interface Endpoint {
   
    URL getUrl();
    ChannelHandler getChannelHandler();
    InetSocketAddress getLocalAddress();
    void send(Object message) throws RemotingException;
    void send(Object message, boolean sent) throws RemotingException;
    void close();
    void close(int timeout);
    void startClose();
    boolean isClosed();
}
// 对服务端的抽象
public interface Server extends Endpoint, Resetable {
   
    boolean isBound();
    Collection<Channel> getChannels();
    Channel getChan