前記
很早以前就有讀Netty源碼的打算了，然而第一次嘗試的時候從Netty4開始，一直抓不到核心的框架流程，后來因為其他事情忙著就放下了。這次趁著休假重新撿起這個硬骨頭，因為Netty3現在還在被很多項目使用，因而這次決定先從Netty3入手，瞬間發現Netty3的代碼比Netty4中規中矩的多，很多概念在代碼本身中都有清晰的表達，所以半天就把整個框架的骨架搞清楚了。再讀
Netty4對Netty3的改進總結，回去讀Netty4的源碼，反而覺得輕松了，一種豁然開朗的感覺。
記得去年讀Jetty源碼的時候，因為代碼太龐大，并且自己的HTTP Server的了解太少，因而只能自底向上的一個一個模塊的疊加，直到最后把所以的模塊連接在一起而看清它的真正核心骨架。現在讀源碼，開始習慣先把骨架理清，然后延伸到不同的器官、血肉而看清整個人體。
本文從Reactor模式在Netty3中的應用，引出Netty3的整體架構以及控制流程；然而除了Reactor模式，Netty3還在ChannelPipeline中使用了
Intercepting Filter模式，這個模式也在Servlet的Filter中成功使用，因而本文還會從Intercepting Filter模式出發詳細介紹ChannelPipeline的設計理念。本文假設讀者已經對Netty有一定的了解，因而不會包含過多入門介紹，以及幫Netty做宣傳的文字。
Netty3中的Reactor模式
Reactor模式在Netty中應用非常成功，因而它也是在Netty中受大肆宣傳的模式，關于Reactor模式可以詳細參考本人的另一篇文章
《Reactor模式詳解》，對Reactor模式的實現是Netty3的基本骨架，因而本小節會詳細介紹Reactor模式如何應用Netty3中。
如果讀《Reactor模式詳解》，我們知道Reactor模式由Handle、Synchronous Event Demultiplexer、Initiation Dispatcher、Event Handler、Concrete Event Handler構成，在Java的實現版本中，Channel對應Handle，Selector對應Synchronous Event Demultiplexer，并且Netty3還使用了兩層Reactor：Main Reactor用于處理Client的連接請求，Sub Reactor用于處理和Client連接后的讀寫請求（關于這個概念還可以參考Doug Lea的這篇PPT：
Scalable IO In Java）。所以我們先要解決Netty3中使用什么類實現所有的上述模塊并把他們聯系在一起的，以NIO實現方式為例：
模式是一種抽象，但是在實現中，經常會因為語言特性、框架和性能需要而做一些改變，因而Netty3對Reactor模式的實現有一套自己的設計：
1. ChannelEvent：Reactor是基于事件編程的，因而在Netty3中使用ChannelEvent抽象的表達Netty3內部可以產生的各種事件，所有這些事件對象在Channels幫助類中產生，并且由它將事件推入到ChannelPipeline中，ChannelPipeline構建ChannelHandler管道，ChannelEvent流經這個管道實現所有的業務邏輯處理。ChannelEvent對應的事件有：ChannelStateEvent表示Channel狀態的變化事件，而如果當前Channel存在Parent Channel，則該事件還會傳遞到Parent Channel的ChannelPipeline中，如OPEN、BOUND、CONNECTED、INTEREST_OPS等，該事件可以在各種不同實現的Channel、ChannelSink中產生；MessageEvent表示從Socket中讀取數據完成、需要向Socket寫數據或ChannelHandler對當前Message解析(如Decoder、Encoder)后觸發的事件，它由NioWorker、需要對Message做進一步處理的ChannelHandler產生；WriteCompletionEvent表示寫完成而觸發的事件，它由NioWorker產生；ExceptionEvent表示在處理過程中出現的Exception，它可以發生在各個構件中，如Channel、ChannelSink、NioWorker、ChannelHandler中；IdleStateEvent由IdleStateHandler觸發，這也是一個ChannelEvent可以無縫擴展的例子。注：在Netty4后，已經沒有ChannelEvent類，所有不同事件都用對應方法表達，這也意味這ChannelEvent不可擴展，Netty4采用在ChannelInboundHandler中加入userEventTriggered()方法來實現這種擴展，具體可以參考
這里。
2. ChannelHandler：在Netty3中，ChannelHandler用于表示Reactor模式中的EventHandler。ChannelHandler只是一個標記接口，它有兩個子接口：ChannelDownstreamHandler和ChannelUpstreamHandler，其中ChannelDownstreamHandler表示從用戶應用程序流向Netty3內部直到向Socket寫數據的管道，在Netty4中改名為ChannelOutboundHandler；ChannelUpstreamHandler表示數據從Socket進入Netty3內部向用戶應用程序做數據處理的管道，在Netty4中改名為ChannelInboundHandler。
3. ChannelPipeline：用于管理ChannelHandler的管道，每個Channel一個ChannelPipeline實例，可以運行過程中動態的向這個管道中添加、刪除ChannelHandler（由于實現的限制，在最末端的ChannelHandler向后添加或刪除ChannelHandler不一定在當前執行流程中起效，參考
這里）。ChannelPipeline內部維護一個ChannelHandler的雙向鏈表，它以Upstream(Inbound)方向為正向，Downstream(Outbound)方向為方向。ChannelPipeline采用Intercepting Filter模式實現，具體可以參考
這里，這個模式的實現在后一節中還是詳細介紹。
4. NioSelector：Netty3使用NioSelector來存放Selector（Synchronous Event Demultiplexer），每個新產生的NIO Channel都向這個Selector注冊自己以讓這個Selector監聽這個NIO Channel中發生的事件，當事件發生時，調用幫助類Channels中的方法生成ChannelEvent實例，將該事件發送到這個Netty Channel對應的ChannelPipeline中，而交給各級ChannelHandler處理。其中在向Selector注冊NIO Channel時，Netty Channel實例以Attachment的形式傳入，該Netty Channel在其內部的NIO Channel事件發生時，會以Attachment的形式存在于SelectionKey中，因而每個事件可以直接從這個Attachment中獲取相關鏈的Netty Channel，并從Netty Channel中獲取與之相關聯的ChannelPipeline，這個實現和Doug Lea的
Scalable IO In Java一模一樣。另外Netty3還采用了
Scalable IO In Java中相同的Main Reactor和Sub Reactor設計，其中NioSelector的兩個實現：Boss即為Main Reactor，NioWorker為Sub Reactor。Boss用來處理新連接加入的事件，NioWorker用來處理各個連接對Socket的讀寫事件，其中Boss通過NioWorkerPool獲取NioWorker實例，Netty3模式使用RoundRobin方式放回NioWorker實例。更形象一點的，可以通過
Scalable IO In Java的這張圖表達：
若與Ractor模式對應，NioSelector中包含了Synchronous Event Demultiplexer，而ChannelPipeline中管理著所有EventHandler，因而NioSelector和ChannelPipeline共同構成了Initiation Dispatcher。
5. ChannelSink：在ChannelHandler處理完成所有邏輯需要向客戶端寫響應數據時，一般會調用Netty Channel中的write方法，然而在這個write方法實現中，它不是直接向其內部的Socket寫數據，而是交給Channels幫助類，內部創建DownstreamMessageEvent，反向從ChannelPipeline的管道中流過去，直到第一個ChannelHandler處理完畢，最后交給ChannelSink處理，以避免阻塞寫而影響程序的吞吐量。ChannelSink將這個MessageEvent提交給Netty Channel中的writeBufferQueue，最后NioWorker會等到這個NIO Channel已經可以處理寫事件時無阻塞的向這個NIO Channel寫數據。這就是上圖的send是從SubReactor直接出發的原因。
6. Channel：Netty有自己的Channel抽象，它是一個資源的容器，包含了所有一個連接涉及到的所有資源的飲用，如封裝NIO Channel、ChannelPipeline、Boss、NioWorkerPool等。另外它還提供了向內部NIO Channel寫響應數據的接口write、連接/綁定到某個地址的connect/bind接口等，個人感覺雖然對Channel本身來說，因為它封裝了NIO Channel，因而這些接口定義在這里是合理的，但是如果考慮到Netty的架構，它的Channel只是一個資源容器，有這個Channel實例就可以得到和它相關的基本所有資源，因而這種write、connect、bind動作不應該再由它負責，而是應該由其他類來負責，比如在Netty4中就在ChannelHandlerContext添加了write方法，雖然netty4并沒有刪除Channel中的write接口。
Netty3中的Intercepting Filter模式
如果說Reactor模式是Netty3的骨架，那么Intercepting Filter模式則是Netty的中樞。Reactor模式主要應用在Netty3的內部實現，它是Netty3具有良好性能的基礎，而Intercepting Filter模式則是ChannelHandler組合實現一個應用程序邏輯的基礎，只有很好的理解了這個模式才能使用好Netty，甚至能得心應手。
關于Intercepting Filter模式的詳細介紹可以參考
這里，本節主要介紹Netty3中對Intercepting Filter模式的實現，其實就是DefaultChannelPipeline對Intercepting Filter模式的實現。在上文有提到Netty3的ChannelPipeline是ChannelHandler的容器，用于存儲與管理ChannelHandler，同時它在Netty3中也起到橋梁的作用，即它是連接Netty3內部到所有ChannelHandler的橋梁。作為ChannelPipeline的實現者DefaultChannelPipeline，它使用一個ChannelHandler的雙向鏈表來存儲，以DefaultChannelPipelineContext作為節點：
public interface ChannelHandlerContext {
Channel getChannel();
ChannelPipeline getPipeline();
String getName();
ChannelHandler getHandler();
boolean canHandleUpstream();
boolean canHandleDownstream();
void sendUpstream(ChannelEvent e);
void sendDownstream(ChannelEvent e);
Object getAttachment();
void setAttachment(Object attachment);
}
private final class DefaultChannelHandlerContext implements ChannelHandlerContext {
volatile DefaultChannelHandlerContext next;
volatile DefaultChannelHandlerContext prev;
private final String name;
private final ChannelHandler handler;
private final boolean canHandleUpstream;
private final boolean canHandleDownstream;
private volatile Object attachment;
.....
}
在DefaultChannelPipeline中，它存儲了和當前ChannelPipeline相關聯的Channel、ChannelSink以及ChannelHandler鏈表的head、tail，所有ChannelEvent通過sendUpstream、sendDownstream為入口流經整個鏈表：
public class DefaultChannelPipeline implements ChannelPipeline {
private volatile Channel channel;
private volatile ChannelSink sink;
private volatile DefaultChannelHandlerContext head;
private volatile DefaultChannelHandlerContext tail;
......
public void sendUpstream(ChannelEvent e) {
DefaultChannelHandlerContext head = getActualUpstreamContext(this.head);
if (head == null) {
return;
}
sendUpstream(head, e);
}
void sendUpstream(DefaultChannelHandlerContext ctx, ChannelEvent e) {
try {
((ChannelUpstreamHandler) ctx.getHandler()).handleUpstream(ctx, e);
} catch (Throwable t) {
notifyHandlerException(e, t);
}
}
public void sendDownstream(ChannelEvent e) {
DefaultChannelHandlerContext tail = getActualDownstreamContext(this.tail);
if (tail == null) {
try {
getSink().eventSunk(this, e);
return;
} catch (Throwable t) {
notifyHandlerException(e, t);
return;
}
}
sendDownstream(tail, e);
}
void sendDownstream(DefaultChannelHandlerContext ctx, ChannelEvent e) {
if (e instanceof UpstreamMessageEvent) {
throw new IllegalArgumentException("cannot send an upstream event to downstream");
}
try {
((ChannelDownstreamHandler) ctx.getHandler()).handleDownstream(ctx, e);
} catch (Throwable t) {
e.getFuture().setFailure(t);
notifyHandlerException(e, t);
}
}
對Upstream事件，向后找到所有實現了ChannelUpstreamHandler接口的ChannelHandler組成鏈（
getActualUpstreamContext()），而對Downstream事件，向前找到所有實現了ChannelDownstreamHandler接口的ChannelHandler組成鏈（
getActualDownstreamContext()）：
private DefaultChannelHandlerContext getActualUpstreamContext(DefaultChannelHandlerContext ctx) {
if (ctx == null) {
return null;
}
DefaultChannelHandlerContext realCtx = ctx;
while (!realCtx.canHandleUpstream()) {
realCtx = realCtx.next;
if (realCtx == null) {
return null;
}
}
return realCtx;
}
private DefaultChannelHandlerContext getActualDownstreamContext(DefaultChannelHandlerContext ctx) {
if (ctx == null) {
return null;
}
DefaultChannelHandlerContext realCtx = ctx;
while (!realCtx.canHandleDownstream()) {
realCtx = realCtx.prev;
if (realCtx == null) {
return null;
}
}
return realCtx;
}
在實際實現ChannelUpstreamHandler或ChannelDownstreamHandler時，調用
ChannelHandlerContext中的sendUpstream或sendDownstream方法將控制流程交給下一個
ChannelUpstreamHandler或下一個ChannelDownstreamHandler，或調用Channel中的write方法發送
響應消息。
public class MyChannelUpstreamHandler implements ChannelUpstreamHandler {
public void handleUpstream(ChannelHandlerContext ctx, ChannelEvent e) throws Exception {
// handle current logic, use Channel to write response if needed.
// ctx.getChannel().write(message);
ctx.sendUpstream(e);
}
}
public class MyChannelDownstreamHandler implements ChannelDownstreamHandler {
public void handleDownstream(
ChannelHandlerContext ctx, ChannelEvent e) throws Exception {
// handle current logic
ctx.sendDownstream(e);
}
}
當ChannelHandler向ChannelPipelineContext發送事件時，其內部從當前ChannelPipelineContext節點出發找到下一個ChannelUpstreamHandler或ChannelDownstreamHandler實例，并向其發送ChannelEvent，對于Downstream鏈，如果到達鏈尾，則將ChannelEvent發送給ChannelSink：
public void sendDownstream(ChannelEvent e) {
DefaultChannelHandlerContext prev = getActualDownstreamContext(this.prev);
if (prev == null) {
try {
getSink().eventSunk(DefaultChannelPipeline.this, e);
} catch (Throwable t) {
notifyHandlerException(e, t);
}
} else {
DefaultChannelPipeline.this.sendDownstream(prev, e);
}
}
public void sendUpstream(ChannelEvent e) {
DefaultChannelHandlerContext next = getActualUpstreamContext(this.next);
if (next != null) {
DefaultChannelPipeline.this.sendUpstream(next, e);
}
}
正是因為這個實現，如果在一個末尾的ChannelUpstreamHandler中先移除自己，在向末尾添加一個新的ChannelUpstreamHandler，它是無效的，因為它的next已經在調用前就固定設置為null了。
ChannelPipeline作為ChannelHandler的容器，它還提供了各種增、刪、改ChannelHandler鏈表中的方法，而且如果某個ChannelHandler還實現了LifeCycleAwareChannelHandler，則該ChannelHandler在被添加進ChannelPipeline或從中刪除時都會得到同志：
public interface LifeCycleAwareChannelHandler extends ChannelHandler {
void beforeAdd(ChannelHandlerContext ctx) throws Exception;
void afterAdd(ChannelHandlerContext ctx) throws Exception;
void beforeRemove(ChannelHandlerContext ctx) throws Exception;
void afterRemove(ChannelHandlerContext ctx) throws Exception;
}
public interface ChannelPipeline {
void addFirst(String name, ChannelHandler handler);
void addLast(String name, ChannelHandler handler);
void addBefore(String baseName, String name, ChannelHandler handler);
void addAfter(String baseName, String name, ChannelHandler handler);
void remove(ChannelHandler handler);
ChannelHandler remove(String name);
<T extends ChannelHandler> T remove(Class<T> handlerType);
ChannelHandler removeFirst();
ChannelHandler removeLast();
void replace(ChannelHandler oldHandler, String newName, ChannelHandler newHandler);
ChannelHandler replace(String oldName, String newName, ChannelHandler newHandler);
<T extends ChannelHandler> T replace(Class<T> oldHandlerType, String newName, ChannelHandler newHandler);
ChannelHandler getFirst();
ChannelHandler getLast();
ChannelHandler get(String name);
<T extends ChannelHandler> T get(Class<T> handlerType);
ChannelHandlerContext getContext(ChannelHandler handler);
ChannelHandlerContext getContext(String name);
ChannelHandlerContext getContext(Class<? extends ChannelHandler> handlerType);
void sendUpstream(ChannelEvent e);
void sendDownstream(ChannelEvent e);
ChannelFuture execute(Runnable task);
Channel getChannel();
ChannelSink getSink();
void attach(Channel channel, ChannelSink sink);
boolean isAttached();
List<String> getNames();
Map<String, ChannelHandler> toMap();
}
在DefaultChannelPipeline的ChannelHandler鏈條的處理流程為：
參考：
《Netty主頁》《Netty源碼解讀（四）Netty與Reactor模式》《Netty代碼分析》Scalable IO In JavaIntercepting Filter Pattern
posted on 2015-09-04 09:40
DLevin 閱讀(7683)
評論(0) 編輯 收藏 所屬分類:
Architecture 、
Netty