spring+netty+haproxy
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协议,架构模样又会不同
如果基于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协议,架构模样又会不同