学习地址1:https://pan.baidu.com/s/1v9rQx_b6RQ6YLie5RJD7HA 提取码:jnph
学习地址2:https://pan.baidu.com/s/1U2fMRyT9Ay8F4fIStpeTiA 提取码:ikin
一、落地大型即时通讯(IM)系统架构及Netty聊天服务集群,精准适配企业级通讯技术需求
1、Netty 服务为用户提供文字/图片/表情/语音/视频内容收发,Netty 中的文件聊天资源存储至MinIO进行分布式保存,对用户黑名单进行拦截,驳回聊天消息,Netty 通过RabbitMQ异步解耦使得SpringCloud监听并进行离线消息存储或动态清清除机端口,Netty 结合RabbitMQ进行消息扩散,实现集群消息分发,Netty 结合Zookeeper实现分布式锁控制同一节点资源的并发读写
2、Netty 可以按需单机启动或者多节点集群化启动,集群节点结合Zookeeper实现注册与发现,根据心跳机制,自动断开不活跃用户设备,Netty 通过Jedis客户端根据算法计算并且动态分配Netty服务集群端口,Netty 与SpringCloud通过OkHttp进行同步远程调用,Zookeeper节点封装同时在线人数,进行累加&累减并且断连自动清除,微服务端通过手写负载均衡算法,按照最少人数节点提供给用户设备连接
3、微服务通过对Zookeeper监听,实现自动清除无效队列以及无效端口,不同手机设备可以获得坐标并且存储至Elasticsearch中,通过ES的geo坐标检索能力可以实现海量数据检索以及漂流瓶功能,微服务各个节点可以水平扩展为集群节点,内部通过OpenFeign进行服务间数据通信
二、netty功能特性
Netty 的分层很清晰:
核心层,主要定义一些基础设施,比如可扩展事件模型、通用通信 API、支持零拷贝的ByteBuffer缓冲区。
传输服务层,主要定义一些通信的底层能力,或者说是传输协议的支持,比如 TCP、UDP、HTTP 隧道、虚拟机管道等。
协议支持层,支持 HTTP、Protobuf、二进制、文本、WebSocket等一系列常见协议, 还支持通过实行编码解码逻辑来实现自定义协议。
三、详解IM消息的序列化协议选型
IM系统的客户端和服务器节点之间,需要按照同一-种数据序列化协议进行数据的交换。简而言之:就是规定网络中的字节流数据,如何与应用程序需要的结构化数据相互转换。
序列化协议主要的工作有两部分,结构化数据到二进制数据的序列化和反序列化。序列化协议的类型:文本协议和二进制协议。
常见的文本协议包括XML和JSON。文本协议序列化之后,可读性好,便于调试,方便扩展。但文本协议的缺点在于解析效率一般,有很多的冗余数据,这一点主要体现在XML格式上。
常见的二进制协议包括Protobuf、Thift, 这些协议都自带了数据压缩,编解码效率高,同时兼具扩展性。二进制协议的优势很明显,但是劣势也非常的突出。二进制协议和文本协议相反,序列化之后的二进制协议报文数据,基本.上没有什么可读性,很显然,这点不利于大家开发和调试。
因此,在协议的选择上,给大家的建议是:对于并发度不高的IM系统,建议使用文本协议,例如JSON;对于并发度非常之高,QPS在千万级、亿级的通信系统,尽量选择二进制的协议。
四、一套分布式IM即时通讯系统的技术选型和架构设计
分布式IM即时通讯系统本质上就是对线上聊天和用户的管理。
针对聊天本身来说,最核心的需求就是:发送文字、图片、文件、语音、视频、消息缓存、消息存储、消息未读、已读、撤回,离线消息、历史消息、单聊、群聊,多端同步,以及其他一些需求。
对用户管理来说,存在的需求包含:添加好友、查看好友列表、删除好友、查看好友信息、创建群聊、加入群聊、查看群成员信息、退出群聊、修改群昵称、拉人进群、踢人出群、解散群聊、填写群公告、修改群备注以及其他用户相关的需求等。
方案目标
在进行技术选型与总体架构设计之前,需要明确一个事项,就是系统无论采用哪种方案,采用哪种架构设计都需要明确这种方案的业务目标、技术目标和架构目标,并在研发过程中不断评估系统的总体性能表现,发现系统瓶颈并不断进行优化。
总体上,我们搭建和开发的分布式IM即时通讯系统,需要满足如下方案目标。
具体是:
1)业务目标:满足需求设计篇章中的各类需求场景;
2)技术目标:支持无限扩容,百万用户同时在线聊天;
3)架构目标:高并发、高性能、高可用、可监控、可预警、可伸缩,支持无限扩展。
五、IM的数据通信格式选型
IM应用开发的前期技术选型时,关于数据通信格式的选择,在同行的眼里,是同样是个极富争议话题。
精略分析一下,究其原因,大概在于以下几点:
可选择的协议或封装格式多种多样:
可选择的余地大:XMPP、Protobuf、JSON、私有2进制、MQTT、定格化XML、Plain text等等;
同一种格式并不能适用于大多数的场景:
不同的场景有同的考虑而协议的选择往往跟这挂钩在一起的,如:移动端IM或推送用XMPP协议时,多数情况下都会被喷;
开发者对所选格式有各自的偏好:
有的人或团队对某种或某几种格式有不一样的经验和技术积累,也促成了他们对某种或某几种协议的偏好。
有疑问加站长微信联系(非本文作者)
![](https://static.golangjob.cn/static/img/footer.png?imageView2/2/w/280)