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

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