| 编辑推荐: |
本文来自于infoq，文章介绍了携程客服系统整个云客服平台的整体链路结构以及云客服平台的智能化应用框架等相关内容。
|
|
背景及设计理念
自携程创立以来，呼叫中心就一直伴随着公司业务一同发展壮大。经过近 20 年的迭代，目前携程的呼叫中心系统已经演进为第五代呼叫中心系统了，也就是我们完全自主研发的基于
FreeSwitch 的软交换与 IVR、微信 Server、邮件系统、无线 IM Server 的全渠道全媒体客服系统。
那么，基于现有可扩展架构的这套客服系统为携程的客服业务提供了什么样的支撑呢？我们可以从以下几个方面一窥全貌。
多渠道：目前支持传统电话、VOIP 电话、IM、微信公众号、邮件等通信渠道的接入。
多地域：目前携程的客服坐席分布在全国及海外各地，其中包括国内的上海、南通、合肥、如皋、信阳，以及海外的爱丁堡、韩国、日本等地。
多业务：本系统目前支撑着携程 200 多条业务线以及 15000+ 坐席的服务业务落地。
多语种：目前提供中文、英语、日语、韩语、法语、俄语等多语种支持。
海量会话：目前电话日均通话量约 100 万通以上，而 IM 会话日均消息量约 1000 万条以上。
上述场景的背后是一套什么样的架构体系在提供服务支撑呢？我们又为何会选择建设这样一套架构体系呢？后文将给出答案。
传统的客服运营通常面临六大痛点，即沟通单一、信息碎片化、智能化程度低、效率低下、移动性不足、成本高昂。在企业发展壮大的过程中，传统的客服运营就逐渐成为制约企业业务发展的瓶颈。有鉴于此，我们研发了一套基于云和容器化的软呼叫中心及客服平台，并且引入了场景化的
AI 能力，从而在源头上消除了前面所说的六大痛点。
现在，我们的客服系统是这样的：
云客服平台 = 软交换云平台（公有云 / 私有云）
+ 全渠道座席（Call/Chat/IM/SNS)
+ 全媒体座席（Voice/Txt/Pic/Video）
+ 多模式（集中 / 在家 / 移动）
+AI 引擎（客服机器人 / 语义解析…）
+CRM、工单系统、知识库
核心架构
系统结构
我们先来看看整体的系统结构，如下图所示。
从上图可以看出我们云客服平台的整体链路结构，其中最核心的就是中间的渠道服务和通信分配层，这一层中的每个节点都可按需进行水平扩展，从而支撑未来的业务发展。
通过这一中间层的转换，我们就将上图左侧来自各个渠道的客人服务请求整合为统一的服务请求，并通过右侧的全渠道坐席界面统一分配给客服人员进行服务响应。这样一来，也就实现了多个通信渠道融合的目的。下一节我们来看看其背后的处理逻辑。
逻辑架构
通信渠道由我们自研的各渠道 Server 构成，其中也包括无线平台研发部所研发的 IM Server。坐席所使用的全渠道通信端（XAgent/APP）使用
WebSocket 协议与这些渠道 Server 保持通信，同时也使用 WebSocket 协议与统一通信分配服务保持通信。
其余诸如分配服务、业务数据服务、AI 能力服务等，均以微服务 API 的方式在平台内部暴露。为此，我们搭建了一套名为方塔尖的微服务框架来提供基础设施的支持。
方塔尖微服务框架
这套框架是基于 SpringCloud 搭建的，分别采用 consul、zuul 来实现服务发现和服务路由。此外，在方塔尖中我们还加入了一些功能级服务，比如用户
/ 权限管理、短信验证码、数据加解密、数据访问层封装等等，以便让其上的逻辑层仅关注业务实现即可。
统一分配
下面我们来看看核心的统一通信分配服务的实现，其架构如下：
顾名思义，这个核心组件的目标就是实现各通信渠道的会话统一分配，其核心逻辑如下：
LinkServer 是坐席服务端，坐席端通过 WebSocket 连接到 LinkServer。
LinkServer 负责维护坐席连接、收发坐席请求和反馈、传递坐席状态。其处理流程如下：
StatusManager 是状态管理服务，负责处理 LinkServer 传递来的坐席状态变化，负责对外提供坐席状态查询。其处理流程如下：
ACD 是 IM+ 系统的核心模块，其主要功能是实现客人坐席分配，ACD 指令和消息的收发、ACD
会话管理等。其处理流程如下：
其中的分配逻辑是基于抽象的业务规则表达式来进行处理的，为此，我们采用了开源的表达式运算器 EvalEx，其好处在于：
使用 BigDecimal 进行计算和返回结果 ;
不依赖于外部库 ;
可以设置精度和舍入模式 ;
支持变量 ;
支持标准布尔和数学运算符 ;
支持标准的基本数学和布尔函数 ;
可以在运行时添加自定义函数和操作符 ;
函数可以用变量数量的参数来定义 (参见最小和最大函数);
支持十六进制数字和科学的数字符号 ;
支持函数中的字符串文字 ;
支持隐式乘法，例如 (a+b)(a-b) 或 2(x-y)，等于 (a+b)(a-b) 或 2(x-y)。
基于此，我们提供了一些基础分配逻辑，并且也支持第三方分配逻辑的对接。
上次服务优先：优先分配给上次服务的客服。
熟客优先：优先分配给为该客户服务次数最多的客服。
均衡分配：按客服工作量平均分配。
最闲分配：优先分配给空闲最长时间的客服。
指定分配：指定分配给某几个客服。
第三方分配：调用第三方接口分配。
智能化
人工智能现在很火，但是在人工智能众多细分领域中，其实 NLP 技术的发展和应用才是人工智能“皇冠上的明珠”，它也是众多
AI 大厂持续投入的领域。
而就目前的市场环境和技术条件而言，客服业务的智能化是最有希望落地 NLP 技术的场景。因此，我们也着力构建了云客服平台的智能化应用框架。该框架结构如下：
其中智能质检和对话机器人是两大重点应用场景，这两个场景的落地能够极大地提升客服业务运营效率并且显著降低运营成本。
对话机器人在我们的客服平台中分为语音机器人和在线 IM 机器人。语音机器人的服务对象是 IVR（交互式语音应答），即电话的呼入呼出
IVR 场景。其处理流程如下：
在线 IM 机器人主要对接的是 IM、微信等即时通信和社交媒体渠道，从广义上可以理解为我们常见的聊天机器人范畴，只不过在客服系统中，其模型是针对专有业务场景进行训练的。因此，相较于通用聊天机器人，在线
IM 机器人其实更容易达到比较好的智能交互效果。其整体模块结构如下：
智能质检对于客服运营管理而言是一项非常重要的功能，借助 ASR 语音转文字的能力，它能将非结构化的音频、文本数据转换成客服运营甚至企业运营统计分析所需的结构化数据，最终形成对业务管理运营的良性反馈闭环。下面两张图分别是我们云客服平台中智能质检的场景顺序图和处理流程图。
平台级能力输出
客服系统不同面向 C 端的应用，我们的目标并非寻求用户的长时间驻留。相反，在客服领域，我们希望能够以最快的时间去响应客户的需求，这样才能提升客户满意度并最大限度降低运营成本。所以，我们客服平台的每个模块、每项功能都是围绕这一主旨而设计构建的。
那么，基于前面的核心基础架构和上述考量，我们的客服平台能够对外输出哪些能力呢？
外呼
外呼通常是呼叫中心会高频使用的业务场景，传统的外呼都是坐席人工发起外呼，费时费力且成本高昂。因此，我们围绕外呼应用研发了四种外呼形态，以满足不同业务场景的需要。这四种外呼形态是，自动外呼、预测外呼、预览外呼和智能外呼。
篇幅所限，就不一一讲解每种形态的具体特性了，但它们的核心都是以自动外呼系统为基础的，其业务处理简图如下：
以此为基础，结合云端基础设施和容器特性，辅以我们自研的各种组件，我们的外呼系统就能提供以下特性：
支持高并发，吞吐能力可扩展 ;
高可靠外呼平台，包含完善的保护机制 ;
支持预测外呼、预约外呼、虚拟坐席外呼 ;
提供智能呼叫算法，提升工作效率。
中转
中转即号码埋名，也就是用虚拟号码替换真实号码的功能。这项功能的目的是让通话双方无法获悉对方的真实号码，从而实现隐私保护的目的。
作为该能力的配套，我们开发了配置界面、录音模块，以及对应的查询 / 统计报表等功能，用户可以基于浏览器操作完成实时的配置生效操作，并浏览话务中转结果。
VOIP
VOIP 也就是大家所熟知的 IP 网络电话。我们的平台提供了 VOIP SDK，方便第三方应用集成，并且自研了音频编解码和动态码率技术，能够满足弱网下的正常语音通信。其特性如下图所示：
全渠道客服工作台
我们为客服人员提供了一站式全渠道的客服工作台，以便客服人员可以在统一的工作界面中为来自各个渠道的客人需求提供服务响应。其特性如下：
全渠道统一，一站式服务体验。
统一电话、网页 IM、APPIM、邮件、微信等多个渠道；
快速响应用户咨询。
全媒体融合，服务形式更丰富
文本、图片、电话、语音、视频等多媒体融合；
服务形式多样化。
数据整合，一目了然
完整用户信息与服务轨迹记录；
提升服务质量。
客户支持
我们的客服平台在核心客服业务能力支持之外还提供了以客户为中心的服务周边配套模块，比如 CRM、工单、知识库等。这是为了给客服人员提供更为详尽的客户信息，以期为客户提供全方位的服务支持。
CRM
客户数据管理:
完整记录用户数据
用户信息统一管理
提高客户留存率
提升企业获客能力
工单
速流转，协同处理
促进企业内外协作，共同处理用户咨询
企业服务更高效
知识库
座席服务规范高效
常用问题
常用语
客服话术标准化
报表监控
作为客服业务运营的日常管理手段，报表和监控是必不可少的支持方式。我们的客服平台自然也提供了相应的运营报表和监控界面。具体特性如下：
实时报表:
多维度、实时展示座席指标数据
可按日、周、月等多条件查询
图表展示方式支持自定义
全面监控预警:
系统、服务、座席，全方位监控
可设阈值告警与告警通知
话务预测:
智能预测后续话务量
突发事件等因子对话务量的影响预测
结语
客服平台是异常复杂和庞大的结构化体系平台，要在一篇文章中全面论述其技术体系架构几乎是不可能完成的任务。受篇幅限制，本文仅摘取了部分核心架构和核心模块功能略作阐述。 |
