客户服务的调度方法、系统、终端设备以及存储介质

技术领域

本发明涉及金融科技(Fintech)技术领域，尤其涉及一种客户服务的调度方法、系统、终端设备以及计算机存储介质。

背景技术

随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技转变，但由于金融行业的安全性、实时性以及稳定性等要求，也对技术提出了更高的要求。

目前，针对不同业务产品提供对应客户服务的调度都是采用硬编码redis(远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、“Key-Value”数据库，并提供多种语言的API(Application Programming Interface，应用程序接口))消息队列与状态机结合的形式来进行。如此，不仅需要针对该不同的业务产品均进行全套的服务处理逻辑的开发、测试和上线部署过程，并且即使是两个业务产品之间存在的差异较小时，也仍需要单独为两业务产品开发各自的服务处理逻辑和进行测试部署，此外，在后期运维过程中，若业务侧需要调整服务处理逻辑从而修改对应参数时，又需要重新进行代码编写和测试。如此，现有采用硬编码redis消息队列与状态机结合的客户服务调度方式，调度业务开发和运维过程耗时严重，无法满足业务侧快速响应客户服务调度的需求。

发明内容

本发明的主要目的在于提供一种客户服务的调度方法、系统、终端设备以及计算机存储介质，旨在解决现有采用硬编码redis消息队列与状态机结合的客户服务调度方式，调度业务开发和运维过程耗时严重，无法满足业务侧快速响应客户服务调度的需求的技术问题。

为实现上述目的，本发明提供一种客户服务的调度方法，所述客户服务的调度方法包括：

获取待服务的业务请求并从所述业务请求中提取请求参数；

根据所述请求参数从预设的分布式配置中心获取目标服务处理逻辑，其中，所述分布式配置中心配置有全部业务产品各自的服务处理逻辑；

按照所述目标服务处理逻辑动态加载各业务模块代码文件；

执行所述业务模块代码文件以调度所述业务请求对应的客户服务。

此外，为实现上述目的，本发明还提供一种客户服务的调度系统，所述客户服务的调度系统包括：

获取模块，用于获取待服务的业务请求并从所述业务请求中提取请求参数，以及，根据所述请求参数从预设的分布式配置中心获取目标服务处理逻辑，其中，所述分布式配置中心配置有全部业务产品各自的服务处理逻辑；

代码动态加载模块，用于按照所述目标服务处理逻辑动态加载各业务模块代码文件；

客服调度模块，用于执行所述业务模块代码文件以调度所述业务请求对应的客户服务。

其中，本发明客户服务的调度系统的各功能模块在运行时实现如上所述的客户服务的调度方法的步骤。

此外，为实现上述目的，本发明还提供一种终端设备，所述终端设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的客户服务的调度程序，所述客户服务的调度程序被所述处理器执行时实现如上所述的客户服务的调度方法的步骤。

此外，为实现上述目的，本发明还提供一种计算机存储介质，所述计算机存储介质上存储有客户服务的调度程序，所述客户服务的调度程序被处理器执行时实现如上所述的客户服务的调度方法的步骤。

此外，为实现上述目的，本发明还提供计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现如上所述的客户服务的调度方法的步骤。

本发明提供一种客户服务的调度方法、系统、终端设备、计算机存储介质以及计算机程序产品，通过获取待服务的业务请求并从所述业务请求中提取请求参数；根据所述请求参数从预设的分布式配置中心获取目标服务处理逻辑，其中，所述分布式配置中心配置有全部业务产品各自的服务处理逻辑；按照所述目标服务处理逻辑动态加载各业务模块代码文件；执行所述业务模块代码文件以调度所述业务请求对应的客户服务。

本发明在针对客户就任意业务产品发起的业务请求进行客户服务调度的过程中，通过被配置为调度系统的终端设备接收任意客户发起的业务请求并从该业务请求当中提取出请求参数，然后，终端设备基于该请求参数从预先配置有全部业务产品各自服务处理逻辑的分布式配置中心当中，获取客户所发起服务请求对应业务产品的目标服务处理逻辑，再然后，终端设备即按照该目标服务处理逻辑来动态的加载处理该服务请求所需的业务模块代码文件，最后，终端设备执行动态加载到的该业务模块代码文件从而调度与该业务请求相适配的客户服务来执行对应的服务操作。

本发明相比于传统采用硬编码redis消息队列与状态机结合进行客户服务调度的方式，通过将全部业务产品的服务处理逻辑配置在一个分布式配置中心当中，从而在某一个业务产品的一部分或者全部服务处理逻辑要更新，或者，某个业务产品的服务处理逻辑需要叠加上另一个业务产品相同的逻辑，均可以直接在该分布式配置中心当中修改该服务处理逻辑对应的配置文件，即，能够动态的针对该服务处理逻辑进行调整，无需进行整个调度系统的重新开发、测试以及上线部署等复杂过程，确保了针对业务请求进行客户服务调度的响应积极性，解决了传统方式中调度业务开发和运维过程耗时严重，无法满足业务侧快速响应客户服务调度的需求的技术问题。

附图说明

图1为本发明实施例方案涉及的终端设备硬件运行环境的设备结构示意图；

图2为本发明客户服务的调度方法第一实施例的流程示意图；

图3为本发明客户服务的调度方法一实施例所涉及的系统框架示意图；

图4为本发明客户服务的调度方法一实施例所涉及的用于动态适配服务处理逻辑的协议代码；

图5为本发明客户服务的调度方法一实施例所涉及的用于动态适配客户服务匹配模型的协议代码；

图6为本发明客户服务的调度方法一实施例所涉及的另一系统框架示意图；

图7为本发明客户服务的调度方法一实施例所涉及的又一系统框架示意图；

图8为本发明客户服务的调度系统一实施例的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

参照图1，图1为本发明实施例方案涉及的终端设备硬件运行环境的设备结构示意图。

