[[416157]]

今天，我們繼續(xù)學(xué)習(xí)Netty邏輯架構(gòu)中的另一個(gè)核心組件ChannelHandler和ChannelPipeline。

如果說(shuō)線程模型是Netty的 “核心內(nèi)功”，那么ChannelHandler就是Netty最著名的 “武功招式”，是我們?nèi)粘Ｊ褂肗etty時(shí)接觸最多的組件。

引用《Netty in action》中的一句話

• From the appliaction developer's standpoint, the primary component of Netty is the ChannelHandler.

所以，阿丸盡可能通過(guò) 圖 和 代碼demo，來(lái)讓大家獲得最直觀的使用體驗(yàn)。

本文預(yù)計(jì)閱讀時(shí)間約 10分鐘，將重點(diǎn)圍繞以下幾個(gè)問(wèn)題展開(kāi)：

• 什么是ChannelHandler和ChannelPipeline?
• ChannelHandler的事件傳播機(jī)制
• ChannelHandler的異常處理機(jī)制
• ChannelHandler的最佳實(shí)踐

1、什么是ChannelHandler和ChannelPipeline

ChannelHandler是一個(gè)包含所有應(yīng)用處理邏輯的容器載體，用來(lái)對(duì)Netty的輸入輸出數(shù)據(jù)進(jìn)行加工處理。

比如數(shù)據(jù)格式轉(zhuǎn)換、異常處理等

ChannelPipeline 則是 ChannelHandler 的容器載體，負(fù)責(zé)以鏈?zhǔn)降男问秸{(diào)度各個(gè)注冊(cè)的ChannelHandler。

我們回顧下之前介紹過(guò)的Netty邏輯架構(gòu)，觀察下ChannelPipeline和ChannelHandler的位置。

再?gòu)木植糠糯螅梢愿用鞔_地看到ChannelPipeline和ChannelHandler的作用。

如上圖所示，當(dāng)EventLoop中監(jiān)聽(tīng)到事件后，會(huì)對(duì)I/O事件進(jìn)行處理。而這個(gè)處理，就是交給ChannelPipeline進(jìn)行，更嚴(yán)格地說(shuō)，是交給ChannelPipeline中的各個(gè)ChannelHandler按照一定的順序進(jìn)行處理。

根據(jù)數(shù)據(jù)的流向，Netty把ChannelHandler分為2類，InboundHandler和OutboundHandler。

如上圖所示，Netty接收到數(shù)據(jù)后，經(jīng)過(guò)若干 InboundHandler 處理后接收成功。如果要輸出數(shù)據(jù)，就需要經(jīng)過(guò)若干個(gè) OutboundHandler 處理完成后發(fā)送。

比如，我們經(jīng)常需要對(duì)接收到的數(shù)據(jù)進(jìn)行解碼，就是在某一個(gè)專門decode的InboundHandler中處理的。如果要發(fā)送數(shù)據(jù)，往往需要編碼，就是在某一個(gè)專門encode的OutBoundHandler中處理的。

值得一提的是，雖然我們?cè)谑褂肗etty時(shí)，直接打交道的是ChannelPipeline和ChannelHandler，但是，它們之間有一座“隱形”的橋梁，名字叫做ChannelHandlerContext。

顧名思義，ChannelHanderContext就是ChannelHandler的上下文，每個(gè) ChannelHandler 都對(duì)應(yīng)一個(gè) ChannelHandlerContext。

每一個(gè) ChannelPipeline 都包含多個(gè) ChannelHandlerContext，所有 ChannelHandlerContext 之間組成了雙向鏈表。如下圖所示。

其中，有兩個(gè)特殊的ChannelHandlerContext，分別是HeadContext和TailContext，表示雙向鏈表的頭尾節(jié)點(diǎn)。

從類圖上可以看到，HeadContext同時(shí)實(shí)現(xiàn)了ChannelInboundHandler和ChannelOutboundHandler。因此，HeadContext在讀取數(shù)據(jù)時(shí)作為頭節(jié)點(diǎn)，向后傳遞InBound事件，同時(shí)，在寫數(shù)據(jù)時(shí)作為尾節(jié)點(diǎn)，處理最后的OutBound事件。

TailContext只實(shí)現(xiàn)了ChannelInboundHandler。它在InBound事件傳遞的末尾，負(fù)責(zé)處理一些資源釋放的工作。在OutBound事件傳遞的第一個(gè)節(jié)點(diǎn)，不做任何處理，僅僅傳遞OutBound事件給prev節(jié)點(diǎn)。

而我們平時(shí)自定義的ChannelHandler，就是插在這兩個(gè)頭尾節(jié)點(diǎn)之間的。

