马蜂窝 IM 移动端架构的从 0 到 1

点击上方“马蜂窝技术”，关注订阅更多优质内容

移动互联网技术改变了旅游的世界，这个领域过去沉重的信息分销成本被大大降低。用户与服务供应商之间、用户与用户之间的沟通路径逐渐打通，沟通的场景也在不断扩展。这促使所有的移动应用开发者都要从用户视角出发，更好地满足用户需求。

论坛时代的马蜂窝，用户之间的沟通形式比较单一，主要为单纯的回帖回复等。为了以较小的成本快速满足用户需求，当时采用的是非实时性消息的方案来实现用户之间的消息传递。

随着行业和公司的发展，马蜂窝确立了「内容+交易」的独特商业模式。在用户规模不断增长及业务形态发生变化的背景下，为用户和商家提供稳定可靠的售前和售后技术支持，成为电商移动业务线的当务之急。

Part.1

设计思路与整体架构

我们结合 B2C，C2B，C2C 不同的业务场景设计实现了马蜂窝旅游移动端中的私信、用户咨询、用户反馈等即时通讯业务；同时为了更好地为合作商家赋能，在马蜂窝商家移动端中加入与会话相关的咨询用户管理、客服管理、运营资源统计等功能。

目前 IM 涉及到的业务如下：

为了实现马蜂窝旅游 App 及商家 IM 业务逻辑、公共资源的整合复用及 UI 个性化定制，将问题拆解为以下部分来解决：

1. IM 数据通道与异常重连机制，解决不同业务实时消息下发以及稳定性保障；

2. IM 实时消息订阅分发机制，解决消息定向发送、业务订阅消费，避免不必要的请求资源浪费；

3. IM 会话列表 UI 绘制通用解决方案，解决不同消息类型的快速迭代开发和管理复杂问题；

整体实现结构分为 4 个部分进行封装，分别为下图中的数据管理、消息注册分发管理、通用 UI 封装及业务管理。

Part.2

技术原理和实现过程

2.1 通用数据通道

对于常规业务展示数据的获取，客户端需要主动发起请求，请求和响应的过程是单向的，且对实时性要求不高。但对于 IM 消息来说，需要同时支持接收和发送操作，且对实时性要求高。为支撑这种要求，客户端和服务器之间需要创建一条稳定连接的数据通道，提供客户端和服务端之间的双向数据通信。

2.1.1 数据通道基础交互原理

为了更好地提高数据通道对业务支撑的扩展性，我们将所有通信数据封装为外层结构相同的数据包，使多业务类型数据使用共同的数据通道下发通信，统一分发处理，从而减少通道的创建数量，降低数据通道的维护成本。

常见的客户端与服务端数据交互依赖于 HTTP 请求响应过程，只有客户端主动发起请求才可以得到响应结果。结合马蜂窝的具体业务场景，我们希望建立一种可靠的消息通道来保障服务端主动通知客户端，实现业务数据的传递。目前采用的是 HTTP 长链接轮询的形式实现，各业务数据消息类型只需遵循约定的通用数据结构，即可实现通过数据通道下发给客户端。数据通道不必关心数据的具体内容，只需要关注接收与发送。

2.1.2 客户端数据通道实现原理

客户端数据通道管理的核心是维护一个业务场景请求栈，在不同业务场景切换过程中入栈不同的业务场景参数数据。每次 HTTP 长链接请求使用栈顶请求数据，可以模拟在特定业务场景 (如与不同的用户私信) 的不同处理。数据相关处理都集中封装在数据通道管理中，业务层只需在数据通道管理中注册对应的接收处理即可得到需要的业务消息数据。