本发明实施例终端设备可以是被配置为调度系统进行客户服务调度的客户端设备，该终端设备可以是智能手机、PC(Personal Computer，个人计算机)、平板电脑、便携计算机等等。

如图1所示，该终端设备可以包括：处理器1001，例如CPU，通信总线1002，用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如Wi-Fi接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的终端设备结构并不构成对终端设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及客户服务的调度程序。

在图1所示的终端中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端，与客户端进行数据通信；而处理器1001可以用于调用存储器1005中存储的客户服务的调度程序，并执行以下客户服务的调度方法的各实施例。

基于上述硬件结构，提出本发明客户服务的调度方法的各实施例。

需要说明的是，目前，针对不同业务产品提供对应客户服务的调度都是采用硬编码redis(远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、“Key-Value”数据库，并提供多种语言的API(Application ProgrammingInterface，应用程序接口))消息队列与状态机结合的形式来进行。如此，不仅需要针对该不同的业务产品均进行全套的服务处理逻辑的开发、测试和上线部署过程，并且即使是两个业务产品之间存在的差异较小时，也仍需要单独为两业务产品开发各自的服务处理逻辑和进行测试部署，此外，在后期运维过程中，若业务侧需要调整服务处理逻辑从而修改对应参数时，又需要重新进行代码编写和测试。如此，现有采用硬编码redis消息队列与状态机结合的客户服务调度方式，调度业务开发和运维过程耗时严重，无法满足业务侧快速响应客户服务调度的需求。

针对上述现象，本发明提供一种客户服务的调度方法。请参照图2，图2为本发明客户服务的调度方法第一实施例的流程示意图，在本实施例中，该客户服务的调度方法应用于上述被配置为调度系统的终端设备，本发明客户服务的调度方法包括：

步骤S10，获取待服务的业务请求并从所述业务请求中提取请求参数；

配置为调度系统的终端设备通过统一的网关接口先接收客户针对业务产品发起的业务请求，然后，针对接收到的该业务请求进行解析以提取该业务请求当中封装的请求参数。

需要说明的是，在本实施例中，终端设备所接收到的任意业务请求均至少包括：发起该业务请求的客户的客户标识、该客户所针对的业务产品的产品标识，以及，该业务请求对应的需要客户服务提供解答的问题的问题类型。

具体地，例如，请参照如图3所示的系统框架，该系统框架中，业务系统即代表需要客户服务(简称客服)提供对应服务支持的各类产品，且该系统框架还包含有被配置为调度系统的终端设备、提供给客户用于输入请求参数发起业务请求的网关接口、配置有全部业务产品各自服务处理逻辑的分布式配置中心、存储具体业务模块代码文件的文件存储空间、存储客户服务匹配模型的模型存储空间，以及存储客户特征和客户服务特征的特征库。

在该系统框架下，客户针对任意业务产品发起的业务请求均通过调用该统一的网关接口：clientGateWay进行输入，而客户在基于该网关接口：clientGateWay输入请求参数发起业务请求时，至少需要输入自身的客户标识—客户编号、业务产品的产品标识—产品编号，以及需要客户服务提供解答的问题的问题类型(通过设有下拉选项的输入框键入)，从而，该终端设备在通过该网关接口：clientGateWay接收到封装有该用户编号、产品编号以及问题类型的业务请求之后，即基于任意成熟的指令解析方式针对该业务请求进行解析以提取得到请求参数：客户编号、产品编号以及问题类型。

步骤S20，根据所述请求参数从预设的分布式配置中心获取目标服务处理逻辑，其中，所述分布式配置中心配置有全部业务产品各自的服务处理逻辑；

需要说明的是，在本实施例中，上述系统架构当中的分布式配置中心当中，配置有全部业务产品各自的服务处理逻辑，通过将全部业务产品各自通用的服务处理逻辑(例如，用户信息查询、用户产品查询和用户权限校验等等))抽象成一个个业务模块文件，然后由该分布式配置中心动态配置该业务模块文件，从而实现动态的加载该服务处理逻辑对应的代码模块。此外，由于已经在该分布式配置中心配置了业务产品所通用的服务处理逻辑，因此，在后续需要增加配置新的业务产品的服务处理逻辑时，仅需配置该新的务产品的服务处理逻辑中，除开通用的服务处理逻辑之外的其它服务处理逻辑，如此，能够有效地提升了业务产品服务处理逻辑的配置效率，从而进一步确保针对业务产品发起服务请求进行客户服务调度的响应积极性。

应当理解的是，基于实际应用的不同设计需要，在不同可行的实施方式当中，该分布式配置中心中当然还配置有其它任意用于调度客户服务所需的参数配置，本发明客户服务的调度方法仅限定将全部用于调度客户服务的参数配置都配置在该分布式配置中心，而对于该参数配置的具体内容，本发明客户服务的调度方法并不进行具体的限定。

终端设备在接收到客户发起的需要客户服务提供支持的业务请求，并提取到该业务请求所封装的请求参数之后，即根据该请求参数在分布式配置中心所配置的全部业务产品各自的服务处理逻辑当中，适配得到客户所发起的该业务请求所属业务产品的目标服务处理逻辑。

具体地，例如，请参照如图3所示的系统框架，分布式配置中心预先被配置有如附图4所示的协议代码，该协议代码规定了两个业务产品—产品A和产品B的服务处理逻辑，该协议代码中，productCode是指业务产品的编号，每个业务产品的编号都不相同(如“A”和“B”)，productBiz是指业务产品具体的服务处理逻辑，其中bizCode是指业务模块代码的编号，配置为调度系统的终端即依赖此编号来匹配加载对应的代码块，bizName是指代码块的业务名称，bizOrder是指业务模块代码的执行顺序：1为最先执行的模块、2为在1之后执行的模块，以此类推，bizError有两个枚举值，分别为break与continue，其中，break是指发生系统异常时中断程序，直接返回，continue是指当业务模块出现异常时，可以跳过该代码模块的判断，直接进行下一个代码模块的处理，而不直接中断线程返回错误码。

