近这一年大部分都在做贷款业务的风控部分开发，有一些个人的体会和演变之路记录一下。
首先，金融贷款类业务风控部分是非常重要的一块核心，主要包含用户的授信，贷款工单审核，复贷提额策略，其中又包括用户的信用分、评分卡，贷前、贷中的A、B模型。
其实说白了，风控的核心作用就是与黑产的对抗和对用户所有操作的可控，发散到商城toB领域，可以通过风险的实时计算，对商家提供有效的实时控制，这是迭代到现在的版本。
什么是风控规则？
说白了就是一个判断逻辑，比如用户逾期超过3天，触碰了这个条件，给与它对应的处置，比如额度减半或者不再允许复贷。规则按复杂度分又分单体决策规则和组合命中规则，单体决策规则就是某一条件触发，决定它是通过还是拒绝还是其他触碰条件（比如降额），而复合规则就是比如一个规则为贷款用户性别为女性，借贷类app数量超过3个，通讯录联系人超过30，这是三个子规则，单个命中不起决策，一起命中决定它的决策。而多个子规则通过灵活匹配，进行组合的规则就是复杂性规则。其次就是发散性决策树规则，是通过子决策阈值进行发散性校验的。
怎么构建？
1 硬编码
用户量不超过30w，借款用户不超过10w，所有规则集不超过50个判定规则的这种小贷产品，就是我们初始化阶段，一般为了节省成本、开发效率、运行效率，会把规则集判定写入到程序代码里面，于是就出现这种代码：
这种就是传统的，通过rule规则集，进行循环遍历决策，大致有几种情况：
1 数据源目标为null，即不确定规则是否命中，uncertain
2 规则不起决策，只记录用户数据源值，不决策
3 规则未命中，记录风控阈值，不决策
4 规则命中，决策拒绝、通过、其他操作，复合子规则暂存。
这种方式的开发，就会导致你的业务线不灵活，存在大量冗余代码，大量操作判定，策略中心每生成一个新的风控策略，开发需要新增循环判断代码，测试需要全部规则测试，造成大量重复性工作累积。虽然可以将所有公用类判定代码提取出来，比如这样：
很明显，这种操作是非常弱智的，随着操作的递增，你的业务重构复杂度会越来越高，这种硬编码的方式，随着规则的累加，越来越不可取。
2 规则引擎
当时随着业务的递增，就开始考虑使用基于rete算法的doorls引擎进行业务整合重构。
什么是rete算法？
怎么构建整合doorls？
doorls又带来了什么问题？
下一篇写吧。