A typical IM architecture might look like this
Whether it is IM message communication system or customer message system, its essence is a set of message sending and delivery system, or a set of network communication system, its essence is two words: store and forward.
Recommendation: If you are interested, the author of another article "a highly available, scalable, highly concurrent IM group chat architecture design practices," suitable for IM group chat architecture design reference.
In addition, the following articles on hands-on development of IM are also worth reading for your interest:
For beginners: develop an IM server from scratch (based on Netty, complete source), pick up the keyboard is dry: with my freehand development of a distributed IM system ", own development IM is so difficult?"
1 Initial architecture of Ctrip asynchronous messaging system
The above figure shows the early architecture of Ctrip's messaging system. The architecture uses mongodb as the message queue, and then develops the system. You can see the interface layer of a common IT system.
2 Jingdong Primary Architecture
The picture above reveals the initial architecture of the JD's messaging system, which is characterized by "Version 1.0 implementation is very straightforward and rugged for quick launch of the business", and the backend system was developed using. net based on Redis.
The initial architecture of the two systems shows how important a messaging system is to improve the quality of our own services. It can be said that the growth of a modern service Internet company is the evolution of an IM system.
Overall thinking for the programme
Combined with my understanding of IM system, this paper also gives a set of message system architecture model with the characteristics of IM system. In this paper, we only consider the online message model of IM system, not its offline message system.
According to individual understanding, its proper feature is as follows
A The server side of the whole system provides the ability to store and forward messages, regardless of whether the overall architecture is B/S or C/S; B messengers can successfully send messages to the back-end, and the back-end confirms that; C receivers can receive messages forwarded by the server side without any weight or leakage that do not exceed the message lifecycle and the system's carrying capacity; D entire system only considers text short messages [i.e. limit the length]; E each message has a life cycle, such as a day, and has a length limit such as 1440B [size of a frame as possible], and only considers the processing of online messages, whether messages that exceed the system's carrying capacity are time-out messages or messages that exceed the system's carrying capacity [such as messages sent by keyboard maniacs or keyboard crazies] are considered "junk messages"; F for the sake of simplicity, many types of messages are not given, such as personal messages, group messages, group discussion messages, etc., are considered to be a kind of group [where there is a substitution, someone uses the word Room]; G for simplicity, the group's establishment and destruction processes are not described in this article and the message process, that is to begin with all the groups whose messages have been completed, and there is no H.
2 Based on the characteristics of the above system, the framework diagram of a slightly complete IM system is given first.
3 Explanation of system terms
1 PC: 单机型客户端,如windows端和mac端等等;2 Web/h5: 网页客户端;3 Android:手机移动端,取其典型Android端,当然也有ios端[但是考虑到各家开发App都是安卓客户端最先上系统新版本,故用Android代表之];4 broker:文本消息的有线或者无线接口端,考虑到携程采用了这个词,我也姑且先用之,它提供了消息的接收与投递功能;5 Relay:图片/语音/视频 转发接口端,其后端可以是自家的服务也可以是第三方服务(如提供图片存储服务的七牛、提供云视频解决方案的腾讯云等);6 msg chat server:消息逻辑处理端;7 Router: 在线状态服务端,存储在线的用户以及其登录的broker接口机的id以及一些心跳包时间等数据;8 Counter: 消息计数器,为每个text等类型的消息分配MSG id;9 Msg Queue: 每个channel消息的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比起来貌似更高级点。
Three specific message sending processes
Before we introduce the message delivery process, we first introduce some basic concepts.
1 pub/sub, UIN and session
One messaging system, macroscopically, is a PUB/SUB system with message generator publisher [or producer], message forwarder broker, message