至此，我們對(duì)ChannelHandler和ChannelPipeline有了基本的認(rèn)識(shí)。具體到實(shí)踐上，我們?cè)撊绾握_地使用ChannelHandler呢?

對(duì)ChannelHandler的使用，必須先了解ChannelHandler的事件傳播機(jī)制和異常處理機(jī)制。

2、ChannelHandler的事件傳播機(jī)制

前面我們提到了Netty中的兩種事件類型，Inbound事件和Outbound事件，分別對(duì)應(yīng)InboundHandler和OutbountHandler進(jìn)行處理。

當(dāng)我們使用Netty進(jìn)行開(kāi)發(fā)的時(shí)候，必須了解Inbound事件和Outbound事件在ChannelPipeline中如何進(jìn)行“事件傳播”，注冊(cè)InboundHandler和OutboundHandler的順序有什么影響。

話不多說(shuō)，我們先來(lái)一個(gè)demo直觀地感受一下。

自定義一個(gè)ChannelInboundHandler

自定義一個(gè)ChannelOutboundHandler

簡(jiǎn)單組裝一下EchoPipelineServer，特別注意一下 6個(gè)handler 的注冊(cè)順序。

然后我們通過(guò)命令行簡(jiǎn)單訪問(wèn)一下這個(gè)Netty Server

curl localhost:8081 

可以看到控制臺(tái)的如下輸出

這樣就清楚了事件傳播順序：

• - 對(duì)于Inbound事件，InboundHandler的處理順序是和注冊(cè)順序一致
• - 對(duì)于Outbound事件，OutboundHandler的處理順序和注冊(cè)順序相反

結(jié)合上一節(jié)說(shuō)的HeadContext和TailContext，我們畫(huà)個(gè)圖來(lái)更直觀地看一下這個(gè)ChannelPipeline中的handler構(gòu)建順序是怎樣的。

在上面的ChannelInitializer中，我們按需添加了3個(gè)InboundHandler和3個(gè)OutboundHandler。所以，在頭節(jié)點(diǎn)HeadContext和TailContext之間，有序構(gòu)成了雙向鏈表。

而InboundHandler3中，通過(guò)調(diào)用 ctx.channel.writeAndFlush( msg ) 方法，將消息從TailContext開(kāi)始，依據(jù)OutboundHandler的路徑向HeadContext方向傳播出去。具體可以看下DefaultChannelPipeline類中的實(shí)現(xiàn)

雖然這里是雙向鏈表，但是無(wú)論是Inbound事件還是Outbound事件，在按序訪問(wèn)鏈表節(jié)點(diǎn)時(shí)，會(huì)根據(jù)事件類型進(jìn)行過(guò)濾。

3、ChannelHandler的異常傳播機(jī)制

我們已經(jīng)了解了ChannelPipeline的鏈?zhǔn)絺鬟f規(guī)則，如果雙向鏈表中任意一個(gè)handler拋出了異常，那么應(yīng)該怎么處理呢?

3.1 InboundHandler的異常處理

我們修改下示例中的TestInboudHandler進(jìn)行模擬。

• channelRead方法中拋出異常
• 重寫exceptionCaught方法，打印當(dāng)前節(jié)點(diǎn)捕獲異常情況

得到輸出如下

可以看到，雖然在InboundHander1中拋出了異常，但是仍然會(huì)被3個(gè)InboundHandler都捕獲一次，并按序向tail節(jié)點(diǎn)方向傳遞，然后拋出異常。

我們也看到了，Netty給出了會(huì)警告，在最后的節(jié)點(diǎn)沒(méi)有進(jìn)行異常處理。

An exceptionCaught() event was fired, and it reached at the tail of the pipeline.  
It usually means the last handler in the pipeline did not handle the exception. 

3.2 OutboundHandler的異常處理

OutboundHandler也是這么操作嗎?

我們來(lái)做個(gè)實(shí)驗(yàn)。

• 在write操作中拋出異常
• 重寫下exceptionCaught方法(這個(gè)方法在OutboundHandler中被標(biāo)記為廢棄)

重寫組裝下channelPipeline，第二個(gè)OutboundHandler中拋出異常

結(jié)果得到的輸出如下:

咦?異常被吃掉了!!

不僅沒(méi)有走進(jìn)exceptionCaught方法，也沒(méi)有其他異常拋出。

只是對(duì)后續(xù)handler的write方法不再執(zhí)行，而flush方法還是都執(zhí)行了一遍。

我們從源碼找找原因吧。跟一下斷點(diǎn)，馬上就找到了原因：

在AbstractChannelHandlerContext中，對(duì)OutboundHandler的write方法做了異常捕獲，然后對(duì)ChannelPromise進(jìn)行了通知。

