Dubbo源码解析第一期：如何使用Netty4构建RPC

一、背景

        早期学习和使用Dubbo的时候（那时候Dubbo还没成为Apache顶级项目），写过一些源码解读，但随着Dubbo发生了翻天覆地的变化，那些文章早已过时，所以现在计划针对最新的Apache Dubbo源码来进行“阅读理解”，希望和大家一起再探Dubbo的实现。由于能力有限，如果文章有错误的地方，欢迎大家留言指正。

        本期的主题是Dubbo如何使用Netty4构建RPC来通讯。

二、Server端视角

        我们看看作为服务提供方，Apache Dubbo是如何使用Netty4的。

2.1 Netty的线程组

        线程组作为Netty的Reactor设计核心组件，在这里自然少不了，我们看到org.apache.dubbo.remoting.transport.netty4.NettyServer中有如下两个方法：

    int DEFAULT_IO_THREADS = Math.min(Runtime.getRuntime().availableProcessors() + 1, 32);String IO_THREADS_KEY = "iothreads";String EVENT_LOOP_BOSS_POOL_NAME = "NettyServerBoss";String EVENT_LOOP_WORKER_POOL_NAME = "NettyServerWorker";protected EventLoopGroup createBossGroup() {return NettyEventLoopFactory.eventLoopGroup(1, EVENT_LOOP_BOSS_POOL_NAME);}protected EventLoopGroup createWorkerGroup() {return NettyEventLoopFactory.eventLoopGroup(getUrl().getPositiveParameter(IO_THREADS_KEY, Constants.DEFAULT_IO_THREADS),EVENT_LOOP_WORKER_POOL_NAME);}

分别用来构建Boss线程组和Worker线程组，Boss线程组负责创建连接，连接创建成功后由Worker线程组来负责处理和发送请求。注意Boss线程组只设置了1个线程，而且没有设置修改接口，通常1个也是够用的，如果设置成可配的会更好。而Worker线程组默认值是当前可用核数和32中取最小值，注意，是最小值，不是最大值，意味着如果你单个Provider实例上可用的核超过32，那么一定要设置IO_THREADS_KEY，否则可能无法达到最大吞吐量（特别是IO密集型应用）。上面代码也给出了这两个线程组的线程池的名称，如果不清楚现在跑的是多少，可以jstack命令看下。注意，为了阐述方便，上面的四个属性定义来自org.apache.dubbo.remoting.Constants。

