第4章 分析层设计：实时分析引擎、规则引擎与异常检测

分析层是整个审计分层架构里最核心的一环。说白了，前面的采集层把数据捞上来，存储层把数据存好，但真正产生价值的判断，全在这层完成。我个人习惯把分析层拆成三个引擎：实时分析引擎、规则引擎、异常检测算法。它们各司其职，又相互配合。

为什么会这么分？你想想看，一条请求日志过来，你可能需要马上判断它是否超时，需要匹配一组复杂的业务规则，还需要看看它的行为模式是否偏离了历史基线。这三件事，用同一个工具去做往往吃力不讨好。分而治之，才是工程上的正解。

4.1 实时分析引擎：选型与实战

实时分析引擎解决的是“高频、低延迟、可容错”的流式计算问题。我在项目中主要接触过两个：Flink 和 Spark Streaming。这里我直接对比一下它们在审计场景下的真实表现。

对比维度	Flink	Spark Streaming
计算模型	真正的逐事件流处理	微批次处理（Micro-batch）
延迟水平	毫秒级（sub-second）	秒级（通常2-10秒）
状态管理	原生支持，强大灵活	依赖外部状态存储
事件时间语义	原生支持，精准	支持，但精度略低
审计场景适用性	高，适合实时规则计算	中，适合准实时聚合统计

我个人更倾向于 Flink。尤其是做服务接口审计时，延迟就是生命线。一个接口调用异常，你希望它发生后的几百毫秒内就能触发告警，而不是等到下一批数据凑齐才处理。我记得在一个项目中，我们需要对每秒超过10万条请求做实时延迟计算，Spark Streaming的微批次模型在批次边界上总是有积累延迟，切到Flink后，延迟直接降了一个数量级。

下面是一个典型的 Flink 作业结构，用于计算接口的实时成功率：

DataStream<AuditEvent> source = env
    .addSource(new KafkaSourceBuilder<>()
        .setBootstrapServers("kafka:9092")
        .setTopics("audit_logs")
        .build());

// 按接口分组，计算滑动窗口内的成功率
source
    .keyBy(event -> event.getApiName())
    .window(SlidingEventTimeWindows.of(
        Time.seconds(10), Time.seconds(2)))
    .aggregate(new SuccessRateAggregator())
    .filter(rate -> rate.getValue() < 0.95)
    .addSink(new AlertSink());

这里用了一个滑动窗口，每2秒算一次过去10秒的数据。如果成功率掉到95%以下，就直接发告警。嗯，要注意窗口大小的设置——太短容易抖动，太长就失去实时性了。

4.2 规则引擎实现：Drools 的生产实践

规则引擎解决的是“复杂条件逻辑的解耦问题”。审计规则经常会变——今天要加一个校验，明天要调整一个阈值。如果把规则硬编码在代码里，那你每次都要改代码、编译、上线。Drools 这类规则引擎，就把规则从代码中抽离出来，变成可配置、可热更新的知识库。

Drools 的规则文件（DRL）写起来大概是这样的：

rule "接口超时严重告警"
when
    $event: AuditEvent(
        responseTime > 5000,
        statusCode == 408
    )
then
    Alert alert = new Alert($event);
    alert.setLevel(AlertLevel.CRITICAL);
    alert.setMessage("接口" + $event.getApiName() + "发生严重超时");
    drools.insert(alert);
end

你看，规则的表达非常接近自然语言了。业务人员甚至可以在理解语法的基础上，自行调整参数。不过，我这里有个避坑指南——我曾经在项目中遇到过一个严重的性能问题：当规则库膨胀到几百条时，Drools 的 rete 网络编译时间越来越长，内存占用也节节攀升。后来我们做了两点优化：一是按业务域拆分规则包，用 agenda-group 控制执行顺序；二是对高频命中的规则做前置过滤，避免每来一条事件都跑全量规则。

规则规模	优化前	优化后
50条规则	2ms/事件	0.5ms/事件
200条规则	15ms/事件	1.2ms/事件
500条规则	OOM 风险	2.5ms/事件

决策表也是 Drools 的一个好用的功能。你把规则写成 Excel 表格，Drools 能直接编译成规则。说白了，就是让非技术人员也能参与规则维护。

4.3 异常检测算法：从统计到机器学习

规则引擎能覆盖已知的、明确的异常。但审计场景里，大量问题是“未知的异常”——比如一个接口的调用量突然翻倍，但状态码全是200。这不违反任何规则，但明显不对劲。这时候就需要异常检测算法。

我个人把异常检测算法分成三个层次，按实施难度递进：

1. 统计阈值法： 简单粗暴。比如用滑动窗口计算均值±3σ，超出就告警。容易计算，但对陡变不敏感。
2. 时序分解法： 把指标分解成趋势、周期、残差。残差异常就是异常。常用 STL 分解或移动平均。
3. 机器学习模型： 使用孤立森林、LOF 或基于 LSTM 的预测误差分析。准确率高，但需要训练数据。

我建议的渐进式路径是这样的： 先用统计法跑起来，积累数据。等数据量大了，再上时序分解。最后，在核心接口上尝试机器学习模型。一步到位往往不现实，我之前尝试跳过第一步直接上LSTM，结果模型没训练好，反而漏报了一堆真实问题。

下面是一个简单的异常检测代码片段，使用移动平均法：

public class MovingAverageDetector {
    private final double[] buffer;
    private double sum = 0;
    private int index = 0;
    private int count = 0;

    public MovingAverageDetector(int windowSize) {
        buffer = new double[windowSize];
    }

    public boolean isAnomaly(double value) {
        double avg = sum / count;
        double score = Math.abs(value - avg) / avg;
        // 如果偏差超过50%，标记为异常
        return score > 0.5;
    }
}

当然，这个例子很简单。真正生产环境还需要考虑衰减窗口、自适应阈值、季节性调整等。但我一直觉得，简单可靠比复杂无用要好一万倍。

下面我把本章的三个核心组件画成了一张关系图，你可以看看它们之间是怎么协作的。