1 用户视图的IM

IM系统组成

用户账号
聊天的参与需要用户，所以需要有一个用户账号，用来给用户提供唯一标识，以及头像、昵称等可供设置的选项
账号关系
账号之间通过某些方式（比如加好友、互关等）构成账号间关系网
联系人列表
你的好友列表或聊天对象的列表。其中你可选择一个联系人进行聊天互动等操作
消息
在聊天互动这个环节产生了消息
聊天会话
你和对方的聊天消息记录就组成了一个聊天会话，在会话里能看到你们之间所有的互动消息

2 研发视图的IM

2.1 组成

客户端

用户收发消息的终端，内置的客户端程序和服务端进行网络通信，用来承载用户的互动请求和消息接收功能。

接入服务

为客户端提供消息收发的出入口，即网关层服务。

接入层避免业务可使用统一协议的header，body部分直接透传二进制，或把body的编码分委托给其他的编解码api。另外对于protobuf还不够紧凑的问题可以再gzip一下后再下推客户端。

发送的消息先由客户端通过网络给到接入服务，然后再由接入服务递交到业务层进行处理。

接入服务的功能：

保持连接

消息推送

当服务端有消息需要推送给客户端时，也是将经过业务层处理的消息先递交给接入层，再由接入层通过网络发送到客户端。

协议的编解码

编解码实际主要是为了节省网络流量，系统会针对传输的内容进行紧凑的编码（比如Protobuf），为了让业务处理时不需要关心这些业务无关的编解码工作，一般由接入层来处理。

session维护

session的作用是标识“哪个用户在哪个TCP连接”，用于后续的消息推送能够知道，如何找到接收人对应的连接来发送。

接入服务还负责最终消息的推送执行，即通过网络连接把最终的消息从服务器传输送达到用户设备。

业务处理服务

消息业务逻辑处理，比如消息的存储、未读数变更、更新最近联系人等。

存储服务

账号信息、联系人关系链，以及消息本身，都需服务端存储持久化存储。还有一些用户消息相关的设置，比如：用户可以设置不接收某些人的消息，还有附件。

服务端可以只是维护一个用于暂存消息和信令的离线buffer，至于存多久和产品需求以及监管需求相关。

即时消息可以放到MQ中，或者缓存中，使用数据抽取工具周期性的将数据提交服务器，进行持久化。服务器存储历史数据和近实时的数据。其实就是通过 MQ来异步化解耦消息存储逻辑。

作用

会话一方用户不在线，上线时进行消息推送
内容审查，监管，电子证据，法律要求
数据分析，舆情分析

外部接口服务

由于手机限制及资源优化的考虑，大部分App在进程关闭或长时间后台运行时，App和IM服务端的连接会被手机os断开。这样当有新的消息产生时，就没法通过IM服务再触达用户，因而会影响用户体验。

为让用户在App未打开或在后台运行时，也能接收到新消息，我们将消息给到第三方外部接口服务，来通过手机操作系统自身的公共连接服务来进行操作系统级的“消息推送”，通过这种方式下发的消息一般会在手机的“通知栏”对用户进行提醒和展示。常用的第三方系统推送服务：

苹果手机自带的APNs（Apple Push Notification service）服务
安卓手机内置的谷歌公司的GCM（Google Cloud Messaging）服务

但GCM服务在国内无法使用，为此很多国内手机厂商在各自手机系统中，也提供类似的公共系统推送服务，如小米、华为、OPPO、vivo等手机厂商都有相应的SDK。

接入服务和业务处理服务独立拆分原因：

接入服务作为消息收发的出入口，必须高可用
如果连接服务总不稳定：连不上或频繁断连，大大影响聊天流畅。
业务处理服务由于随产品需求迭代，变更非常频繁，随时有新业务需上线重启。
若消息收发接入和业务逻辑处理都在一起，势必让接入模块随业务逻辑的变更上线而频繁起停，导致已通过网络接入的客户端连接经常性地断连、重置、重连。
这种连接层的不稳定性会导致消息下推不及时、消息发送流畅性差，甚至会导致消息发送失败，从而降低用户消息收发的体验。

所以将“只负责网络通道维持，不参与业务逻辑，不需要频繁变更的接入层”抽离出来，不管业务逻辑如何调整变化，都不需要接入层进行变更，这样能保证连接层的稳定性，从而整体上提升消息收发的用户体验。

业务开发人员的角度看，接入服务和业务处理服务进行拆分有助于提升业务开发效率，降低业务开发门槛。

模块拆分后，接入服务负责处理一切网络通信相关的部分，比如网络的稳定性、通信协议的编解码等。这样负责业务开发的同事就可以更加专注于业务逻辑的处理，而不用关心让人头痛的网络问题，也不用关心“天书般的通信协议”了。

接入模块收到一个消息后，通过rpc或者mq来进行对接推送到业务模块。

