前言
接上一篇中的服务暴露逻辑，当接口使用Dubbo协议暴露服务时，会启动一个DubboServer来监听消费端的请求，端口的绑定和监听都是通过Exchanger层来实现的。关于Exchanger和Transporter层的原理，在前面讲Consumer的时候讲的比较清楚了，这篇主要讲下跟Consumer端逻辑不同的部分。
Exchanger层实现
Handler实现
上一篇DubboProtocol中在暴露服务时会创建一个ExchangeServer，调用的是Exchangers.bind(url, handler)方法。handler参数就是请求来的时候Dubbo协议的处理逻辑。所以对于每个协议都有一个handler实现。Dubbo协议对Handler的实现逻辑如下：
private ExchangeHandler requestHandler = new ExchangeHandlerAdapter() {
@Override
public void received(Channel channel, Object message) throws RemotingException {
if (message instanceof Invocation) {
reply((ExchangeChannel) channel, message);
} else {
super.received(channel, message);
}
}
}
当Consumer的调用请求来的时候，会回调handler.received()方法，在received方法中，直接判断收到的是不是Invocation，如果是的话调用reply()返回结果。
@Override
public CompletableFuture上面代码的核心其实只有两步，一是根据调用参数找到export服务的Invoker，二是调用Invoker的invoke方法，根据上一篇讲的Invoker构造，会调到javassist生成的代理类，然后调到@Service注解的实现类的方法上。第一步的getInvoker()方法如下：
Invoker getInvoker(Channel channel, Invocation inv) throws RemotingException {
...
...
String serviceKey = serviceKey(port, path, inv.getAttachments().get(VERSION_KEY), inv.getAttachments().get(GROUP_KEY));
DubboExporter exporter = (DubboExporter) exporterMap.get(serviceKey);
if (exporter == null) {
...
...
}
return exporter.getInvoker();
}
接口暴露服务的时候会将exporter缓存在map中，调用请求根据key来获取exporter然后拿到Invoker
Exchanger实现
跟Consumer端一样，最终bind方法会调用到HeaderExchanger实现类。
public class HeaderExchanger implements Exchanger {
@Override
public ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {
return new HeaderExchangeServer(Transporters.bind(url, new DecodeHandler(new HeaderExchangeHandler(handler))));
}
}
在handler参数上又封装了2层handler，这个也跟Consumer层没有区别，最终调用的Transporters.bind()方法，传入的handler链如下：
DecodeHandler是判断收到的Request是不是实现了Decodeable接口，是的话会调用接口的decode()方法。而HeaderExchangeHandler则会在DubboProtocol.requestHandler()返回结果后，封装Response并调用channel.send()发给调用方。 这里要注意的是，虽然Client端和Server端都会用到这两个Handler的，但是在处理Request和Response的时候，handler发挥的作用是不一样的。
Transporter
Exchange层在给Handler又封装了两层后，最终调用的Transporters.bind()方法，按照默认实现，Dubbo使用的传输层框架是netty4，所以实际调用的是NettyTransporter.bind()。
public class NettyTransporter implements Transporter {
@Override
public RemotingServer bind(URL url, ChannelHandler listener) throws RemotingException {
return new NettyServer(url, listener);
}
}
public class NettyServer extends AbstractServer implements RemotingServer{
public NettyServer(URL url, ChannelHandler handler) throws RemotingException {
super(ExecutorUtil.setThreadName(url, SERVER_THREAD_POOL_NAME), ChannelHandlers.wrap(handler, url));
}
}
Transporter中初始化一个NettyServer，构造函数中又对handler做了一次wrap，这里跟Client调用的同一个方法，wrap后的handler链变成了如下图的样子：
上图中具体Handler的作用
Consumer Transporter部分也讲过了，不再重复。直接进入NettyServer.doOpen()方法，开始监听客户端请求：
@Override
protected void doOpen() throws Throwable {
bootstrap = new ServerBootstrap();
bossGroup = new NioEventLoopGroup(1, new DefaultThreadFactory("NettyServerBoss", true));
workerGroup = new NioEventLoopGroup(getUrl().getPositiveParameter(IO_THREADS_KEY, Constants.DEFAULT_IO_THREADS),
new DefaultThreadFactory("NettyServerWorker", true));
//这个Handler中缓存了所有已经建立的channel
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() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
int idleTimeout = UrlUtils.getIdleTimeout(getUrl());
NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec(), getUrl(), NettyServer.this);
if (getUrl().getParameter(SSL_ENABLED_KEY, false)) {
ch.pipeline().addLast("negotiation",
SslHandlerInitializer.sslServerHandler(getUrl(), nettyServerHandler));
}
ch.pipeline()
.addLast("decoder", adapter.getDecoder()) //Dubbo协议解码
.addLast("encoder", adapter.getEncoder()) //Dubbo协议编码
.addLast("server-idle-handler", new IdleStateHandler(0, 0, idleTimeout, MILLISECONDS))
.addLast("handler", nettyServerHandler);
}
});
// bind
ChannelFuture channelFuture = bootstrap.bind(getBindAddress());
channelFuture.syncUninterruptibly();
channel = channelFuture.channel();
}
Netty的逻辑不多解释，直接看pipeline中添加的handler，当请求到达Server端时，InboundHandler会发挥作用，所以依次经过的handler的顺序如下：
- ByteToMessageDecoder：由
adapter.getDecoder()返回，负责把二进制数据转换成java对象，这里会使用export时传入的DubboCodec将二进制解码成Request - IdleStateHandler ： 数据流入和流出都会经过
- NettyServerHandler ： 在接收数据时，使用channel和Request回调Dubbo的Handler，将数据交给后续handler处理，也就是前面图2中的handler链
总结
最后整理一下整个服务的暴露过程：
1）Spring启动的时候Dubbo会根据配置文件或者@Service注解找到哪些类需要暴露成远程服务。找到这些类之后，会把每个类都注册成一个Spring 的Bean，同时定义一个新的Bean，这个Bean的类型是ServiceBean，所以最终暴露的是ServiceBean
2）调用ServiceBean的export方法后，Dubbo会根据配置生成url，根据实现类生成一个Invoker代理。有了url就可以知道使用什么协议暴露服务在哪个端口，比如dubbo协议就会调用DubboProtocol的方法，使用netty框架启动一个server，将server的handler和Invoker绑定成一个exporter。
3）export成功后，将url注册到注册中心。当server收到请求时，根据请求参数找到exporter，调用exporter中的Invoker执行本地类的实现。
本篇文章的传输层部分讲的比较简单，因为大部分内容跟Consumer端是重复的，理解有困难可以查阅下消费端Exchenger和Transporter两篇文章的内容。