4. 巡检系统架构设计：整体巡检流程架构图
金融特征 PSI 缺失巡检系统需要处理海量时序特征数据，并保证每日巡检的时效性与准确性。一个分层清晰的架构能够将数据采集、指标计算、异常告警与可视化展示解耦，便于各模块独立扩展与维护。本章详细阐述四层架构的设计方案及各模块职责。
4.1 整体巡检流程架构图
下图展示了巡检系统的核心分层结构，数据从左至右依次流经采集层、计算层、告警层与展示层，最终形成从原始数据到决策支持的完整闭环。
4.2 各模块职责与交互关系
四层架构中每一层都承担独立的职责，并通过标准化的接口与上下游进行数据交互。下表详细列出了各层的主要职责、核心组件及交互方式。
| 架构层 | 核心职责 | 关键组件 | 输出/交互方式 |
|---|---|---|---|
| 数据采集层 | 从多源异构数据源拉取特征数据，完成格式校验与缺失标记 | DataX、Canal、Kafka Connect、自定义采集 Agent | 输出标准化 JSON/Avro 消息至 Kafka Topic；或写入 Hive 分区表供批量读取 |
| 计算层 | 执行 PSI 指标计算、缺失率统计、分布偏移检测，并持久化结果 | Spark Structured Streaming、Flink Job、MySQL、Elasticsearch | 计算结果写入 MySQL 指标表；实时结果写入 ES 索引；通过 Redis 缓存中间结果 |
| 告警层 | 基于规则引擎与动态基线判断异常，执行分级告警与通知分发 | 告警规则引擎、AlertManager、通知网关（邮件/钉钉/企微） | 调用通知网关发送告警消息；将告警事件写入 ES 告警索引；回调展示层刷新看板 |
| 展示层 | 提供可视化看板、趋势分析、告警事件查询与报表导出能力 | Grafana、Kibana、自研 Web 管理后台 | 通过 SQL/ES DSL 查询计算层与告警层数据；提供 REST API 供外部系统调用 |
4.3 层间交互关系详解
各层之间的交互并非简单的单向数据流，而是包含同步与异步两种模式，以及必要的反馈回路。
- 采集层 → 计算层（异步消息驱动）：采集层将清洗后的特征数据以消息形式发送到 Kafka 指定 Topic。计算层通过订阅 Topic 实现流式消费，无需等待采集层全部完成即可开始计算，降低端到端延迟。
- 计算层 → 告警层（定时轮询 + 事件推送）：告警层定期（如每 5 分钟）从 MySQL/ES 拉取最新计算结果，与预设阈值进行比对。对于紧急异常（如 PSI > 0.25），计算层也可通过 RPC 直接推送告警事件，缩短响应时间。
- 告警层 → 展示层（数据查询 + 实时推送）：展示层通过 Grafana 数据源插件查询 ES 中的告警事件与指标趋势。同时，告警层通过 WebSocket 将新产生的告警实时推送到前端看板，实现秒级刷新。
- 展示层 → 采集层/计算层（配置下发）：运维人员通过展示层管理后台修改采集频率、计算参数或告警阈值，配置变更通过配置中心（如 Apollo/Nacos）下发到采集层与计算层，实现热更新。
架构设计要点：
- 解耦性：各层通过消息队列（Kafka）与配置中心解耦，单层升级或故障不影响其他层。
- 可扩展性：计算层与告警层支持水平扩展，通过增加节点应对特征数量增长。
- 数据一致性：采集层对每条数据生成唯一 ID，计算层通过幂等写入保证结果不重复。
- 可观测性：每层暴露 Prometheus 指标，通过 Grafana 监控各层处理延迟与吞吐量。
4.4 数据流与反馈闭环
下图展示了巡检系统中数据从采集到展示，再到配置反馈的完整闭环流程，突出展示了各层之间的双向交互关系。
实践建议：在初期搭建时，建议先实现采集层 → 计算层 → 展示层的主链路，确保数据能够正常流转与展示。告警层与配置中心可在主链路稳定后再逐步接入，降低首次上线的复杂度。