【导语】2017年下半年正值金融P2P行业多头爆发，问题平台以每月100家左右的速度激增；风险上升爆表的一年，风险政策为应对风险在短时间内推出了N多的规则，且在快速的进行迭代，作为技术团队，我们需要怎样来适应这个变化？
拍拍贷业务线规模庞大，涉及风控策略几百个，对应规则更是成千上万，任何一点风吹草动，都可能衍生出一大批规则，如何快速的让这些规则应用到业务上，成为了我们关注的重点。
【案例】我们先看一个简单案例，了解一下什么是规则
从图中可以看出，规则主体(绿色)部分包含字符串大小比较(评级>D)，逻辑十分简单，我们完全可以通过硬编码的方式实现，if…else….可以胜任，但是当这个判断的数量变成几十、甚至几百个的时候，那将是满屏的if…else…想想都很壮观，且这些规则是随时都可能调整的，那么必然带来如下缺点：
- 规则由开发人员编写维护，增加与业务的沟通成本
- 规则数量庞大的情况下，可维护性差
- 规则迭代的成本高，开发、测试介入，走上线流程
- 代码耦合性高
基于这种情况，我们目前底层采用了开源规则引擎Drools， Drools是一款业内比较主流也比较流行的开源规则引擎，通过Drools将规则的编写从业务逻辑中抽离出来，单独由规则制定人员进行实现。
规则的实现一般分为两个步骤：
- 使用workbench界面进行勾选，组合定义规则处理的对象，我们称为Data Object
- 在定义好Data Object之后，我们可以通过两种方式进行规则的编写：
一是通过DecisionTable的方式进行规则部署，这是一种通过表格定义规则的方式，由Drools提供模版格式，业务人员则可在其中进行规则的实现
此外还可以使用Drl进行规则的编写，Drl是Drools自带的一款domain specific language，其表述性声明式的编程语法简单直观，学习曲线也比较平缓，实现方式也更灵活。
在Workbench内查看规则Drl
DRL语言描述（转）
此外，Drools workbench也包含了用户分组管理，域管理，权限管理等功能，可以帮助业务团队更好进行业务的切分与规划。同时规则的启用与关闭也可在界面上进行简单操作实现。因此，在面向业务人员的终端功能方面，Drools基本可以满足业务需求解决规则实现问题。
不过作为一个线上应用，我们同时还需要考虑到其在系统端与其他应用进行交互与协作，在此过程中，我们发现了诸多值得优化的地方，例如规则处理对象Data Object在实际生产调用过程中作为Drools调用入参存在限制强，灵活度低的问题，因此我们进行了额外的开发和封装，衍生出了新的Drools服务框架【kie-server web方式】
新框架主要分以下几个模块：
一、资源管理
资源管理模块，主要用于控制规则版本的上线操作，在新版本规则被发布到Kie Server上，且其它准备工作完成之后，在后台手动确认使用新版本规则
二、知识库
这里的知识库概念，对应的是每个规则包需要的变量集合及模板，以drools api访问格式进行存储
三、模板配置
提供在线编辑每条业务线所需的变量，实时新增/废弃变量以及默认值的处理，保证上流应用调用的稳定
调用关系如下（已简化）
以上将规则入参以配置的方式从业务代码中提取出来，提升开发效率的同时，也带来了新的问题，就是当大规模业务线需要新的维度变量的时候，一次需要修改N多的模板，操作起来枯燥、乏味，且效率较低。
因此我们进行了以下规划与优化：
- 将变量中心集成进来，并按照类型进行分类，让模板配置可灵活选择
- Drools字段名称定义跟变量中心名称保持一致，便于生成新的模板
- 动态勾选完成，可推送至所选业务线（多选），解决多业务线共用一组变量问题
- 规则版本的灰度
- 规则有效性检测
通常规则引擎的使用场景，主要还是基于real-time on-demand的业务处理和调用，每个业务单元在收集完单元所需的信息之后，通过drools API的单条调用，得到业务决策结果。不过这样单元级别的系统调用方式只是风控策略的其中一种使用场景，事实上，风控策略对于历史信息也会需要诸多的业务决策，这样的决策实现方式更多是采用批处理的方法，而批处理的方法当然也可以使用逐条进行调用来实现，但实际上这样的方式其实是非常低效的。因此我们通过Embed的方式，修改了对规则的调用实现
将Source 的Drl文件拷贝至项目工程中，作为Local文件使用，使用的过程中，这些文件会被编译并会预加载至内存中，然后从外部获取规则所需数据，通过CommandFactory工具加载基于Command的数据结构，由命令执行器来进行执行。结果集ExecutionResults是对入参Object的一个再加工，可直接进行转换遍历。
其优点：
- 分批次执行，效率大大提升
当然也存在一些问题：
- 规则中静态匹配数据量较大，且没有防重复执行的时候，批量执行容易将机器CPU打满
- 其部署方式，需要手动解压规则包，Drl文件需要手动添加到固定地址，更换较麻烦，效率较低
对此我们也做了如下的优化：
- 规则编写完成之后，bulid到远程maven仓库
- 本地工程直接引用最新版的规则库LATEST
- 通过反射将本地key映射到maven库中最新jar对应的对象上
- 本地通过KieScanner定时检测远程maven仓库，设置时间间隔，拉取最新规则
- 由此可实现规则执行过程中动态更新规则
此外，Drools在批处理的使用过程中，如果通过web方式进行交互，那么必然需要维护一份规则中要用的object，硬编码和配置；如果通过Embed方式进行交互，本地也需要维护一份反射对象，这两种方式都不是很完美，是否可以结合两者，将反射对象剥离出来，既简化了模板配置，又可以避免模板转化的繁琐。
吴萧