大厂的客服平台架构实践

点击下方“ JavaEdge ”，选择“ 设为星标 ”

第一时间关注技术干货！ 关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主，编程严选网创始人。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。

负责：中央/分销预订系统性能优化；活动&优惠券等营销中台建设；交易平台及数据中台等架构和开发设计。

0 前言

客服平台，旨在从用户角度，用户通过智能渠道如C端自助或者人工客服渠道反馈问题和表达诉求，渠道识别和记录用户问题后，给出问题对应的解决方案。

为保证解决方案质量，提升用户体验和管理效率，我们需要统一管理这些解决方案：建设解决方案平台，整合各BU提供的业务信息和服务能力，为人工和智能渠道统一提供标准化解决方案。

1 解决方案平台

分析散落各处的解决方案，一般是基于BU输入的业务逻辑和服务能力封装的处理能力，大体可以分为两类：回答咨询使用的话术和解决问题的处理流程。为此我们目前提供了静态知识和动态流程两类标准解决方案，加上方案匹配层，组成整个解决方案平台：

• 动态解决方案：主要指流程，简称为SOP，应用场景比较广泛，例如用户自助处理单车关锁失败的流程，或者人工客服解决用户费用投诉的流程等，主要支持需要按标准流程处理和解决用户问题的场景；

• 静态解决方案：主要指知识，相关产品在业内通常称为知识库，在咨询类和指导类场景中很常见，例如用户进线咨询某个活动的规则，又例如客服熟悉新业务知识等，主要应用于规则介绍、问题解释和指导等场景；

• 方案匹配：主要负责管理问题到答案的关系；

2 动态解决方案

需标准化流程引导及解决用户问题的场景，提供流程管理平台，负责生产、执行和管理动态流程。

用户（C端用户、客服等）通过表单界面进行信息交互，背后则是处理该问题的业务流程向前驱动和处理。

2.1 链路示意

链路需解决问题：

• 如何支持不同渠道的交互方式
• 如何支持处理流程标准化
• 业务信息和服务能力如何规范且高效地接入

为此，设计拆分：

• 交互方式：不同表单类型支持各渠道不同交互，为用户提供标准化交互能力和一致的交互体验
• 流程管理：业务处理逻辑核心，负责根据用户和业务的输入数据，驱动处理步骤按业务规定的逻辑执行，起到引导和规范作用。基于流程引擎提供核心的流程执行和管理能力，支持业务针对不同场景自定义处理流程，实现从流程接入到执行的线上化和标准化。
• 资源管理：表单和流程的设计支持了业务信息的标准化接入，而服务能力的接入，从使用角度定义资源的概念，主要包括api及api返回的字段field。为管理资源，基于资源引擎搭建了资源配置化接入和使用的能力，支持BU服务能力的标准化接入，同时对业务运营使用服务能力更友好

2.2 整体功能架构

图片

基于流程的整套配置管理能力，一个流程从设计到测试到上线实现全流程线上化，很大程度缩短业务迭代周期，提升产研效率。

基于这条链路实现业务可视化管理，为业务梳理、质量把控、风险控制提供支持。打通C端自助链路，意味着一个用户问题对应的处理自助流程上线可完全配置化上线，迭代效率平均提升60%。在此基础打通端-解决方案-工单的数据链路，为业务精细化运营提供数据支撑。

3 静态解决方案

业务信息要透传给用户或辅助客服解决用户问题的场景，提供标准的静态知识解决方案，从产品层提供客服知识点、用户Q&A对、相似问题列表等。

整体功能架构

客服业务对静态知识的核心诉求：

• 知识的结构化/非结构化存储
• 适用各场景的检索能力

当前产品在这两方面的能力受限于关系型数据库的存储，接下来将进行一系列升级建设，同时也包括产品层面知识检索、运营和反馈等功能的进一步加强。

4 方案匹配

根据用户问题找到相应解决方案，处理多渠道的问题与同一方案的匹配关系。

匹配过程，一个问题能找到唯一解决方案，一个解决方案可对应多个问题。理想，分别为用户每个问题和每个解决方案设计唯一编号，方案匹配层只需要维护问题到答案的一对多的关系即可。但：

• 用户问题描述方式不是唯一编号，而是多维排列组合
• 每次想匹配的不一定是一个标准解决方案，也可以是一组，比如一个静态知识方案和一个动态流程方案打包成最终的解决方案

因此方案匹配层的设计思路是维护问题组到答案组的关系，目前这一层的能力比较单薄，未来计划升级底层能力，支持异构的问题组和答案组匹配，提升可扩展性以适应业务及产品层的快速迭代。

5 技术沉淀

前面我们从业务视角介绍了解决方案平台如何支持客服业务，其实在平台建设过程也遇到了一些技术上的挑战，下面主要结合解决方案平台建设过程中遇到的问题介绍一些技术沉淀：

6 流程引擎

介绍动态解决方案，提到底层依赖核心基础能力——流程引擎。调研了Activiti等方案，作为成熟工作流引擎，activiti功能强大完整生态，但在场景中优势不明显：

• 定位，建设的是流程引擎产品化后的产品，对流程引擎只依赖流程驱动的核心能力
• 功能，在流程定义和执行过程中对部署校验、数据交互、分支选择等方面有activiti不满足或不易扩展的需求
• 性能，Activiti通用性和灵活性决定实现复杂度，如频繁存储层操作等导致性能不佳，不能很好满足C端
• 上手成本及维护成本

最终决定场景自研。轻量级流程引擎，自研流程引擎主要负责提供稳定而高效的能力：驱动流程执行，告诉上层下一个节点是啥。

6.1 关键模型

考虑兼容性，在设计如何描述流程时参考bpmn规范：