如此，终端设备在接收到客户发起的业务请求并提取到请求参数之后，假定该请求参数中，客户编号为客户的ID：xxx…3(x为任意大于或者等于0的正整数)、产品编号为A，则终端设备通过先从该分布式配置中心当中拉取得到全部产品各自的服务处理逻辑，然后将该产品编号A与productCode字段的value值“A”进行匹配，从而在确定相等的情况则读取对应的productBiz字段作为当前客户发起的该业务请求所属的产品A的目标服务处理逻辑。

需要说明的是，在本实施例中，目标服务处理逻辑—productBiz是一个数组，数组里面的每一个对象都是一套业务逻辑，终端设备首先根据bizOrder的大小值排序，从小到大依次排列要执行的代码模块，例如，终端设备根据产品A的目标服务处理逻辑—productBiz中，bizOrder的大小值对应编号依次要执行的业务模块代码分别为：checkUserId，complaintHistory，customerComplaintHistory……。

步骤S30，按照所述目标服务处理逻辑动态加载各业务模块代码文件；

终端设备在根据请求参数从分布式配置中心获取到目标服务处理逻辑之后，即开始按照该目标服务处理逻辑处理客户发起的业务请求，并在处理该业务请求的过程中，依据该目标服务处理逻辑中业务模块代码的编号，依次动态的加载各个业务模块代码文件。

需要说明的是，在本实施例中，业务模块代码文件是对于一些通用的服务处理逻辑(例如，用户信息查询、用户产品查询和用户权限校验等等)的抽象，配置为调度系统的终端设备将这些通用的服务处理逻辑抽象成一个个配置文件配置在分布式配置中心，从而可以依赖spi机制(Spi机制是指Service Provider Interface：实源自服务提供者框架(Service Provider Framework)，是一种将服务接口与服务实现分离以达到解耦、大大提升了程序可扩展性的机制。引入服务提供者就是引入了spi接口的实现者，通过本地的注册发现获取到具体的实现类，轻松可插拔)动态的加载代码模块。

具体地，例如，请参照如图3所示的系统框架，配置为调度系统的终端设备在将产品编号A与productCode字段的value值“A”进行匹配，从而读取对应的productBiz字段作为当前客户发起的该业务请求所属的产品A的目标服务处理逻辑，并根据产品A的目标服务处理逻辑—productBiz中，bizOrder的大小值对应编号依次要执行的业务模块代码分别为：checkUserId，complaintHistory，customerComplaintHistory……之后，即按照该业务模块代码编号：checkUserId、complaintHistory、customerComplaintHistory……，依次在分布式配置中心存储具体业务模块代码文件的文件存储空间当中，将与该各业务模块代码编号匹配业务模块代码文件动态加载进系统(如java系统)应用程序当中，并按序针对该业务模块代码文件进行执行。

需要说明的是，在本实施例中，配置为调度系统的终端设备通过采用java SPI机制实现的代码文件动态加载。具体地，例如，配置为调度系统的终端设备通过工作人员针对接口的自定义编程和预置的策略模式，按照工作人员预先添加的用于控制加载业务模块代码文件的配置文件，来实现针对该业务模块代码文件的动态加载。此外，配置为调度系统的终端设备还通过JDK(Java Development Kit(JDK)是针对Java开发员的软件开发工具包。)中提供的工具类：“java.util.ServiceLoader”来实现服务查找。

进一步地，在本实施例中，配置为调度系统的终端设备中接口的自定义编程为基于面向接口的编程方式进行编码得到。

需要说明的是，由于抽象的各个代码模块往往会有很多不同的实现方案，例如：常见的日志模块方案、xml解析模块、JDBC驱动模块等，因此，工作人员在面向对象的设计思想中，在配置为调度系统的终端设备中的接口上，基于面向接口的编程方式进行编码以实现该各个代码模块之间的对接，而不是直接面向实现类的硬编码。

进一步地，在本实施例中，配置为调度系统的终端设备基于SPI技术实现客户发起的服务请求的发现。

需要说明的是，在本实施例中，SPI技术是JAVA中提供为某个接口寻找服务实现类的机制，

具体地，例如，配置为调度系统的终端设备通过类似于Spring框架中的IOC思想(即，将程序加载装配的控制权移到程序之外)，通过在JAVA SPI机制中约定，当服务的提供者(例如某个新的日志组件)提供了服务接口的某种实现之后，在jar包的META-INF/services/目录中同时创建一个以该服务接口命名的文件，文件中填写了实现该服务接口具体实现类的全限定类名。如此，在当外部程序装配代码模块的时候，就可以通过该jar包中META-INF/services/目录里的配置文件找到具体的实现类路径，从而可以通过反射机制装载实例化，从而完成模块的注入。

步骤S40，执行所述业务模块代码文件以调度所述业务请求对应的客户服务。

终端设备在动态的加载各个业务模块代码文件之后，即针对该业务模块文件进行执行，并在执行到用于分配客户服务的模块代码文件时，进一步基于请求参数中的客户标识，来适配和调度对应的客户服务以针对该业务请求提供服务支持。

需要说明的是，在本实施例中，请参照如图3所示的系统框架和如图4所示的协议代码，配置调度系统的终端设备在执行代码模块编号checkUserId、complaintHistory和/或者customerComplaintHistory……所对应的模块代码文件的过程中，若有异常发生，则直接根据该协议代码当中的配置的bizError来判断是跳过当前异常继续执行还是直接在当前处理节点返回异常信息。

进一步，在一种可行的实施例中，在上述步骤S40之后，本发明客户服务的调度方法，还可以包括：

步骤S50，获取针对所述目标服务处理逻辑的修改请求；

终端设备在调度客户服务针对客户发起的业务请求提供对应服务支持之后，进一步获取客户基于自身需求发起的、针对该业务请求所属业务产品的目标服务处理逻辑进行修改的修改请求。

