2. 实时监控体系架构:数据采集层、实时计算层、存储层、展示层整体架构设计
催收触达看板的实时监控体系,本质是一条从“原始事件”到“业务决策”的低延迟数据管道。本章将体系拆解为四个核心层次:数据采集层、实时计算层、存储层与展示层。每一层承担明确的职责,层与层之间通过标准协议解耦,确保整体架构可水平扩展、可故障恢复。
架构设计原则:催收场景对延迟极度敏感——从坐席外呼动作发生到看板指标刷新,端到端延迟必须控制在 5 秒以内。因此,本架构优先采用流式处理(Streaming)而非批处理(Batch),并避免在关键路径上引入磁盘 I/O 瓶颈。
2.1 四层架构总览
下图展示了实时监控体系的完整数据流向。从催收系统产生的原始事件日志,经过采集、计算、存储,最终在展示层以看板形式呈现给风控与运营人员。
2.2 数据采集层:事件捕获与缓冲
采集层是管道的起点,负责从催收系统的各个模块中无侵入地捕获原始事件。催收系统产生的典型事件包括:坐席外呼开始/结束、短信发送状态回执、IVR按键轨迹、AI语音对话节点等。
| 事件类型 | 数据源 | 采集方式 | 典型字段 |
|---|---|---|---|
| 外呼事件 | CTI 日志 / SIP 信令 | 日志文件采集(Filebeat) | 坐席ID、客户ID、开始时间、结束时间、结果码 |
| 短信事件 | 短信网关 API 回调 | HTTP 推送 → Kafka | 手机号、模板ID、发送时间、状态(成功/失败) |
| IVR 事件 | IVR 平台日志 | Syslog / Flume | 通话ID、按键值、节点ID、持续时间 |
| AI 语音事件 | AI 对话引擎日志 | Kafka Connect | 会话ID、意图标签、情绪评分、转写文本 |
关键设计要点:所有采集组件必须支持 断点续传(offset 管理)和 至少一次语义(At-Least-Once)投递。采集端引入 Kafka 作为统一缓冲层,既削峰填谷,又为下游多消费者提供数据重放能力。
2.3 实时计算层:流处理与异常检测
实时计算层是整个架构的“大脑”。它从 Kafka 消费原始事件,执行窗口聚合、指标计算、规则匹配等核心逻辑。催收场景下,计算层需要处理两类主要任务:
- 常规指标计算:按 1 分钟/5 分钟窗口,统计坐席外呼量、接通率、承诺还款率、短信送达率等 KPI。
- 异常波动检测:基于历史基线(如过去 7 天同一时段均值),判断当前指标是否超出阈值(如接通率骤降 20%),触发告警。
以下是一个基于 Flink 的窗口聚合伪代码示例,展示如何计算每分钟的坐席外呼接通率:
DataStream<CallEvent> events = env
.addSource(new FlinkKafkaConsumer<>("call_events", ...));
events
.keyBy(event -> event.getAgentId())
.window(TumblingProcessingTimeWindows.of(Time.minutes(1)))
.aggregate(new AggregateFunction<CallEvent, AgentStats, AgentMetrics>() {
@Override
public AgentStats createAccumulator() {
return new AgentStats();
}
@Override
public AgentStats add(CallEvent event, AgentStats stats) {
stats.totalCalls++;
if ("ANSWERED".equals(event.getResultCode())) {
stats.answeredCalls++;
}
return stats;
}
@Override
public AgentMetrics getResult(AgentStats stats) {
double connectRate = stats.totalCalls > 0
? (double) stats.answeredCalls / stats.totalCalls * 100
: 0.0;
return new AgentMetrics(stats.totalCalls, connectRate);
}
})
.map(metrics -> {
// 异常检测:如果接通率低于历史基线 20%,标记为异常
double baseline = getBaseline(metrics.getAgentId());
if (metrics.getConnectRate() < baseline * 0.8) {
metrics.setAnomaly(true);
}
return metrics;
})
.addSink(new FlinkKafkaProducer<>("metrics_output", ...));
注意:实时计算层必须设计 状态后端(如 RocksDB)来维护窗口状态和基线数据。同时,建议将异常检测规则外置到配置中心(如 Apollo/Nacos),支持热更新,避免因规则变更而重启作业。
2.4 存储层:分层存储与查询优化
存储层需要同时满足低延迟查询(看板秒级刷新)和高吞吐写入(每秒数万事件)两个矛盾需求。因此,采用分层存储策略:
| 存储类型 | 存储内容 | 选型方案 | 查询场景 |
|---|---|---|---|
| 热存储 | 最近 1 小时的聚合指标 | Redis(Hash + Sorted Set) | 看板实时曲线、Top-N 坐席排名 |
| 温存储 | 最近 7 天的分钟级聚合数据 | Apache Druid / ClickHouse | 趋势分析、同比/环比对比 |
| 冷存储 | 原始事件日志(全量) | Elasticsearch / HDFS | 明细追溯、离线分析、审计 |
下图展示了存储层内部的数据流转与查询路径:
2.5 展示层:看板渲染与交互
展示层直接面向风控运营人员、团队主管和高级管理层。它从存储层查询数据,以图表、表格、告警列表等形式呈现。催收触达看板的展示层需要支持以下核心能力:
- 实时曲线:每秒刷新外呼量、接通率、承诺还款率等关键指标,支持按坐席、队列、产品线等维度下钻。
- 异常告警弹窗:当计算层检测到异常波动时,看板顶部弹出告警条,并高亮对应指标。
- 历史对比:支持选择“今日 vs 昨日”或“今日 vs 上周同期”的叠加曲线。
- 明细跳转:点击聚合指标可跳转到对应的原始事件明细列表(从 ES 查询)。
选型建议:如果团队技术栈以 Java/大数据为主,推荐 Grafana + Druid/ClickHouse 组合,Grafana 原生支持实时刷新和告警。如果团队有前端自研能力,可基于 ECharts + WebSocket 构建定制化看板,实现更灵活的交互逻辑。
2.6 架构关键指标总结
| 层次 | 核心组件 | 延迟要求 | 扩展性策略 |
|---|---|---|---|
| 数据采集层 | Filebeat / Flume / Kafka | < 1 秒(端到端入 Kafka) | Kafka 分区扩展 + 采集端水平扩容 |
| 实时计算层 | Flink / Spark Streaming | < 3 秒(事件到指标输出) | TaskManager 并行度调整 + 状态后端优化 |
| 存储层 | Redis / Druid / ClickHouse / ES | < 1 秒(查询响应) | 读写分离 + 数据分片 + 冷热数据自动迁移 |
| 展示层 | Grafana / 自研看板 | < 1 秒(页面渲染) | CDN 静态资源加速 + 查询缓存 |