系统集成与跨切面 · 总结
金融系统集成全景图
summary/system-integration.md
金融系统集成全景图
设计日期: 2026-04-14 定位: Week 6 综合演练 — 5个金融系统如何协作 关联: 支付网关 / 记账引擎 / 风控引擎 / 信贷系统 / 清算结算
一、系统全景
1.1 五大系统定位
┌─────────────────────────────────────────────────────────────────┐
│ 金融核心系统全景 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 信贷系统 │ │ 支付网关 │ │ 清算结算 │ │
│ │ (贷前/中/后)│ │ (收付退查) │ │ (轧差划拨) │ │
│ └─────┬────┘ └─────┬────┘ └─────┬────┘ │
│ │ │ │ │
│ └──────────────┼──────────────┘ │
│ │ │
│ ┌────────┴────────┐ │
│ │ │ │
│ ┌─────┴─────┐ ┌──────┴─────┐ │
│ │ 风控引擎 │ │ 记账引擎 │ │
│ │ (实时决策) │ │ (复式记账) │ │
│ └───────────┘ └────────────┘ │
│ │
│ ── 业务系统层 ── ── 基础能力层 ── │
└─────────────────────────────────────────────────────────────────┘
1.2 系统间依赖矩阵
| 调用方 ↓ / 被调用方 → | 支付网关 | 记账引擎 | 风控引擎 | 信贷系统 | 清算结算 |
|---|---|---|---|---|---|
| 支付网关 | - | 同步记账 | 同步风控 | - | 提供交易 |
| 记账引擎 | - | - | - | - | 提供账务 |
| 风控引擎 | - | - | - | - | - |
| 信贷系统 | 放款/扣款 | 同步记账 | 授信风控 | - | - |
| 清算结算 | - | 清算记账 | - | - | - |
1.3 系统间通信模式
| 场景 | 通信方式 | 原因 |
|---|---|---|
| 支付→风控 | 同步RPC | 风控决策必须在支付前完成 |
| 支付→记账 | 同步RPC+异步补偿 | 记账必须成功，但不能阻塞太久 |
| 信贷→支付 | 同步RPC | 放款/还款依赖支付结果 |
| 信贷→风控 | 同步RPC | 授信决策需要风控 |
| 支付→清算 | 异步消息 | 清算非实时，T+1批量处理 |
| 清算→记账 | 同步RPC | 清算结果必须入账 |
二、核心业务链路
2.1 链路一：在线支付
用户下单 → 商户调用支付网关
│
├─① 风控检查（同步，<50ms）
│ └→ 风控引擎: 特征提取→规则+模型→决策
│ ├─ PASS → 继续
│ ├─ REJECT → 拒绝支付
│ └─ REVIEW → 人工审核队列
│
├─② 通道路由（同步，<10ms）
│ └→ 路由引擎: 成本+成功率+限额→选通道
│
├─③ 通道调用（同步，<3s）
│ └→ Channel Adapter → PSP/银行
│
├─④ 记账（同步，<100ms）
│ └→ 记账引擎:
│ 借: 备付金账户（资产+）
│ 贷: 商户待结算（负债+）
│
├─⑤ 通知（异步）
│ └→ 商户回调 + 用户通知
│
└─⑥ 清算（T+1异步）
└→ 交易数据→清算系统→轧差→结算
2.2 链路二：信贷放款
用户申请借款
│
├─① 授信决策（首次）
│ ├─ 征信查询（外部）
│ ├─ 风控引擎: 反欺诈+信用评估
│ └─ 审批: 自动/人工 → 额度
│
├─② 用信申请
│ ├─ 额度检查（信贷系统）
│ ├─ 风控引擎: 交易风控
│ └─ 合同生成
│
├─③ 放款
│ ├─ 信贷系统 → 支付网关: 代付指令
│ ├─ 支付网关 → PSP/银行: 实际划款
│ └─ 记账引擎:
│ 借: 贷款（资产+）
│ 贷: 备付金（资产-）
│
├─④ 还款（每期）
│ ├─ 信贷系统 → 支付网关: 代扣指令
│ ├─ 支付网关 → PSP/银行: 实际扣款
│ └─ 记账引擎:
│ 借: 备付金（资产+）
│ 贷: 贷款本金（资产-）
│ 贷: 利息收入（收入+）
│
└─⑤ 逾期处理
├─ 信贷系统: 逾期标记+催收
├─ 记账引擎: 逾期利息计提
└─ 风控引擎: 更新用户风险标签
2.3 链路三：T+1 清算结算
T日（交易日）
│
└─ 支付网关: 交易数据→Kafka→清算系统
T+1日（清算日）
│
├─ 01:00 数据采集
│ └─ 清算系统: 从消息队列采集T日全部交易
│
├─ 02:00 数据校验
│ └─ 与PSP/银行的对账文件比对
│
├─ 03:00 轧差计算
│ └─ 多边轧差: 计算各参与方净额
│ 商户A: 应收 ¥50,000
│ 商户B: 应收 ¥30,000
│ PSP手续费: 应收 ¥800
│ 平台: 应收 ¥1,200
│
├─ 04:00 结算指令生成
│ └─ 生成资金划拨指令 → 记账引擎入账
│ 借: 待清算（负债-）
│ 贷: 商户结算款（负债+）
│
├─ 05:00 资金划拨
│ └─ 通过CNAPS/银行划拨到商户银行账户
│
└─ 06:00 确认+报表
├─ 清算完成确认
├─ 头寸更新
└─ 清算报表生成
三、数据流全景
3.1 资金流
用户银行账户
│
┌────┴────┐
│ PSP/银行 │
└────┬────┘
│
┌──────────┴──────────┐
│ 支付网关 │
│ (通道路由+收付) │
└──────────┬──────────┘
│
┌─────────────┼─────────────┐
│ │ │
┌──────┴──────┐ ┌────┴────┐ ┌─────┴─────┐
│ 备付金账户 │ │ 手续费 │ │ 商户待结算 │
│ (记账引擎) │ │ (收入) │ │ (负债) │
└──────┬──────┘ └─────────┘ └─────┬─────┘
│ │
│ T+1 清算结算 │
│ ┌────────────────┐ │
└───→│ 轧差 → 划拨 │←───┘
└───────┬────────┘
│
商户银行账户
3.2 信息流
┌─────────┐ 交易数据 ┌─────────┐ 风控事件 ┌─────────┐
│ 支付网关 │──────────→│ 清算结算 │ │ 风控引擎 │
│ │ │ │ │ │
│ │──风控请求──────────────────────────→│ │
│ │←─风控结果──────────────────────────│ │
│ │ │ │ │ │
│ │──记账请求─→│ │ │ │
└─────────┘ ↓ └─────────┘ └─────────┘
┌─────────┐
│ 记账引擎 │← 清算记账
│ │← 信贷记账
└─────────┘
↑
┌─────────┐
│ 信贷系统 │──放款/还款──→支付网关
│ │──风控请求───→风控引擎
└─────────┘
3.3 关键数据一致性保障
| 链路 | 一致性策略 | 失败处理 |
|---|---|---|
| 支付→记账 | 本地事务+同步调用 | 支付成功但记账失败→补记账Job |
| 支付→风控 | 同步调用 | 风控超时→降级策略（放行/拒绝） |
| 信贷→支付 | 同步调用+状态机 | 放款失败→重试/人工介入 |
| 清算→记账 | 批量事务+对账 | 清算记账失败→暂停清算+告警 |
| 支付→清算 | 异步消息+对账 | 消息丢失→T+1对账补偿 |
四、统一概念模型
4.1 跨系统共享概念
| 概念 | 支付网关 | 记账引擎 | 风控引擎 | 信贷系统 | 清算结算 |
|---|---|---|---|---|---|
| 用户 | 付款人 | 账户持有人 | 风控对象 | 借款人 | - |
| 商户 | 收款方 | 商户账户 | - | - | 结算对象 |
| 交易 | 支付订单 | 记账凭证 | 风控事件 | 借据 | 清算指令 |
| 金额 | 支付金额 | 借贷金额 | 交易金额 | 本金/利息 | 轧差净额 |
| 状态 | 支付状态 | 凭证状态 | 决策结果 | 借据状态 | 清算状态 |
4.2 ID关联关系
payment_order.order_no ←→ risk_event.biz_id
payment_order.pay_no ←→ journal_entry.biz_ref
loan_contract.id ←→ payment_order.biz_order_id（放款/还款）
payment_order.pay_no ←→ clearing_instruction.trade_ref
clearing_batch.id ←→ journal_entry.biz_ref（清算记账）
五、技术架构统一视角
5.1 技术栈矩阵
| 组件 | 支付网关 | 记账引擎 | 风控引擎 | 信贷系统 | 清算结算 |
|---|---|---|---|---|---|
| 语言 | Java/Go | Java | Java/Python | Java | Java |
| 框架 | Spring Cloud | Spring Boot | Spring Boot + Flink | Spring Cloud | Spring Batch |
| 主库 | MySQL(分库) | PostgreSQL | - | MySQL(分库) | PostgreSQL |
| 缓存 | Redis | Redis | Redis(特征) | Redis | Redis |
| 消息 | Kafka | Kafka | Kafka | Kafka | Kafka |
| 搜索 | - | - | ES(日志) | ES(案件) | - |
| 调度 | XXL-Job | XXL-Job | Flink | XXL-Job | XXL-Job |
5.2 部署架构
┌─────────────────────────┐
│ 负载均衡 │
│ (Nginx / ALB) │
└────────────┬────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
┌─────┴─────┐ ┌──────┴──────┐ ┌─────┴─────┐
│ 支付网关 │ │ 信贷系统 │ │ 管理后台 │
│ (3+ 节点) │ │ (3+ 节点) │ │ (2 节点) │
└─────┬─────┘ └──────┬──────┘ └───────────┘
│ │
┌─────────┼──────────────────┼─────────┐
│ │ │ │
┌───┴───┐ ┌──┴───┐ ┌────────┐ ┌┴────────┐
│风控引擎│ │记账引擎│ │清算结算 │ │消息队列 │
│(5+节点)│ │(3+节点)│ │(2+节点) │ │(Kafka) │
└───┬───┘ └──┬───┘ └───┬────┘ └─────────┘
│ │ │
│ ┌────┴────┐ │
│ │ 数据库集群│ │
│ │ (主从+分片)│ │
│ └─────────┘ │
│ │
└───────────────────┘
Redis 集群
5.3 可观测性统一方案
| 层次 | 工具 | 关注指标 |
|---|---|---|
| 链路追踪 | Jaeger/SkyWalking | 跨系统调用链路、延迟分布 |
| 指标监控 | Prometheus + Grafana | 各系统QPS/延迟/成功率/资源使用 |
| 日志聚合 | ELK Stack | 统一日志格式、错误追踪 |
| 业务监控 | 自研Dashboard | 支付成功率/风控拦截率/清算进度/资金对账率 |
| 告警 | AlertManager | 分级告警：P0短信→P1企微→P2邮件 |
六、全局性架构决策
6.1 分布式事务策略
决策: 不使用全局分布式事务（如2PC/XA），采用本地事务+异步补偿+最终一致性。
理由:
- 金融系统对可用性要求极高（99.99%），2PC的协调器是单点风险
- 各系统独立演进，强耦合的分布式事务限制了迭代速度
- 通过对账机制（T+1）兜底，保证最终一致
补偿机制:
- 同步调用失败 → 本地记录+异步重试Job
- 异步消息丢失 → 定时对账发现差异 → 补偿
- 长时间不一致 → 告警+人工介入
6.2 幂等设计统一规范
所有跨系统调用必须幂等：
- 支付网关: 商户订单号+支付方式 作为幂等键
- 记账引擎: 业务方+业务流水号 作为幂等键
- 信贷系统: 借据号+操作类型 作为幂等键
- 清算结算: 清算日期+批次号 作为幂等键
6.3 统一错误码体系
错误码格式: [系统码][模块码][错误序号]
PAY-ROUTE-001: 无可用支付通道
LED-POST-001: 借贷不平衡
RSK-RULE-001: 命中黑名单
CRD-LINE-001: 额度不足
CLR-NETT-001: 轧差计算异常
七、演进路线
7.1 阶段演进
Phase 1: 单体 (0→日均10万笔)
└─ 所有系统在一个应用中，单库
Phase 2: 服务化 (10万→100万笔)
└─ 拆分为5个独立服务，引入消息队列
Phase 3: 分布式 (100万→1000万笔)
└─ 数据库分库分表，引入缓存，异步化
Phase 4: 多机房 (1000万→1亿笔)
└─ 同城双活，异地灾备，读写分离
Phase 5: 全球化 (1亿→10亿笔)
└─ 多地域部署，就近接入，跨境合规
7.2 与 DeFi 的架构对比
| 维度 | CeFi（本设计） | DeFi |
|---|---|---|
| 信任模型 | 中心化机构背书 | 代码即法律（智能合约） |
| 清算 | T+1批量清算 | 实时原子结算 |
| 记账 | 复式记账+数据库 | 区块链账本（不可篡改） |
| 风控 | 集中式实时决策 | 链上参数+预言机 |
| 监管 | 央行/银保监 | 链上治理(DAO) |
| 可用性 | 99.99%（运维保障） | 区块链共识保障 |
| 扩展性 | 水平扩展（加机器） | L2 Rollup |
7.3 CeFi→DeFi 桥接机会
- RWA（真实资产代币化）: 信贷资产→链上Token→全球流动性
- PayFi: 支付网关对接链上结算，T+1→T+0
- 链上清算: 智能合约实现DVP原子结算
- DeFi风控: 链上行为分析+预言机价格监控
- 混合记账: 链下高频记账+链上定期锚定（Proof of Reserve）
八、面试综合问题
Q1: 如果让你从零搭建一个互联网金融平台的技术架构，你会怎么设计？
答案要点:
- 先确定业务范围（支付/信贷/理财？）
- 按领域拆分服务（支付/记账/风控/信贷/清算）
- 基础能力先行（记账引擎+风控引擎是地基）
- 数据一致性策略（本地事务+异步补偿+对账）
- 安全合规先行（PCI-DSS/等保三级/监管报送）
- 渐进式演进（单体→微服务→分布式→多机房）
Q2: 这5个系统之间最关键的集成点在哪里？
答案要点:
- 支付→记账：资金操作必须入账，一致性要求最高
- 支付→风控：延迟敏感，风控不能成为瓶颈
- 信贷→支付：放款/还款的资金流转
- 支付→清算：交易数据准确完整
- 清算→记账：清算结果准确入账
Q3: 如果其中一个系统出了故障，对其他系统有什么影响？如何做故障隔离？
答案要点:
- 风控故障：支付降级（配置化：高风险场景拒绝/低风险场景放行）
- 记账故障：支付可继续，记账异步补偿（先记本地日志，恢复后补账）
- 支付故障：信贷无法放款/还款，需人工处理
- 清算故障：延迟结算，不影响实时交易
- 故障隔离：熔断器/限流/超时/降级/异步解耦