需要说明的是，在本实施例中，由于客户服务在针对客户提供对应服务支持之后，客户可能会提出删除与客户服务之间的接触历史的需求或者其它需求，从而，配置为调度系统的终端设备即基于封装该需求的生成针对该业务请求所属业务产品的目标服务处理逻辑进行修改的修改请求。应当理解的是，基于实际应用的不同设计需要，在不同可行的实施方式当中，客户当然还可以在客户服务提供对应服务支持的过程中或者之后，提出其它需求，本发明客户服务的调度方法并不针对该修改请求的具体种类进行限定。

步骤S60，按照所述修改请求在所述分布式配置中心对所述目标服务处理逻辑进行修改得到新的服务处理逻辑。

终端设备在获取到客户发起修改请求之后，即按照该修改请求封装的客户需求，针对分布式配置中心已经配置的、该客户所发起业务请求所属业务产品的目标服务处理逻辑进行修改，进而得到修改后该业务产品新的服务处理逻辑。

具体地，例如，配置为调度系统的终端设备在调度客户服务针对客户针对业务产品A发起的业务请求提供对应服务支持之后，客户和/或者业务产品A的开发工作人员提出需要删除该客户与客户服务之间的接触历史的修改请求，则终端设备接收该修改请求并直接在分布式配置中心上修改业务产品A的服务处理逻辑相关的参数配置，及，移除接触历史模块代码的id，以使得修改后业务产品A新的服务处理逻辑由原来的“首先调用用户权限校验代码模块、然后进行用户交易记录查询代码模块、再进行用户接触历史的查询代码模块、最后进入分配客服代码模块，变为：首先调用用户权限校验代码模块、然后进行用户交易记录查询代码模块、最后进入直接分配客服代码模块。

本发明实施例提供一种客户服务的调度方法，通过配置为调度系统的终端设备通过统一的网关接口先接收客户针对业务产品发起的业务请求，然后，针对接收到的该业务请求进行解析以提取该业务请求当中封装的请求参数；终端设备在接收到客户发起的需要客户服务提供支持的业务请求，并提取到该业务请求所封装的请求参数之后，即根据该请求参数在分布式配置中心所配置的全部业务产品各自的服务处理逻辑当中，适配得到客户所发起的该业务请求所属业务产品的目标服务处理逻辑；终端设备在根据请求参数从分布式配置中心获取到目标服务处理逻辑之后，即开始按照该目标服务处理逻辑处理客户发起的业务请求，并在处理该业务请求的过程中，依据该目标服务处理逻辑中业务模块代码的编号，依次动态的加载各个业务模块代码文件；终端设备在动态的加载各个业务模块代码文件之后，即针对该业务模块文件进行执行，并在执行到用于分配客户服务的模块代码文件时，进一步基于请求参数中的客户标识以及预设的客户服务匹配模型，来适配和调度对应的客户服务以针对该业务请求提供服务支持。

此外，终端设备在调度客户服务针对客户发起的业务请求提供对应服务支持之后，进一步获取客户基于自身需求发起的、针对该业务请求所属业务产品的目标服务处理逻辑进行修改的修改请求；终端设备在获取到客户发起修改请求之后，即按照该修改请求封装的客户需求，针对分布式配置中心已经配置的、该客户所发起业务请求所属业务产品的目标服务处理逻辑进行修改，进而得到修改后该业务产品新的服务处理逻辑。

本发明相比于传统采用硬编码radis消息队列与状态机结合进行客户服务调度的方式，通过将全部业务产品的服务处理逻辑配置在一个分布式配置中心当中，从而在某一个业务产品的一部分或者全部服务处理逻辑要更新，或者，某个业务产品的服务处理逻辑需要叠加上另一个业务产品相同的逻辑，均可以直接在该分布式配置中心当中修改该服务处理逻辑对应的配置文件，即，能够动态的针对该服务处理逻辑进行调整，无需进行整个调度系统的重新开发、测试以及上线部署等复杂过程，确保了针对业务请求进行客户服务调度的响应积极性，解决了传统方式中调度业务开发和运维过程耗时严重，无法满足业务侧快速响应客户服务调度的需求的技术问题。

进一步地，基于上述第一实施例，提出本发明客户服务的调度方法的第二实施例，本实施例与上述第一实施例之间的主要区别在于，在本实施例中，各所述业务模块代码文件中包括分配客户服务的模块代码文件，上述步骤S40，可以包括：

步骤S401，执行所述分配客户服务的模块代码文件以加载预设的客户服务匹配模型，其中，所述客户服务匹配模型基于客户特征和客户服务特征进行深度学习训练得到；

步骤S402，利用所述客户服务匹配模型适配所述业务请求对应的客户服务，并调度所述客户服务。

需要说明的是，在本实施例中，客户服务匹配模型为基于tensorFlow的深度学习算法模型，每个客户服务匹配模型的计算都是基于上述如图3所示系统框架内，特征库中的多个特征值(包括客户特征的特征值和客户服务特征的特征值)计算而来，此外，每个模型的数学模型略有不同、模型各自的侧重点也不同，不同的业务产品也是通过配置不同的模型来为客户针对业务产品发起的业务请求提供客服调度服务。

此外，该客户服务匹配模型的数量大于一，如图3所示系统框架内，客户服务匹配模型具体可以包括：客服响应率模型、客服满意率模型、客服专业程度模型、客服等候时间模型、用户接触历史模型、用户行为模型、用户信息模型以及用户等候时间模型，应当理解的是，基于实际应用的不同设计需要，在不同可行的实施方式当中，配置为调度系统的客户终端所处的系统框架内，客户服务匹配模型当然还可以包括其它不用于此处所列举的各算法模型，本发明客户服务的调度方法并不针对该客户服务匹配模型的具体种类进行限定。

终端设备在动态的加载各个业务模块代码文件之后，即针对该业务模块文件进行执行，并在执行到用于分配客户服务的模块代码文件时，进一步基于请求参数中的客户标识以及预设的客户服务匹配模型，来适配和调度对应的客户服务以针对该业务请求提供服务支持。

