智联卓聘 卓聘聊聊(IM)开发实践

1.  卓聘IM开发背景

   　智联卓聘是智联旗下高端人才招聘平台，成立快4年多，业务增涨每年以100%速度增涨快，同时对产品和研发速度都比较高。

 　 2015年提出IM开发，主要用于后选人与猎头及时交流，降低后选人与猎头沟通成本。我们首先考虑就是网上各种IM的云平台，而这些平台都有一个问题，聊天记录管理上有着各种限制和不方便，所以我们决定自己去完成一个。

　　

2.  IM 技术选型

　　前期主要是PC版本的IM工具开发，（实际当时我们还没有自己APP)，像大多数网站一样。把聊天功能仅嵌入网页的一角。有消息时弹出，没有消息时收起。

 　 首先想到用Openfire，XML冗余大、在数据二进制流传输上有着各种问题。我们的开发时间就一个月，二个后端，一个前端。资源严重不足。我没有时间翻看它的源码，不仔细去看源码我是很担心一但出问题风验是不可控制的。

　　我们转向了WebSocket，它基于了HTPP协议，很好解决了网页HTTP通信协议的无状态性。仅仅在HTTP熟悉的协议中多了Upgrade: websocket，Connection: Upgrade这二项，最大问题是在低版本浏览器上无法使用。

 　最后像大多数IM开发者我们选择了，长轮询这样方式。开发成本低、是个浏览器就能用。开源的有Comet4j、CometD拿来就能用，几天就能看完源码。

 

3、IM演进过程

3.1 原始版

 

　　决定使用长轮询后，长轮询这样方式对服务器消耗资源是很大的，问题是如何集群。

 　  我们做法在用户登录IM时，把用户ID 做一次Hash，就可把用户分到一台具体推送服务中，要发送信息给你好友时，用ID查询就可得到它在那台机器，直接推送信息到这台机器就可以。

　　在简单快速完成了第一阶段任务后，随之而来问题也越来越多，长轮询请求过多，而这些请求不是用户聊天产生的，而是因为用户打开了一个个带有聊天网页产生的。同时也发现用户聊天内容不断增多，输入的聊天内容越长推送越慢。

 

3.2 改进版

 　　同一用户打开N多个页面。都会产生N个长轮询连接，在CometD代码中，就发现同一用户会限制长轮询个数。但是现实中不能这么解决问题。 用户打开很多页签，这是用户习惯问题。同过观察用户行为，平时IM在收起状态时，（在整个页面右下角，见图），用户不会主动去操作IM工具，如果能减少这样不必要连接就可以减少50%-60%无用长轮询，但是有以下二点需要解决。

 

   1、你的好友可以看到你是在线状态 。

 

   2、你如何收到你的好友消息。

 

　　我们解决方案是，在页面加载IM工具时用户自动登录，同过用心跳保持在线状态。你的好友推送信息给你时，我们通过短轮询拉取。我们采用 Nginx+Lua+Redis方式。这样请求就不会打到后面服务器上。 

 

　　最早开始做IM工具时了解比较少。用户发送文本内容越大越多时，直接影响了直个服务器推送消息的速度。IM需要做成推拉模式才是理想方式。用户在发送内容给好友时，把具体内容存储后返回一个ID，同时生成一个带有ID的命令包发给推送服务，前端在接收到ID的命令包后进行解析，再根据ID去拉取具体内容。

 

　　随着业务扩大和需求不断增加，APP也要上线IM功能，使用长轮询方式无论是在耗电、还是在稳定性上用户体验都很差。如果再单独为APP建立一套IM，无论是在业务上还是成本上都是不能接受的。关键问题是如何打通PC与APP用户之间实时交流。

3.3 进阶版

　　由于上一版本我们将发送和接收已经分开，所以发送信息时我们不需要改变原有模块，需要改变就是APP的接收方式，把以前长轮询能改为WebSocket，同时不影响以前PC接收方式，最好方式是让前端选择使用长轮询还是WebSocket还是其它。所以我们把架构做了如下调整。

　　

 

 

　　我们增加了“通知服务”模块，在前端与推送服务之间建立了或长轮询或WebSocket连接，把以前直接发给推送服务模块的“指令”改成发往通知服务模块。通知服务模块目前是一组消息队列。而推送服务还兼顾者消息订阅者功能。在分析路由规则后直接把信息推送给指定前端。

4、 总结与未来方向

　　IM是一种时实怀要求很高的系统，最大问题是，用户是否可以正常登录，一但登录，就可以收发信息，而当用户量和用户同时在线交流不断增加时，集群的建设和收发速度都是直接影响用户体验的重要因素。IM中每个用户状态，信息敏感度都是必不可少监控项。目前我们也在不断优化自动扩容、风险监控这些方向。希望给猎头、企业HR、应聘者提供更好交流方式。