非常喜歡這個(gè)組合，內(nèi)容轉(zhuǎn)自： http://www.blogjava.net/liuguly/archive/2014/05/21/413900.html?

netty是個(gè)高性能的網(wǎng)絡(luò)通信框架，該框架性能高異步事件驅(qū)動(dòng)模式，數(shù)據(jù)讀寫(xiě)更高效提供更全面功能強(qiáng)的ByteBuf緩沖。完全可以基于此框架：自定義cs協(xié)議通信

如果基于RMI框架，阿里的dubbo，facebook的thrift完全夠用了，但是有時(shí)候我們的客戶(hù)端不是java語(yǔ)言所寫(xiě)或者走自定義協(xié)議通信，比如流行的openfire，tigase，ejabberd等基于xmpp協(xié)議，它們底層的通信要么基于現(xiàn)有的成熟框架，比如mima或者netty，要么自己實(shí)現(xiàn)底層socket通信，而且還涉及分布式緩存，集群，分布式垃圾回收，異常處理，連接管理等等，這都不是一件容易的事情。所以遇見(jiàn)這種情況，仍然兩種選擇：1、基于現(xiàn)有成熟通信框架。2、自己寫(xiě)通信框架。

下面先說(shuō)下TCP/IP參考模型，它是OSI參考模型7層的簡(jiǎn)化 圖示：



看到上圖后，一目了然，基于HTTP協(xié)議的通信已經(jīng)很成熟了，大多數(shù)框架都支持包括netty，如果客戶(hù)端基于http協(xié)議，那么netty自帶的http相關(guān)處理類(lèi)完全足夠。

如果是自定義協(xié)議，那么走的是TCP/IP參考模型的傳輸層，可靠傳輸必然是TCP協(xié)議，舉例：
如果有以下自定義協(xié)議：
@@ID|info|time|xxx|xxx|$$\r\n

每天有上萬(wàn)客戶(hù)端發(fā)送的都是此類(lèi)消息，那么server的任務(wù)是保證數(shù)據(jù)安全、傳輸高效、維護(hù)連接、維護(hù)用戶(hù)session、支持高并發(fā)等等，那么綜合netty，寫(xiě)自己的業(yè)務(wù)，就能事半功倍了。
先給一個(gè)極其簡(jiǎn)單的架構(gòu)圖：




haproxy負(fù)載均衡
nettyServer提供服務(wù)
DB存儲(chǔ)數(shù)據(jù)

這是一個(gè)很簡(jiǎn)單的架構(gòu)，若擴(kuò)展
1：haproxy提供主從設(shè)備
2：nettyServer需維護(hù)共享數(shù)據(jù)塊安全，加同步或許會(huì)降低性能，或者針對(duì)該數(shù)據(jù)塊增加隊(duì)列機(jī)制，采用多線(xiàn)程守護(hù)模式編寫(xiě)代碼。
3：客戶(hù)端非常多，橫向增加nettyServer。
4：若客戶(hù)端數(shù)量級(jí)別非常之大，數(shù)據(jù)庫(kù)采用讀寫(xiě)分離主從庫(kù)，對(duì)業(yè)務(wù)進(jìn)行梳理劃分，讀和寫(xiě)在不同數(shù)據(jù)庫(kù)，DB將可橫向發(fā)展，最后可發(fā)展為大規(guī)模。
5：最后需對(duì)服務(wù)器節(jié)點(diǎn)再次劃分。
以上涉及細(xì)節(jié)會(huì)有很多

這種架構(gòu)適用于自定義協(xié)議，若用應(yīng)用層協(xié)議如http協(xié)議，架構(gòu)模樣又會(huì)不同

spring+netty+haproxy三人行組合