3. 规则命中监控系统架构设计

规则命中监控系统是精算模型从离线验证走向实时生产的关键桥梁。本章围绕“数据采集 → 规则计算 → 监控告警”三条主线，给出完整的架构设计、模块职责与技术选型依据。整体架构采用 Kafka + Flink/Spark Streaming + Redis + Prometheus 四层组合，兼顾高吞吐、低延迟与可观测性。

3.1 整体架构图

下图展示了规则命中监控系统的三层核心架构，以及各层之间的数据流与反馈回路。

3.2 各模块职责

下表详细列出每个模块的核心职责与关键设计约束。

3.3 技术选型与对比

核心组件选型基于实时计算场景的吞吐、延迟、状态管理与生态集成能力。下表给出关键对比与最终选型理由。

3.4 数据流与关键路径

一条规则从数据产生到告警触发，经历以下完整路径：

1. 数据接入： 业务日志 / CDC 事件 → Kafka 源 Topic（如 ods_rule_input）。
2. 规则加载： Flink 作业启动时从 Redis 加载全量规则元数据，并订阅 Redis 规则变更通道实现热更新。
3. 规则匹配： Flink 对每条消息执行规则引擎（如 Drools / 自研表达式引擎），命中后生成命中记录。
4. 状态聚合： 按规则 ID + 时间窗口聚合命中次数、金额、用户数等指标，写入 Redis 计数器。
5. 结果输出： 命中明细写入 Kafka 结果 Topic（如 dwd_rule_hit_detail），聚合指标暴露为 Prometheus Gauge。
6. 监控告警： Prometheus 定期拉取指标，Alertmanager 根据告警规则（如命中率突降 > 50%）触发通知。

3.5 高可用与扩展性设计

• Kafka 层： 源 Topic 与结果 Topic 均配置 3 副本，acks=all，min.insync.replicas=2，保证数据不丢。分区数按预估峰值吞吐的 2 倍预留，支持动态扩容。
• Flink 层： 启用 Checkpoint（间隔 30s，Exactly-Once 语义），状态后端使用 RocksDB 避免 OOM。作业并行度与 Kafka 分区数对齐，支持 Savepoint 停机升级。
• Redis 层： 采用主从 + 哨兵架构，读写分离。规则元数据缓存设置 TTL（默认 1h），计数器使用 Redis Stream 实现持久化，防止重启丢失。
• Prometheus 层： 使用联邦集群或 Thanos 实现多机房指标聚合。Alertmanager 配置高可用对（2 节点），避免单点告警遗漏。