27.app后端搭建聊天服务器的经历

现在，聊天功能已经成了社交app的标配了。但是，众多web开发出生的程序员对聊天相关的服务的不了解，带来了很多开发上的困扰。在这篇文章中，根据下面3个方面，谈谈聊天服务。

1. 聊天服务的技术选型

2. 开发社交app中，实现聊天服务踩过的坑

3. 那些著名app的聊天服务

1. 聊天服务的技术选型

需要开发聊天服务，首先要选择用到的协议，现在，常用的聊天协议有：

（1） xmpp，一个基于xml的消息协议，被广泛应用于Gtalk,Facebook，但缺点也很明显，由于基于xml，会产生大流量。

（2） mqtt，IBM开发的即时通讯协议，一个简单的消息协议，需要自己实现加好友，群聊等IM常见的功能

（3）类ActivitySync，微信实现的协议，省流量，性能高，但由于是私有协议，IM的所有功能都需要自己实现。

Xmpp协议作为一个被广泛使用的消息协议，有大量的网络资料和成熟开源模块，例如在android和ios上，就很方便集成xmpp协议。IM作为一个复杂的系统，有方方面面需要考虑，使用成熟的协议，能帮助我们避免很多问题，提高了开发效率。

同时，xmpp协议的缺点也很明显，基于xml，造成了费流量。

不信，你瞧：

上面是xmpp协议添加好友的内容，看到了吗？这么简单的一个功能，用了多少字节！！！

综合上面所述，对于创业型的公司来说，如果需要在最短时间内实现聊天功能，除了使用环信，融云等第三方IM服务外，最好是选择xmpp协议。

现在主流的实现了xmpp的两个开源项目：

（1）Ejobberd，用erlang语言开发，成熟稳定，集群支持，支持多进程高并发。但由于它是基于小众的erlang，也造成了很高的开发成本，例如，想招个熟悉erlang同时也熟悉聊天服务的人，很难。

（2）openfire, 用java开发，成熟稳定，插件多，但是对内存要求高，并发低，集群支持差，单机的并发就十多万。

在创业公司里，我的建议是使用openfire，毕竟熟悉java的开发人员还是挺多的，而且在初期，也不会有太高的并发，等有钱有人后，再对聊天系统改造。

虽然，作为一名有理想有道德有职业尊严的后端工程师，想把聊天系统做好，但理想是美好的，现实是残酷的。创业初期的环境，决定了没法打造完善的系统，但最起码，使用openfire能先把聊天功能做出来。

2. 开发社交app中，实现聊天服务踩过的坑

在做第一个社交app中，使用openfire除了常规的聊天外，还需要实现两个功能：

（1）未读消息数

（2）保存聊天记录

由于当时不具备对openfire进行二次开发的能力（或者说是因为心存恐惧），采用了一个现在看起来无比傻的方案：

接收消息，App端是直接连接openfire服务器；发送消息，用php封装了相关发送消息的api，app端通过调用api来发送消息，在api层来处理”未读消息数”和” 保存聊天记录”。

实现”未读消息数”的方法：每次app打开或退出前，调用一个api标识该app是否在线并在redis中记录下来，在调用发送消息的api时，通过检测一个消息，判断是否未读消息（发送离线的消息就是未读消息）

实现” 保存聊天记录”的方法：在调用发送消息的api时，把发送的消息异步保存到数据库。

实现了上面两个技术方案，体会到为了解决一个问题引引入了无数的新问题是啥情况了。”未读消息数”功能简直是恶梦，数字根本不准，特别是遇上了app闪退，断网的情况下。这个功能必须要在openfire内部去实现，聊天服务器都有记录相关的用户在线状态的。

在做第二个社交app时，需要实现“发送给ios的离线消息，用apns推送”这个功能。我吸取了第一个社交app的教训，采用了开发openfire插件的方法，把所有发送给ios的离线消息在openfire内部截获下来，并用队列传送到apns系统中，愉快地解决了这个问题。最后，把这个插件开源，放到了我的github中（github.com/newjueqi/sendOfflineMsg）

3. 那些著名app的聊天服务

Whatsapp:

初期使用开源Ejabberd服务器，使用Erlang实现。接下来的许多年一直从事Ejabberd的重写和修改，包括从XMPP转换到内部开发协议、调整代码库以及重设计一些核心组件，对Erlang VM做了大量的修改以获得高性能。

陌陌：

最初的一年是使用了xmpp，一年后改为私有的协议。

环信：

对xmpp协议进行了改造：

（1）登录握手的改进

（2）心跳的改进

（3）文件传输

（4）在线状态的改造

（5）把聊天室协议改为适合移动互联网的群聊