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,造成了费流量。

不信,你瞧:

<iq id="rosterset1" type="set">
<query xmlns="jabber:iq:roster">
<item jid="[email protected]" name="user"/>
</query>
</iq>
<presence from="[email protected]" to="[email protected]" type="subscribe"/>

上面是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)      把聊天室协议改为适合移动互联网的群聊

陌生人社交应用Whisper中文版“耳语”:

据小道消息,把xmpp协议中的xml改为json。

--------------------------------------------------------------------------------------------------------------------------

打开链接  app后端系列文章总目录 总目录 ,能查看本人发表过的所有原创“app后端”文章。

【作者】曾健生

【QQ】190678908

【app后端qq群】254659220

【微信公众号】 appbackend

【新浪微博】 @newjueqi

【博客】http://blog.csdn.net/newjueqi

如果您觉得文章对你有所帮助,欢迎打赏。

微信打赏:

支付宝打赏:

时间: 2024-12-18 19:58:27

27.app后端搭建聊天服务器的经历的相关文章

9.app后端选择什么服务器

对于很多刚入行的朋友来说,不清楚应该选择什么样的服务器提供商,是选择传统的IDC, 租用服务器租用机柜,还是选择现在很火的云服务器呢?在本文中,通过对比传统的IDC和云服务,简单阐述一下服务器的选择. 1.是选择传统的IDC还是云服务? 在app领域,经常会出现应用爆发的情况.如果真的出现了应用爆发,为了应对爆发的压力,最简单的方法就是升级服务器的硬件,加cpu啊,加内存. 在传统的IDC,要加cpu或内存,流程如下: 1.和客户经理商商谈所需硬件的价格 2.汇款过去,等IDC的财务确认 3.确

app后端设计--总目录 (转)

特此说明,我转载的!!! app后端设计(1)--api app后端设计(2)--xmpp的使用 app后端设计(3)--短信,邮件,推送服务 app后端设计(4)-- 通讯的安全性 app后端设计(5)-- 表情的处理 app后端设计(6)-- LBS app后端设计(7)-- 项目管理 app后端设计(8)-- 数据库分表 app后端设计(9)-- 动态通知 app后端设计(10)--数据增量更新 app后端设计(11)-- 系统架构 app后端设计(12)--图片的处理 app后端设计(1

手把手教你搭建LyncServer2013之安装持久聊天服务器(十三)

这一节中,不得不说的就是持久聊天服务器,为Lync  Server 2013新建的一个角色,在企业版中,需要单独部署,不能和其他服务器并置,WAC服务器也是如此,因在前面的拓扑中未定义持久聊天服务器,下面我们开始新建拓扑并进行发布了,在前端服务器上打开拓扑生成器,并下载当前拓扑信息 右键持久聊天池,新建持久聊天池 输入FQDN并选择"单计算机池" 我后续想测试下合规性,所以这里选了启用合规性,可以根据自己组织内部需求进行选择,输入显示名称 定义SQL Server存储,我这里仍然使用镜

app 后端技术

app 后端技术 一直以来工作的方向是web server,对app server没有什么了解.虽然没有接触过移动app开发,但对app后端技术还是挺有探索欲望的,app应用和web应用在前端的用户习惯不同,相信后端也会有很多不太一样的地方.开此文记录一些网上收集到的app后端技术体系,以备了解. 下面就app server在业务设计上通常需要考虑的几个方面: 1.api风格 如何设计一套合理且优雅的api接口集,可以参考Restful分格: api采用http(s)协议与前端通信: 每个uri

14.app后端如何设计api

app和后端的交互,一般都是通过后端提供的api实现.api的设计,估计很多刚进入app后端的小伙伴会一无头绪,不知道怎么入门.下面根据自己3年的app后端经验,总结出下几个api设计原则,给小伙伴参考. 1. 什么是api? 这个问题在以前发表的文章"7.app和app后端的通讯"中其实已经回答了,这里再重复一次. 相信大家都用过银行的柜员机(ATM)的查询余额,转帐,取款等操作. 当在柜员机取款的时候,我们输入要取款的金额,隔一会钱就出来了,如果因为有什么问题不能取款(例如超过取款

app后端架构设计(转)

(1)Restful设计原则 Restful风格:RESTfu设计原则,它被Roy Felding提出(在他的”基于网络的软件架构“论文中第五章).而REST的核心原则是将你的API拆分为逻辑上的资源.这些资源通过http被操作(GET ,POST,PUT,DELETE). 但现在看,一般的操作只有两种:GET ,POST. 这个设计原则最简单的应用就是根据object而不是页面来设计api.最开始的时候,app的一个页面需要什么数据,api就返回什么数据.结果随着app的UI不断改版,需要的数

1.用互联网的产品思维打造一本app后端的书

刚刚接触app后端,是做完adidas中国的官方商城的时候,那时不清楚app后端应该怎么架构,只能摸着石头过河,网络上只有一些零散的资料,遇到问题,只能不断地搜索,思考,务必找到解决问题的方法. 在从事app后端的3年里,亲手打造了两款社交app,现在也在日pv过亿的云端平台里从事研发工作,慢慢地对app后端的架构有了一些体会. 把自己的工作笔记发表在CSDN博客专栏"app后端技术架构"发表后,收到了很多网友的反馈,后来为了方便交流,就创建了"app后端技术"qq

app后端api设计【转】

博客:https://blog.csdn.net/newjueqi/article/details/44037011 app和后端的交互,一般都是通过后端提供的api实现.api的设计,估计很多刚进入app后端的小伙伴会一无头绪,不知道怎么入门.下面根据自己3年的app后端经验,总结出下几个api设计原则,给小伙伴参考. 1. 什么是api? 这个问题在以前发表的文章"7.app和app后端的通讯"中其实已经回答了,这里再重复一次. 相信大家都用过银行的柜员机(ATM)的查询余额,转帐

使用Angular和Nodejs搭建聊天室

一,利用Node搭建静态服务器 这个是这个项目的底层支撑部分.用来支持静态资源文件像html, css, gif, jpg, png, javascript, json, plain text等等静态资源的访问.这里面是有一个mime类型的文件映射. mime.js /** * mime类型的 map * @ author Cheng Liufeng * @ date 2014/8/30 * 当请求静态服务器文件的类型 html, css, gif, jpg, png, javascript,