IM专题：模型分析（2）—开发模型

开发模型用于描述一个系统最本质或最关键的部分；在系统需求分析之后，软件设计之前，架构师心中需要有一个清晰的开发模型来指导自己，最终将软件一步一步进行落地。

目前，IM 系统以 “代理人模型” 为主（在上篇文章 IM专题：模型分析（1）—IM运行模型 中有分析），这种模式的 IM 系统的开发模型应该是怎样的呢？大家可以这样来思考，如果自己负责从 0 到 1 研发一个 IM 系统，最关键的部分是什么呢？

这需要我们眯起眼看问题，忽略掉细节后，来进行抽象思考。很多读者认真学习完前面的文章IM专题系列合集后，发私信说：“IM 其实很简单，本质上就是一个数据库应用程序，再加上一个长连接”，个人认同这种看法。 IM 系统的开发模型，见下图。

即：IM 系统 = 生产系统 + 存储系统 + 订阅系统。

存储系统解决 IM 的用户、消息（点对点消息、群消息、系统消息等）、联系人（用户联系人、群联系人、系统联系人等）等数据通过怎样的模型进行存储的问题，以方便大数据量的读写和扩展。

生产系统解决客户端消息如何传输到服务端并写入到存储系统中的问题；这一部分非常简单，由客户端主动触发，服务端被动响应即可，可以通过长连接传输数据，也可以通过短连接传输。

订阅系统解决服务端的消息如何传输到客户端的问题；这一部分是重点，玩法多样，可探讨的点很多；“订阅” 一词表达出服务端的消息需要向客户端做定向传输，张三发消息给李四，只能李四来接收，王五是不能接收的；当然，在 IM 中，“订阅” 是一个隐形行为，不需要通过接口显示调用。

这就是 IM 系统的开发模型，将 【生产系统】【存储系统】【订阅系统】充分理解之后，IM 系统最核心的问题就解决了，此时可以有条不紊地逐步将细节进行落实即可。

IM 系统的开发模型，同样适用于 “注册中心系统”、“配置中心系统”、“MQ 系统” 等，我们在后续其他专题文章中逐步进行分析。

订阅系统解决服务端的消息是如何传输到客户端的，常见的解决方案有三种，我们也分别抽象出了三个模型，即：信箱模型、电话模型和BP机模型。

一、信箱模型

信箱模型，也叫做 pull 模型，见下图。

信箱模型中，客户端向服务端发出数据请求，服务端从对应用户的 “信箱” 中拿到数据后回复客户端，不过大部分情况下，客户端可能只拿到一个空的回复。“信箱” 一词，表达出不同的用户在服务端有自己独立的信箱存储，故而名为信箱模型。

信箱模型中，动作由客户端触发，服务端只管实现接口和被动响应即可，由客户端对结果负责；信箱模型在单体架构的消息收发逻辑中分析过（见 IM专题：单体架构IM系统（2））。

信箱模型在落地实现时，可以采用短连接协议 HTTP，也可以采用长连接协议 TCP；该模型的优点是落地实现非常简单，但是服务端的消息传输到客户端的及时性不高，同时因为客户端多次无效轮询也会造成资源的浪费。

二、电话模型

电话模型，也叫做 push 模型，见下图。

电话模型中，服务端将消息直接推送到客户端，客户端收到后向服务端回复确认；这种方式没有无效的数据传输，服务端拿到消息后，直接向客户端做定向推送，就好像服务端存有客户端用户的电话号码一样可以准确定位，故而名为电话模型。

电话模型中，动作由服务端触发，客户端收到消息后，回复确认即可，由服务端对结果负责；电话模型在分层架构的消息收发逻辑中分析过（见 IM专题：分层架构IM系统（12）—消息收发逻辑实现）。

电话模型在落地实现时，通常采用长连接协议 TCP；该模型的优点是服务端的消息传输到客户端的及时性非常高，也不存在无效传输和资源浪费，但是电话模型实现时复杂度较高，因为服务端要存储所有客户端的连接句柄，大数据量推送时要解决高负载问题和推送失败后的异常处理，毕竟服务端是对结果负责的。

对比信箱模型和电话模型，优缺点正好相反，那么第三种模型则往往集其优势于一体。

三、BP机模型

BP机模型，是 push/pull 结合的模型，见下图。

BP机模型中，当服务端产生消息时，首先通知客户端，对服务端来讲这是一个 push 的动作；然后客户端向服务端发起数据请求，服务端获取数据后，回复给客户端，对客户端来讲这是一个 pull 的动作。大家是否记得九十年代的 BP 机，手拿 BP 机的人当收到寻呼后，根据寻呼内容进行回电，而客户端就充当了这样的一个角色，故而该模型命名为 BP 机模型。

BP机模型中，总共是三次交互，但是消息的及时性很高，中间没有任何无效的数据传输；服务端产生消息后，只向客户端推送一个体积非常小的 “通知包” 即可，没有复杂逻辑，然后在业务逻辑方面向客户端提供接口，被动响应即可，所以在落地实现时非常简单。

简单总结一下就是：BP机模型落地简单，消息及时性也高。在目前很多订阅模型的系统中，大都采用 BP 机模型方式进行落地，BP 机模型落地时可以采用多种不同方式的协议组合。

1、 http long pull + http

大家所熟知的主流配置中心系统 Apollo，通过 BP 机模型方式客户端从服务端获取更高版本的配置数据；首先服务端通过 http long pull 即 http 长轮询方式通知客户端有新的配置项产生，然后客户端通过 http 协议请求服务端获取到新的配置项数据。

2、tcp + http

有一款很流行的 IM 系统，也是通过 BP 机模型方式客户端从服务端获取新消息；服务端收到新的消息后，通过 tcp 协议通知到接收方客户端，然后客户端通过 http 方式向服务端拉取所有的消息的内容（未见到该 IM 系统的源码，不方便描述其产品名称）。

3、tcp + tcp

大名鼎鼎的分布式协调系统 zookeeper，通过 BP 机模型方式实现了监听机制和数据传输；当客户端在服务端创建节点并添加监听后，在该节点数据有变动时，服务端首先通过 tcp 连接通知到客户端，然后客户端仍然是基于该 tcp 连接向服务端请求节点的最新数据，服务端计算后进行返回。

最后，总结文中关键：

1. IM 系统的开发模型，即：IM 系统 = 生产系统 + 存储系统 + 订阅系统；
2. 订阅系统有三种实现方案，即：信箱模型、电话模型、BP 机模型；BP 机模型集信箱模型和电话模型的优势于一体；
3. BP 机模型在落地实现时，有三种常用协议方式组合：（1）http long pull + http： 即通过 http long pull 推送通知， 基于 http 拉取数据；（2）tcp + http：即通过 tcp 推送通知，基于 http 拉取数据；（3）tcp + tcp：即通过 tcp 推送通知，基于 tcp 拉取数据。

作者：棕生 | 来源：公众号——架构之魂