介绍
先来看下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
层的设计提现了桥梁模式,抽象与实现独立演化。关键在于思想。