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 getChannel(InetSocketAddress remoteAddress);
}
// 对客户端的抽象
public interface Client extends Endpoint, Channel, Resetable {
    void reconnect() throws RemotingException;
}

上述所举例子是Transporter层所提现的抽象，在来看下桥梁模式中的实现。实现指的是跟具体服务器相关的一套类库，分别Netty，Mina，Grizzly各自的类库。

这样的设计完全提现了桥梁模式的定义：将抽象和实现解耦，让它们可以独立变化。

对上层暴露的接口

说完Transporter的设计模式，来看看这个模块对上层暴露的接口。找到Transporters类。

public class Transporters {

    private Transporters() {
    
  	// 绑定动作，委托给具体的transporter实现，就是说你在配置中配置了哪种服务器就用哪种
  	// 可选项netty，netty4，mina，grizzly
    public static Server bind(URL url, ChannelHandler... handlers) throws RemotingException {
				// ----------------------此处生路一堆代码------------------------
        return getTransporter().bind(url, handler);
    }

    // 连接动作，委托给具体的transporter实现，就是说你在配置中配置了哪种服务器就用哪种
  	// 可选项netty，netty4，mina，grizzly
    public static Client connect(URL url, ChannelHandler... handlers) throws RemotingException {
				// ----------------------此处生路一堆代码------------------------
        return getTransporter().connect(url, handler);
    }
		
    // 获取Transporter的adaptive对象
    public static Transporter getTransporter() {
        return ExtensionLoader.getExtensionLoader(Transporter.class).getAdaptiveExtension();
    }
}

getTransporter这个方法是要获取Transporter的adaptive对象，拿出来的是一个动态生成的适配对象。这部分不清楚的请参考dubbo扩展类的初始化和SPI 自适应扩展

对下层具体服务器的适配衔接

这边以Netty4举例来说明Transporter对下层的衔接。看下NettyTransporter的代码

public class NettyTransporter implements Transporter {

    public static final String NAME = "netty4";

    @Override  // 对绑定的实现就是new NettyServer，构造方法中有具体的绑定动作。
    public Server bind(URL url, ChannelHandler listener) throws RemotingException {
        return new NettyServer(url, listener);
    }

    @Override  // 对连接的实现就是new NettyClient，构造方法中有具体的连接动作。
    public Client connect(URL url, ChannelHandler listener) throws RemotingException {
        return new NettyClient(url, listener);
    }
}

NettyServer的具体实现

下面看下NettyServer的具体实现，类比较大，挑重点来说。

public class NettyServer extends AbstractServer implements Server {

    private Map<String, Channel> channels; // <ip:port, channel> 保存了所有客户端的连接
    private ServerBootstrap bootstrap;// netty的bootstrap
    private io.netty.channel.Channel channel;	// netty的服务端channel
    private EventLoopGroup bossGroup;
    private EventLoopGroup workerGroup;

    public NettyServer(URL url, ChannelHandler handler) throws RemotingException {
      	// 这边handler被做了一次包装，目的是要在事件回调的时候把同步转换成异步，使用线程池来处理
        super(url, ChannelHandlers.wrap(handler, ExecutorUtil.setThreadName(url, SERVER_THREAD_POOL_NAME)));
    }

    @Override
    protected void doOpen() throws Throwable {
        bootstrap = new ServerBootstrap();
        bossGroup = new NioEventLoopGroup(1, new DefaultThreadFactory("NettyServerBoss", true));
        workerGroup = new NioEventLoopGroup(getUrl().getPositiveParameter(Constants.IO_THREADS_KEY, Constants.DEFAULT_IO_THREADS),
                new DefaultThreadFactory("NettyServerWorker", true));
      	// netty的handler，这个handler会接收connect，receive等事件，并且把事件传播给dubbo transporter的handler。是具体服务器的handler与transporter的handler之间的衔接。
        final NettyServerHandler nettyServerHandler = new NettyServerHandler(getUrl(), this);
        channels = nettyServerHandler.getChannels();
        bootstrap.group(bossGroup, workerGroup)
                .channel(NioServerSocketChannel.class)
                .childOption(ChannelOption.TCP_NODELAY, Boolean.TRUE)
                .childOption(ChannelOption.SO_REUSEADDR, Boolean.TRUE)
                .childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT)
                .childHandler(new ChannelInitializer<NioSocketChannel>() {
                    @Override
                    protected void initChannel(NioSocketChannel ch) throws Exception {
                        NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec(), getUrl(), NettyServer.this);
                        ch.pipeline()//.addLast("logging",new LoggingHandler(LogLevel.INFO))//for debug
                                .addLast("decoder", adapter.getDecoder())// 解码器
                                .addLast("encoder", adapter.getEncoder())// 编码器
                                .addLast("handler", nettyServerHandler);// netty的handler
                    }
                });
        // bind
        ChannelFuture channelFuture = bootstrap.bind(getBindAddress());
        channelFuture.syncUninterruptibly();
        channel = channelFuture.channel();
    }

    @Override
    protected void doClose() throws Throwable {
        // ----------------------此处生路一堆代码------------------------
    }

    @Override
    public Collection<Channel> getChannels() {
				// ----------------------此处生路一堆代码------------------------
    }

    @Override
    public Channel getChannel(InetSocketAddress remoteAddress) {
        return channels.get(NetUtils.toAddressString(remoteAddress));
    }

    @Override
    public boolean isBound() {
        return channel.isActive();
    }
}

如果搞过Netty的，上面这段代码，应该不难理解。说下与Transporter有关的2个值得注意点。

1.NettyServer的构造方法，Handler被做了一次包装，目的是要在事件回调的时候把同步转换成异步，使用线程池来处理。dubbo的handler机制中有详细说。

2.NettyServerHandler，这个类是Handler从具体服务器转移到Transporter Handler的关键。

NettyClient的具体实现

下面看下NettyClient的具体实现，类比较大，挑重点来说。

public abstract class AbstractClient extends AbstractEndpoint implements Client {
  	// ----------------------此处生路一堆代码------------------------
    public AbstractClient(URL url, ChannelHandler handler) throws RemotingException {
        super(url, handler);
				// ----------------------此处生路一堆代码------------------------
        doOpen(); 
				// ----------------------此处生路一堆代码------------------------
        connect();
      	// ----------------------此处生路一堆代码------------------------
    }
  	// ----------------------此处生路一堆代码------------------------
}

public class NettyClient extends AbstractClient {
  	// ----------------------此处生路一堆代码------------------------
    @Override
    protected void doOpen() throws Throwable {
        // ----------------------此处生路一堆代码------------------------
    }

    @Override
    protected void doConnect() throws Throwable {
        // ----------------------此处生路一堆代码------------------------
    }
}

典型的模板方法模式，NettyClient被构造时，先执行AbstractClient的构造方法。会调用doOpen和connect完成与服务器端的连接动作。因为代码篇幅过大，所以这边只摘抄了一个关键结构，来说明流程和关系。

总结

Transporter层的设计提现了桥梁模式，抽象与实现独立演化。关键在于思想。