NIO系列1：框架拆解

最近一年用NIO写了不少网络程序，也研究了一些开源NIO网络框架netty、mina等，总结了一下NIO的架构特点。

无论是netty还是mina它们都在java原生NIO的基础上进行了完善的封装，虽然细节有所不同，但总体架构思路一致，都大概划分出了以下几个组成部分：

- - transport：传输层的抽象

- - protocol： 协议codec的抽象

- - event model：统一事件模型

- - buffer：底层buffer封装

在完全屏蔽底层API的同时，对上层应用提供了自身的统一API接口。

框架进行黑盒封装的同时，再进行通用化的接口开放，带来的好处是统一化，但坏处是程序的透明度降低，抽象度提高，增加理解难度和实现难度。

下面说说每个部分的一些设计考量：

transport传输层抽象都是对java原生NIO API的封装，在这一层封装的程度在于框架的实现目标。例如mina立足于通用的网络框架，因此完全屏蔽了原生的API，提供了自身的统一接口，因为它不仅需要封装NIO的API还有一系列其他类型的IO操作的API，提供统一API接口。为了通用兼顾各类传输通道因此可能不得不暴露多余的API接口，使用方需甄别传输通道的不同，增加了理解难度。

protocol封装各类常用协议的codec操作，但目前这些网络框架的codec实现都与自身的API紧密绑定，降低了可重用性。

event model 事件模型的设计通常不能完全独立，例如java NIO本身的模型是事件驱动的，但传统阻塞型IO并非事件驱动，要兼顾二者通常要付出额外的代价和开销。

有一种说法是让异步IO同步化使用（因为同步化使用更简单，异步导致了业务处理的碎片化）到底对不对值得商榷？模型阻抗导致的代价和开销屏蔽在了黑盒中，也容易误导应用程序员对本该采用同步化处理的业务却滥用了异步化机制，并不会带来什么好处。

buffer 通常都用来配合底层IO数据流和协议codec使用，本身是否适合暴露给应用方取决于框架是否整合codec，因为codec本身带有业务性质，而纯粹的IO数据流处理使用的buffer则完全无需暴露给应用方。

以上简单说了下NIO框架各部分的设计考量，可以看出目前流行的NIO框架（netty和mina）都在走一条类似“瑞士军刀”的路线，集各种功能与一身（多种IO封装、协议封装），但你又很难把瑞士军刀上的某个刀片拆下来单独使用。

在实践中感觉，考虑从单一性、简洁性、重用性、组合性、透明性几个方面去设计原子化的IO组件也许更可取，更像是一种“工具箱”路线。

典型的事件驱动模型NIO框架组件交互图如下：

Acceptor： 负责监听连接事件负责接入

Processor：负责IO读写事件处理

EventDispatcher：负责事件派发

Handler：业务处理器

后面将通过一个系列文章来讨论一个原子化的NIO组件实现的细节及设计考量。