进一步地，在一种可行的实施例中，上述步骤S401，可以包括：

步骤S4011，按照所述产品标识在所述分配客户服务的模块代码文件中适配算法模型编号；

步骤S4012，确定所述算法模型编号在各所述客户服务匹配模型中对应的目标客户服务匹配模型；

终端设备在执行动态的加载各个业务模块代码文件的过程中，在执行到该各个业务模块代码文件中的分配客户服务的模块代码文件时，先利用解析客户发起的业务请求以提取出的请求参数中的产品标识，在该模块代码文件中适配算法模型编号，并确定该算法模型编号在多个客户服务匹配模型当中所对应的目标客户服务匹配模型。

具体地，例如，请参照如图3所示的系统框架，分布式配置中心还预先被配置有如附图5所示的协议代码，该协议代码中，ProductCode即代表的是产品编号，learningModel代表的是算法模型编号，并且，该协议代码规定了业务产品—productA调用的是skillModel(客服技能模型)，产品productB调用的是userInfoModel用户信息模型，modelConfig指的是算法模型的配置信息，因为同一业务产品同一时间同一算法模型可以跑多种版本(这样可以快速基准验证算法模型的效果)，modelVersion指的是算法模型的版本，flow指的是使用该版本的流量，流量总和为100。

具体地，例如，请参照如附图3所示的系统框架，配置为调度系统的终端设备在处理到业务模块-querySupportCustomer之后，整体客户服务的调度过程就到了算法协议匹配阶段(即利用客户服务匹配模型适配为客户发起的业务请求提供服务支持的客户服务)，同样的，终端设备会拉取上述分布式配置中心上配置最新的算法模块逻辑协议(即上述如图5所示的协议代码)，然后通过productCode字段的value值来与productA匹配，相等则读取learningModel字段对应的value值，该值就代表对应的算法模型的id(算法模型编号)，然后，终端设备在读取learningModel字段对应的value值为skillModel的情况下，即确定当前用于针对业务产品A的业务请求进行对应客户服务适配的目标客户服务匹配模型为客服技能模型。

步骤S4013，根据所述客户标识计算得到模型版本号；

步骤S4014，在所述目标客户服务匹配模型的各待选版本中，加载所述模型版本号指向的目标版本的模型。

终端设备在确定出当前用于针对客户所发起业务请求进行对应客户服务适配的目标客户服务匹配模型之后，进一步利用解析该业务请求以提取出的请求参数中的用户标识，来计算得到模型版本号，从而在确定该目标客户服务匹配模型的各待选版本中，加载利用该模型版本号所指向的目标版本的模型，以进行对应客户服务的适配。

具体地，例如，请参照如图3所示的系统框架，分布式配置中心还预先被配置有如附图5所示的协议代码，配置为调度系统的终端设备在确定当前用于针对业务产品A的业务请求进行对应客户服务适配的目标客户服务匹配模型为客服技能模型之后，继续在最新的算法模块逻辑协议中读取ModelConfig字段下的值，这其中，ModelVersion代表productA产品对应的skillModel算法模型(客服技能模型)的版本号一共有三个且分别为1.1.2，1.1.3，和1.1.4，该三个版本的skillModel算法模型，1.1.2的版本对应的流量为30％、1.1.3版本对应的流量为30％、1.1.4版本对应的流量则为40％，终端设备通过按客户标识—客户编号除以100的余数来确定目标版本的模型，即，如果客户编号除以100的余数在0-29，则分配给1.1.2版本的skillModel算法模型作为目标版本的模型进行执行以适配客户服务，而如果该余数在30-59则分配给1.1.3版本的skillModel算法模型作为目标版本的模型进行执行以适配客户服务，或者，如果该余数是在60-99则分配给1.1.4版本的skillModel算法模型作为目标版本的模型进行执行以适配客户服务。

需要说明的是，在本实施例中，一个算法模型id(算法模型编号)有许多个算法版本，通过该算法模型的id和算法模型的版本号可以加载对应的算法模型到终端设备的内存中，上述如图5所示的协议代码中，flow字段的value值代表的即是具体算法模型所拥有的流量。

进一步地，在另一种可行的实施例中，上述步骤S402，可以包括：

步骤S4021，若检测到所述客户服务匹配模型故障，或者检测到所述客户服务匹配模型输出的模型计算结果的偏移量超过预设偏差阈值，则动态加载新的客户服务匹配模型以适配所述业务请求对应的客户服务。

需要说明的是，在本实施例中，预设偏差阈值为客户服务匹配模型经过计算输出的结果与最优解之间可允许的最大偏差。

终端设备在确定用于针对客户发起的业务请求进行对应客户服务适配的客户服务匹配模型，并在利用该客户服务匹配模型适配该客户服务的过程中，若检测到该客户服务匹配模型无法执行运算过程从而确定模型出现了故障时，终端设备即可立即重新确定一个新的客户适配模型，并加载执行该新的客户服务匹配模型进行客户服务的适配，或者，若终端设备检测到该客户服务匹配模型基于入参(客户特征的特征值)进行计算所输出的模型计算结果，大于或者等于可允许的最大偏差时，终端设备同样的立即重新确定一个新的客户适配模型，并加载执行该新的客户服务匹配模型进行客户服务的适配。

需要说明的是，在本实施例中，请参照如图3所示的系统框架，在该系统框架中，特征库可以为客户与客户服务(客服)各自对应的特征库，且该特征库里有每个客户和每个客服的各个特征值的指标，配置为调度系统的终端设备把以往每个客户与客服配对的历史记录作为数据样本进行算法模型训练，输入值为对应客户的各个特征值与对应客服的各个特征值，输出值为客户与客服各自相互的评分，然后在每个评分项的基础之上做一个加权计算得到输出值y，其中，加权计算时，不同的模型，权重值是不同的，例如：由于用户满意度模型与客服响应率模型的侧重点不同，从而在用户满意度模型中，客户的等待时间权重与客服空闲时间权重都比客服响应率模型中这两者的权重低，但是客户的客服专业能力评分与客服服务态度评分则有都比客服响应率模型中两评分各自权重高。

