第4章规则引擎实战

4、规则引擎实战：规则编写与测试、规则热加载、规则优先级与冲突处理

规则引擎这东西，说白了就是风控系统的「大脑」。我见过不少团队，花大价钱买了规则引擎，结果写出来的规则一塌糊涂，要么跑不动，要么互相打架。今天咱们就来聊聊，怎么把这个「大脑」用好。

4.1 规则编写：从自然语言到可执行代码

规则编写是基本功。我习惯把规则拆成三部分：条件、阈值、动作。举个例子：

「如果用户登录IP在30分钟内变化超过3个城市，且登录设备为模拟器，则直接拒绝交易。」

这条规则翻译成代码，大概长这样：

rule "异地登录+模拟器检测"
    when
        $loginEvent : LoginEvent(ipCityChangedCount > 3, timeWindow < 30min)
        $deviceInfo : DeviceInfo(isEmulator == true)
    then
        $riskResult.setAction("REJECT");
        $riskResult.setReason("疑似盗号行为");
end

嗯，这里要注意：条件不要写得太复杂。我曾经接手过一个项目，一条规则里塞了十几个条件，结果排查问题花了三天。你想想看，维护起来得多痛苦？

我的习惯：每条规则的条件控制在5个以内。超过5个，就拆成多条规则，或者用规则集来管理。

4.2 规则测试：别让线上环境背锅

规则写好了，怎么测？我见过最坑的做法是——直接上线试。结果呢？误杀了一堆正常用户，业务方直接炸了。

我个人建议，测试分三步走：

单元测试：用JUnit或TestNG，模拟各种输入，验证规则输出是否正确。
回放测试：拿历史数据跑一遍，看看新规则和老规则的结果差异。
灰度测试：先切1%的流量，观察一段时间，没问题再全量。

这里给个单元测试的示例：

@Test
public void testEmulatorRule() {
    // 构造一个模拟器登录事件
    LoginEvent event = new LoginEvent();
    event.setIpCityChangedCount(5);
    event.setTimeWindow(20);
    event.setDeviceType("emulator");

    // 执行规则引擎
    RiskResult result = ruleEngine.evaluate(event);

    // 验证结果
    assertEquals("REJECT", result.getAction());
    assertEquals("疑似盗号行为", result.getReason());
}

避坑指南：我曾经因为测试数据没覆盖边界情况，导致线上漏过了一批高风险交易。后来我养成了习惯——边界值一定要测，比如阈值的上下限、空值、异常值。

4.3 规则热加载：不停机更新规则

业务变化快，规则也得跟着变。总不能每次改规则都重启服务吧？那用户体验得多差。

规则热加载，说白了就是在不重启应用的情况下，动态更新规则。实现方式主要有两种：

方式	原理	优点	缺点
文件监听	监听规则文件的变化，自动重新加载	实现简单，无需额外组件	分布式环境下同步困难
配置中心	将规则存储在配置中心（如Apollo、Nacos）	支持分布式，版本管理方便	需要引入配置中心组件

我个人更推荐用配置中心的方式。为什么呢？因为分布式环境下，文件监听很难保证所有节点同时更新。你想想看，A节点已经用了新规则，B节点还在用旧规则，那结果能一样吗？

用Nacos实现热加载的伪代码：

@Component
public class RuleHotLoader implements ApplicationListener<ConfigChangeEvent> {

    @Override
    public void onEvent(ConfigChangeEvent event) {
        // 获取最新的规则内容
        String newRuleContent = event.getNewValue();
        
        // 重新编译规则
        KieBase newKieBase = compileRule(newRuleContent);
        
        // 替换旧的规则库
        ruleEngine.replaceKieBase(newKieBase);
        
        log.info("规则热加载完成，时间：{}", System.currentTimeMillis());
    }
}

  关键点：热加载时，一定要保证原子性。也就是说，要么全部更新成功，要么全部回滚。我曾经遇到过加载一半服务挂了，结果新旧规则混在一起，那叫一个乱。

4.4 规则优先级：谁先谁后，得有个说法

规则多了，就得排个序。优先级决定了规则执行的先后顺序。我见过最典型的错误——所有规则优先级都一样，结果每次执行结果都不一样。

规则优先级的设计原则：

高优先级规则先执行：比如「黑名单直接拒绝」这种规则，优先级应该最高。
低优先级规则后执行：比如「用户画像分析」这种辅助规则，优先级可以低一些。
同优先级按顺序执行：如果优先级相同，就按规则定义的顺序执行。

在Drools中，设置优先级很简单：

rule "黑名单检测"
    salience 100  // 优先级，数值越大越先执行
    when
        $user : User(blacklist == true)
    then
        $riskResult.setAction("REJECT");
end

rule "用户画像分析"
    salience 50   // 优先级较低
    when
        $user : User(age > 30, income > 10000)
    then
        $riskResult.addTag("高价值用户");
end

我的经验：优先级数值不要用1、2、3这种小数字。为什么？因为后期加规则时，很容易插不进去。我习惯用10的倍数，比如10、20、30，这样中间还能插。

4.5 规则冲突处理：别让规则「打架」

规则冲突，说白了就是两条规则对同一个事件给出了不同的结论。比如：

规则A说「这个用户是高风险，拒绝」
规则B说「这个用户是VIP，放行」

那到底听谁的？

处理冲突，我总结了三种策略：

策略	说明	适用场景
优先级优先	优先级高的规则说了算	大多数场景
最严格优先	取风险最高的结论	金融风控、安全场景
投票机制	多条规则投票，少数服从多数	需要综合判断的场景

我个人习惯用「最严格优先」。为什么呢？因为风控的本质是宁可错杀，不可放过。你想想看，放行一个高风险用户，可能损失几十万；误杀一个正常用户，最多就是赔个礼道个歉。

避坑指南：我曾经遇到过一个案例，规则A和规则B互相矛盾，结果系统陷入了死循环。后来我加了一个冲突检测机制——每次规则变更时，自动扫描所有规则，发现冲突就报警。这个机制救了我好几次。

4.6 知识体系总览

说了这么多，咱们用一张图来总结一下规则引擎实战的核心逻辑：

这张图把规则引擎实战的核心知识点串起来了。从规则编写开始，经过测试、热加载、优先级管理，最后到冲突处理，每一步都有坑，每一步也都有解法。

好了，这一章的内容就到这里。记住一句话：规则引擎不是写出来就完事了，而是要在实战中不断打磨。希望这些经验能帮你少走一些弯路。

📚 课程目录

4、规则引擎实战：规则编写与测试、规则热加载、规则优先级与冲突处理

4.1 规则编写：从自然语言到可执行代码

4.2 规则测试：别让线上环境背锅

4.3 规则热加载：不停机更新规则

4.4 规则优先级：谁先谁后，得有个说法

4.5 规则冲突处理：别让规则「打架」

4.6 知识体系总览