京东咚咚是什么 京东的使命是什么…

本文来自中生代技术群的分享，微信公众号 ： freshmanTechnology

今天晚上我们非常荣幸地邀请到京东商城架构师杨超老师给大家做技术分享，主题是《京东在线客服：京东IM的实践》。

今天主要聊聊2011做京东在线客服。在线客服即京东咚咚起步那些年的叫法。时间相对有点久远，隔了5年回忆写了这些东西，期望能给大家带来些收获。

这是今天分享内容目录： 首先说说背景，聊一聊当时大概情况。第二，聊一下在线客服的整体结构，通过一个示意图和一个结构图聊一聊整体的结构。后面就三部分：web端，引擎端，客户端分别谈一些问题。最后就进行一下总结。

背景这里： 就是需要做一个聊天工具，让客服解答用户购买商品的时候一些疑问，以及购买后根据订单的一系列问题的咨询。根淘宝的阿里旺旺很类似。

这是整体示意图，第一个小图，为用户进入的页面：咨询。comet收消息，那么comet是什么：基于Ajax长轮询（long-polling，浏览器兼容），协议以上版本才支持的新特性。即是Ajax请求过来。可以在服务端维持一段时间，随时可以返回结果。发消息普通的Ajax 的post请求。通过服务端服务，转客户端，引擎程序再转到人工客服。整体的示意如下：消息流转情况。

这里主要是当时客户端，客服部分是用C#实现，通过mina长连接与引擎服务建立连接。引擎服务与Web端服务的交互消息主要通过redis中间存储进行转接。Web客户端也是轮循模式。历史消息是异步存储到MySQL服务器的。

这里的一些Liunx系统参数修改的具体含义我也记不得太清晰，大家可以网上查查 。这是2011调优时候记录下来的。当时决定外部采购，但还是自己开发进行一轮压力测试。当时有live800,51客服，还有几家客服进行压测时候修改。最后结果是当时的性能比他们好5-10倍，在后面总结会再谈一下比他们好的原因。请大家接着往下看!

这是客服引擎端的通讯。 主要通过mina,开启一个端口监听，客户端会认证后连过来。通讯协议自己定义的。主体用的JSON格式进行的定义。网络差的时候，当时遇到问题有TCP的心跳包会导致原来建立的长连接回收。解决自定义会话与连接进行关联，不会导致客服频繁上下线。

这里主要讲为什么当时用了mina，为什么自定义协议，当时一些思考和想法。

这里大体说了下会话和消息的及时性保证的问题。

这是客户端的截图，第一个主体客服工作区域，转接给其他客服。单客服接太多会话，服务不过来转给同事。这里还有有个难点就是同事人数问题。当客服体系庞大的时候，超过2000客户时加载比较慢。客服同事在线状态更新速度，都需要进行，服务端异步计算进行状态存。这里大家就知道为什么QQ只有会员才会有2000联系人了。咱们接着往下聊。

这里主要讲： 客户端现在还记得当时几个突出问题。

回忆总结下来：做客户端主要难点这些问题，但是下面的总结可能也不全。为什么会比在线客服提供商要高5-10倍性能？

第一：采用最快的缓存redis 数据库都进行了异步化操作。

第二：抛弃了XMPP的通用协议，而使用自定义的协议，使得传输量小了，另外用NIO的模式（mina 用NIO）实现。

其他的点：很多地方都是针对的自身场景定制的，而其他在线客服提供商，可能拘泥于通用吧！当然这是猜测性分析。

最后想说下团队很重要。当时我们就有6个开发，一个产品，一测试。当时平均年龄25左右，在2个半月时间，从无到有的做了这个系统。其中很多大的小的问题，至少刚讲的10倍。

回到团队，感触就是：人多人少，其实并不是一个成功团队的关键。一个有化学反应团队，才是好的团队。总结当时我们也会争吵，不过有着一致目标，把它做出来，并做好。也许可能也跟每个技术都有一个聊天工具情节吧！

Q&A

问：一个客户在一段时间内由一个客服服务，还是由多个客服服务？

答：两边进行转译，实际转译出来就是 URL，图片URL。一个客服登陆，可以同时接待很多用户的咨询。不过当时测试结果最快的客服人员，也只能接待8位。

问：自定义通信协议是否就是拿sip扩展的？

答：自定义：通讯协议完全，是自己定义，并没有参照SIP。说参照肯跟当时 我在移动写过通讯录 传输专利。

问：redis如何实现客户和客服的交换消息？

答：用三个多个键／值对进行关联。首先是客服登陆态，通过hash，然后web会话sid关联客服再生一个消息队列。

更多深度技术内容，请关注云栖社区微信公众号：yunqiinsight。