摘要：而存在的意義就是保證請求或響應對象可在線程池中被解碼，解碼完成后，就會分發到的。

目標：從源碼的角度分析服務端接收到請求后的一系列操作，最終把客戶端需要的值返回。

上一篇講到了消費端發送請求的過程，該篇就要將服務端處理請求的過程。也就是當服務端收到請求數據包后的一系列處理以及如何返回最終結果。我們也知道消費端在發送請求的時候已經做了編碼，所以我們也需要在服務端接收到數據包后，對協議頭和協議體進行解碼。不過本篇不講解如何解碼。有興趣的可以翻翻我以前的文章，有講到關于解碼的邏輯。接下來就開始講解服務端收到請求后的邏輯。

假設遠程通信的實現還是用netty4，解碼器將數據包解析成 Request 對象后，NettyHandler 的 messageReceived 方法緊接著會收到這個對象，所以第一步就是NettyServerHandler的channelRead。

可以參考《dubbo源碼解析（十七）遠程通信——Netty4》的（三）NettyServerHandler

public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
    // 看是否在緩存中命中，如果沒有命中，則創建NettyChannel并且緩存。
    NettyChannel channel = NettyChannel.getOrAddChannel(ctx.channel(), url, handler);
    try {
        // 接受消息
        handler.received(channel, msg);
    } finally {
        // 如果通道不活躍或者斷掉，則從緩存中清除
        NettyChannel.removeChannelIfDisconnected(ctx.channel());
    }
}

NettyServerHandler是基于netty4實現的服務端通道處理實現類，而該方法就是用來接收請求，接下來就是執行AbstractPeer的received。

可以參考《dubbo源碼解析（九）遠程通信——Transport層》的（一）AbstractPeer

public void received(Channel ch, Object msg) throws RemotingException {
    // 如果通道已經關閉，則直接返回
    if (closed) {
        return;
    }
    handler.received(ch, msg);
}

該方法比較簡單，之前也講過AbstractPeer類就做了裝飾模式中裝飾角色，只是維護了通道的正在關閉和關閉完成兩個狀態。然后到了MultiMessageHandler的received

可以參考《dubbo源碼解析（九）遠程通信——Transport層》的（八）MultiMessageHandler

public void received(Channel channel, Object message) throws RemotingException {
    // 如果消息是MultiMessage類型的，也就是多消息類型
    if (message instanceof MultiMessage) {
        // 強制轉化為MultiMessage
        MultiMessage list = (MultiMessage) message;
        // 把各個消息進行發送
        for (Object obj : list) {
            handler.received(channel, obj);
        }
    } else {
        // 直接發送
        handler.received(channel, message);
    }
}

該方法也比較簡單，就是對于多消息的處理。

可以參考《dubbo源碼解析（十）遠程通信——Exchange層》的（二十）HeartbeatHandler。其中就是對心跳事件做了處理。如果不是心跳請求，那么接下去走到AllChannelHandler的received。

可以參考《dubbo源碼解析（九）遠程通信——Transport層》的（十一）AllChannelHandler。該類處理的是連接、斷開連接、捕獲異常以及接收到的所有消息都分發到線程池。所以這里的received方法就是把請求分發到線程池，讓線程池去執行該請求。

還記得我在之前文章里面講到到Dispatcher接口嗎，它是一個線程派發器。分別有五個實現：

這些Dispatcher的實現類以及對應的Handler都可以在《dubbo源碼解析（九）遠程通信——Transport層》中查看相關實現。dubbo默認all為派發策略。所以我在這里講了AllChannelHandler的received。把消息送到線程池后，可以看到首先會創建一個ChannelEventRunnable實體。那么接下來就是線程接收并且執行任務了。

ChannelEventRunnable實現了Runnable接口，主要是用來接收消息事件，并且根據事件的種類來分別執行不同的操作。來看看它的run方法：