此外，不同的算法模型，模型入参也不同，相同的入参在不同模型中的权重也不同(例如：客服响应率模型中，入参特征值为客服专业能力特征、客服通话服务时长特征、客服的年龄、籍贯等基本信息特征、客户的基本信息特征、客户的问题类型特征、客服等候时长特征、客户等候时长特征，以及客户急迫等级特征等。而用户响应率模型的入参中虽然同样有客户的基本信息特征、客服等候时长特征和客户等候时长特征，但是该客户的基本信息特征、客服等候时长特征和客户等候时长特征给在两种算法模型当中的权重却不一致)。

基于此，本发明客户服务的调度方法通过构建线性方程：y＝W

在另一种可行的实施例中，配置为调度系统的终端设备除了基于上述深度学校框架训练构建客户服务匹配模型来为用户适配调度客户服务之外，该终端设备还可以直接基于任意成熟的权重数据公式来进行客户服务的调度。

具体地，例如，请参照如图6所示的系统框架，终端设备在执行动态的加载各个业务模块代码文件的过程中，在执行到该各个业务模块代码文件中的分配客户服务的模块代码文件时，先利用解析客户发起的业务请求以提取出的请求参数中的产品标识和客户标识，然后按照该产品标识和该客户标识在存储客户特征和客户服务特征的特征当中，提取出对应客户特征和与该产品标识所指向业务产品关联的客户服务特征，从而直接按照任意成熟的权重计算公式，将该客户特征和客户服务特征代入进行计算从而确定并调度与该客户相适配的最优客户服务。

在本实施例中，通过终端设备在执行动态的加载各个业务模块代码文件的过程中，在执行到该各个业务模块代码文件中的分配客户服务的模块代码文件时，先利用解析客户发起的业务请求以提取出的请求参数中的产品标识，在该模块代码文件中适配算法模型编号，并确定该算法模型编号在多个客户服务匹配模型当中所对应的目标客户服务匹配模型；终端设备在确定出当前用于针对客户所发起业务请求进行对应客户服务适配的目标客户服务匹配模型之后，进一步利用解析该业务请求以提取出的请求参数中的用户标识，来计算得到模型版本号，从而在确定该目标客户服务匹配模型的各待选版本中，加载利用该模型版本号所指向的目标版本的模型，以进行对应客户服务的适配；并且终端设备在确定用于针对客户发起的业务请求进行对应客户服务适配的客户服务匹配模型，并在利用该客户服务匹配模型适配该客户服务的过程中，若检测到该客户服务匹配模型无法执行运算过程从而确定模型出现了故障时，终端设备即可立即重新确定一个新的客户适配模型，并加载执行该新的客户服务匹配模型进行客户服务的适配，或者，若终端设备检测到该客户服务匹配模型基于入参(客户特征的特征值)进行计算所输出的模型计算结果，大于或者等于可允许的最大偏差时，终端设备同样的立即重新确定一个新的客户适配模型，并加载执行该新的客户服务匹配模型进行客户服务的适配。

如此，本发明客户服务的调度方法实现了根据深度学习框架训练得到客户服务匹配模型来进行用户与客户服务之间的匹配和调度，相比于传统客户服务调度方式中直接将闲置时间最长的客户服务分配给等待时间最长的用户，本发明客户服务的调度方法据深度学习框架进行权重的计算，从而差异化的将客户服务分配给不同的用户，使得客户服务与用户之间的适配程度更高，客户服务能够更加准确、高效的为用户提供服务，即有效提升了客户服务调度的准确性和效率，还提升了用户体验。

进一步地，基于上述第一实施例和第二实施例，提出本发明客户服务的调度方法的第三实施例，本实施例与上述第一实施例和第二实施例之间的主要区别在于，本发明客户服务的调度方法，还可以包括：

步骤A，从分布式配置中心中获取全部所述业务产品各自的服务处理逻辑，并将各所述服务处理逻辑存储在本地的各节点机器当中；

配置为调度系统的终端设备在根据从客户所发起业务请求中提取的请求参数进行目标服务处理逻辑的适配操作之前，还可以预先从分布式配置中心将全部业务产品各自的服务处理逻辑均拉取到本地的各个节点机器上进行存储，如此，终端设备即可在进行目标服务处理逻辑的适配操作时，直接由对应的节点机器在本地存储的全部服务处理逻辑当中进行适配。

具体地，例如，请参照如图3所示的系统框架，配置为调度系统的终端设备在每一次上电启动之后即基于与分布式配置中心之间建立的通讯连接，从该分布式配置中心当中拉取得到全部产品各自的服务处理逻辑，然后将该全部服务处理逻辑关联存储在本地各个节点机器的本地存储空间(运行内存或者固态存储介质)当中。

进一步地，在一种可行的实施例中，在上述步骤A中，“将各所述服务处理逻辑存储在本地的各节点机器当中”的步骤之后，本发明客户服务的调度方法，还可以包括：

步骤B，接收所述分布式配置中心数据更新通知，并按照所述数据更新通知针对各所述节点机器存储的各所述服务处理逻辑进行更新；

配置为调度系统的终端设备实时的接收分布式配置中心下发的数据更新通知，该数据更新通知由分布式配置中心基于动态生效机制在针对本地配置的服务处理逻辑进行修改之后生成的，该终端设备在接收到该数据更新通知之后即按照该数据更新通知当中携带的修改内容将本地各个节点机器上存储的服务处理逻辑进行对应的更新处理。