• 流程：定义起点、终点及起点到终点要执行的活动、执行路径、执行策略
• 流程元素：构成流程中的各种元素，分为节点和顺序流两大类，节点又分事件节点（如开始和结束节点）、任务节点、网关节点（如排他网关节点）
• 流程模型：每个元素中描述了它从哪来可以向哪去，于是用流程元素列表可以完整描述一个流程

6.2 整体设计

要使用一个流程，分两步：

• 设计一个流程
• 执行这个流程

就像定义一个类与创建一个对象。因此流程引擎架构基本按这思路，分为两大部份：流程定义和流程执行

6.3 流程定义

为保证流程在执行过程中：

• 不受流程模型更新的影响

• 考虑运维

流程定义时，对流程模型采用近似快照的处理，在流程执行时直接使用快照模型：

6.4 流程执行

从【开始节点】开始，处理【当前节点】，完成处理后，根据当前状态及配置规则找到下个节点，并继续处理节点，直到【结束节点】：

• RuntimeProcessor：上游主动与引擎交互的时机为开始执行流程和执行流程中的一些任务节点，流程引擎为流程执行开放了三个核心接口：开始执行、提交、回滚任务

• FlowExecutor：负责根据流程定义不断驱动节点的处理，同时管理流程实例状态

• ElementExecutor：负责单节点处理，包括下个节点选择，同时管理节点实例状态

7 资源引擎

解决方案平台为解决各种用户问题，会整合的业务输入中还有一部分是服务能力（目前主要是由各BU通过API提供）。整个客服业务在其他场景也有类似对接大量业务API需求。基于使用和管理这些API以及高效接入和迭代的各种需求与痛点，参考解决方案平台的API接入&管理模式，将其沉淀抽象出资源引擎，收敛管理客服体系内接入的BUAPI，提供使用资源的工具，支持配置化接入及统一管理。

7.1 整体设计

将BU提供的服务能力称为“资源”，并根据使用场景将资源分为两大类：

• API：BU提供的接口能力，如查询订单详情api
• Field：通常为一个字段，如订单详情接口返回的“总金额”字段

使用资源分为定义资源和获取资源两部份，资源引擎提供的能力也以这两部份为核心，辅以相关的配套管理能力，于是我们设计了相关的模块：

• 客服端：SDK，使用方自行集成该SDK，根据资源引协议，查询资源定义，并获取及解析资源
• 服务端：服务端，支持资源定义的查询
• 管理平台：配置化接入资源及资源列表的统一管理
• 质量数据：产出离线数据，包括接入的资源的使用情况、错误率、耗时等质量数据，帮助使用方及BU发现问题，迭代方案

7.2 交互模式

7.3 系统架构

Manager：资源管理后台，是资源及相关的配置管理入口

Server：服务端，需要高性能且稳定地支持客户端的查询，尽量做到轻量，因此server只做两件事：访问控制、高效查询

Client：客户端SDK，负责获取资源

Resource：BU提供的服务能力，目前主要支持API，未来根据需求考虑扩展

7.4 资源计算

Client即SDK负责最核心的获取资源的逻辑，层次设计：

• Protocol：协议层，描述sdk使用方如何使用资源，如可扩展GQL

• Processor：核心逻辑，

  • a. 与server交互获取资源相关定义
  • b. 根据定义计算执行计划
  • c. 通用executor调用BUAPI
  • d. 解析和加工API返回的数据，得到最终结果

• Executor：根据资源定义，调用BU能力获取直接结果

7.5 案例

• field f1来自api a1(对应返回结果的apiField1字段)

• api a1的参数为field f4

• field f4不是api数据，只是对field f3的再加工；

• field f3的值为v3；

• field f2描述省略...

求：f1、f2值：

• Interpret：协议解析，解析出参数列表以及需要获取的资源列表；

• Preprocess：这里包括要获取的资源以及它们依赖的所有资源的配置；

• Allocate：将2得到的资源列表分成组，分组原则是组内的每个资源至少与组内的另一个资源有依赖关系，且不依赖任何组外的资源，抽象来说类似有向联通图的意思；

• Process：将每个组内的资源列表提交给处理任务，遍历进行原子处理：

• 
  

1. 递归获取该资源依赖的资源列表；
2. 执行API，得到原始结果；
3. 根据transformer，对原始结果进行加工，得到最终结果；

资源引擎除了支持解决方案平台，目前还在特征、工单等场景落地。此外，除了支持BU服务能力接入，资源引擎也适用于客服能力输出给BU的场景中，目前这套标准化方案也在建设中。

8 总结

解决方案平台通过标准化的思路，整合业务提供的业务信息和服务能力，拉齐不同渠道的答案和处置方案，提供可视化的方案管理平台。在打磨标准化能力的同时，下一步将会向着自动化与智能化的方向探索，以期在提升解决能力，支持精细化运营等方面发掘更大价值。

写在最后

编程严选网（www.javaedge.cn），程序员的终身学习网站已上线！

点击阅读原文，即可访问网站！

欢迎长按图片加好友，我会第一时间和你分享软件行业趋势，面试资源，学习途径等等。

添加好友备注【技术群交流】拉你进群，更多教程资源应有尽有

关注公众号后，在后台私信：

• 回复 【架构师】 ，获取架构师学习资源教程
• 回复【面试】 ，获取最新最全的互联网大厂面试资料
• 回复【简历】 ，获取各种样式精美、内容丰富的简历模板
• 回复 【路线图】 ，获取直升Java P7技术管理的全网最全学习路线图
• 回复 【大数据】 ，获取Java转型大数据研发的全网最全思维导图
• 微信【ssshflz】私信  【副业】 ，进副业交流群
• 点击 【阅读原文】 ，即可访问程序员一站式学习网站

最近在准备面试，为大家准备一份2024最新最全Java学习路线一条龙