3、部署架构设计：整体部署架构图与组件职责
风控网关中集成 LightGBM 模型，需要一套清晰、低延迟、高可用的部署架构。本节从全局视角出发，给出客户端请求经过网关、模型服务、数据库的完整链路，并逐一说明每个组件的核心职责。
3.1 整体部署架构图
下图展示了风控网关中 LightGBM 模型服务的典型部署拓扑。请求从客户端发起，经过网关层路由与预处理，由模型服务执行推理，最终将结果持久化至数据库。
3.2 各组件职责说明
下表详细列出架构中每个组件的核心职责、技术选型建议及关键设计考量。
| 组件 | 核心职责 | 技术选型建议 | 关键设计考量 |
|---|---|---|---|
| 客户端 | 发起风控请求，携带业务特征数据（用户ID、设备指纹、交易金额等） | HTTP SDK / gRPC stub | 请求超时设置、重试策略、幂等性 |
| 请求路由 | 根据请求类型（注册、登录、交易）分发到对应风控策略链路 | Nginx / Kong / Spring Cloud Gateway | 路由规则热更新、灰度分流 |
| 特征预处理 | 对原始请求做特征工程：缺失值填充、类别编码、数值标准化、特征交叉 | Python / Java 特征工程模块 | 特征逻辑与模型训练时保持一致，使用特征存储（Feature Store） |
| 限流熔断 | 保护下游模型服务不被突发流量打垮，支持 QPS 限流、并发限流、熔断降级 | Sentinel / Hystrix / 自研限流组件 | 限流阈值动态调整、熔断后快速降级返回默认分数 |
| 结果缓存 | 对相同特征输入的推理结果进行短时缓存（如 5 秒），避免重复计算 | Redis / 本地 LRU Cache | 缓存 key 设计、TTL 策略、缓存穿透防护 |
| LightGBM 推理引擎 | 加载训练好的 LightGBM 模型文件，对预处理后的特征执行推理，输出风险分数 | LightGBM C API / Python pickle / ONNX Runtime | 模型热加载、版本管理、推理延迟监控（目标 < 10ms） |
| 数据库 | 持久化推理请求日志、特征快照、风险分数、决策结果，用于离线分析和模型迭代 | MySQL / PostgreSQL / ClickHouse | 异步写入、分表策略、数据保留周期 |
3.3 请求处理流程步骤
一次完整的风控推理请求，在架构中经历以下 7 个步骤：
- 客户端发起请求：携带业务特征数据，通过 HTTP/gRPC 发送至网关层。
- 请求路由：网关根据请求 URL 或 Header 中的策略标识，将请求分发至对应的风控链路。
- 特征预处理：对原始特征执行标准化、编码、缺失值处理，生成模型所需的特征向量。
- 限流熔断检查：判断当前 QPS/并发是否超过阈值；若超过则直接返回降级结果（如默认风险分 0.5），不调用模型服务。
- 结果缓存查询：以特征向量哈希为 key 查询缓存；若命中则直接返回缓存结果，跳过推理。
- LightGBM 推理：将特征向量传入推理引擎，执行模型计算，返回风险分数（0~1）。
- 结果持久化：将请求特征、推理结果、决策标签异步写入数据库，供后续分析和模型迭代使用。
架构设计要点：网关层与模型服务层之间通过 RPC 或 HTTP 轻量协议通信，保持无状态设计，便于独立扩缩容。数据库写入采用异步队列（如 Kafka / RabbitMQ），避免推理链路被 I/O 阻塞。
3.4 部署架构关键指标
下表列出了部署架构中需要重点监控的关键性能指标（KPI），用于评估系统健康状况。
| 指标名称 | 目标值 | 监控位置 | 说明 |
|---|---|---|---|
| P99 推理延迟 | < 10 ms | 模型服务层 | 单次 LightGBM 推理的端到端耗时 |
| P99 端到端延迟 | < 50 ms | 网关层 | 从客户端请求到返回结果的完整链路耗时 |
| 模型服务 QPS | ≥ 5000 | 模型服务层 | 单节点每秒处理的推理请求数 |
| 缓存命中率 | ≥ 30% | 网关层缓存模块 | 短时缓存减少重复推理，降低模型负载 |
| 数据库写入延迟 | < 200 ms | 数据库层 | 异步写入的 P99 延迟，不阻塞推理主链路 |
注意：如果 P99 推理延迟超过 20 ms，需要检查模型文件大小、特征维度是否过高，或考虑使用 ONNX Runtime 进行推理加速。数据库写入延迟过高时，应优先排查写入队列的积压情况。
下图以时序图形式展示一次风控推理请求在架构各组件间的交互过程，便于理解调用顺序与数据流向。
3.5 部署架构最佳实践
- 网关层无状态化：网关节点不存储任何会话状态，便于水平扩展和滚动升级。
- 模型服务独立部署：与业务服务分离，避免模型加载和推理影响业务主流程。
- 模型版本管理：使用模型注册表（如 MLflow）管理模型版本，支持 A/B 测试和快速回滚。
- 异步写入数据库：采用消息队列缓冲写入请求，避免数据库抖动影响推理延迟。
- 全链路监控：在网关层、模型服务层、数据库层分别埋点，监控延迟、QPS、错误率。
架构总结：本部署架构以网关层为流量入口，通过限流、缓存、特征预处理等机制保护下游模型服务，LightGBM 推理引擎专注执行高性能计算，数据库异步持久化请求日志。整体设计遵循“无状态、可扩展、低耦合”原则，能够支撑高并发风控场景。