在线客服技术详解（理论）

￡神魔★判官ぃ 2022-09-29 14:52 345阅读 0赞

前言
    
    在线客服是一个比较流行的功能，网络上有很多提供在线客服服务的公司，但介绍在线客服技术的文章却很少。另外，网上有一些免费的在线客服框架，但大部分都只适用与小规模的在线客服服务，对于大规模应用（几万人甚至几十万人同时在线），却基本没有。本文将根据自己的一些实际经验，讲解在线客服的各项技术。
    
    这里讲的在线客服系统是基于Web环境，采用Java、JavaScript来实现的。

aJax技术

讲在线客服技术，就不得不讲到aJax技术，AJAX全称为“Asynchronous JavaScript and XML”（异步JavaScript和XML），是指一种创建交互式网页应用的网页开发技术。有了这种技术，就可以实现网页部分数据的更新，而不像传统Web技术那样，需要刷新整个页面。

目前有很多aJax框架，如DWR，Dojo，ProtoType，BackBase等，不同的aJax框架，实现的功能不同，用处也不同，在开发项目的时候，需要根据自己的需要选择不同的框架。我比较推崇采用DWR，因为这个框架的实现比较优美，使用也比较简单，而且能够把Java和JavaScript统一起来。

DHTML（动态HTML）

DHTML（动态HTML）提供了在浏览器中维护内容、进行用户交互的扩展能力。就像Java开发者使用servlet和JSP那样，DHTML也应该是你的工具箱中的一部分。

DHTML涉及到HTML、级联样式表（CSS）、JavaScript和DOM。传统的页面只能通过重新装载来自server新页面的方式进行更新。DHTML提供了在页面被装载完毕后对浏览器内的HTML文档的完全控制。你应该见过一些带有“图像翻滚”、弹出内容、可收缩菜单功能的web页面，它们便是使用DHTML技术实现的。尽管存在一些标准上的差异（见下面的“跨浏览器DHTML”），多数兼容JavaScript1.4版本的浏览器（后面将简称为“版本4的浏览器”）都支持DHTML。

从开发者的角度审视浏览器中的整个文档，比如Frame、图片、表格等，它们都可以表示为具有层次的对象模式——DOM。通过使用JavaScript可以维护DOM的成员，不但可以改变文档的内容和外观，而且还可以捕捉例如鼠标移动、form提交这些用户事件，而后对DOM进行相应修改。例如鼠标移动到图片的上方可以产生“mouse-over”事件，这时通过显示高亮版本的图片或者弹出解释性文字的方式修改页面外观。

通知解决方案

在线客服系统最重要的就是通知，用户发送的消息如何通知到客服，客服发送的消息又如果通知到用户，下面将讲解其中一些常用的通知解决方案。

1、 轮询

这是一种比较古老而简单的解决方案，也就是定时刷新，在线客服在聊天的时候，aJax在后台定时获取数据，如果接收到发送过来的消息的话，则将消息显示在聊天框上。

这种技术的缺点就是后台刷新太频繁了，而很多刷新都是没有数据返回了，导致性能的下降。

2、 长连接

这种技术有称为“长轮询”，它是基于轮询技术的，但有所改进，客户端向服务端发起请求的时候，服务端不会直接返回，而是会阻塞请求，直到服务器读取到消息后才返回，这个时候，客户端才调用回调函数，将读取到的消息显示出来。

这里讲的在线客服系统将选用该技术来实现。

图 2. 基于长轮询的服务器推模型

![这里写图片描述][SouthEast]

3、 消息

这种解决方案采用一个作为client的applet，它使用TCP/IP或者无连接的UDP、甚至多播协议来建立与消息中间键server的通讯，然后由server推送消息给client。你可以从例如SoftWired的iBus、IBM的MQSeries、BEA的WebLogic Event这些消息产品中直接挑选，或者自己使用基于socket的java.io.ObjectStream定制开发消息软件。

Comet技术

Commet是一种使用HTTP长连接，无需浏览器安装插件的“服务器推”方案。它有两者方案：基于aJax的长轮询方式；基于iframe和htmlfile的流方式。这里，我们只关注里面的基于aJax的长轮询方式。

