2、需求分析与架构设计：业务需求梳理、技术选型原则、系统架构分层设计
好，咱们正式开始搭建合规监控系统。这一章很关键，说白了就是「画图纸」。图纸画不好，后面盖起来的楼肯定歪。我见过太多团队，上来就撸代码，结果做到一半发现需求没对齐，技术栈选错了，最后推倒重来。嗯，咱们不干那种傻事。
2.1 业务需求梳理：先搞清楚要监控什么
做合规监控，第一步不是选技术，而是搞清楚业务到底要什么。我个人习惯，先拉上业务方、法务、风控，开个需求对齐会。会上我会问三个问题：
- 监控什么数据？ 交易流水？用户行为？合同文本？还是舆情信息？
- 监控的规则是什么？ 是硬性指标（比如金额超过100万必须预警），还是软性判断（比如疑似洗钱模式）？
- 监控的时效性要求？ 实时拦截？还是T+1事后分析？
我在项目中遇到过，业务方说「我要实时监控」，结果一聊发现，所谓的实时其实是每5分钟跑一次批处理。你想想看，如果真按实时流处理去设计，成本翻好几倍，完全没必要。所以，需求一定要掰开揉碎了聊。
核心产出物：需求清单
梳理完后，我会输出一份结构化的需求清单，大概长这样：
| 需求编号 | 需求描述 | 数据来源 | 时效要求 | 优先级 |
|---|---|---|---|---|
| R001 | 单笔交易金额超过100万触发预警 | 交易流水表 | 实时 | P0 |
| R002 | 同一IP地址24小时内登录超过10个账号 | 登录日志 | 准实时（分钟级） | P1 |
| R003 | 合同文本中检测到敏感词 | 合同存储系统 | T+1 | P2 |
小技巧： 需求优先级用P0/P1/P2来标。P0是系统必须有的，没有就不能上线；P1是核心功能，可以稍微延后；P2是锦上添花。这样排期的时候心里有数。
2.2 技术选型原则：别追新，要追稳
技术选型这块，我踩过不少坑。曾经有个项目，团队非要上最新的流处理框架，结果文档不全，社区也不活跃，出了问题连个问的人都没有。最后灰溜溜地换回了成熟方案。
所以，我的技术选型原则就三条：
- 成熟度优先：选社区活跃、文档齐全、有大量生产案例的技术。比如消息队列用Kafka，流处理用Flink，存储用ClickHouse或Elasticsearch，这些都是经过验证的。
- 团队能力匹配：你团队里没人懂某个技术，硬上就是给自己挖坑。我建议，选型前先做个技术摸底，看看团队擅长什么。
- 可扩展性：合规监控的数据量会越来越大，规则也会越来越复杂。选型时要考虑水平扩展能力，别一开始就选了个单机版。
避坑指南： 我曾经选了一个号称「全栈实时计算」的框架，结果发现它不支持自定义规则的热加载。每次改规则都要重启服务，业务方差点没把我吃了。所以，规则热加载这个能力，一定要在选型时确认清楚。
2.3 系统架构分层设计：四层架构，各司其职
好，需求清楚了，技术选型原则也定了，接下来就是画架构图。合规监控系统，我习惯分成四层：采集层、处理层、存储层、展示层。每一层各司其职，层与层之间通过标准接口通信。
下面这张图，是我手绘的架构逻辑，用SVG画出来，方便你理解：
你看，数据从下往上流。采集层负责把数据捞进来，处理层做计算和判断，存储层把结果存好，展示层把结果呈现给用户。每一层都有明确的边界。
2.3.1 采集层：数据入口，要稳要全
采集层是系统的「眼睛」。数据采不全，后面分析得再好也没用。我一般会分三类数据源来设计：
- 日志类数据：比如应用日志、服务器日志。用Filebeat或Logstash采集，打到Kafka里。
- 数据库变更数据：比如交易流水、用户信息。用Debezium或Canal监听binlog，实时捕获变更。
- 外部API数据：比如第三方风控接口、舆情API。通过自定义采集器定时拉取。
经验之谈： 采集层一定要做「数据质量校验」。我曾经遇到过，某个上游系统改了字段格式没通知我们，结果采集进来的数据全是乱码，处理层直接崩了。所以，在采集层加个简单的schema校验，能省很多事。
2.3.2 处理层：大脑所在，规则与算法
处理层是系统的核心。所有合规判断都在这里完成。我把它分成两条线：
- 实时流处理：用Flink消费Kafka里的数据，做规则匹配。比如单笔交易超限、短时间内多次登录，这些都可以在毫秒级完成。
- 批处理：用Spark做T+1的离线分析。比如合同文本的敏感词检测、用户行为画像的构建。
规则引擎这块，我建议用Drools或者自研的轻量级规则引擎。为什么？因为业务规则变化太频繁了。你想想看，今天反洗钱规则更新，明天又加个新监管要求，如果每次都要改代码发版，运维得疯掉。规则引擎支持热加载，改规则不用重启服务。
注意： 规则引擎的性能瓶颈往往在「规则数量」上。当规则超过1000条时，匹配效率会急剧下降。我建议做规则分级：高频规则用内存匹配，低频规则走数据库查询。
2.3.3 存储层：数据仓库，分类存放
存储层不是简单的「找个数据库存起来」。不同数据有不同的存储需求：
| 数据类型 | 存储选型 | 原因 |
|---|---|---|
| 原始日志 | Kafka + 对象存储（MinIO） | 原始数据量大，需要低成本存储，且支持回溯重放 |
| 实时指标 | ClickHouse | 列式存储，聚合查询快，适合实时看板 |
| 告警记录 | Elasticsearch | 全文检索能力强，方便事后排查 |
| 规则配置 | MySQL/PostgreSQL | 关系型数据库，事务支持好，适合配置管理 |
嗯，这里要注意，存储层一定要考虑数据生命周期。比如原始日志保留30天，聚合指标保留1年，告警记录保留3年。超过期限的数据自动归档或删除，不然存储成本扛不住。
2.3.4 展示层：最后一公里，用户体验
展示层是用户直接打交道的部分。做得不好，前面再牛也没用。我一般会提供这几个功能：
- 实时监控大屏：展示当前告警数量、处理状态、趋势图。用WebSocket推数据，别用轮询。
- 告警通知：支持邮件、短信、企业微信、钉钉。通知模板要可配置，别写死。
- 规则配置界面：让业务方自己配规则，不用每次都找开发。界面要简单，拖拽式最好。
- 报表导出：支持PDF、Excel，方便合规审计。
核心原则： 展示层要「快」和「准」。快是指页面加载快，数据刷新快；准是指数据不能出错。合规监控的数据如果错了，后果很严重。所以，展示层的数据一定要做「数据一致性校验」，比如展示的告警数量和存储层实际数量对一下。
好了，这一章的内容就这些。需求梳理清楚了，技术选型原则记住了，四层架构也画出来了。下一章咱们开始动手搭建开发环境，把采集层先跑起来。
公众号:蓝海资料掘金营，微信deep3321