第二章：架构演进之路——从单机规则引擎到分布式实时计算平台
聊到风控系统的架构演进，我脑子里第一个蹦出来的画面，是十年前那个深夜。
那时候我刚接手一个支付项目的风控模块。说白了，就是一个单机规则引擎。所有规则写在一个XML配置文件里，每次请求来了，顺序匹配一遍。嗯，当时觉得挺酷的。
后来流量一上来，问题全暴露了。规则多了，匹配慢了；并发高了，机器挂了。我这才意识到——单机架构，撑不住。
2.1 第一阶段：单机规则引擎
这是最原始的阶段。所有逻辑跑在一台机器上，规则引擎加载一个规则集，对每个请求做顺序匹配。
核心特征：
- 规则存储在本地文件或数据库
- 单线程或少量线程处理请求
- 规则变更需要重启服务
- 性能瓶颈明显：单机QPS通常不超过1000
我在项目中遇到过最典型的问题：规则数量从50条涨到500条，响应时间从5ms飙升到200ms。为什么？因为每条规则都要遍历所有字段，而且规则之间还有依赖关系。
避坑指南：我曾经在一个项目中，把规则引擎的匹配逻辑写成了嵌套循环。结果线上压测时，CPU直接打满。后来改成Rete算法，才把性能拉回来。记住：规则引擎的核心是匹配效率，不是规则数量。
2.2 第二阶段：垂直拆分与缓存加速
单机扛不住了，怎么办？拆。
我们把风控系统拆成了几个模块：规则引擎、名单服务、模型服务。每个模块独立部署，通过RPC调用。
同时，我引入了本地缓存。高频访问的名单数据，比如黑名单、白名单，直接缓存在内存里。这一下，响应时间从200ms降到了20ms。
我的习惯：缓存不是越多越好。我一般只缓存两类数据：一是变化频率极低的（比如黑名单），二是计算成本极高的（比如模型特征）。其他数据，老老实实走DB。
但垂直拆分也有代价。模块之间的调用链变长了，网络延迟成了新瓶颈。我记得有一次，规则引擎调用名单服务，超时时间设了100ms，结果高峰期大量超时，导致整个风控链路雪崩。
2.3 第三阶段：分布式实时计算平台
到了这个阶段，我们开始认真思考：能不能把风控做成一个流式计算平台？
答案是肯定的。我们基于Flink搭建了实时计算平台。核心思路是：
- 所有事件（交易、登录、注册）统一接入消息队列
- Flink作业实时消费，做特征计算、规则匹配、模型推理
- 结果写入在线存储，供下游决策
架构对比：
| 维度 | 单机规则引擎 | 分布式实时平台 |
|---|---|---|
| 处理模式 | 请求-响应 | 流式处理 |
| 扩展性 | 垂直扩展 | 水平扩展 |
| 延迟 | 10-200ms | 10-50ms |
| 规则管理 | 本地文件 | 配置中心+热加载 |
| 容错 | 单点故障 | 自动故障转移 |
你想想看，单机引擎处理1000QPS就吃力了，分布式平台轻松扛到10万QPS。而且，规则变更不用重启，配置中心一推，秒级生效。
但分布式也不是银弹。我踩过一个坑：Flink作业的状态后端用了RocksDB，结果因为磁盘IO瓶颈，导致背压严重。后来改成内存状态后端，才把延迟降下来。
2.4 核心演进逻辑：为什么必须走这条路？
说白了，风控系统的演进，是被业务逼出来的。
- 流量增长：从日均百万到日均十亿，单机扛不住
- 规则复杂度：从几十条到几万条，顺序匹配不现实
- 实时性要求：从秒级到毫秒级，批处理不行了
- 运维成本：从手工部署到自动化运维，人工搞不定
我个人习惯，每次做架构升级前，先问三个问题：
- 当前瓶颈在哪？是CPU、内存、IO还是网络？
- 业务容忍的最大延迟是多少？
- 团队有没有能力运维分布式系统？
如果这三个问题想清楚了，架构演进的方向就不会偏。
2.5 一张图看懂演进脉络
下面这张图，是我自己画的。它展示了从单机到分布式的核心变化。
嗯，这张图其实概括了核心思路。从单机到分布式，不是简单的技术堆叠，而是对延迟、吞吐、可用性的重新平衡。
我的建议：如果你现在还在用单机规则引擎，别急着上分布式。先看看你的瓶颈在哪。很多时候，加个缓存、优化一下规则匹配算法，就能解决80%的问题。分布式是最后的手段，不是第一选择。
好了，这一章就聊到这。下一章我们会深入规则引擎的内部实现，聊聊Rete算法和表达式引擎的优化技巧。