Pushlet是一个开源的Comet框架，其中在设计上有很多值得借鉴的地方，能够使用它来开发一个不是大规模的在线客服系统。而对于大型商用的在线客服系统，我觉得它还无法胜任。

负载均衡（分布式部署）

一个正式商用的在线客服系统，不可能只在一个WEB服务器部署，这样子，性能和容量都很难扩展，所以必然是允许分布式部署的，通过负载均衡设备（或软件）来实现分布式访问。

如果采用分布式部署的话，那么就涉及到聊天的数据保存在哪里的问题。是保存在web服务器上，还是数据库呢？如果是单web服务器的话，那肯定是保存在web服务器上，其流程大概如下：

1、 用户发送消息是，系统将数据保存在web服务器（同时也保存数据库）上。

2、 客服对应的长连接获取web服务器上的数据，然后在客服的页面上显示出来。

3、 客服回复聊天信息，系统将数据保存到web服务器（同时也保存数据库）上。

4、 用户所在的长连接获取web服务器上的数据，然后在用户的页面上显示处理。

由于从web服务器上获取数据比在数据库获取数据的效率高，所以上面的逻辑是合理的，但是，基于分布式部署的环境下，他存在多个web服务器，那么发起聊天的消息应该保存在哪台服务器上呢？还是所有的服务器都保存一次呢？在分布式环境下存在一些像JBossCache等缓存同步的技术，但对应在线聊天系统，实时性的要求非常高，是否存在实时性的问题呢？

另外一个，基于安全的考虑，一般需要将用户所访问的功能放到一个web服务器集群上，客服所访问的功能放到另外一个web服务器集群上，两个web服务器集群的网络需要隔离，以防止黑客的攻击。这就又出现一个问题，如果用户发送的消息放到用户的web服务器上，那么客服如果获取到该消息呢？同理，用户的web服务器有如果获取客服web服务器对应的消息呢？

那么放到数据库来实现呢？把聊天记录都放到数据库中，用户和客服都从数据库获取聊天的信息。这样子的话，那么数据库的负荷将非常大，随着用户数的不断增加，数据库负荷越来越大，而且，在大用户下，存储都是非常频繁的，将所有人的聊天信息放到数据库上，是不明智的。还有一个安全上的考虑，一般实现用户的功能都不直接访问数据库，一般会经过一个中间的服务器作为中转，那么如果聊天信息从数据库取的话，效率则会更低。

那么，能不能像QQ那样，聊天双方直接建立连接，实时发送呢？其实，这是一种相对老点的技术，一般是采用Socket，或者UDP，实现双方的通讯。这种机制的缺点客户端可能需要采用applet插件或ActiveX插件，通讯时有比较大的性能消耗，最重要的一点，这些技术受网络的影响特别大，在一个环境下可以正常使用，在另外一个环境下，可能就无法正常使用了。所以，本文考虑的是采用aJax长轮询方式来实现的。

在这里，我建议客服的聊天数据从数据库读取，而用户的聊天数据从web服务器上读取。这是因为客服的数据相对比用户少很多，直接从数据库读取聊天数据，对数据库的性能影响较少，而用户的数量庞大，直接从数据库读取，无法满足要求。

那么，客服是将回复数据写到客服的web服务器，还是用户的web服务器呢？我的建议是写到用户的web服务器，因为用户的数据量非常庞大，用户从用户的web服务器获取数据，要比从客服的web服务器获取数据，性能要高得多。客服每次发送聊天信息的时候，往用户的web服务器写数据，虽然效率低，但由于客服的数据量小，并不影响性能。

另外，在分布式部署下，数据该记得所以的web服务器，还是某台特定的web服务器呢？我建议写到某个特定的web服务器上，这样避免客服每发送一条聊天信息，都要往所有的web服务器写数据，这会影响性能，但web服务器不断增加的时候，性能会随之下降。

