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

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

下面先說下TCP/IP參考模型，它是OSI參考模型7層的簡化 圖示：



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

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

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




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

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

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