原文：https://weibo.com/p/1001603950681689090105

 无论是IM消息通信系统还是客户消息系统，其本质都是一套消息发送与投递系统，或者说是一套网络通信系统，其本质两个词:存储与转发。由于看到最近一个月内业界有些公司的相关人员介绍了自己的IM系统，如

• 携程高级经理顾庆分享的携程异步消息系统初期架构

  
  图一

图二

  上两图显示了携程家的消息系统的初期架构，图一中的架构充分体现我朝IT开发人员"快糙猛"的开发风格，直接用mongodb作为消息队列，然后就把系统开发出来了，至图片2中才稍微见到一个常见IT系统的接口层。

• 京东咚咚初期架构

  
  京东咚咚初期架构图

  上图揭示了京东家的消息系统的初期架构，作者云下山巅揭示了其特点是“为了业务的快速上线，1.0 版本的技术架构实现是非常直接且简单粗暴的”，而且后台系统使用.net基于Redis就把一个IM系统开发出来了。
  两家系统的初期架构说明，一套消息系统对提升自家的服务质量是多么的重要，可以认为现代的服务型的互联网公司成长过程就是一套IM系统的进化史。
  也说明，一家的稍微初具实力的IT公司都可以自己很easy地搭建一套简单易用的即时通信系统。
  本文结合鄙人对IM系统的了解，也给出一套初具IM系统系统特点的消息系统模型

1 在线消息系统

  本文只考虑IM系统的在线消息模型，不考虑其离线消息系统(能够存储IM消息的系统)。根据个人理解其应有的feature如下：

• A 整个系统中Server端提供存储转发能力，无论整体架构是B/S还是C/S；
• B 消息发送者能够成功发送消息给后端，且得到后端地确认；
• C 接收端能否不重不漏地接收Server端转发来的没有超过消息生命周期和系统承载能力的消息；
• D 整个系统只考虑文本短消息[即限制其长度]；
• E 每条消息都有生命周期，如一天，且有长度限制如1440B【尽量不要超过一个物理frame】，只考虑在线消息的处理，无论是超时的消息还是超出系统承载能力的消息[如键盘狂人或者键盘狂机器人发出的消息]都被认为是"垃圾消息";
• F 为简单起见，不给消息很多类型，如个人对个人消息，群消息，讨论组消息等，都认为是一种群[下文用channel替代之，也有人用Room这个词]消息类型；
• G 为简单起见，这个群的建立与销毁流程本文不述及，也即消息流程开始的时候各个消息群都已经组建完毕，且流程中没有成员的增减；
• H 账户申请、用户鉴权和天朝独有的黄反词检查等IM安全层等暂不考虑；

根据以上系统特点，先给出一套稍微完备的IM系统的框架图：

IM系统框架图

  针对上图，我先给出各个模块的中文说明，然后分章节介绍这套系统的各个模块的职能，以及相关的系统流程。

• 1.系统名词解释

1 PC: 单机型客户端，如windows端和mac端等等；
2 Web/h5: 网页客户端；
3 Android： 手机移动端，取其典型Android端，当然也有ios端[但是考虑到各家开发App都是安卓客户端最先上系统新版本，故用Android代表之]；
4 broker：文本消息的有线或者无线接口端，考虑到携程采用了这个词，我也姑且先用之，它提供了消息的接收与投递功能；
5 Relay：图片/语音/视频 转发接口端，其后端可以是自家的服务也可以是第三方服务(如提供图片存储服务的七牛、提供云视频解决方案的腾讯云等)；
6 msg chat server：消息逻辑处理端；
7 Router: 在线状态服务端，存储在线的用户以及其登录的broker接口机；
8 Counter: 消息计数器，为每个text等类型的消息分配MSG id；
9 Msg Queue: 未读消息的msg id队列，存储每个client未接收的且未超时的且未超出队列大小的msg id集合；
10 Mysql/mongodb: 消息存储服务、用户资料数据、以及channel成员列表服务数据库，因为二者比较典型，所以取用了这个名字，当然你可以在其上部署一层cache服务；
11 Client：客户端层；
12 Interface/If(下文简称If)：服务接口层；
13 Logic：消息逻辑处理层，[这层其实应该有系统最多的模块]；
14 DB：存储层，存储了在线状态、消息id以及msg id队列和消息内容等；
15 http: 消息发送和接收协议，IM协议中一般理解为long polling消息处理方式，在web端多采用这种协议；
16 Websocket: 另一种消息发送和接收协议，在移动环境或者采用html5开发的系统多采用这种协议；
17 TCP: 另一种消息发送和接收协议，在环境或者采用html5开发的系统多采用这种协议；
18 UDP: 另一种消息发送和接收协议，某个不保证提供稳定消息传输服务的厂家采用的协议，也许也是用户最多使用的协议，它的优点是无论是无线还是有限环境下都非常快，又由于http/Websocket的基础都是tcp协议，UDP协议在环境拥塞情况下由于不提供拥塞控制等退让算法，反而会去争用网络通道，所以在网络复杂的特别是发生网络风暴的情况下它会显得更快^ _ ^ & ^ _ ^【呵呵哒】；
19 RPC: 一种远程过程调用协议，提供分布式环境下的函数调用能力；
20 Restful: 一种远程服务提供的架构风格，跟RPC比起来貌似更高级点；

