第二章：系统架构设计——整体架构分层与模块划分

好，咱们直接进入正题。异常交易检测系统，说白了就是一个「找茬」的系统。每天几千万甚至上亿笔交易流过去，你得在毫秒级内判断哪笔有问题。这活儿不轻松，架构设计要是没想清楚，后面全是坑。

我个人习惯，做这类系统先画一张大图。把数据怎么来、怎么算、怎么分析、怎么告警，一条线捋清楚。今天我就把这张图拆开，跟你聊聊每一层我踩过的坑和积累的经验。

2.1 整体架构分层

我把系统分成四层：数据层、计算层、分析层、告警层。每层各司其职，层与层之间通过消息队列或API通信。为什么要这么分？你想想看，如果所有逻辑揉在一起，改一个规则就得重启整个服务，线上谁敢这么干？

2.2 数据层——地基要稳

数据层是整个系统的命根子。数据进不来，或者进来的是脏数据，后面全白搭。我在项目中遇到过最头疼的事，就是上游业务方改了字段格式没通知我们，结果模型跑出来的结果全是错的。

数据层主要干三件事：

• 实时采集：用Kafka做消息队列，吞吐量高、延迟低。我建议每个交易事件都带上时间戳和唯一ID，方便后续回溯。
• 离线存储：历史数据存HDFS或HBase。为什么要存？因为模型训练、回测分析都需要历史数据。嗯，这里要注意，存储周期至少保留90天，监管要求经常是180天。
• 数据清洗：空值填充、格式统一、异常值过滤。我曾经因为一个字段的时区没统一，导致凌晨的交易全部被误判为异常。

2.3 计算层——速度与精度的平衡

计算层是系统的「发动机」。实时场景用Flink，批处理场景用Spark。为什么这么选？说白了，Flink的毫秒级延迟适合做实时风控，Spark的吞吐量适合做离线特征计算。

计算层核心模块：

模块	技术选型	说明
实时特征计算	Flink + Redis	计算近5分钟交易频次、金额累计等
离线特征工程	Spark + Hive	生成用户画像、设备指纹等静态特征
指标聚合	Flink CEP	复杂事件处理，比如「同一IP多账户登录」

我记得有一次，实时特征计算用Flink的滑动窗口，窗口大小设了10分钟，结果业务方说「用户刚登录就下单，你们怎么没检测到？」。后来改成1分钟滑动窗口，问题就解决了。窗口大小这个参数，真得根据业务场景调。

2.4 分析层——规则与模型的博弈

分析层是决策中心。我把它分成两条线：规则引擎和机器学习模型。两条线并行，结果取并集或加权融合。

规则引擎：用Drools或自研规则引擎。规则要可配置、可热更新。我曾经见过一个团队，改一条规则要重启服务，每次上线都提心吊胆。你想想看，线上风控规则一天改好几次，重启一次丢多少数据？

机器学习模型：XGBoost和LightGBM是主流。为什么不用深度学习？因为风控场景讲究可解释性。监管问你「为什么判定这笔交易异常」，你得能说出个一二三。树模型的特征重要性排序，就是最好的解释。

2.5 告警层——最后一公里

告警层是跟用户打交道的界面。检测出异常不算完，你得让该知道的人知道，并且能快速处理。

告警方式：

• 实时推送：WebSocket或长轮询，推送到风控后台。延迟控制在1秒内。
• 工单系统：生成工单，分配给审核人员。工单要包含上下文信息：交易时间、金额、设备指纹、历史行为等。
• 可视化大屏：实时展示异常交易趋势、告警类型分布、处理时效等。老板喜欢看这个。

嗯，这里有个细节：告警要分级。红色告警直接阻断交易，黄色告警进人工审核，蓝色告警只记录不处理。别一上来就全阻断，用户体验会崩的。

2.6 技术选型原则

技术选型这事儿，我踩过太多坑了。总结几条原则：

1. 成熟优先：选社区活跃、文档齐全的开源组件。别为了炫技用冷门框架，出了问题连个问的人都没有。
2. 团队匹配：团队擅长Java就用Flink，擅长Scala就用Spark。强行换技术栈，学习成本太高。
3. 可运维性：组件要有完善的监控和日志。我曾经用过一个流处理框架，出了异常连堆栈都打不全，排查问题跟大海捞针一样。
4. 成本可控：实时计算集群很贵。如果业务量不大，用批处理+短周期调度也能满足需求。别一上来就上Flink集群，先算算账。

好了，架构设计这块就聊到这儿。记住一句话：架构是服务于业务的，别为了架构而架构。下一层咱们会深入数据层的具体实现，到时候再细聊。