非常喜欢这个组合，内容转自：http://www.blogjava.net/liuguly/archive/2014/05/21/413900.html
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协议，架构模样又会不同