有过挪动端开发经验的开发者都深有体会：挪动端 IM 的开发，与传统 PC 端 IM 有很大的不同，尤其无线网络的不可靠性、挪动端硬件设施资源的有限性等问题，导致一个残缺的挪动端 IM 架构设计和实现都充斥着大量的挑战。
挪动互联网时代的降临促使咱们所有的开发者都要从用户视角登程，基于某一特定场景来创立利用，满足用户需要。通常，在这些利用中，沟通环节都是必不可少的。这就要求创业者不仅要花工夫和精力来推敲用户在某一特定场景下有何痛点需要，推敲如何解决这一需要，并且可能还要破费更多的精力和工夫来解决产品中“沟通”这一技术节点。
而要解决沟通问题，就须要一套 IM 零碎（而且必定要反对挪动端）。做为 IM 开发者或行将成为 IM 开发者的技术人员，IM 的价值和重要性不言自明。但从技术实现来说，这并不容易。当然，假如你有 100 个用户，什么都是容易的，然而假如你有了 100 万、1000 万甚至 1 亿的用户，再简略的技术节点解决不好，都会成为劫难，何况 IM 零碎（尤其是挪动端的 IM 零碎）还是存在许多技术难点和坑点的。
无关挪动端 IM 通信协议的坑
其次，咱们再看一下 IM 协定如何选型。通常 IM 采取的协定有 xmpp、mqtt、protobuf 等数据通信公有协定，咱们来逐个剖析他们的优缺点。
- XMPP 协定：
长处：基于 xml 协定，容易了解，应用宽泛，易于扩大。
毛病：流量大，在挪动终端也耗电。交互过程简单。多被 pc 时代的产品应用，不适宜挪动时代的 IM 产品，即便咱们基于 xmpp 进行改良，简化握手过程，改良文件传输机制，然而它的基因决定了如何改良，他都不适宜挪动互联网时代的 IM 产品。就像凤姐无论怎么整容，也变成不了高圆圆一样。
- MQTT 协定：
长处：适配多平台。
毛病：协定简略，然而须要本人扩大好友，群组等性能。
- 公有协定：
长处：得心应手，本人定义，流量小。
毛病：工作量微小，扩展性差，须要思考全面。
- 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 也是外围的根底库。
挪动端 IM 客户端的坑
最初，咱们再来理解一下挪动端有哪些难点须要解决。
- 流量：
采取哪种协定、图片缩略图、附件的压缩三点决定了流量的大小。
- 耗电：
(1) 流量越小，耗电越低。(2) 心跳策略，缩小心跳次数，耗电量就会升高。
- 心跳时长：
wifi，2G，3G，4G，挪动、电信、联通, 不同网络，不同运行商，NAT 生效工夫不一样，因而心跳的工夫也就不一样。
- 网络连接：
cmnet 和 cmwap 下连贯解决机制。
- 网络不稳固：
挪动端最大的特点就是网络不稳固，在不稳固的网络状态下，如何保障音讯以最快的速度达到？如何防止重联风暴？这些既须要从整体架构思考，也须要在挪动端采取奇妙的策略加以防止。即时通讯聊天软件开发能够征询蔚可云。
挪动端 IM 架构设计的坑
首先，来看挪动端 IM 架构设计须要思考的问题。
- 连接器的设计：
连接器次要用来治理客户端的长连贯。目前最好的连接器单台 8G8 核的服务器能够做到 70 万—100 万的连贯，而某些开发者只能做到 4000 左右的连贯，相差好几个数量级。这里的奥秘在哪里呢？
- 中间件的设计：
是否采纳通信中间件？通信中间件的益处有哪些？如果不采纳中间件，连接器和逻辑服务器的连贯关系如何治理呢？
- 逻辑服务器：
逻辑服务器通常简略一点，次要是依据业务逻辑进行最小粒度的划分即可。然而即便如此，还是有很多的开发者把看似相干实则不相干的逻辑放在一起，如把鉴权和 message 服务器放在一起。
- 状态服务器：
状态服务器次要治理用户在线、离线的相干状态，须要采取核心节点的计划，否则状态就会不同步。这里次要须要思考状态服务器所对应的数据存储机制，如何进行写操作，如何进行读操作？以便最大的进步状态服务器的解决能力和响应速度。
- 数据库的设计：
数据库的设计是最难的，也是做大的瓶颈。因为无论对于 sql（关系型）数据库还是 nosql（非关系型）数据库，都有读写解决的极限，那就须要思考数据库如何分区（依据什么准则、什么操作、哪些用户拜访哪个节点上的数据库）。同时又须要思考每个原子操作（如登陆）须要读哪些库，写哪些库。只有这些指标明确了，你能力在假如有 100 万并发用户，100 万条并发音讯的状况下，精确评估服务端须要多少台服务器，如何部署。
- 其余：
还有设施推送的解决，何种机制可能保障不丢音讯，离线音讯如何解决，等等。这些都是必备而又非常复杂的性能点和技术要求，都须要采取正确的架构和策略能力实现。