1、前言

有过移动端开发经历的开发者都深有体会：移动端 IM 的开发，与传统 PC 端 IM 有很大的不同，尤其无线网络的不可靠性、移动端硬件设备资源的有限性等问题，导致一个完整的移动端 IM 架构设计和实现都充满着大量的挑战。本文将简述移动端 IM 最重要的架构设计和通信协议选择方面的坑点，希望为 IM 开发者同行带来些许启发。

2、学习交流

移动端 IM 开发推荐文章：《新手入门一篇就够：从零开发移动端 IM》

3、概述

移动互联网时代的来临促使我们所有的开发者都要从用户视角出发，基于某一特定场景来创建应用，满足用户需求。通常，在这些应用中，沟通环节都是必不可少的。这就要求创业者不仅要花时间和精力来琢磨用户在某一特定场景下有何痛点需求，琢磨如何解决这一需求，并且可能还要花费更多的精力和时间来解决产品中“沟通”这一技术节点。

而要解决沟通问题，就需要一套 IM 系统（而且肯定要支持移动端）。做为 IM 开发者或即将成为 IM 开发者的技术人员，IM 的价值和重要性不言自明。但从技术实现来说，这并不容易。当然，假设你有 100 个用户，什么都是容易的，但是假设你有了 100 万、1000 万甚至 1 亿的用户，再简单的技术节点解决不好，都会成为灾难，何况 IM 系统（尤其是移动端的 IM 系统）还是存在许多技术难点和坑点的。

4、有关移动端 IM 通信协议的坑

其次，我们再看一下 IM 协议如何选型。通常 IM 采取的协议有 xmpp、mqtt、protobuf 等数据通信私有协议，我们来逐一分析他们的优缺点。

1. XMPP 协议：

优点：基于 xml 协议，容易理解，使用广泛，易于扩展。

缺点：流量大，在移动终端也耗电。交互过程复杂。多被 pc 时代的产品使用，不适合移动时代的 IM 产品，即使我们基于 xmpp 进行改进，简化握手过程，改进文件传输机制，但是它的基因决定了如何改进，他都不适合移动互联网时代的 IM 产品。就像凤姐无论怎么整容，也变成不了高圆圆一样。

2. MQTT 协议：

优点：适配多平台。

缺点：协议简单，但是需要自己扩展好友，群组等功能。

3. 私有协议：

优点：随心所欲，自己定义，流量小。

缺点：工作量巨大，扩展性差，需要考虑全面。

4. Protobuf 协议：

优点：非常小、非常快、非常简单，一条消息数据用 Protobuf 序列化后的大小是 JSON 的 1/10、XML 格式的 1/20、是二进制序列化的 1/10。

缺点：不能表示复杂的数据结构，但是对于 IM 来讲，已经足够。强烈推荐此协议。

补充 1：强列建议使用 Protobuf，理由如下

灵活、高效：灵活（方便接口更新）、高效（效率经过 google 的优化，传输效率比普通的 XML 等高很多）；

易于使用：开发人员通过按照一定的语法定义结构化的消息格式，然后送给命令行工具，工具将自动生成相关的类，可以支持 java、c++、python 等语言环境。通过将这些类包含在项目中，可以很轻松的调用相关方法来完成业务消息的序列化与反序列化工作。

语言支持：原生支持 c++、java、python 等多达 10 余种语言。

补充 2：Protobuf 主要适用于

需要和其它系统做消息交换的，对消息大小很敏感的。那么 protobuf 适合了，它语言无关，消息空间相对 xml 和 json 等节省很多。

小数据的场合。如果你是大数据，用它并不适合。

项目语言是 c++、java、python 等，因为它们可以使用 google 的源生类库，序列化和反序列化的效率非常高。其它的语言需要第三方或者自己写，序列化和反序列化的效率不保证。

总体而言，Protobuf 还是非常好用的，被很多开源系统用于数据通信的工具，在 google 也是核心的基础库。

5、移动端 IM 客户端的坑

最后，我们再来了解一下移动端有哪些难点需要解决。

1. 流量：

采取哪种协议、图片缩略图、附件的压缩三点决定了流量的大小。

2. 耗电：

(1)流量越小，耗电越低。(2)心跳策略，减少心跳次数，耗电量就会降低。

3. 心跳时长：

wifi，2G，3G，4G，移动、电信、联通,不同网络，不同运行商，NAT 失效时间不一样，因此心跳的时间也就不一样。

4. 网络连接：

cmnet 和 cmwap 下连接处理机制。

5. 网络不稳定：

移动端最大的特点就是网络不稳定，在不稳定的网络状态下，如何保证消息以最快的速度到达？如何避免重联风暴？这些既需要从整体架构考虑，也需要在移动端采取巧妙的策略加以避免。

6、移动端 IM 架构设计的坑

首先，来看移动端 IM 架构设计需要考虑的问题。

1. 连接器的设计：

连接器主要用来管理客户端的长连接。目前最好的连接器单台 8G8 核的服务器可以做到 70 万—100 万的连接，而某些开发者只能做到 4000 左右的连接，相差好几个数量级。这里的奥妙在哪里呢？

2. 中间件的设计：

是否采用通讯中间件？通讯中间件的好处有哪些？如果不采用中间件，连接器和逻辑服务器的连接关系如何管理呢？

3. 逻辑服务器：

逻辑服务器通常简单一点，主要是根据业务逻辑进行最小粒度的划分即可。但是即便如此，还是有很多的开发者把看似相关实则不相关的逻辑放在一起，如把鉴权和 message 服务器放在一起。

4. 状态服务器：

状态服务器主要管理用户在线、离线的相关状态，需要采取中心节点的方案，否则状态就会不同步。这里主要需要考虑状态服务器所对应的数据存储机制，如何进行写操作，如何进行读操作？以便最大的提高状态服务器的处理能力和响应速度。

5. 数据库的设计：

数据库的设计是最难的，也是做大的瓶颈。因为无论对于 sql（关系型）数据库还是 nosql（非关系型）数据库，都有读写处理的极限，那就需要考虑数据库如何分区（根据什么原则、什么操作、哪些用户访问哪个节点上的数据库）。同时又需要考虑每个原子操作（如登陆）需要读哪些库，写哪些库。只有这些指标明确了，你才能在假设有 100 万并发用户，100 万条并发消息的情况下，准确评估服务端需要多少台服务器，如何部署。

6. 其他：

还有设备推送的处理，何种机制能够保证不丢消息，离线消息如何处理，等等。这些都是必备而又非常复杂的功能点和技术要求，都需要采取正确的架构和策略才能实现。

7、结语

以上难点和坑点草草记录下来也不过千把字，但是真正要解决这些问题并达到生产应用标准，却要不知道花费多少日日夜夜、敲下多少行代码，恐怕也只有真正做过 IM 的开发者才有比较深刻的体会。

咨询热线：+86 400-966-9672

官网：  https://www.workplus.io