后續(xù)源碼就不展開(kāi)了，有興趣的同學(xué)自己打斷點(diǎn)跟一下，比較清楚。

那么問(wèn)題來(lái)了，怎么在OutboundHandler中捕獲異常呢?很明顯就是直接添加ChannelPromise的回調(diào)。

上代碼：

在前面提到的ExceptionHandler中，復(fù)寫write方法，然后注冊(cè)一個(gè)ChannelPromise的Listener就行了。

當(dāng)然，這個(gè)ExceptionHandler同樣要注冊(cè)到ChannelPipeline。

千萬(wàn)注意!!這里ExceptionHandler同樣是添加到ChannelPipeline的tail方向的最后，而不是添加在head方向。

無(wú)論是inboundHandler或者是outboundHandler的異常，都是按序向tail方向傳遞的。

異常就這樣抓到了。

4、ChannelHandler的最佳實(shí)踐

其實(shí)前面已經(jīng)對(duì)ChannelHandler的常用機(jī)制做了介紹，這里簡(jiǎn)單再介紹下兩個(gè)最佳實(shí)踐。

4.1 不在ChannelHandler中耗時(shí)處理

這一點(diǎn)其實(shí)在前一篇《 深入Netty邏輯架構(gòu)，從Reactor線程模型開(kāi)始》已經(jīng)提到過(guò)，這里作為自定義ChannelHandler的最佳實(shí)踐再?gòu)?qiáng)調(diào)一下，不在ChannelHandler中做耗時(shí)處理。

這里包括兩點(diǎn)。

• 不在I/O線程中直接處理耗時(shí)操作。
• 也不把耗時(shí)操作放進(jìn)EventLoop的任務(wù)隊(duì)列中。

由于Netty4的無(wú)鎖串行化設(shè)計(jì)，一旦任何耗時(shí)操作阻塞了某個(gè)EventLoop，那么這個(gè)EventLoop上的各個(gè)channel都會(huì)被阻塞。更詳細(xì)內(nèi)容可以參考上一篇《 深入Netty邏輯架構(gòu)，從Reactor線程模型開(kāi)始》。

所以，我們對(duì)于耗時(shí)操作，我們要放在自己的業(yè)務(wù)線程池中進(jìn)行處理，如果需要發(fā)送response，需要提交任務(wù)到EventLoop的任務(wù)隊(duì)列中執(zhí)行。

給個(gè)簡(jiǎn)單的demo。

4.2 統(tǒng)一的異常處理

在本文的第三節(jié)中，講解了ChannelHandler的異常傳播機(jī)制。

對(duì)于InboundHandler來(lái)說(shuō)，如果你有跟handler特定相關(guān)的異常，可以直接在handler里進(jìn)行exceptionCaught。如果是一些通用的異常，可以自定義ExceptionHandler注冊(cè)到ChannelPipeline的末尾進(jìn)行統(tǒng)一攔截。

對(duì)于OutboudHandler來(lái)說(shuō)，就是通過(guò)自定義ExceptionHandler，重寫對(duì)應(yīng)方法，并注冊(cè)ChannelPromise的Listener。同樣的，ExceptionHandler注冊(cè)到ChannelPipeline的末尾進(jìn)行統(tǒng)一攔截。

所以，總結(jié)下如何添加一個(gè)“統(tǒng)一”的異常攔截器呢?

• 自定義ExceptionHandler繼承ChannelDuplexHandler，并注冊(cè)到 tail節(jié)點(diǎn)前(ChannelPipeline的最后一個(gè)節(jié)點(diǎn))。
• 對(duì)于Inbound事件，我們需要在exceptionCaught()進(jìn)行處理。
• 對(duì)于Outbound事件，我們需要對(duì)OutboundHandler的不同方法(如write、flush)注冊(cè)ChannelFutureListener事件。

異常攔截器的注冊(cè)位置應(yīng)該在tail方向的最后一個(gè)Handler。

注意，統(tǒng)一異常處理除了更優(yōu)雅處理通用異常外，也是排查故障的好幫手。比如有時(shí)候?qū)τ诰幗獯a異常，可以在統(tǒng)一處理異常處捕獲，快速定位問(wèn)題。

5、小結(jié)

來(lái)簡(jiǎn)單回顧下吧。

本文介紹了什么是ChannelHandler和ChannelPipeline。能厘清InboundChannelHandler、OutboundChannelHandler、ChannelHandlerContext是什么嗎?

然后對(duì)ChannelHandler的事件傳播機(jī)制、異常處理機(jī)制做了詳細(xì)介紹。

最后說(shuō)明了日常開(kāi)發(fā)中ChannelHandler的最佳實(shí)踐。

希望對(duì)大家有所幫助。