在线聊天室的实现(4)--分布式聊天室的基础架构

 

前言:
　　前面都在讲述如何实现一个简单的聊天室, 并回顾了websocket的协议, 以及Netty 4.x的简单使用.
　　但如果仅局限于单机的聊天室实现, 那显然难登"大雅之堂". 借这个机会, 想尝试聊一下千万级聊天室的实现. 同时浅谈一下游戏中, 公共的聊天室资源服务定位.
　　本系列的文章链接如下:
　　1). websocket协议和javascript版的api
　　2). 基于Netty 4.x的Echo服务器实现 
　　3). 简易聊天室的实现 

架构演进:
　　这边讲述一下聊天室服务的思考过程.
　　• 单进程聊天室
　　优点是实现简单, 当然缺点也显而易见. 虽然现在的服务器, 衡量高并发连接的性能时, 言必称C1000K. 但实际上, 为了服务可靠稳定, 其经验的链接上限值, 往往限定在万级别. 甚至更低, 毕竟聊天室的连接是高活跃的.
　　• 以群分割的聊天室架构
　　聊天室服务, 多是以地域/兴趣来构建和划分. 同群用户只要在同一个进程即可, 但不同群的用户, 未必需要在同一个进程中. 因此基于这个假定, 以群来分割分布式聊天室集群.
　　整个聊天室服务, 拥有多个服务节点. 每个节点承担多个地域/兴趣群.
　　那用户如何进入指定的聊天室进程节点呢? 需要有一个专门的聊天室群管理节点, 用于路由决策, 同时管理扩容/缩容集群的过程.
　　

　　但是, 由于聊天的用户, 可能来自五湖四海, 直连聊天器节点, 每个用户的体验是有差异的. 为了能够让用户能够就近接入服务器节点, 又不破坏同群同节点的设定. 看来需要在chatserver之前, 再加入一层接入节点.
　　• 连接/业务分离的聊天室架构
　　接入层Connector维护与客户端的连接, 同时在特定的chatserver注册自己的状态. 这样既能让用户就近接入网络, 又能保持同群同节点.
　　该架构参考了网易的pomelo开源系统, 具体可参考如下链接: 分布式聊天服务器. 
　　
　　注: gate服务用于connector的智能选择(就近接入, 负载均衡). master用于chatserver节点的管理和房间的分配.
　　其优点描述如下:
　　负载分离：这种架构将承载连接的逻辑与后端的业务处理逻辑完全分离.
　　扩展性好: 用户数的扩展可通过增加connector进程数来简单实现. 房间/频道的扩展也是, 解决了理论上的频道/用户无限扩展.

进一步设想:
　　我非常认可接入/业务分离的架构, 其实其他很多服务的架构也是类似的形态.
　　当然我这边设定的聊天室是基于websocket来实现的. 而至今还有很多浏览器并不完全支持H5. 因此如果想要实现全浏览器的聊天室的话, 还是选用其他方式来借助, 比如借助Flash Socket, Comet技术.
　　由此, 我们简单的绘制架构如下:

　　

总结:
　　画图永远是简单的, 真正去操作实践才是最难的. 架构的发展, 也是工程经验的不断尝试, 积累的产物.

写在最后：
　　如果你觉得这篇文章对你有帮助, 请小小打赏下. 其实我想试试, 看看写博客能否给自己带来一点小小的收益. 无论多少, 都是对楼主一种由衷的肯定.