[14章]SpringCloud+Netty集群实战千万级 IM系统

kaudmands · · 259 次点击 · 开始浏览    置顶
这是一个创建于 的主题,其中的信息可能已经有所发展或是发生改变。

学习地址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协议时,多数情况下都会被喷; 开发者对所选格式有各自的偏好: 有的人或团队对某种或某几种格式有不一样的经验和技术积累,也促成了他们对某种或某几种协议的偏好。

有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

259 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传