咚咚客服模型 ——复杂业务的拨云见日之路

咚咚在线客服自诞生以来，客服客服的服务领域从电商到其它领域，范围从国内到国际，先后在商城内的业务需求方包括：京东官方客服、供应商(自营)客服、POP客服、金融客服、众包客服、1号店、众筹客服、平台化客服等；国际站包括印尼、泰国、俄罗斯、西班牙等；目前还支持开放业务，包括名创优品，Toplife、互联网医院、香山、黑鲨等业务方。下图1.1是咚咚在线客服在国内的业务关系网(部分)

图1.1  复杂的业务关系网

出于体验和效率的原因，图1.1中不同服务类型的客服之间可能存在业务合作，也可能不存在，这让原本单纯的人与人之间聊天因为业务合作变得复杂起来，而这些业务关系还无时无刻不在发生着变化。下图1.2是顾客和客服建立会话的简要过程。

图1.2  顾客咨询客服的过程

如图1.2 所示，咚咚在线客服的整体流程就是寻址客服+交互聊天，为了极致体验的需

要，即给每一位顾客分配到最合适一位客服。咚咚在寻址客服的过程中花了很大的力气，顾客从不同合作网站，不同终端的各大入口进来，要经过一系列的行业规则参数匹配，以及客服负荷状态，历史咨询关系等一系列个性化匹配，来寻址到最合适的客服，从而达到提升顾客和客服有效沟通效率的目的。

随着业务的井喷发展，体验和效率的矛盾越来越突出，这就急需找到一种好的办法来支撑整个咚咚在线客服的业务发展。其实，犹如这样的业务场景，在咚咚在线客服外的其他项目中也是普遍存在的(例如：滴滴派单，商品分拣，热线电话分类引导等等)。下面将从设计和技术上，分别介绍咚咚在线客服在面对复杂业务的经历和选择，其中一些的通用方法和经验，希望和大家引起共鸣。

1. 客服模型
   

图2.1 咚咚客服模型

第一个模型是客服组织模型，如图2.1所示，我们首先抽象出了服务商，行政组，技能组，客服四种实体，来刻画了客服领域可预见的所有场景(一个客服隶属于唯一的行政组，方便管理；同时绑定一个或多个不同的技能线，方便不同业务顾客的接待；而包含多个行政组和技能组的客服组织单位，我们抽象为服务商，提供客服的组织或单位通过实例化服务商即可，这样来达到解耦具体业务的目的。例如：一个POP商家可以实例化为一个服务商，一个在线医疗组织可以实例化为一个服务商，…)。规则则是控制各种业务逻辑流转的另一种抽象(通过用户规则进行顾客分流到不同技能组的拦截；当A技能组或服务商的客服不能处理顾客的问题，通过转接或跨服务商转接来实现交由B技能组或服务商处理；某个技能组或服务商A想将业务整体或部分托管给别的技能组或服务商B时，通过分流规则来实现)。以上抽象的客服模型基本适合在线客服在电商、医疗、教育等各种C2C 、C2B、B2B的领域，而个性化则是交由规则去扩展，从而达到目的。

2.管理模型

图2.2 咚咚管理模型

业务模型为了支持更好的维护和拓展，要让不同的用户参与进来自主进行扩展，就需要强有力的管理模型，这里抽象咚咚第二个模型-管理模型：系统层、运营层、个体层，分别来概括咚咚平台参与的所有用户，为真正的平台化自主化扩展作下铺垫。

3.权限模型

图2.3 咚咚权限模型

管理模型为了进一步支持各类用户自定义等动态扩展的需求，这里抽象的第三个模型就是权限模型，基于角色的权限，这也是行业通用的做法，传统ERP的权限机制很完善，但是复杂度也很高。因此，需要针对具体平台量体裁衣，核心的几点就是角色要支持动态扩展（自定义角色），要支持具有共同特征的临时组队（临时群），支持完善的批量赋权机制（虚拟服务商）。咚咚目前支持的就仅支持网页菜单权限和插件权限，但是其它权限可以平行扩展，这些抽象确实带来很大方便，后期扩展性比较强。

设计的落地，合理的技术方案是必不可少的。下面将从支撑模型的技术来介绍我们的落地方案

1. 数据库设计
   

图3.1 一总多分的数据库架构

图3.2 动态扩展分库的示意图

模型的落地，首要避不开的就是数据库的设计，数据库的设计通常涉及到水平分库分表和垂直分库分表，这是常见的手段，这里不再赘述，值得提醒的是：我们真的到了分库分表的时候了么？通过充分评估，咚咚客服模型数据仅涉及到垂直分库分表，同时支持动态扩展分库。下面分别介绍带来的好处和坏处。

(1)     垂直分库：为了数据安全隔离，突破数据库连接IO瓶颈，需要将数据库垂直分库，形成的结构是：一个总库，多个分库(表结构完全同构)；全局索引表：弥补分库带来的连表查询问题。当然，坏处就是跨库join，分布式事物

(2)     垂直分表：将基本和扩展信息，关联表一定分离开，核心表和非核心表区分，优点：核心字段的表稳定，索引量小；缺点就是不可避免要联表查询

(3)    动态扩库：业务发展和数据隔离决定动态扩展分库，其中简单的既要支持动态扩展，又要不降低的性能，简单的方案，如上图业务ID构成中含有：虚拟DB+动态ID+其它字段。那么读写应用访问数据时，直接能解析出虚拟DB，虚拟DB和物理DB之间可以被管理的，一般映射关系表不会太大，因此，可以动态配置(UCC或其它动态配置中间件)推送至应用的内存空间。这样可以映射到对应物理DB，这样的设计既可以动态扩展数据库，又不会带来读写性能的下降。

当然，如果有水平分库，考虑的还有诸如一致性hash，union等更多问题，咚咚数据模型没有涉及，大家自行参考其它方案。

图3.3 基于消息异步确认的分布式事物

虽然仅有垂直分库，但在公司分布式数据库不是很完善的时候，也面临自行解决分布式事物的问题，咚咚采用了消息异步确认的机制，该方案实现较为简单，但是有一定业务定制性，简单原理如图3.3所示。基本步骤如下：

(1)    消息生产方在A库中本地事物同时提交业务数据和消息数据分别到两张表中

(2)    将A库的消息数据(操作B库的业务数据消息)发送到JMQ中(失败就进行重试发送)

(3)    消费JMQ中消息，然后写业务数据到B库中，本地事物成功，表明成功；如果失败，执行重试，业务失败，则给生产方发送业务补偿消息，通知回滚

(4)    生产方和消费方定期扫描本地消息表，把没有处理完的消息或失败的消息再发送一遍

2.系统架设

图3.4 数据模型的工程架构图

咚咚客服模型对应的系统架构大致如下：“谁生产数据，谁提供数据消费”的统一管理思想。这样，不仅可以灵活升级，自由决断优化，而且可以集中管控数据库资源。管理端在公网中只有web代理服务，无任何业务含义；管理端的数据模型服务包括管理基础模型服务和管理扩展模型的服务，都在内网中，最底层是数据库，这样设计既可以业务解耦，又可以解决防数据直连的安全问题；业务读服务完全在内网中，而且使用读库，外部获取数据，走统一网关服务。