|
背景 随着金融环境的剧烈变化及人们悄然转变的消费习惯，金融行业的业务变化愈加频繁和剧烈。尤其是风控和反欺诈场景，涉及规则成百上千。 这类经常变更的业务规则让公司开发人员和运营人员都非常头疼。按照产品开发的传统方式，通常是在程序代码或配置文件中不断添加逻辑判断，来实现业务规则。但这种方式、会出现如下弊端：（1）增加开发人员与测试人员的工作量。（2）部门间需要更加频繁地进行业务沟通，时间成本增加。（3）增加用人成本，造成公司损失。如何解决这些弊端成了技术部门的重要任务之一。规则引擎的出现完美地解决了这个问题。 如何通过规则引擎解决上述问题呢？ 将复杂且多变的业务规则从硬编码中解放出来，以规则脚本的形式存放在文件或特定的存储介质中（这里可以是数据库表），使得业务规则的变更不需要修正项目代码、重启服务器就可以在线上环境立即生效。这样就将业务决策从程序代码中分离出来，使其代码与业务解耦。通过特定的语法内容编写业务模块，由API进行解析并对外提供执行接口，再接收输入数据、进行业务逻辑处理并返回执行结果。而我们选择用的规则引擎就是Drools 为什么选用Drools？ Drools与其他规则引擎对比： 图一：Drools对比图 由图一对比得出Drools与相对于其他规则框架有以下优势： 1. 非常活跃的社区支持（JBoss支持）； 2. 快速的执行速度； 3. 完善的功能； 4. 国外金融领域使用比较多； 什么是Drools？ Drools是为Java量身定制的基于Charles Forgy的RETE（RETE的详细介绍：https://blog.csdn.net/sdmxdzb/article/details/81461744）算法的规则引擎的实现。具有了OO接口的RETE,使得商业规则有了更自然的表达。 Rule是什么呢？ 一条规则是对商业知识的编码。一条规则有 attributes ，一个 Left Hand Side （ LHS ）和一个 Right Hand Side （ RHS ）。Drools 允许下列几种 attributes ：salience ， agenda-group ， no-loop ， auto-focus ， duration ， activation-group 。 规则的 LHS 由一个或多个条件（ Conditions ）组成。当所有的条件（ Conditions ）都满足并为真时， RHS 将被执行。RHS 被称为结果（ Consequence ）。LHS 和 RHS 类似于 if（<LHS>){ <RHS> } 下面介绍几个术语： 对新的数据和被修改的数据进行规则的匹配称为模式匹配（ Pattern Matching ）。进行匹配的引擎称为推理机（ Inference Engine ）。被访问的规则称为 ProductionMemory ，被推理机进行匹配的数据称为 WorkingMemory 。Agenda 管理被匹配规则的执行。推理机所采用的模式匹配算法有下列几种：Linear ， RETE ， Treat ， Leaps 。这里注意加红的地方，对数据的修改也会触发重新匹配，即对 WorkingMemory中的数据进行了修改。 然后规则引擎大概是这个样子的： 这个图也很好理解，就是推理机拿到数据和规则后，进行匹配，然后把匹配的规则和数据传递给Agenda。 规则引擎实现了数据同逻辑的完全解耦。规则并不能被直接调用，因为它们不是方法或函数，规则的激发是对 WorkingMemory 中数据变化的响应。结果（ Consequence ，即 RHS ）作为 LHS events 完全匹配的 Listener 。 数据被 assert 进 WorkingMemory 后，和 RuleBase 中的 rule 进行匹配（确切的说应该是 rule 的 LHS ），如果匹配成功这条 rule 连同和它匹配的数据（此时就叫做 Activation ）一起被放入 Agenda ，等待 Agenda 来负责安排激发 Activation （其实就是执行 rule 的 RHS ），上图中的菱形部分就是在 Agenda 中来执行的， Agenda 就会根据冲突解决策略来安排 Activation 的执行顺序。 下面附上drools规则引擎的执行过程: 反欺诈平台规则引擎使用案例 由某行反欺诈平台执行过程为例： 图二：某银行反欺诈平台数据架构 如图二以监管部门发布的【146号文】中关于基于大基数技术的风险防控、ⅡⅢ类银行账户管理相关监管考核内容数据流向为例,数据源获取从三个方向获取：1.行内数据（例如用户交易数据）推送到Kafka中，利用Flink实时消费Kafka中的数据，将清洗过后的数据通过Flink对数据进行处理后保存到Redis；2.我们以行内外数据为数据源，接入黑白名单列表，保存到ElasticSearc;3.通过欺诈交易组合查询接口获取其他数据。然后由银行全渠道交易调用风险查询接口在不降低客户体验满意度的前提下实现对交易事前、事中和事后的风险侦测、识别、处理，快速、动态和全面控制电子银行业务风险，推动银行业务快速、健康、安全地发展。 结束语 数据解决方案部已经在部分银行将规则引擎应用到风控，反欺诈等多个业务场景。规则引擎的运用，不仅简化了系统的复杂度，而且提高了系统的可维护性；同时相对独立的开发模式，使得开发人员只需关注业务逻辑，灵活应对业务需求的变动，节约了项目成本，避免服务停机重启。未来还会有更多业务与规则解耦的运用场景，Drools将会成为主流的解决方案 |
|
|
