一、风控的起点：从规则引擎到第一行代码

说实话，每次有人问我「风控系统怎么做」，我脑子里第一个画面不是高大上的机器学习模型，而是十年前那个深夜——我一个人蹲在工位上，对着一个if-else嵌套了八层的规则引擎发呆。

那时候我刚接手公司的风控模块。说是模块，其实就是一段没人敢动的代码。为什么？因为里面塞了上百条规则，谁改谁出事。嗯，这就是我们今天要聊的——单体架构下的风控系统，它到底长什么样？

1.1 规则引擎的诞生：从人工到自动化

先说说背景。2014年左右，我所在的公司做电商业务。每天几千笔订单，运营团队靠人工审核——看地址、看金额、看用户等级。后来单量涨到每天几万笔，人扛不住了。

老板说：「你搞个自动审核的东西出来。」

我当时的第一反应是：写个规则引擎呗。说白了，就是把人工审核的逻辑翻译成代码。

举个例子，一条典型的规则长这样：

// 伪代码：判断订单是否高风险
if (订单金额 > 5000 && 用户注册天数 < 7 && 收货地址是新地址) {
    标记为高风险；
    触发人工审核；
}

你看，逻辑很简单。但问题来了——规则多了以后，维护成本直线上升。我遇到过最夸张的情况：一条规则改了三次，结果把另一条规则的条件覆盖了，线上出了事故。

3.2 单体架构下的风控系统长什么样？

那时候没有微服务，没有容器化。整个风控系统就是一个Java应用，部署在一台服务器上。我画了一张图，你可以看看它的结构：

这张图我到现在还记得很清楚。为什么？因为后来每次系统出问题，我都要对着这张图找瓶颈。

1.3 单体架构的「三宗罪」

用了一段时间后，问题开始暴露。我总结了三类典型问题：

问题类型	具体表现	我踩过的坑
性能瓶颈	单台服务器扛不住高并发，规则越多处理越慢	双十一当天，系统响应时间从50ms飙到3秒，订单积压了十几万
维护地狱	规则耦合严重，改一条可能影响十条	有一次改了一条金额规则，结果把风控白名单误杀了，导致VIP用户下单失败
扩展困难	加新功能要重新部署整个应用	想加个设备指纹校验，结果要停服半小时，业务方差点没把我吃了

1.4 代码长什么样？一个真实的例子

给你看一段我当年写的代码。别笑，那时候就是这么写的：

// 风控判断入口（单体架构版本）
public class RiskControlService {
    
    public RiskResult evaluate(Order order) {
        // 规则1：金额检查
        if (order.getAmount() > 10000) {
            return RiskResult.REJECT("金额超限");
        }
        
        // 规则2：新用户检查
        if (order.getUser().getRegisterDays() < 30) {
            return RiskResult.REVIEW("新用户需人工审核");
        }
        
        // 规则3：地址检查
        if (isSuspiciousAddress(order.getAddress())) {
            return RiskResult.REJECT("地址异常");
        }
        
        // 规则4：设备指纹检查（后来加的）
        if (order.getDeviceId() != null && isBlackDevice(order.getDeviceId())) {
            return RiskResult.REJECT("设备在黑名单中");
        }
        
        // ... 还有几十条类似的规则
        
        return RiskResult.PASS("通过");
    }
}

你看，代码本身没什么技术含量。但问题在于——每加一条规则，这个方法的行数就增加一截。到后来，这个方法有800多行。谁都不敢动，动就出事。

1.5 单体架构的「幸存者偏差」

你可能会问：既然单体架构这么烂，为什么当年大家都在用？

原因很简单：业务量还没大到需要拆分的程度。

我举个例子。当时我们每天处理5万笔订单，单台服务器完全扛得住。规则引擎虽然笨重，但至少能跑。而且团队就两三个人，搞微服务反而增加复杂度。

说白了，单体架构不是不能用，而是你要知道它的天花板在哪里。

我记得有一次CTO问我：「什么时候该重构？」

我的回答是：「当你改一条规则需要花半天时间做回归测试的时候。」

嗯，这个标准我一直用到现在。

1.6 总结：单体架构下的风控系统画像

最后，我用一个表格总结一下单体架构风控系统的特点：

维度	特点	我的评价
部署方式	单台服务器，一个应用包	简单粗暴，但扩展性差
规则管理	硬编码或配置文件	适合小规模，超过100条就失控
性能	单机处理，QPS有限	日均10万单以内还行
团队规模	2-3人维护	人多了反而乱
适合场景	业务初期，规则简单	快速验证业务模式

说实话，现在回头看那段经历，我反而觉得挺宝贵的。因为只有经历过单体架构的痛，你才会真正理解为什么后来要搞微服务、要上规则引擎平台、要引入机器学习模型。

下一章，我们会聊聊当业务量涨到每天百万级的时候，单体架构是怎么崩溃的——以及我们是怎么用「垂直拆分」来救火的。

---

公众号：蓝海数据掘金营，微信 deep3321