netty是個高性能的網絡通信框架，該框架性能高異步事件驅動模式，數據讀寫更高效提供更全面功能強的ByteBuf緩沖。完全可以基于此框架：自定義cs協議通信
如果基于RMI框架，阿里的dubbo，facebook的thrift完全夠用了，但是有時候我們的客戶端不是java語言所寫或者走自定義協議通信，比如流行的openfire，tigase，
ejabberd等基于xmpp協議，它們底層的通信要么基于現有的成熟框架，比如mima或者netty，要么自己實現底層socket通信，而且還涉及分布式緩存，集群，分布式垃圾回收，異常處理，連接管理等等，這都不是一件容易的事情。所以遇見這種情況，仍然兩種選擇：1、基于現有成熟通信框架。2、自己寫通信框架。
下面先說下TCP/IP參考模型，它是OSI參考模型7層的簡化 圖示：
看到上圖后，一目了然，基于HTTP協議的通信已經很成熟了，大多數框架都支持包括netty，如果客戶端基于http協議，那么netty自帶的http相關處理類完全足夠。
如果是自定義協議，那么走的是TCP/IP參考模型的傳輸層，可靠傳輸必然是TCP協議，舉例：
如果有以下自定義協議：
@@ID|info|time|xxx|xxx|$$\r\n
每天有上萬客戶端發送的都是此類消息，那么server的任務是保證數據安全、傳輸高效、維護連接、維護用戶session、支持高并發等等，那么綜合netty，寫自己的業務，就能事半功倍了。
先給一個極其簡單的架構圖：
haproxy負載均衡
nettyServer提供服務
DB存儲數據
這是一個很簡單的架構，若擴展
1：haproxy提供主從設備
2：nettyServer需維護共享數據塊安全，加同步或許會降低性能，或者針對該數據塊增加隊列機制，采用多線程守護模式編寫代碼。
3：客戶端非常多，橫向增加nettyServer。
4：若客戶端數量級別非常之大，數據庫采用讀寫分離主從庫，對業務進行梳理劃分，讀和寫在不同數據庫，DB將可橫向發展，最后可發展為大規模。
5：最后需對服務器節點再次劃分。
以上涉及細節會有很多
這種架構適用于自定義協議，若用應用層協議如http協議，架構模樣又會不同
posted on 2014-05-21 00:21
朔望魔刃 閱讀(5959)
評論(0) 編輯 收藏 所屬分類:
netty