那么，客服往哪台特定的web服务器写数据呢？用户又如何知道从哪台特定的web服务器上获取数据呢？这个，我们在用户登陆，负载均衡服务器给其分配到某个特定的服务器的时候，就可以将这个特定服务器的IP记录下来，客服就可以往这台机器发消息了，而用户也同样可以从该IP获取数据了。

路由分配

现在来讲一个路由分配，这个应该从什么时候进行路由分配，如何进行路由分配，分配失败了怎么办等方面来讨论。

1、什么时候进行路由分配

什么时候进行路由分配呢？是用户一登陆系统了就给其进行路由分配，还是等待用户发送了第一个聊天信息才开始路由分配呢？

这个要分情况讨论，像一般的web在线客服系统（或者WAP在线客服系统），用户都是一登陆系统，就给其分配一个客服的。这种，有一个好处，就是登陆的时候，已经分配客服了，那么发送第一条信息的时候，就不需要再路由分配了，可以直接将该信息分配到对应的客服，这样能提高聊天的效率。而不好的地方就是会占用资源，如果用户登陆后，分配了客服后，用户又一直不发送聊天信息，也不退出系统的话，这就占用了一个资源，可能导致客服的处理量减少了。好在正常的逻辑下，用户登陆系统后，都是会马上发送聊天信息的，所以这种情况就比较少了。所以一般的web在线客服系统，我建议采用一登陆就路由分配的策略。

对于像短信在线客服这样的系统，由于用户没有登陆系统这样一步操作，那肯定是用户发送第一条聊天信息就开始进行路由分配啦。

是用户每发送一条信息就分配一次，还是只路由分配一次，以后发送消息都不进行分配呢？

如果用户每发送一条信息，都路由分配一次的话，这样有一个好处，就是可以平均给客服分配话务量，用户发送消息的时候，都可以计算一次，把该消息分配给当前处理量最小的客服；它的缺点就是影响性能，因为路由分配是需要消耗性能的，每次发送都会消耗性能，另外一个就是缺乏稳定性，如果前一条消息发送给一个客服，下一条消息又发送给另外一个，那么，用户感觉会不舒服，而客服在处理的时候也会不知道前因后果。

只路由分配一次，效率就比较高，但它有个缺点，就是每个用户聊天的频率不同，比如说，两个客服都是同时处理10个用户，但一个客服对应的用户比较喜欢聊天，拼命的发送聊天信息，那么这个客服也会比较忙；而另一个客服对应的用户很久才发送一次聊天消息，那么这个客服就会很闲了。但总的来说，这种情况很少，而且我们可以通过一个路由分配策略来减少和规避这些情况。所以，我建议采用只路由分配一次的情况。

2、如何进行路由分配

现在网上大部分的在线客服系统都是匿名的，它是通过你从哪个网页点击登录，从而分配到对应技能的座席。有些在线客服系统是通过帐户（如银行的在线客服系统）或者手机号码（如电信的在线客服系统）登录的，它是通过用户的类型，或者用户选择询问的内容，来路由分配到不同的客服上的。

但不管怎么说，一般都是将客服划分为不同的技能，一个客服可能拥有一个或者多个技能，用户登陆的时候，属于一种技能，路由分配的时候根据该路由策略将用户分配到对应的客服。它一般要求有下面几个原则：

1、 继承原则

分配给座席的聊天消息，需要有一定的继承性，比如说，用户聊天完成后，退出系统，隔几分钟后，再次登录系统，这时，最好把该呼叫还是分配给原先处理该用户的客服，这样子，用户的好感度会比另外分配不同的用户好得多。

2、 分技能服务原则

不同的用户，根据其技能不同，需要分配到对应技能的客服上，也就是说，客服划分为多个技能，这样的好处的节省客服的培训费用。但它有一个不好的地方，就是用户问一些跨越该客服技能范围内的问题，这时客服就无能为力了，它只能询问其它人，或者将来话转移给其它客服处理，这就会影响用户的好感，所以，对于一个高端用户，可能是需要一个全才性的客服来为他们服务的。

3、 平均分配原则

聊天信息要平均分配，从而保证客服处理的量都是平均的。

