有过挪动端开发经验的开发者都深有体会：挪动端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万条并发音讯的状况下，精确评估服务端须要多少台服务器，如何部署。
- 其余：
还有设施推送的解决，何种机制可能保障不丢音讯，离线音讯如何解决，等等。这些都是必备而又非常复杂的性能点和技术要求，都须要采取正确的架构和策略能力实现。