public void run() {
    // 如果是接收的消息
    if (state == ChannelState.RECEIVED) {
        try {
            // 直接調用下一個received
            handler.received(channel, message);
        } catch (Exception e) {
            logger.warn("ChannelEventRunnable handle " + state + " operation error, channel is " + channel
                    + ", message is " + message, e);
        }
    } else {
        switch (state) {
            //如果是連接事件請求
        case CONNECTED:
            try {
                // 執行連接
                handler.connected(channel);
            } catch (Exception e) {
                logger.warn("ChannelEventRunnable handle " + state + " operation error, channel is " + channel, e);
            }
            break;
            // 如果是斷開連接事件請求
        case DISCONNECTED:
            try {
                // 執行斷開連接
                handler.disconnected(channel);
            } catch (Exception e) {
                logger.warn("ChannelEventRunnable handle " + state + " operation error, channel is " + channel, e);
            }
            break;
            // 如果是發送消息
        case SENT:
            try {
                // 執行發送消息
                handler.sent(channel, message);
            } catch (Exception e) {
                logger.warn("ChannelEventRunnable handle " + state + " operation error, channel is " + channel
                        + ", message is " + message, e);
            }
            break;
            // 如果是異常
        case CAUGHT:
            try {
                // 執行異常捕獲
                handler.caught(channel, exception);
            } catch (Exception e) {
                logger.warn("ChannelEventRunnable handle " + state + " operation error, channel is " + channel
                        + ", message is: " + message + ", exception is " + exception, e);
            }
            break;
        default:
            logger.warn("unknown state: " + state + ", message is " + message);
        }
    }

}

可以看到把消息分為了幾種類別，因為請求和響應消息出現頻率明顯比其他類型消息高，也就是RECEIVED，所以多帶帶先做處理，根據不同的類型的消息，會被執行不同的邏輯，我們這里主要看state為RECEIVED的，那么如果是RECEIVED，則會執行下一個received方法。

可以參考《dubbo源碼解析（九）遠程通信——Transport層》的（七）DecodeHandler。可以看到received方法中根據消息的類型進行不同的解碼。而DecodeHandler 存在的意義就是保證請求或響應對象可在線程池中被解碼，解碼完成后，就會分發到HeaderExchangeHandler的received。

public void received(Channel channel, Object message) throws RemotingException {
    // 設置接收到消息的時間戳
    channel.setAttribute(KEY_READ_TIMESTAMP, System.currentTimeMillis());
    // 獲得通道
    final ExchangeChannel exchangeChannel = HeaderExchangeChannel.getOrAddChannel(channel);
    try {
        // 如果消息是Request類型
        if (message instanceof Request) {
            // handle request.
            // 強制轉化為Request
            Request request = (Request) message;
            // 如果該請求是事件心跳事件或者只讀事件
            if (request.isEvent()) {
                // 執行事件
                handlerEvent(channel, request);
            } else {
                // 如果是正常的調用請求，且需要響應
                if (request.isTwoWay()) {
                    // 處理請求
                    handleRequest(exchangeChannel, request);
                } else {
                    // 如果不需要響應，則繼續下一步
                    handler.received(exchangeChannel, request.getData());
                }
            }
        } else if (message instanceof Response) {
            // 處理響應
            handleResponse(channel, (Response) message);
        } else if (message instanceof String) {
            // 如果是telnet相關的請求
            if (isClientSide(channel)) {
                // 如果是客戶端側，則直接拋出異常，因為客戶端側不支持telnet
                Exception e = new Exception("Dubbo client can not supported string message: " + message + " in channel: " + channel + ", url: " + channel.getUrl());
                logger.error(e.getMessage(), e);
            } else {
                // 如果是服務端側，則執行telnet命令
                String echo = handler.telnet(channel, (String) message);
                if (echo != null && echo.length() > 0) {
                    channel.send(echo);
                }
            }
        } else {
            // 如果都不是，則繼續下一步
            handler.received(exchangeChannel, message);
        }
    } finally {
        // 移除關閉或者不活躍的通道
        HeaderExchangeChannel.removeChannelIfDisconnected(channel);
    }
}

該方法中就對消息進行了細分，事件請求、正常的調用請求、響應、telnet命令請求等，并且針對不同的消息類型做了不同的邏輯調用。我們這里主要看正常的調用請求。見下一步。

void handleRequest(final ExchangeChannel channel, Request req) throws RemotingException {
    // 創建一個Response實例
    Response res = new Response(req.getId(), req.getVersion());
    // 如果請求被破壞了
    if (req.isBroken()) {
        // 獲得請求的數據包
        Object data = req.getData();

        String msg;
        // 如果數據為空
        if (data == null) {
            //消息設置為空
            msg = null;
            // 如果在這之前已經出現異常，也就是數據為Throwable類型
        } else if (data instanceof Throwable) {
            // 響應消息把異常信息返回
            msg = StringUtils.toString((Throwable) data);
        } else {
            // 返回請求數據
            msg = data.toString();
        }
        res.setErrorMessage("Fail to decode request due to: " + msg);
        // 設置錯誤請求的狀態碼
        res.setStatus(Response.BAD_REQUEST);

        // 發送該消息
        channel.send(res);
        return;
    }
    // find handler by message class.
    // 獲得請求數據 也就是 RpcInvocation 對象
    Object msg = req.getData();
    try {
        // 繼續向下調用 返回一個future
        CompletionStage