IM 内容分享(二)：单体架构IM系统
目录
前言
一、通讯协议
二、编程语言
三、数据库选型
四、 用户状态维护
五、方案
方案一、 定时器方案
方案二、时间轮方案
总结文中关键
前言
先直接抛出业务背景
有一款游戏，日活跃量（DAU）在两千左右，虽然 DAU 不高，但这两千用户的忠诚度非常高，而且会持续为游戏充值；为了进一步提高用户体验，继续增强用户的忠诚度，老板想要在该款游戏中引入聊天功能，同时探索和验证游戏用户对 IM 的需求和依赖度。IM 需要在两周后上线，如果你是这个 IM 项目的架构师，带着两名经验尚欠的程序员，你如何设计并落地该 IM 系统？
业务背景并不复杂，简单总结一下：
-
用户规模小：DAU 在两千左右，同时在线人数高峰期不到200；
-
开发人员少：一名架构师加两名程序员；
-
开发时间短：一周开发加一周测试，只有两周时间。
这种情况下，研发策略通常是：怎么简单就怎么做，怎么快就怎么来！
所以对该 IM 系统采用【单体架构】的方式进行设计，见下图。
前端是运行安卓系统和 IOS 系统的移动设备，游戏 APP 内嵌 IM 的客户端，由前端同学负责开发。
后端是 Server 节点，通过多进程多机器部署的方式，避免 “单点”；这个地方需要注意：【单体架构】并非 “单点架构” ，单体架构仍然是分布式架构的一种，通过集群的方式提供高可用和高吞吐的服务；对多个 Server 节点的访问通过 Nginx 来做反向代理；Server节点由后端同学负责开发。
存储部分包括数据库和缓存，数据库中分别创建 “消息表”、“离线消息表”、“联系人表” 和 “用户表”；缓存用来记录用户的在线信息；数据库和缓存由 DBA 同学负责维护。
单体架构的系统，最大的优势就是在项目前期开发简单、部署简单、测试简单、运维简单，开发同学几乎可以将所有的注意力全部放在业务逻辑上，实现真正的【快速落地】。
下面分别讨论一下关键的技术选型：前端与后端的通讯协议、后端的编程语言、数据库选型。
一、通讯协议
前端与后端之间的通讯协议，有四种选择，见下表。
IM 系统通常会选择 “长连接” 类型的协议；但是 WebSocket 协议因为刚推出不久，成熟度不高；TCP 协议属于传输层协议，较为复杂，如果没有丰富的 TCP 网络编程经验的话，在研发时间非常紧张的情况下，建议不要选择 TCP。
所以，这里我们选择最简单和最容易落地的协议—Http；对于编程经验尚欠的应届生来讲，Http编程也不会有太大难度。
分析到这里，相信大家肯定有这样的疑惑：Http 是短连接的无状态协议，如何进行消息的即时通讯呢？难道是通过客户端周期性的轮询访问吗？是的，同时在线人数只有几百的情况下，客户端周期性轮询是完全没有问题的，况且Server是多节点部署，完全可以 Cover 客户端周期轮询的压力。
二、编程语言
Server 端编程语言，也有四种选择（公司内部正在使用的技术栈），见下表。
C++、Java、PHP、Go 四门编程语言都有非常成熟的并发编程模型，这里我们选择公司和团队最熟悉的语言—Go，使用最熟悉的语言才会带来更高的编程效率和更快的问题解决速度。
三、数据库选型
数据库选型有三种选择，分别是关系型 SQL 数据库—MySQL、非关系型 NoSQL 数据库—MongoDB、已经新兴的NewSQL 数据库—TiDB，见下表。
在该单体架构的 IM 系统中，数据库需要提供强事务能力，来保证业务的完整逻辑；同时，数据库需要做到更低成本的运维；这里我们选择满足需求和容易运维的数据库—MySQL。
四、 用户状态维护
用户状态是什么状态呢？就是用户的 “在线” 和 “离线” 状态。很多同学可能会有疑惑，不是基于 “长连接协议” 的客户端才会有 “在线” 和 “离线” 这一回事吗？http 是无状态化的短连接，难道也有 “在线” 一说？是的，客户端在线与否，其实与通讯协议并不是强相关的，协议仅仅是传递数据的方式而已，甚至我们用 http 比用 tcp 更能精准表达出用户的状态。
通过 http 协议表达用户的在线状态，这一块技术实现应该非常成熟了；大家不妨思考一下，当我们登录163邮箱，把浏览器关闭，10分钟后再次访问 163 邮箱，是不需要重新登录的；这就是 http 实现用户在线状态的关键。
单体架构 IM 系统实现用户状态维护的核心逻辑，见下图。
-
登录
-
客户端向 server 端发送 http 登录请求；
-
因为客户端是嵌入在游戏 APP 中运行的，游戏会有登录逻辑，所以 server 只需要调用游戏侧的登录服务进行鉴权校验即可；
-
登录成功后，server 向 redis 中写入
-
后续，客户端访问 server 端其他所有接口时，server 读 redis ，如果对应的 session 不存在，说明用户未登录或登录已失效，需要重定向引导客户端重新登录。
-
心跳
-
客户端向 server 端周期性（2秒）发送 http 心跳请求；
-
server 延长 redis 中对应 session 的有效期，并修改 session 的 cmd 和 time 属性。
-
-
登出
-
客户端向 server 端发送 http 登出请求；
-
server 直接删除 redis 中对应的 session 数据。
-
在该单体架构的 IM 系统中，对用户状态的维护，就是对 redis 缓存中 session 数据的维护；在客户端访问 server 其他接口时，server 也会对 session 的有效期和 cmd、time 属性进行修改。
五、 点对点消息收发
消息收发是 IM 系统最核心的功能；基于 http 协议的单体架构 IM 系统的 “点对点消息收发“ 逻辑见下图。
-
消息收发
-
client1 向 server 端发送 http 消息请求；
-
server 端向数据库中分别写入 “离线表” 和 “云消息表”；（离线表和云消息表在同一个数据库中，通过数据库保证其事务性）
-
client2 向 server 端周期性（2秒）发送 http 拉取消息请求；（拉取消息复用心跳请求）
-
server 端从数据库 “离线表” 中读取 client2 相关记录后返回；
-
client2 再次发送拉取消息请求时，携带上次已经成功拉取的消息msgid，server 端删除 “离线表” 中相关记录。
-
整个消息的收发逻辑并不复杂，【发消息】和【收消息】动作完全由客户端触发，server 端被动响应即可；我们把这样的消息收发模型叫做 【信箱模型】。很明显，信箱模型的实现非常简单，缺点是消息的及时性不高，取决于客户端的心跳动作。
在整个消息的收发逻辑中，有两个细节点需要注意：“离线表” 通常在消息接收方离线时存储其消息，而在该实现逻辑中， server 端不管 client2 是否在线都会直接将消息持久化在 “离线表” 中， 这样处理的原因在于防止 clien2 没有及时拉取消息而造成消息丢失，提高了消息的可靠性；再一个，当 client2 从 “离线表” 中拉取消息时，不能立刻将其删除，必须在下次拉取时进行删除，这也是消息可靠性的体现。
五、 云消息
所谓 “云消息”，指存储在云端的消息，这样的消息可以被反复拉取，用来查看历史记录和实现消息漫游；在上述的消息收发逻辑中，每次客户端发消息时，server 端都会在 “云消息表” 中保存一条记录，所以客户端随时随地都能实现对云消息的读取，见下图。
-
云消息
-
client 向 server 端发送 http 拉取历史消息请求；
-
server 端从云消息表中读取相关记录返回。
-
五、方案
我们知道，http 是短连接协议，即一次客户端请求和服务端回复后，连接就断开了；在不更换协议（更换协议代价很大）的前提下，我们对其进行优化：服务端接收请求到回复客户端的时间，完全是可以控制的。描述到这里，很多同学应该已经非常清楚了，即：将短连接的 http 访问优化为 http 长轮询方式，通过 http 长轮询方式模拟出 “长连接” 的效果。http 长轮询见下图。
http-client 向 http-server 发出请求，http-server 拿到请求后，会立刻 hold 住该请求不返回；http-server 返回响应需要满足下面任何一个条件：
-
超过了一定时间，比如15秒，即超时了；（该条件减少了无效的 http 请求）
-
在超时之前产生了该 http-client 的数据。（该条件提高了消息的实时性）
http-client 收到响应后，会立刻再次向 http-server 发出请求，重复上述过程。
在单体架构 IM 系统的服务端，只需改造 http 部分，增加一个【http 长轮询】的插件即可大大提高消息的实时性，改造成本低，见效快！那么 【http 长轮询】插件应该如何实现呢？我们分别介绍 “定时器” 和 “时间轮” 两种实现方案。
方案一、 定时器方案
定时器方案非常容易理解，即针对每一个 http 客户端，当服务端接收到请求后，就开启 15秒（假设超时时间是 15秒）的定时器；15秒内若产生了消息，则立刻返回，否则就等15秒后超时返回。我们基于 Go 语言代码进行描述，如下。
chTimeout := make(chan struct{}, 1) //定义 “超时管道”go func() {time.Sleep(time.Second * POLLING_TIMEOUT) //定时器15秒超时fmt.Printf("INFO | [heartHandler] timeout")chTimeout <- struct{}{} //超时后，向“超时管道” 中写入元素}()select {case <-chTimeout: //从 “超时管道” 中读数据fmt.Fprint(w, "nonthing")case msg := <-chPushMsg: //从 “消息管道” 中读数据bs, _ := json.Marshal(msg)fmt.Fprint(w, string(bs))}
通过 Go 语言代码实现定时器方案非常简单！
在 Go 语言中有一个类似于 “IO 多路复用” 的用法，即通过 select-case 语句实现对多个管道的监听，哪个管道先有了数据，就执行哪个 case 语句。
基于此，我们定义了两个管道，一个是用于 15 秒定时器超时的 “超时管道”，一个是传输消息的 “消息管道”；“超时管道” 在一个独立的协程中，由 “定时器” 控制，超时后向 “超时管道” 写入一个元素数据 （即 struct{}，内容不重要，有数据即可表示超时）。select-case 语句非常巧妙地帮助我们实现了 要么15秒后超时返回，要么15秒内有消息即可返回的选择情况。
我们分析一下这个定时器实现方案：服务端需要针对每一次的 http 请求，分别启动一个 “定时器”；”定时器“ 在本质上是一个计算脉冲的计数器，达到设定值之后，通过软中断方式向 CPU 发起中断请求；当 http 客户端并发请求增大之后，服务端同时运行的 “定时器” 也会增多，于是软中断也增多，CPU 会经常性的停下手头工作去处理中断请求，CPU的工作效率会大大降低。那么，在 http 客户端数量不断增多的时候，如何进行优化呢？
下面的时间轮方案可以非常优雅地解决这个问题。
方案二、时间轮方案
在时间轮实现方案只需要一个每秒走一格的定时器即可，其核心思想是将同一秒内超时的所有客户端进行批量处理；见下图。
在该时间轮实现方案中，需要准备三个数据结构：
-
一个作为 “时间轮” 的循环队列，该时间轮的指针，每秒钟走一格，走一圈是一个完整的超时周期（图中超时时间是 13秒）；
-
一个用户维度的 map
-
一个时间轮时间维度的 map<时间轮时间， uid列表>，该 map 的 key 是时间轮的刻度，value 是这个时间刻度时所有发起 http 请求的 uid 列表。
当客户端发出 http 请求到服务端时，服务端将用户和当前时间刻度信息分别写入到上述的两个 map 中；在 13 秒超时之前，如果产生了用户的消息，则从上述两个 map 中删除用户和时间刻度信息；时间轮当前指针每走一格所指向的时间刻度，该时间刻度对应的用户列表就是 13 秒前发出 http 请求的用户列表，这些用户就是超时的客户端，需要超时返回，即返回空的 http 响应。
这样描述可能比较抽象，我们举一个例子：
-
假设当前时间轮指针指向了当前时间刻度 2，此时 有三个客户端分别是 101、102、103 发出 http 请求到服务端，服务端需要在 第一个 map 中分别写入 <101, 2> ， <102, 2>，<103, 3>，在第二个 map 中写入 <2, [101, 102, 103]>；
-
三秒后，时间轮指针指向了当前时间刻度 5，此时产生了用户 102 的消息，服务端需要先从第一个 map 中删除元素 <102, 2>（同时记录下时间刻度 2，方便后续操作），再从第二个 map 中删除 102 的记录，删除后的map为 <2, [101, 103]>；
-
九秒后，在时间轮指针指向当前刻度 2 时，此时第二个 map 中，key 是 2 的所有的uid列表，即 [101, 102]，就是所有超时的客户端列表，需要超时返回。
时间轮实现方案，通过一个定时器实现了对同一秒内超时的所有客户端的批量处理。
基于 http 长轮询方式实现的 IM 系统的单体架构中， server 节点还是无状态化的吗？所谓 “无状态化” 节点，是指进程在内存和硬盘中没有独立的数据；很明显，不同的 server 节点会 hold 住不同客户端的 http 请求，也就是不同的 server 节点中会存储不同客户端的数据， server 节点是有状态化的；此时，点对点的消息发送逻辑肯定需要进行调整。
大家可以先思考几个问题：
-
在 http 长轮询模式下， server 节点是有状态的，如何实现 server 节点的高可用呢？
-
客户端 x 发消息给 y，如果 x 和 y 访问的是不同的 server 节点，应该如何处理呢？
-
在 http 长轮询模式下，怎样判断消息接收方是否在线呢？
我们直接给出在 http 长轮询模式下，消息点对点的发送流程；以客户端 x 发消息给客户端 y 为例，如下：
-
客户端 x 向 server 端发送 http 消息请求；
-
server 首先将消息直接落库，分别写 “云消息表” 和 “离线表”；
-
然后 server 访问缓存，获取消息接收方 y 的在线状态，若 y 不在线，则整个流程结束；
-
如果消息接收方 y 在线，通过访问缓存获取 y 连接的是哪一个 server 节点；
-
如果 y 和 x 连接的同一个 server 节点，则 server 将该消息通过 http 长轮询返回给客户端 y；
-
如果 y 连接的是另一个 server 节点，此时需要当前 server节点将消息推送到目标 server 节点；
-
最后目标 server 节点将消息通过 http 长轮询返回给客户端 y。
在上述流程中，有两个地方需要特别注意：
-
客户端每一次发起 http 长轮询请求，相当于一次心跳，表示用户的在线状态，需要在缓存中记录客户端的在线数据；在 http 短轮询模式中，缓存中记录的 session 数据是 map
-
不管消息接收方在线与否，server 节点接收消息后，都需要写 “离线表”，这样设计的原因是为了提高消息的可靠性；因为即使用户 “在线”，在 http 长轮询返回时，客户端有可能接收不到消息，同时，在一次完整的 http 长轮询请求的间隙中，消息都是有丢失的可能的，所以持久化 “离线表” 是可靠性的保证；因此，在每一次 http 长轮询请求中，都需要访问 “离线表”，一是删除客户端已经收到的消息，二是从 “离线表” 中获取还未收到的消息。
在 http 长轮询模式下， server 节点是有状态的，那么其高可用如何保证呢？这个问题很容易解决：首先 server 节点肯定要集群化部署，然后由 反向代理 nginx 转发请求到 server ；nginx 通过配置实现客户端ip的会话保持，即将相同的客户端请求始终转发到固定的 server 节点；当 server 节点挂掉之后，nginx 将请求转发到其他 server 节点即可，服务仍将持续提供，只需变更缓存中客户端状态信息即可。
单体架构 IM 系统，从架构到设计，从协议到逻辑，其关键点都进行了 一 一 分析；最后，我们简单聊一下 server 的整体设计，server 通过 Go语言进行了实现，见下图。
-
主协程，不处理任何的业务逻辑，用于接收外部信号，如关闭程序等；
-
子协程，用于接收客户端连接，针对每一个客户端连接，子协程都会生成两个协程来维护该连接，即：每一条连接会有一个独立的协程组来维护（该协程组中有两个协程，一个用于读，一个用于写）；
-
连接管理器，实现对所有连接的管理，从连接中读取请求交由业务逻辑模块处理；
-
业务逻辑模块，实现核心的业务逻辑，包括：登录、登出、心跳、发消息等；
-
在线用户管理器，维护连接当前 server 节点所有的客户端；如果消息接收方在当前 server 节点，在线用户管理器通过 管道（chan）将消息传输给连接管理器中消息接收方的连接；
-
通讯协议，是公共协议定义，由【连接管理器】【业务逻辑模块】【在线用户管理器】共同引用。
关于 “每一条连接会有一个独立的协程组来维护”，是 Go 语言通用的高效网络编程模型，见下图。
-
客户端与服务端建立连接时，在服务端其实创建了一个 socket （即 fd 或句柄）；
-
然后为该 socket 生成一个协作组，该协程组包括两个协程：协程1-1，负责对 socket 进行读；协程1-2，负责对 socket 进行写；这两个协程，一个读一个写互不影响，高效协作；
-
当需要向客户端写消息时，不管是当前socket 请求的数据，还是从其他 socket 中读取的数据，必须通过协程组的管道（channel） 作为入口，然后协程1-2会从 channel 中读取数据然后写入到 socket 中。
总结文中关键
1、业务背景：用户规模小、开发人员少、开发时间短；
2、研发策略：怎么简单怎么做，怎么快怎么来；
3、 IM单体架构：前端（APP）+ Server + 数据库
单体架构最大的优势就是在项目前期开发简单、部署简单、测试简单、运维简单。
4、技术选型：
选择最简单和最容易落地的协议—Http，
选择公司和团队最熟悉的语言—Go，
选择满足需求和容易运维的数据库—MySQL。
5、“信箱模型” 由客户端主动向服务端发送请求，服务端被动响应即可；该模型实现简单，但作为 IM 系统来说，消息的实时性不高；
6、 基于 “信箱模型” 的单体架构 IM 系统，用户的在线状态通过在 redis 中保存有有效期的 session 来实现，并通过客户端的周期心跳实现 session 的持续有效；
7、 基于 “信箱模型” 的单体架构 IM 系统，发消息的逻辑是发送方向 “离线表” 和 “云消息表” 写入消息记录，收消息的逻辑是接收方从 “离线表” 中读取消息记录；云消息表用来实现消息的历史记录读取和消息漫游。
8、基于 http 周期轮询方式的 “信箱模型”，消息的实时性不高，可优化为 http 长轮询方式，通过 http 长轮询模拟出 “长连接” 的效果；
9、http 长轮询有两种实现方案：定时器方案和时间轮方案；
10、Go 语言实现的定时器方案，通过 select-case 语句实现了对多个管道的多路复用监听，达到了随时产生消息随时返回或超时返回的目的；定时器方案适用于客户端数量较少的情况；
11、时间轮方案实现了对同一秒内所有超时客户端的批量处理，该方案需要三个数据结构：循环队列，map
12、基于 http 长轮询方式实现的 IM 系统的单体架构中， server 节点是有状态的；
13、基于 http 长轮询发消息流程：消息到达 serer 后，先落库；若消息接收方在当前 server 节点，直接返回，否则需要将消息推送到目标 server 节点；
14、 基于 http 长轮询方式实现的 IM 系统，缓存中需要记录客户端连接的是哪一个 server 节点；
15、 在 http 长轮询模式中，不管消息接收方在线与否，server 节点接收消息后，都需要写 “离线表”；
16、 Go 语言通用的高效网络编程模型：每一条连接会有一个独立的协程组来维护；协程1-1，负责对 socket 进行读；协程1-2，负责对 socket 进行写。