2.1 Netty的ChannelHandler

        Netty的可扩展性主要来自其核心组件之一ChannelHandler，ChannelHandler能帮助我们解决拆包&粘包、协议编解码、权限校验等RPC常遇到的问题。那我们来看看现在Dubbo的Provider端用到了哪些ChannelHandler，同样，我们看NettyServer#initServerBootstrap方法：

    protected void initServerBootstrap(NettyServerHandler nettyServerHandler) {boolean keepalive = getUrl().getParameter(KEEP_ALIVE_KEY, Boolean.FALSE);bootstrap.group(bossGroup, workerGroup)// 根据是否支持EPoll来返回EpollServerSocketChannel或者NioServerSocketChannel.channel(NettyEventLoopFactory.serverSocketChannelClass())// SO_REUSEADDR设置为true表示允许重用本地地址和端口。如果服务器意外关闭后再次启动，可以立即绑定到之前使用的地址和端口。.option(ChannelOption.SO_REUSEADDR, Boolean.TRUE)// 表示禁用Nagle算法。Nagle算法会将小的网络包合并成较大的包来提高网络效率，但会增加数据传输的延迟。一般对延迟敏感的场景都会禁用Nagle算法。.childOption(ChannelOption.TCP_NODELAY, Boolean.TRUE)// 开启TCP的心跳机制，用于检测连接是否还活着.childOption(ChannelOption.SO_KEEPALIVE, keepalive)// PooledByteBufAllocator是Netty提供的一种内存分配器实现，它可以重用ByteBuf对象的内存，提高内存的利用率和性能。.childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT).childHandler(new ChannelInitializer<SocketChannel>() {@Overrideprotected void initChannel(SocketChannel ch) throws Exception {int closeTimeout = UrlUtils.getCloseTimeout(getUrl());NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec(), getUrl(), NettyServer.this);// 处理HTTPSch.pipeline().addLast("negotiation", new SslServerTlsHandler(getUrl()));ch.pipeline()// 解码，读数据的时候用.addLast("decoder", adapter.getDecoder())// 编码，写数据的时候用.addLast("encoder", adapter.getEncoder())// 注意，这是Netty提供的ChannelHandler.addLast("server-idle-handler", new IdleStateHandler(0, 0, closeTimeout, MILLISECONDS))// NettyServerHandler可是核心.addLast("handler", nettyServerHandler);}});}

我们重点关注下childHandler中添加的ChannelHandler。在这之前，我们先对Channel中的ChannelPipeline和ChanelHandler进行简单介绍，我们知道每个连接对应一个Channel，而每个Channel对应一个ChannelPipeline，用来组织和管理连接上面的处理器ChannelHandler（责任链的方式）。ChannelHandler分为ChannelInboundHandler和ChannelOutboundHandler两大类，分别管理入站（读）和出站（写）的流程定制，当然，为了使用方便，Netty提供了很多开箱即用的ChannelHandler，便于我们轻松实现HTTP、WebSocket等协议。

SslServerTlsHandler

        这是上面通过childHandler添加的第一个ChannelHandler（它属于Netty中ByteToMessageDecoder的子类，ByteToMessageDecoder的主要用途是将接收到的字节数据解码为消息对象，并将解码后的消息对象传递给下一个处理器进行后续的业务处理。继承它可以方便的处理多种数据格式，例如二进制数据、文本数据等），看这Handler的名称就知道是做什么的，用来进行SSL|TLS加解密。在其实现的decode方法中，如果发现ByteBuf是支持SSL|TLS，那么会立马在当前Channel的ChannelPipeline中加入SslHandler（Netty自带的支持SSL|TLS握手的ChannelHandler），注意，是加载当前SslServerTlsHandler之后。为了能在SSL|TLS解码后能继续执行SslServerTlsHandler的逻辑，在SslHandler后面又新加了一个SslServerTlsHandler（其中sslDetected=true，说明数据包到这里已经解包完成），用于校验协议。

        当然，如果SslServerTlsHandler发现你没有使用SSL|TLS（Netty中的SslHandler#isEncrypted能判断ByteBuf是否进行过加密），那么会直接把自己从ChannelPipeline中删除。这里给出SslServerTlsHandler#decode代码：

    @Overrideprotected void decode(ChannelHandlerContext channelHandlerContext, ByteBuf byteBuf, List<Object> list)throws Exception {// Will use the first five bytes to detect a protocol.if (byteBuf.readableBytes() < 5) {return;}// SSL|TLS 校验完成后会创建一个新的SslServerTlsHandler，其中sslDetected会设置成trueif (sslDetected) {return;}CertManager certManager =url.getOrDefaultFrameworkModel().getBeanFactory().getBean(CertManager.class);ProviderCert providerConnectionConfig = certManager.getProviderConnectionConfig(url, channelHandlerContext.channel().remoteAddress());// 如果没启用SSL|TLS，那么获取到的providerConnectionConfig就会是null，从而删除并退出该Handlerif (providerConnectionConfig == null) {ChannelPipeline p = channelHandlerContext.pipeline();p.remove(this);return;}if (isSsl(byteBuf)) {SslContext sslContext = SslContexts.buildServerSslContext(providerConnectionConfig);enableSsl(channelHandlerContext, sslContext);return;}if (providerConnectionConfig.getAuthPolicy() == AuthPolicy.NONE) {ChannelPipeline p = channelHandlerContext.pipeline();p.remove(this);return;}logger.error(INTERNAL_ERROR, "", "", "TLS negotiation failed when trying to accept new connection.");channelHandlerContext.close();}

NettyCodecAdapter.InternalDecoder

        之前已经给了NettyServer#initServerBootstrap方法，其中可以发现这个内部解码器InternalDecoder是继SslServerTlsHandler的下一个ChannelHandler，由于它和SslServerTlsHandler一样，是ByteToMessageDecoder的子类，所以我们直接看其decode方法：

    private class InternalDecoder extends ByteToMessageDecoder {@Overrideprotected void decode(ChannelHandlerContext ctx, ByteBuf input, List<Object> out) throws Exception {// ChannelBuffer是Dubbo对通道缓冲区的抽象，这里的NettyBackedChannelBuffer就是其Netty缓冲区第一个实现，NettyBackedChannelBuffer内部直接使用的是Netty的ByteBufChannelBuffer message = new NettyBackedChannelBuffer(input);// Dubbo中的NettyChannel是衔接Netty Channel和Dubbo内部通道抽象的桥梁，其中NettyChannel就有Dubbo的解码器NettyChannel channel = NettyChannel.getOrAddChannel(ctx.channel(), url, handler);do {int saveReaderIndex = message.readerIndex();// 这里的codec默认是DubboCountCodec实例，支持MultiMessage解码，这里返回的msg已经是org.apache.dubbo.remoting.exchange.Request对象Object msg = codec.decode(channel, message);if (msg == Codec2.DecodeResult.NEED_MORE_INPUT) {message.readerIndex(saveReaderIndex);break;} else {// is it possible to go here ?if (saveReaderIndex == message.readerIndex()) {throw new IOException("Decode without read data.");}if (msg != null) {out.add(msg);}}} while (message.readable());}}

1. DubboCountCodec（implements Codec2）：用来处理MultiMessage类型的消息，Dubbo Consumer可以通过MultiMessage来一次性发送多个请求，但一般没人这么用，大家更愿意传递一个List来让下游Dubbo Provider来批量处理，上述InternalDecoder#decode方法内部调用了其decode方法，decode方法会继续触发其他org.apache.dubbo.remoting.Codec2实现类的调用。

2. DubboCodec（extends ExchangeCodec）：DubboCountCodec#decode内部会调用其父类ExchangeCodec#decode方法，主要用于将Dubbo协议中的请求和响应消息进行序列化和反序列化。看到这里，难道Dubbo没用LengthFieldBasedFrameDecoder？这可是Netty中解决TCP拆包、粘包的神器！没有，Dubbo自己在ExchangeCodec#decode方法中自己解决了粘包、拆包问题，通过返回DecodeResult.NEED_MORE_INPUT来表示需要更多数据。ExchangeCodec#decode方法最后又将调用DubboCodec#decodeBody来解码body部分，这里给出Dubbo的协议图：

我们看看DubboCodec解码body部分的代码（注意DubboCodec可以解码也可以编码，这里为了简单起见，只展示解码部分）：

    @Overrideprotected Object decodeBody(Channel channel, InputStream is, byte[] header) throws IOException {byte flag = header[2], proto = (byte) (flag & SERIALIZATION_MASK);// get request id.long id = Bytes.bytes2long(header, 4);// decode request.Request req;Object data;req = new Request(id);req.setVersion(Version.getProtocolVersion());req.setTwoWay((flag & FLAG_TWOWAY) != 0);// get data length.int len = Bytes.bytes2int(header, 12);req.setPayload(len);DecodeableRpcInvocation inv;// 如果你实现了自定义解析器，那么就使用自定义的if (customByteAccessor != null) {inv = customByteAccessor.getRpcInvocation(channel, req, new UnsafeByteArrayInputStream(readMessageData(is)), proto);} else {// 否则用Dubbo内置的inv = new DecodeableRpcInvocation(frameworkModel,channel,req,new UnsafeByteArrayInputStream(readMessageData(is)),proto);}// DecodeableRpcInvocation来通过协议对应的序列化器来反序列化inv.decode();data = inv;req.setData(data);return req;}

可以看到，DubboCodec将使用DecodeableRpcInvocation#decode来完成最终解码过程。需要注意的是，我们可以通过设置DECODE_IN_IO_THREAD_KEY（"decode.in.io.thread"）参数来让Dubbo决定整个decode操作是否在IO线程中执行，默认是在IO线程执行。

2. DecodeableRpcInvocation（extends RpcInvocation）：

前面我们说真正的反序列化是在该类中实现的，我们看下代码：

    @Overridepublic Object decode(Channel channel, InputStream input) throws IOException {int contentLength = input.available();this.put(Constants.CONTENT_LENGTH_KEY, contentLength);// 通过请求中的SerializationId来选择对应的序列化对象进行数据的反序列化ObjectInput in = CodecSupport.getSerialization(serializationType).deserialize(channel.getUrl(), input);this.put(SERIALIZATION_ID_KEY, serializationType);// 设置Dubbo版本号String dubboVersion = in.readUTF();request.setVersion(dubboVersion);setAttachment(DUBBO_VERSION_KEY, dubboVersion);// 设置需要调用的接口标识String path = in.readUTF();setAttachment(PATH_KEY, path);String version = in.readUTF();setAttachment(VERSION_KEY, version);// Do provider-level payload checks.String keyWithoutGroup = keyWithoutGroup(path, version);// 为了防止数据过载，在Dubbo Consumer端可以设置payLoad，这里检查数据是否超过payLoad限制checkPayload(keyWithoutGroup);// 设置需要调用的方法标识setMethodName(in.readUTF());// 参数类型的全限定名，如果有多个参数，通过;分隔String desc = in.readUTF();setParameterTypesDesc(desc);ClassLoader originClassLoader = Thread.currentThread().getContextClassLoader();try {Object[] args = DubboCodec.EMPTY_OBJECT_ARRAY;Class<?>[] pts = DubboCodec.EMPTY_CLASS_ARRAY;if (desc.length() > 0) {// 根据参数描述来拿到对应的Class对象pts = drawPts(path, version, desc, pts);// 根据参数的Class和值，解析到真正的参数对象args = drawArgs(in, pts);}setParameterTypes(pts);Map<String, Object> map = in.readAttachments();if (CollectionUtils.isNotEmptyMap(map)) {addObjectAttachments(map);}decodeArgument(channel, pts, args);} catch (ClassNotFoundException e) {throw new IOException(StringUtils.toString("Read invocation data failed.", e));} finally {Thread.currentThread().setContextClassLoader(originClassLoader);if (in instanceof Cleanable) {((Cleanable) in).cleanup();}}return this;}

我们可以看到，先是通过CodecSupport.getSerialization来获取对应的序列化对象，然后通过它来反序列化数据（我们可以通过看org.apache.dubbo.common.serialize.Serialization有哪些实现类来了解Dubbo默认支持的协议类型）。

NettyServerHandler

        当轮到NettyServerHandler执行的时候，由于前面的ChannelHandler处理，请求数据已经反序列化成了org.apache.dubbo.remoting.exchange.Request对象，到了NettyServerHandler#received内部，就轮到一些列 org.apache.dubbo.remoting.ChannelHandler 的子类来处理了：

MultiMessageHandler

        如果是MultiMessage类型的消息，那么for循环去调用内部handler去处理，否则只调用handler处理一次。

HeartbeatHandler

        在Channel上设置读的时间戳，便于后续判断该Channel是否存活，同时判断请求是不是HeartBeatRequest类型，如果是，则直接应答。否则继续执行下一个handler。

AllChannelHandler

        根据请求的url来获取处理的线程池，然后将请求和DecodeHandler实例构造成ChannelEventRunnable对象来扔进线程池中执行。

    @Overridepublic void received(Channel channel, Object message) throws RemotingException {ExecutorService executor = getPreferredExecutorService(message);try {// 这里的handler是DecodeHandler对象executor.execute(new ChannelEventRunnable(channel, handler, ChannelState.RECEIVED, message));} catch (Throwable t) {if (message instanceof Request && t instanceof RejectedExecutionException) {sendFeedback(channel, (Request) message, t);return;}throw new ExecutionException(message, channel, getClass() + " error when process received event .", t);}}

DecodeHandler

        前面说了AllChannelHandler之后的逻辑是在另一个线程中执行的，毫无疑问，在这个新的线程中，主要是用来调用DecodeHandler的来进行解码，在Dubbo Provider接收客户端请求的场景下，调用的是received方法：

    @Overridepublic void received(Channel channel, Object message) throws RemotingException {// 如果之前设置的不是在IO线程中解码，那么就在这个线程中解码if (message instanceof Decodeable) {decode(message);}// 如果是Request对象，那么得对消息负载（真正的请求对象）进行解码if (message instanceof Request) {decode(((Request) message).getData());}if (message instanceof Response) {decode(((Response) message).getResult());}// handler是HeaderExchangeHandler对象handler.received(channel, message);}

HeaderExchangeHandler

        该Handler根据请求的交互方式来决定如何处理请求（例如有的交互方式是不需要应答的），处理真正调用，比如会拿Request.data(RpcInvocation)，最终会去调用DubboProtocol#ExchangeHandler的reply方法来拿到一个异步结果对象，并设置完成时候res的状态码和结果的赋值：

    void handleRequest(final ExchangeChannel channel, Request req) throws RemotingException {Response res = new Response(req.getId(), req.getVersion());// find handler by message class.Object msg = req.getData();try {// handler是DubboProtocol#ExchangeHandler对象CompletionStage<Object> future = handler.reply(channel, msg);future.whenComplete((appResult, t) -> {try {if (t == null) {res.setStatus(Response.OK);res.setResult(appResult);} else {res.setStatus(Response.SERVICE_ERROR);res.setErrorMessage(StringUtils.toString(t));}channel.send(res);} catch (RemotingException e) {logger.warn(TRANSPORT_FAILED_RESPONSE,"","","Send result to consumer failed, channel is " + channel + ", msg is " + e);}});} catch (Throwable e) {res.setStatus(Response.SERVICE_ERROR);res.setErrorMessage(StringUtils.toString(e));channel.send(res);}}