4、 最闲分配原则

路由分配的时候，需要将用户来话分配到最闲的客服上。

5、 不同接通率原则

对于不同基本的用户，有不同的接通率，比如说，VIP用户每次来话都接入，而低端用户，则显示系统忙。

下面是一个简化的处理流程图：

![这里写图片描述][SouthEast 1]

事件通知机制

我们可以把在线客服之间的一些操作，比如说聊天，发送魔法表情，发送文件，甚至语言、视频等，都看做是一个事件来处理，事件可以传送不同的状态和参数，这样子就很方便扩展了，比如说，我现在新增一种功能，叫发送Google地图所在地，点击发送后，对方会收到这边Google地图所在点的地理位置，那么我们只需要设置后，发送是所下发是事件类型，参数，收到事件后执行的方法等参数，就可以了。有了事件通知机制，我们就可以用一套统一的逻辑处理事情，新增功能，只需要稍作修改或者配置就可以实现。

我们甚至可以把接口暴露处理，供第三方系统使用，那么就可以把在线客服系统的功能无限延伸了，类似Google地图一样。

客服状态

客服的状态应该至少有“在线”、“离线”、“暂时离开”三种状态，对应每个状态，有不同的呼叫处理策略，在线能接入来话，离线则不接来话，暂时离开一般是当前还在聊的消息则接入，而新来话则不分配过来了。用户的状态则一般只有“在线”和“离线”两种，用户的状态不做路由控制，也就是说客服回了信息，是直接回复给用户的，不做路由。用户的状态一般是给客服展示用的，让客服知道当前用户是处理什么状态，另外，还可以对不同的状态做一些控制，如用户在线，则客服回复信息直接发送；如果用户里面，客服回复消息自己，可以给其发送一条短信。

上面指的状态至少一些基本的状态，在大部分在线客服系统上，还会根据需要添加一些状态，比如说，客服状态可以添加一个休息态，进入休息态的时候，客服会将当前聊天的来话释放，并不再接收任何来话；可以增加一个抢答态，进入该状态后，客服可以增加原先可服务的用户数。

我们可以将客服状态开发成可扩展的，可以任意扩展客服状态，而不需要修改代码的逻辑，我们新增一种状态，并设置进入该状态和离开该状态所要执行的JavaScript方法，而对于路由分配策略，我们也可以通过设计来避免修改路由分配策略的逻辑。这里给出一个参考的方法，我们将客服状态划分为“在线”、“离线”、“暂时离开”三种基本状态，其它新增的状态都属于这三种状态的一种，如休息态属于暂时离开（但在进入休息态之前有一个释放正在处理的所有来话的动作），抢答态属于在线态（但在进入抢答态之前有一个扩大服务用户个数的动作）。这样子，我们通过配置后，可以实现增加状态后，路由策略还是可以正常处理的功能。

客服状态和用户状态属于不同的状态，应该分开处理和维护。

来话状态

来话状态一般比较固定，分为“无来话”，“来话首次到达”，“来话再次到达”，“来话正在处理”，“来话未处理”，“来话已处理”这六种状态。

当用户登录后，这是用户来没有发送消息，这时是无来话的状态。

用户发送第一条消息后，消息进入客服页面，这时是“来话首次到达”状态，这个时候，客服的页面一般是该来话闪烁显示（如QQ）。

客服给用户回复信息，正在回复途中（这时一般是打开了一个聊天窗口，如QQ），这个时候，处于“来话正在处理”状态，这个时候，来话不再闪烁显示。

客服打开了聊天窗口，但未回复又关闭了，这时处于“来话未处理”状态，这时一般来话图标不再闪烁，如果为了与来话已处理状态区分，可以把图标修改成其它样式，以方便辨认出是没有处理的来话。

客服回复了信息，并关闭了聊天窗口，这时处于“来话已处理”状态。

用户再次发送消息，则处于“来话再次达到”状态，这时来话应该闪烁，但应该与首次到达状态有所区分，因为首次到达一般比较重要，需要马上处理，而再次到达的来话则显得没那么重要了。