业务模块下发消息给用户时，怎么知道用户处于接入模块的那一个实例服务（接入模块肯定是有多个实例同时运行的）
推送时，可以在用户上线时维护一个全局uid到接入网关的映射来做定向推送，对于超大群或直播互动场景可不区分某一个用户落在哪个接入网关，而是让所有网关获取后来下推连到本机用户。

IM特点

实时性

即时消息被广泛应用于各种社交、互动领域的基本前置条件：

如果通过微信聊天，对方半天才收到消息，基本上就是备胎不想再聊了
直播时，如果主播的互动消息房间里的粉丝要等很长时间才能收到，也很难让粉丝们有积极参与的欲望

可靠性

不丢消息
“丢消息”是互动中让人难以接受的Bug，某些场景下可能导致业务可用性差，甚至不可用的情况。比如直播间“全员禁言”的信令消息丢失，就可能导致直播室不可控的一些情况。
消息不重复
消息重复不仅会对用户造成不必要的骚扰和困惑，可能还会导致比较严重的业务异常，比如直播间“送礼物”的消息由于某种原因被重复发出，处理不妥的话可能会导致用户损失。

一致性

同一条消息，在多人、多终端需要保证展现顺序的一致性。

单聊场景
一致性是指希望发送方的消息发送顺序和接收方的接收顺序保持一致
一个群的某一条消息
希望群里其他人接收到的消息顺序一致
同一用户的多台终端
希望发送给这个用户的消息在多台设备上也能保持一致性。
多端同步的。收到消息一般先落db，然后写离线buffer。db全量，buffer定长或者按时间过期。redis和pika一般比较适合做离线buffer，mysql和hbase一般用于消息的db存储。

安全性

数据传输安全
数据存储安全
消息内容安全

教你微信IM即时消息系统的架构设计相关推荐

分布式发布订阅消息系统 Kafka 架构设计 - 目前见到的最好的Kafka中文文章
转自:http://www.oschina.net/translate/kafka-design 参与翻译(4人):fbm, 飞翔的猴子, Khiyuan, nesteaa 感谢这些同志们的辛勤工作, ...
Netty入门与实战:仿写微信IM即时通讯系统
转载自:Netty入门与实战:仿写微信IM即时通讯系统 Netty是互联网中间件领域使用最广泛最核心的网络通信框架,几乎所有互联网中间件或者大数据领域均离不开Netty,掌握Netty是作为初中级工程 ...
IM即时通讯系统源码，即时通讯系统开发架构
IM系统是一种即时通讯系统,可以让用户实时地发送和接收消息,支持文字.图片.语音等多种类型的消息.下面我们来介绍一下IM系统的架构设计和示例代码. IM系统的架构设计 IM系统的架构设计一般包括以下几 ...
新浪微博：大规模离线视频处理系统的架构设计
微博视频平台在4亿月活用户吃瓜嗨聊的高并发.大流量背景下,既要保证用户微博生产和消费体验,又要支持业务快速迭代,确保正确性.稳定性和高可用性.本次演将以微博视频大规模视频离线处理系统的架构设计为主题为 ...
Java生鲜电商平台-促销系统的架构设计与源码解析
Java生鲜电商平台-促销系统的架构设计与源码解析说明:本文重点讲解现在流行的促销方案以及源码解析,让大家对促销,纳新有一个深入的了解与学习过程. 促销系统是电商系统另外一个比较大,也是比较复杂的系 ...
7个不同的维度，详解秒杀系统的架构设计
今天我从 7 个不同的维度,讲讲秒杀系统的架构设计,主要知识点如下: Nginx + 前后端分离 + CDN 缓存 + 网关(限流+熔断) 集群的路由层 + Redis(缓存热点数据.分布式锁) MQ ...
阅读心得6：《首次公开！菜鸟弹性调度系统的架构设计》
本周阅读了老师推荐阅读的公众号:架构师中的推文<首次公开!菜鸟弹性调度系统的架构设计>,感想如下: 菜鸟裹裹是一款提供查快递.寄快递的应用软件,主要适用于全网包裹查询,支持淘宝.天猫.京东 ...
Java生鲜电商平台-电商会员体系系统的架构设计与源码解析
Java生鲜电商平台-电商会员体系系统的架构设计与源码解析说明:Java生鲜电商平台中会员体系作为电商平台的基础设施,重要性不容忽视.我去年整理过生鲜电商中的会员系统,但是比较粗,现在做一个最好的整 ...
一个小型的网页抓取系统的架构设计
一个小型的网页抓取系统的架构设计网页抓取服务是互联网中的经常使用服务.在搜索引擎中spider(网页抓取爬虫)是必需的核心服务.搜索引擎的衡量指标"多.快.准.新"四个指标中,多 ...

教你微信IM即时消息系统的架构设计