具体地，例如，分布式配置中心在接收到工作人员针对已经配置的某一业务产品C的服务处理逻辑进行修改调整的配置参数，从而针对该业务产品C的服务处理逻辑进行更新得到新的服务处理逻辑之后，该分布式配置中心即立即将针对该业务产品C的服务处理逻辑进行修改调整的配置参数，封装作为一个实时的数据更新通知下发给配置为调度系统的终端设备，从而，该终端设备在接收到该数据更新通知之后，即解析出该配置参数，并按照该配置参数针对本地各个节点机器上存储的业务产品C的原服务处理逻辑进行修改调整从而得到该业务产品C的新的服务处理逻辑。

需要说明的是，在本实施例中，上述分布式配置中心的动态生效机制具体可以基于Http长轮询请求和Spring扩展机制实现，即，通过在Spring容器启动过程中，分布式配置中心通过自定义的BeanPostProcessor和BeanFactoryPostProcessor(都是Spring IOC容器提供的扩展接口)將参数中包含“${…}”占位符和“@Value”注解的Bean注册到分布式配置中心框架中定义的注册表中，然后通过Http长轮询不断获取服务端的配置信息，一旦配置发生变化，即根据变化的配置的Key找到对应的Bean，然后修改Bean的属性，从而实现配置的动态生效。

步骤C，按照预设时间周期从所述分布式配置中心获取更新后的新的服务处理逻辑，并利用所述新的服务处理逻辑针对各所述节点机器存储的各所述服务处理逻辑进行更新。

需要说明的是，在本实施例中，预设时间周期为用于配置为调度系统的终端设备主动重复从分布式配置中心拉取服务处理逻辑的时间周期，应当理解的是，基于实际应用的不同设计需要，在不同可行的实施方式当中，该时间周期当然可以设定为不同大小，本发明客户服务的调度方法并不针对该时间周期的具体大小进行限定。

配置为调度系统的终端设备除了被动接收分布式配置中心基于修改服务处理逻辑生成的数据更新通知之外，还通过按照预先设定好的预设时间周期循环主动的向该分布式配置中心拉取分布式配置中心基于对原服务处理逻辑进行修改后得到的新的服务处理逻辑，然后利用该新的服务处理逻辑针对该终端设备本地各个节点机器上存储的服务处理逻辑进行更新处理。

具体地，例如，配置为调度系统的终端设备以24h为时间周期，在每过24h之后即向分布式配置中心拉取一次新的服务处理逻辑，如此循环。从而，分布式配置中心在某一个24h的时间周期内接收到工作人员针对已经配置的某一业务产品C的服务处理逻辑进行修改调整的配置参数，从而针对该业务产品C的服务处理逻辑进行更新得到新的服务处理逻辑之后，该调度系统的终端设备即在系统当前时间到达下一个时间周期开始的时刻，主动的向该分布式配置中心发起一个“检测新的服务处理逻辑并返回”的服务请求，从而该分布式配置中心接收该服务请求在本地检测到该业务产品C的新的服务处理逻辑，并将该新的服务处理逻辑反馈给该终端设备，如此，该终端设备在接收到该新的服务处理逻辑之后，即针对本地各个节点机器上存储的业务产品C的原服务处理逻辑进行替换以实现对服务处理逻辑的更新处理。

需要说明的是，在本实施例中，配置为调度系统的终端设备被动接收分布式配置中心下发的数据更新通知，和主动的向该分布式配置中心拉取新的服务处理逻辑，可以同步执行或者择一执行，本发明客户服务的调度方法并不针对该执行方式进行具体的限定。

进一步地，在另一种可行的实施例中，本发明客户服务的调度方法除了通过分布式配置中心配置业务产品对应的服务处理逻辑之外，还可以直接在本地配置该服务处理逻辑，本发明客户服务的调度方法，还可以包括：

步骤D，在本地的各所述节点机器中配置生成全部所述业务产品各自的服务处理逻辑。

配置为调度系统的终端设备除了从分布式配置中心拉取全部业务产品各自的服务处理逻辑，还可以直接在本地的各个节点机器上配置与分布式配置中心相同的全部业务产品各自的服务处理逻辑，从而，该终端设备即可在进行目标服务处理逻辑的适配操作时，直接由对应的节点机器在本地存储的全部服务处理逻辑当中进行适配。

具体地，例如，请参照如图7所示的系统框架，配置为调度系统的终端设备在接收到客户发起的业务请求并提取到请求参数之前，通过接收工作人员输入的配置参数—如图4所示的协议代码，直接在本地各个节点机器的本地存储空间(固态存储介质)当中生成对应的配置文件进行存储，即，在本地各个节点机器的本地存储空间配置全部业务产品各自的服务处理逻辑

进一步地，在一种可行的实施例中，在上述步骤S10，获取待服务的业务请求并从所述业务请求中提取请求参数之后，本发明客户服务的调度方法，还可以包括：

步骤E，根据所述请求参数在各所述节点机器存储的各所述服务处理逻辑中适配目标服务处理逻辑。

具体地，例如，配置为调度系统的终端设备在从分布式配置中心拉取得到全部业务产品各自的服务处理逻辑，并将该全部服务处理逻辑存储在本地各个节点机器的本地存储空间之后，若该终端设备接收到客户发起的业务请求并提取到请求参数，则直接由本地任意一个节点机器将该请求参数中包含的产品编号与本地存储空间内保存的全部服务处理逻辑当中productCode字段的value值进行匹配，从而在确定该产品编号与该value值相等的情况下，读取全部服务处理逻辑当中对应的productBiz字段作为当前客户发起的该业务请求所属的产品的目标服务处理逻辑。

或者，如此，该终端设备在接收到客户发起的业务请求并提取到请求参数之后，由本地任意一个节点机器将该请求参数中包含的产品编号与本地存储空间内保存的全部服务处理逻辑进行匹配，从而读取得到当前客户发起的业务请求所属的产品的目标服务处理逻辑。