如果来话首次达到后，用户再发了消息，则来话还应该处于首次到达状态。

状态控制的流程图如下：

![这里写图片描述][SouthEast 2]

主动服务

当用户正在浏览网站的某个网页是，这时，在线客服系统可以检测到该用户，并向其发起主动服务。

这里可以分为两者情况，一种是用户进入某个页面是，弹出询问，是否接收主动服务，用户点击是，则双方进入聊天，这种其实不是真正的主动服务，只不过是用户所访问的页面上含有一段代码，该代码弹出一个询问，用户点击是，其实，只不过就相当于用户登录聊天界面一样。另外一种方式是不弹出询问，客服查询当前在线且没有聊天的用户，然后主动给其发送一条消息，或者发起一次邀请，用户所浏览的页面检测到该消息或邀请，提示给用户。

主动服务离不开网页上嵌入的一段代码，一般情况下，用户所浏览的页面跟在线客服系统是两个独立的系统，那么是什么原来能够使得用户浏览的页面能够通知到在线客服系统呢？

这就是靠网页上签入的代码了，这一般是一段JavaScript代码，它远程调用在线客服系统的代码，然后执行某个方法。

对于前面说的第一种情况，则比较简单，就是包含的这段JavaScript代码中含有弹出某个浮动窗口的代码，点击是的时候，则会打开聊天窗口。

对于第二种情况，则比较复杂，这种JavaScript代码含有写在线客服数据的功能，进入网页的时候，则往在线客服系统写数据，这样子，客服就可以查询出当前在线的用户了。至于客服发起主动服务，那么嵌入的这段代码中，还应该还有监听的功能，它能监听到客服发送过来的消息，只有监听代码的写法，则类似与正常聊天是，用户监听客服的消息一样，采用aJax的长轮询方式来实现就可以了。

来话轨迹

用户访问了哪些页面，包含了哪些功能，客服都可以查询得到，这主要就是靠上面所说过的一段JavaScript代码来实现了，在网页嵌入了这段代码，并指明了网页所属的类型，当用户访问网页的时候，这段JavaScript代码就会收集当前访问的url地址，用户的IP等信息，记录到在线客服系统中。

当用户与客服在聊天是，系统就会记录下聊天的信息，对应的客服工号等信息。

这些信息串起来，就构成了来话轨迹，可以知道用户在正在来话中，所做的事情，包括访问的页面，用户的地址，聊天的信息，甚至可以包括给用户发送的短信，邮件，用户的行为（比如说，银行的在线客服系统，能够知道用户取了多少钱，刚刚打了客服电话的内容等）。

来话转接

当用户正在与客服聊天时，用户问了一个超出该客服技能的问题时，客服可以把该来话转移到其它客服处理。

来话转接其实可以分解为两个动作，1、另一个客服接到新来话，2、当前客服释放该来话。

来话转接可以划分为直接转某个客服和转到某个技能上两者。转到某个技能上，则类似与路由分配，会再进入分配流程，把该来话分配到该技能上处理数最少的客服上。

来话转接要对转接失败进行处理，如果转到了客服正忙，或技能的所有客服正忙，或所以客服都不在线，这时是无法正常转接的。那么转接失败后，当前客服需要继续处理该来话。

来话转接到另外一个客服，另外一个客服如果需要辨认出该来话是转接的话，则需要有所标识，比如说，在来话转接的时候，模拟用户给客服发消息消息，里面注明是来话转移，从那个客服转移过来的；另外，呼叫转接的时候，也可以是客服直接给另一个客服发一条提示，说明是转接的来话。

> 文章转载自： [http://zkread.com/article/575835.html][http_zkread.com_article_575835.html]

[SouthEast]: /images/20220708/32119b9472234a39bbec18b9d506f28c.png
[SouthEast 1]: /images/20220708/1ca4772339bc480f8f87eb9f9f24c51c.png
[SouthEast 2]: /images/20220708/91379760bf044d85be982b157a454406.png
[http_zkread.com_article_575835.html]: http://zkread.com/article/575835.html