基于规则引擎在催收业务中实现高效的案件分配

原创 LJie 拍码场

业务背景

在信贷业务中，客户逾期后会交由专门的催收员进行催收跟进。

在催收业务的开展过程中，我们从两方面来提升业务的精细运营：

客户端：不同的客户具有不同的特征，例如：逾期天数不同、金额不同、借款产品不同等。不同特征的用户，我们需要采用不同的催收策略去跟进。

业务端：催收作为人力密集的行业，为了提升人员工作效率，我们对催收员做了精细的划分，例如：逾期天数较长催收难度的客户会交给经验丰富的人员来催收，或者直接委外给外包公司。不同属地的客户交给该地区的催收公司跟进，可以更方便的跟进。

案件分配系统解决的问题就是如何高效的实现客户端的案件与业务端催收员的关系。

解决思路

结合上面介绍的业务背景，在催收业务分配中，逾期客户与催收经办的匹配是基于多种数据维度与多种分配策略的。

为了实现灵活的分案策略管理，在分案系统设计中，遵循两个原则。

逻辑和数据分离

数据位于“域对象”中，业务逻辑位于“规则”中。

策略和执行分离

业务策略位于“规则系统”中，具体执行位于“执行系统”中。

选型- 规则引擎：让策略变得更加平易近人

采用规则引擎使用场景分析

- 需要快速做出响应和决策

- 规则变更期望脱离于开发人员，脱离复杂coding

- 有不确定性的需求，变更频率较高

- 流程分支非常复杂，希望有专人维护

规则引擎 Drools的优点

- 将业务策略剥离出程序，交给专门的业务分析团队管理，及时响应策略变更

- 减少编写“硬代码”业务规则的成本和风险

- 应付特殊状况，即一开始没有提到要将业务逻辑考虑在内- PPD内部有很多其他团队使用 Drools，运用经验成熟

系统方案及落地

系统架构视图

在系统设计中，遵循的主要思路是将经常变更的策略模块与不变化的执行模块尽可能的剥离开。

规则引擎
负责管理所有的业务规则
- 案件是否入催（eg：特殊原因是否停催、敏感地区是否停催等）
- 案件选择什么样的催收方式（eg：自动外呼形式、人工催收方式）、
- 各家催收公司（包含自有分公司与外包公司）的负荷管理（eg：A公司是B公司人均系数的80%、C公司定量1000个案件等）
- 各小组的负荷管理（eg：A小组采用平均分配的方式、B小组采用注水法分配、C小组定量等）
执行器

负责从各个支撑系统获取逾期客户数据，并且组装好后送到规则引擎，获取策略结果并执行

在落地过程碰到的问题及解决方案

在项目实施落地过程中，碰到了一些技术问题，这里也记录一下我们的解决方案，希望可以给遇到同样问题的人带来帮助。

1. XML序列化中 JAXB 的性能问题

> 问题现象：在与Drools规则引擎的交互中，需要将入参XML序列化后传入，我们使用的JDK原生的 JAXB 来实现序列化，发现在每次 Unmarshal 时平均耗时都在1s以上，而且运行时会导致CPU 使用率上升。<br>

而分案系统每次的运行都会与Drools交互百万次以上，所以会导致系统的吞吐很低。

> 解决方式：经过测试下来，发现最耗时间和CPU的操作是在 JAXBContext对象的实例化上，所以解决问题的思路是减少JAXBContext对象的实例化。

经过分析与测试，JAXBContext实例对象是线程安全的，可以放心共享使用。但是JAXBContext对象的Marshaller实例对象和Unmarshaller实例对象都是非线程安全的。

所以我们采用的方式是采用单例模式，在应用程序启动时实例化一次 JAXBContext，并将JAXBContext对象放在Spring容器里，在使用的时候直接从容器里取出。

> 示例代码

// JAXBContext初始化@Configurationpublic class XMLConfiguration {    @Bean(name = "requestJAXBContext")    public JAXBContext jaxbContext() throws JAXBException {        return JAXBContext.newInstance(PreSelectCaseDroolsRequestDto.class);    }}// JAXBContext使用JAXBContext context= (JAXBContext) SpringContextUtil.getBean("requestJAXBContext");Marshaller marshal = context.createMarshaller();