【虎.无名】之Blog学习

“循证架构”一词虽是新创，但也可算是新瓶装老酒了。Rod用之来循证Spring等轻量级框架之优势、EJB之劣势。前一段做了个GPRS服务器的系统，也尝试了把“循证架构”的循证思路。竟然要循证，总得先列举下需求：

首先，服务器必须与GPRS发送设备进行通讯， 数据的接收、发送、检查链路状态等基本功能，还需要具体分析包文，组包等业务功能的处理。其次，工期很紧，风险分析中列为第一大风险。再者，服务器的稳定性、可靠性也是一大重点。最后，需要提供对服务器管理的接口。

手头也有些较为成熟的网络通讯的基础代码，拿来复用解决1，3问题也非难事，倒是4需要进行开发。不过早就听闻 Mina、Cindy等大名（下载Mina代码过程中反倒发现本文的主角QuickServer），于是就对这几个框架循证了一遍，寻找合适开发的网络通讯框架。

从功能上看，Mina、Cindy、QuickServer实现的功能也基本差不多，都是封装基本的网络IO操作，暴露事件接口供二次开发。 Mina需要继承IOHandlerAdapter类或ProtocolHandlerAdapter类，从该类中继承各事件方法实现业务操作。 Cindy也需要继承SessionHandlerAdapter具体类，跟Mina类似。QuickServer则需要实现接口 ClientEventHandler实现业务功能。这些类和接口提供的事件大致雷同：Connected，Closed，Received，Sent， Timeout等等。

Mina和Cindy使用了nio，而QuickServer则同时支持blockingIO和nio，需要进行配置选择（一个遗憾就 是QuickServer的nio模式下竟然不支持Timeout事件）。Mina实现中有一个很好的设计就是剥离IO层和Protocol层，作者的用意是想在IO层实现对IO的处理，在Protocol实现对业务的处理，很好的一个分层思想。QuickServer则是一个大杂烩，把各种IO处理封装 在 BasicClientHandler中，里面还混杂了blockingIO、NIO等操作。

额外功能上，Mina和Cindy都可以支持一个进程中开启多个服务端口进行不同处理，而QuickServer则不行。不过QuickServer提供了另外一个非常实用的功能-管理服务端口，通过其设定的一些指令查询服务器的状态、控制服务器等。此功能成为最后选择的最大优势。其他例如IP过滤的功能在QuickServer中只需要进行配置即可。

这次没对这三个服务器在性能上进行比较。以后再找机会完成:-)

从代码质量上来看，无疑Mina和Cindy占了上风，QuickServer的分层实在不咋样。Mina和Cindy有不少相似的地方。而QuickServer的目的与其有所不同，集成许多方便的功 能，甚至还加入数据库连接池的功能（感觉作者有点无聊了）。最后的循证其实还是选了个最实用的工具，的确减少不少的工作量。此后还遇到一些二进制的问题就 不表了。

LeonW最近发表的5篇文章

• 杂文-孰本孰末？ - June 6th, 2006