Java通訊框架，有時也被稱為網絡服務器，其實就是封裝IO操作，并提供更高級的API接口。目前比較流行的框架就是：MINA、Cindy、QuickServer等。前段時間為了縮短開發時間，也在項目中加入了這些框架，從最開始使用QuickServer 1.4.7出現的報文接收不全異常；到用Cindy 2.4.4作為臨時過渡，到最后確定使用MINA 1.0.1，也經歷了一個艱辛而痛苦的時期。下面是整理的目前網上關于Java通訊框架比較好的文章，僅供大家參考。



循證架構之QuickServer篇

作者：LeonW

“循證架構”一詞雖是新創，但也可算是新瓶裝老酒了。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的目的與其有所不同，集成許多方便的功 能，甚至還加入數據庫連接池的功能（感覺作者有點無聊了）。最后的循證其實還是選了個最實用的工具，的確減少不少的工作量。此后還遇到一些二進制的問題就 不表了。



MINA is a good framwork

作者：fisher

Netty2的作者TrustinLee在為Apache LDAP項目所作的通訊基礎框架MINA中顯示了在通訊框架方面雄厚的實力，MINA是迄今為止我見過在java領域最好的通訊基礎件，看得出，他通過Netty2的經驗積累加上對ACE等傳統大型框架的理解之后，在制作MINA的一開始就確定了一個近似于完美的架構，同時，我在RoadMap中看到MINA與Spring、JMX和OSGI的結合計劃，雖然不知道什么時候能夠完成，但光看這個RoadMap已經很讓人激動了。

在MINA的服務綁定上，一開始就使用了serviceRegistry類這種中控型的注冊綁定方式，看得出他對OSGI有一定研究并已決意向其靠攏。

而借鑒于ACE的Accepter和Connector結構使得Session的使用更加方便，同時分為IO層和Protocol兩層的通訊基礎件也是使得使用變得很方便。

最后要提一下的是作者使用的FilterChain式結構來加載Filter，使得很多非通訊核心問題得以從基礎件中剝離出來，甚至連線程池模式都可以使用Filter來指定，雖然自己制作的線程池要想結合到MINA中需要一些額外的努力，但是仍然極大的增加了框架的靈活性。



MINA vs. QuickServer

作者：fisher

First for all, QuickServer is licensed as LGPL, and MINA as ASL.

從我個人角度而言，去年看過QuickServer的源碼，我在項目中采用的每一個框架或類庫都會做綜合評價，通常不會是一個原因導致我采用或沒有采用某個庫或框架，具體最后沒有采用QuickServer的原因忘記了，但是當時給我的總體感覺是，QuickServer雖然很方便，但不會讓我在架構上得到新的好處。而它最大的優點則是，支持JDK1.3（如果沒記錯的話），另外就是License的問題

下面看一看來自TrusinLee的評論：

Thank for the information about another network application framework.  I found a few differences:

Ø         QuickServer supports blocking mode.  (MINA supports only non-blocking mode, but you can make your operation block at your will.)

Ø         QuickServer provides GUI-based admin.  (MINA doesn't have one yet, but will have full JMX support soon, which is a standard.)

Ø         QuickServer uses java.util.logging.  (MINA uses SLF4J, which is a safe replacement of commons-logging.)

Ø         QuickServer uses its own XML settings.  (MINA provides Spring framework integration instead.)

Ø         QuickServer can specify maximum number of clients allowed.  (MINA can do this using a filter, but not implemented by default.  Of course, this will be implemented as an overload prevention filter.)

Ø         QuickServer team has one crew.  (MINA has three crews.)

Ø         QuickServer project started in 2003.  (MINA started in 2005.)

Ø         QuickServer has a difference event handler interface from MINA.  (You'll have to compare it by yourself.  IMHO, MINA has one simple enough handler which covers all QuickServer provides.)

Ø         QuickServer doesn't support UDP at all.  (MINA does)

Ø         QuickServer doesn't support client-side API at all.  (MINA does)

Ø         QuickServer integrated authentication and text protocol in its core.  (MINA didn't and they are considered as a cross-cutting concern that a filter should take care of.  IMHO, MINA is more extensible here.)



Cindy2.x比MINA性能好是可以預見的，原因在于MINA提供的ByteBuffer和FilterChain。

Cindy3.x源代碼我沒有看，所以不好評價。

關于MINA的效率問題，在MINA的maillist中也被提出，似乎有相應的issue正要被加入到它的Issue Tracker中。

Cindy3.x才剛剛開始，我認為多給Crmky一些時間，他一定可以將架構設計的更好。

MINA在設計上也有少許問題，他的IoFilterChain將FilterManager和FilterChain合而為一，在看其代碼的時候會覺得很亂。另外，為了保證包的順序，一個IoSession上的Handler在上一次read調用沒有返回前，是不會被再次調用的。我認為MINA的基礎架構在1.0和1.1版本之間還會變化，以適應新加入的configuration方式。另外，MINA會產生一些內存垃圾，我用profiler檢查過MINA，似乎是SocketIoProcessor中的某個計數器在不停的產生2byte的什么東東（記不太情了），不過似乎Trustin也注意到這個問題了，最近他說會在1.0release之后改善效率和內存的問題。

你可以到Crmky的blog上發帖子，看看他是否愿意提供一個Cindy3.X和MINA的對比。

總體來說，java的通訊框架設計并不特別注重效率，而追求架構上的優雅，當然，這也和java中本來能夠進行效率調優的手段就不多有關系，如果真要優化，可能還是需要使用JDK5.0以上提供的高效的內存操作，另外，據說在Linxu2.6內核以后，Mustang的NIO使用了Linux的epoll來實現select()，也許會對目前的IO效率有所幫助。