在本实施例中，通过配置为调度系统的终端设备在根据从客户所发起业务请求中提取的请求参数进行目标服务处理逻辑的适配操作之前，还可以预先从分布式配置中心将全部业务产品各自的服务处理逻辑均拉取到本地的各个节点机器上进行存储，如此，终端设备即可在进行目标服务处理逻辑的适配操作时，直接由对应的节点机器在本地存储的全部服务处理逻辑当中进行适配，或者，通过配置为调度系统的终端设备除了从分布式配置中心拉取全部业务产品各自的服务处理逻辑，还可以直接在本地的各个节点机器上配置与分布式配置中心相同的全部业务产品各自的服务处理逻辑，从而，该终端设备即可在进行目标服务处理逻辑的适配操作时，直接由对应的节点机器在本地存储的全部服务处理逻辑当中进行适配。

以及，通过配置为调度系统的终端设备实时的接收分布式配置中心下发的数据更新通知，该数据更新通知由分布式配置中心基于动态生效机制在针对本地配置的服务处理逻辑进行修改之后生成的，该终端设备在接收到该数据更新通知之后即按照该数据更新通知当中携带的修改内容将本地各个节点机器上存储的服务处理逻辑进行对应的更新处理；或者，通过配置为调度系统的终端设备除了被动接收分布式配置中心基于修改服务处理逻辑生成的数据更新通知之外，还通过按照预先设定好的预设时间周期循环主动的向该分布式配置中心拉取分布式配置中心基于对原服务处理逻辑进行修改后得到的新的服务处理逻辑，然后利用该新的服务处理逻辑针对该终端设备本地各个节点机器上存储的服务处理逻辑进行更新处理。

本发明相比于传统客户服务调度方式，将调度用的服务处理逻辑存储或者直接配置到调度系统的每个节点，即，配置为调度系统的终端设备在拉取分布式配置中心当中与服务处理逻辑相关的配置时，会将配置数据保存一份到每个节点机器上的本地，并且，还针对该配置数据进行实时的更新操作，从而，当分布式配置中心不可用或者基于成本无法单独设立该配置中心时，终端设备也可以直接读取本地的配置数据，正常执行客户服务的调度操作，进一步提升了客户服务调度的稳定性和整体效率。

进一步地，本发明还提供一种客户服务的调度系统，该客户服务的调度系统应用于消息客户端设备。请参照图8，图8为本发明客户服务的调度系统一实施例的功能模块示意图。如图8所示，本发明客户服务的调度系统包括：

获取模块10，用于获取待服务的业务请求并从所述业务请求中提取请求参数，以及，根据所述请求参数从预设的分布式配置中心获取目标服务处理逻辑，其中，所述分布式配置中心配置有全部业务产品各自的服务处理逻辑；

代码动态加载模块20，用于按照所述目标服务处理逻辑动态加载各业务模块代码文件；

客服调度模块30，用于执行所述业务模块代码文件以调度所述业务请求对应的客户服务。

进一步地，各所述业务模块代码文件中包括分配客户服务的模块代码文件，客服调度模块30，包括：

模型加载单元，用于执行所述分配客户服务的模块代码文件以加载预设的客户服务匹配模型，其中，所述客户服务匹配模型基于客户特征和客户服务特征进行深度学习训练得到；

客服适配单元，用于利用所述客户服务匹配模型适配所述业务请求对应的客户服务，并调度所述客户服务。

进一步地，所述请求参数包括：发起所述业务请求的客户的客户标识和所述业务产品的产品标识，所述客户服务匹配模型的数量大于一,模型加载单元，包括：

适配子单元，用于按照所述产品标识在所述分配客户服务的模块代码文件中适配算法模型编号；

确定子单元，用于确定所述算法模型编号在各所述客户服务匹配模型中对应的目标客户服务匹配模型；

计算子单元，用于根据所述客户标识计算得到模型版本号；

加载子单元，用于在所述目标客户服务匹配模型的各待选版本中，加载所述模型版本号指向的目标版本的模型。

进一步地，客服适配单元，还用于若检测到所述客户服务匹配模型故障，或者检测到所述客户服务匹配模型输出的模型计算结果的偏移量超过预设偏差阈值，则动态加载新的客户服务匹配模型以适配所述业务请求对应的客户服务。

进一步地，本发明客户服务的调度系统，还包括：

逻辑存储模块，用于从分布式配置中心中获取全部所述业务产品各自的服务处理逻辑，并将各所述服务处理逻辑存储在本地的各节点机器当中；

逻辑生成模块，用于在本地的各所述节点机器中配置生成全部所述业务产品各自的服务处理逻辑；

本发明客户服务的调度系统的获取模块，还用于根据所述请求参数在各所述节点机器存储的各所述服务处理逻辑中适配目标服务处理逻辑。

进一步地，本发明客户服务的调度系统，还包括：

逻辑更新模块，用于接收所述分布式配置中心数据更新通知，并按照所述数据更新通知针对各所述节点机器存储的各所述服务处理逻辑进行更新；以及，按照预设时间周期从所述分布式配置中心获取更新后的新的服务处理逻辑，并利用所述新的服务处理逻辑针对各所述节点机器存储的各所述服务处理逻辑进行更新。

进一步地，逻辑更新模块，还用于获取针对所述目标服务处理逻辑的修改请求；以及，按照所述修改请求在所述分布式配置中心对所述目标服务处理逻辑进行修改得到新的服务处理逻辑。

其中，上述客户服务的调度系统中各个模块的功能实现与上述客户服务的调度方法实施例中各步骤相对应，其功能和实现过程在此处不再一一赘述。

本发明还提供一种计算机存储介质，该计算机存储介质上存储有客户服务的调度程序，所述客户服务的调度程序被处理器执行时实现如以上任一项实施例所述的客户服务的调度方法的步骤。

本发明计算机存储介质的具体实施例与上述客户服务的调度方法各实施例基本相同，在此不作赘述。

本发明还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现如以上任一项实施例所述的客户服务的调度方法的步骤。

本发明计算机存储介质的具体实施例与上述客户服务的调度方法各实施例基本相同，在此不作赘述。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。