• 2. 消息发送流程
     在介绍发送流程之前，先介绍几个基本概念

  • 2.1 pub/sub、UIN和session
       一个消息系统，从宏观上来说，就是一个PUB/SUB系统，有消息生成者publisher (or producer），有消息中转者broker，有消息处理者msg server，以及消息消息者subscriber （ or consumer）。消息消费者可以是一个人，也可以是一群人，在pub/sub系统之中producer&consumer一起构成了一个channel，或者称之为room，或者称之为group。
      无论是producer还是consumer，每个具体单位都要由系统分配给一个id，称之为UIN（名词来源于icq）。
      后端的if层的broker机器可以在全球或者某个区域分布多个，UIN依据dns系统可以得到if层所有的机器列表，如果dns层由于机器坏掉或者是被攻击时不能服务，那么客户端应该根据记忆[无论是上次成功登陆的机器还是被厂家内置的机器列表]知道某些机器的ip&port地址，然后根据测速结果来选择一个离其最近的broker。
      UIN在于broker之间进行一段时间内有效的会话服务，称之为一个session。这个session存活于一个长连接里，也可以横跨几个长连接或者短连接，即session自身依赖的网络链接是不稳定的。session有效期间内，Server认为UIN在线，session有效期内客户端要定时地给broker发送心跳包。本文认为的session可以是不稳定的，即session有效期内下发给客户端的消息可以丢失，但是可以通过一些其他手段保证消息被投递给客户端。

  • 2.2 发送流程
      消息的制造者[producer]一般是IM系统的最基本单元UIN[即一个自然人]，既然是一个自然人，就认为其发送能力有限，不可能一秒内发出多于一条的消息，即其消息频率最高为： 1条msg / s。高于这个频率，都被认为是键盘狂人或者狂躁机器人，客户端或者服务端应该具有拒绝给这种人提供服务或者丢弃其由于发狂而发出的消息。
      基于上面这个假设，producer发出的消息请求被称为msg req，服务器给客户端返回的消息响应称为msg ack。整个消息流程为：

* A client以阻塞方式发出msg req，req = {producer uin, channel name, msg device id, msg time, msg content}；
* B broker收到消息后，以uin为hash或者通过其他hash方式把消息转发给某个msg chat server；
* C msg chat server收到消息后以 {producer uin【发送者id】 + msg device id【设备id】+ msg time【消息发送时间，精确到秒】}到本地消息缓存中查询消息是否已经存在，如果存在则终止消息流程，给broker返回"duplicate msg"这个msg ack，否则继续；
* D msg chat server到Counter模块以channel name为key查询其最新的msg id，把msg id自增一后作为这条消息的id；
* E msg chat server把分配好id的消息插入本地msg cache和msg DB[mysql/mongoDB]中；
* F msg chat server给broker返回msg ack, ack = {producer uin, channel name, msg device id, msg time, msg id}；
* G broker把ack下发给producer；
* H producer收到ack包后终止消息流程，如果在发送流程超时后仍未收到消息则转到步骤1进行重试，并计算重试次数；
* I 如果重试次数超过两次依然失败则提示“系统繁忙” or “网络环境不佳，请主人稍后再尝试发送”等，终止消息发送流程。

  上面设计到了一个模块图中没有的概念：msg cache，之所以没有绘制出来，是因为msg cache的大小是可预估的，假设msg chat server的服务人数是40 000人，消息发送频率是1条/s，消息的生命周期是4 hour，消息长度是1kB。，那么这个cache大小 = 1k * 4 * 3600 * 40000 = 576 000 000kB，这个数字可能有点恐怖，如果是真实商业环境这个数字只会更小。其本质是一个hashtable。
  这个流程牵涉到一个比较重要的模块：Counter，这个模块其实都可以用Redis充当，怎么做你自己想^ _ ^。
  上面还有一个概念未叙述到：发送箱，它存储了所有本地发送出去的消息，其中没有服务端分配的msg id的消息都被认为是发送失败的消息，待用户主动尝试发送或者网络环境重新稳定后可以有客户端尝试重新发送流程。
  用户查看本地历史消息的时候，就要依据msg id把消息排序好展现给用户。至于用户发送过程中看到的消息可以认为是本地消息的一个cache，每个channel最多给他展现100条，这100条消息的排序要依照每条消息的发出时间或者是消息的接收时间[这个接收到的消息时间以消息到达本机时的本地时钟为依据]。当用户要查看超出数目如100条消息之外的消息，客户端要引导用户去走历史消息查看流程。

+ 2.3 消息状态部分流程
https://kb.cnblogs.com/page/541190/