3. 评分通道架构演进：单体架构 → 垂直拆分 → 微服务 → 单元化架构
风控评分通道作为金融交易的核心决策链路，其架构演进直接决定了系统的吞吐能力、响应延迟与运维复杂度。本章将沿着一条清晰的演进路径，逐一剖析四种架构形态的设计思想、适用场景与核心痛点。
3.1 单体架构：一切从简，但瓶颈明显
在业务初期，风控规则简单、流量可控时，团队通常将所有功能打包为一个进程：规则引擎、名单库、模型计算、数据库访问、外部接口调用全部耦合在一起。
典型特征： 单进程部署、共享数据库、功能模块间直接方法调用。
| 维度 | 单体架构表现 | 瓶颈点 |
|---|---|---|
| 开发效率 | 初期快速迭代，本地调试方便 | 代码膨胀后编译慢、合并冲突频繁 |
| 性能 | 进程内调用延迟低（<1ms） | 单机资源上限，无法水平扩展 |
| 可用性 | 单点部署，运维简单 | 任何模块故障导致全链路不可用 |
| 容量 | 依赖单机垂直扩容 | QPS 通常不超过 2000 |
典型事故： 某互金公司早期风控单体应用，因名单库内存泄漏导致 OOM，评分通道全链路阻塞 12 分钟，直接损失超 300 万。
3.2 垂直拆分：按业务域隔离，提升并行能力
当单体应用无法支撑多业务线（如信贷、支付、保险）时，团队按业务域将系统拆分为独立的评分通道应用。每个垂直应用拥有独立的数据库和部署单元，通过 API 网关统一接入。
3.3 微服务架构：细粒度拆分，弹性与复用最大化
垂直拆分仍存在大量重复代码（如名单服务、模型服务、日志服务）。微服务架构将评分通道拆解为多个独立的原子服务，每个服务围绕单一业务能力构建，通过轻量级 RPC 或消息队列协作。
核心原则： 服务按职责拆分（规则服务、名单服务、模型服务、决策服务、数据服务），每个服务独立部署、独立数据库、独立 CI/CD。
| 服务名称 | 职责 | 典型 QPS | 存储 |
|---|---|---|---|
| 规则服务 | 执行决策树/规则集 | 50000+ | Redis + MySQL |
| 名单服务 | 黑/白/灰名单匹配 | 100000+ | Redis Cluster |
| 模型服务 | 运行机器学习模型 | 20000+ | 本地模型文件 |
| 决策服务 | 聚合评分结果，输出最终决策 | 50000+ | 无状态 |
| 数据服务 | 获取用户画像、交易数据 | 30000+ | MySQL + HBase |
3.4 单元化架构：突破地域限制，迈向无限扩展
当业务规模达到千万级 QPS、跨地域部署成为刚需时，微服务架构面临数据库连接数瓶颈、跨机房延迟、全局单点等问题。单元化架构（Cell-based Architecture）将整个系统划分为多个独立的“单元”，每个单元包含完整的评分通道服务栈和专属数据分片，流量按用户 ID 或请求特征路由到指定单元。
单元化核心设计： 每个单元是一个自包含的“小系统”，拥有独立的网关、服务实例、数据库和缓存。单元间无状态调用尽量少，数据通过异步消息最终一致。
3.5 四种架构对比总结
| 架构模式 | QPS 上限 | 响应延迟 | 运维复杂度 | 适用阶段 | 典型团队规模 |
|---|---|---|---|---|---|
| 单体架构 | ~2000 | < 50ms | 低 | 业务验证期 | 3-5 人 |
| 垂直拆分 | ~20000 | < 100ms | 中 | 多业务线并行 | 10-20 人 |
| 微服务架构 | ~200000 | < 200ms | 高 | 高速增长期 | 30-100 人 |
| 单元化架构 | 1000000+ | < 50ms（就近） | 极高 | 全球化/超大规模 | 100+ 人 |
架构演进建议： 不要为了“先进”而盲目升级。单体架构能解决问题时，不要引入微服务；微服务能支撑业务时，不要急于单元化。每次架构升级都应基于明确的业务痛点和可量化的性能指标。