跨境支付平台架构：领域边界、技术选型与演进路径
跨境支付平台架构：领域边界、技术选型与演进路径
平台架构的关键不是服务数量，而是业务事实、资金事实和外部渠道事实拥有清晰的权威边界。
为什么值得讨论
当收款、付款、换汇、合规、账务和渠道能力同时出现时，错误的边界会制造跨域事务和责任空洞。本文给出组装与演进方法。
适合读者：支付架构师、技术负责人、平台产品负责人和需要规划分期交付的团队。
1. 总体架构(分层视图)
┌────────────────────────────────────────────────────────────┐
│ 接入层 商户 Portal │ OpenAPI(API Key+签名) │ 运营后台 │ 移动端 │
├────────────────────────────────────────────────────────────┤
│ 产品服务层(BFF/编排) │
│ 全球收款服务 │ 全球付款服务 │ 换汇服务 │ 钱包服务 │ 账单服务 │
├────────────────────────────────────────────────────────────┤
│ 核心域服务层 │
│ 会员&KYB │ 合规引擎(筛查/TM/案件) │ 风控引擎 │ 计费引擎 │
│ 报价引擎 │ 头寸&流动性 │ 订单中心(收/付/换汇单) │ 申报服务 │
├────────────────────────────────────────────────────────────┤
│ 资金基础设施层 │
│ 记账核心(账户+复式记账) │ 渠道网关(路由+适配器) │ 对账&差错中心 │
├────────────────────────────────────────────────────────────┤
│ 技术基础设施层 │
│ 消息总线 │ 调度(EOD Pipeline) │ 规则引擎 │ 配置中心 │
│ 数据平台(数仓/风控特征/监管报送) │ 可观测性 │ 密钥&安全 │
└────────────────────────────────────────────────────────────┘对应关系：02 收款/03 付款 → 产品服务层与订单中心;04 → 报价引擎+头寸;05 → 合规/风控/申报;06 → 记账核心;07 → 渠道网关;08 → 对账&差错+EOD。
2. 服务划分与边界(DDD 域)
| 域 | 服务 | 边界要点 |
|---|---|---|
| 客户域 | 会员、KYB/KYC、合规档案 | 一客户多辖区档案(05 篇：跨境支付合规风控：从 KYB 到交易监控 2.2) |
| 交易域 | 收款单、付款单、换汇单、状态机引擎 | 订单是业务事实的权威记录;账务是资金事实的权威记录，二者分开 |
| 资金域 | 记账核心、头寸管理、流动性调度 | 记账核心独立部署、独立库，最高可用性等级 |
| 定价域 | 报价引擎、计费引擎 | 报价即锁定(Quote 有效期)，费率规则版本化(03 篇：全球付款系统：从指令生命周期到失败退回 7) |
| 合规域 | 筛查、交易监控、案件管理、申报 | 同步卡点(筛查)与异步分析(TM)分离 |
| 渠道域 | 渠道网关、路由、VA 管理 | 适配器可插拔，状态归一(07 篇：渠道网关与智能路由：连接全球资金网络) |
| 结算域 | 对账、差错中心、商户结算、EOD 编排 | 兜底真相来源(08 篇：清结算与对账：如何持续证明每一分钱都对得上) |
同步与异步的铁律：交易主链路上的同步依赖只允许：余额/记账、名单筛查、报价锁定、风控决策(均要求 P99 < 200ms);其余(通知、TM 分析、数仓、对账)一律异步事件。
3. 核心链路时序(以跨币种付款为例)
商户 API 下单(client_order_id 幂等)
→ 订单中心:创建付款单 CREATED
→ 收款人校验(格式/路由号库/渠道字段规则) [同步]
→ 合规筛查(收款人过名单) [同步,命中→挂起人工]
→ 报价+计费(锁定汇率与费用,生成 Quote) [同步]
→ 记账核心:扣商户余额+冻结至过渡户(FUNDED) [同步,先账后钱]
→ 路由引擎选渠道 → 渠道网关下单 [异步化:指令队列]
→ 渠道回执/轮询 → 状态推进 SUCCEEDED/FAILED/RETURNED
→ 记账核心:出款确认分录 / 失败解冻退回
→ 事件总线 → 通知商户、对账系统、数仓、申报一致性实现：订单状态机为 Saga 协调者，每步都有补偿动作(失败→解冻);业务与账务之间用 Outbox/本地消息表 + 幂等消费(06 篇：金融账务核心：多币种账户与复式记账怎么设计 4.1);对外资金操作坚持"先账后钱 + query-before-retry"(07 篇：渠道网关与智能路由：连接全球资金网络 6)。
4. 数据架构
- OLTP：每个核心服务独立库(PostgreSQL/MySQL)，记账核心库物理隔离、同城双活/异地灾备;
- 事件总线:Kafka——交易事件是对账、风控、数仓、通知的统一供给源;事件 Schema 版本化管理;
- 数据平台：准实时数仓(交易宽表)支撑运营报表、监管报送、路由成功率统计、TM 模型特征;
- 规则/配置类数据：费率、路由规则、分录模板、筛查阈值——统一配置中心，全部版本化 + 审批流 + 灰度生效(这些配置错一个就是资金事故);
- 留存与审计：原始报文、审批留痕、账务流水按合规要求留存 5-7 年，冷热分层。
5. 技术选型建议
| 层面 | 建议 | 理由 |
|---|---|---|
| 语言 | Java/Kotlin(核心域)+ Go(网关/高并发组件) | 金融领域生态成熟、招聘容易;非强制，团队基因优先 |
| 数据库 | PostgreSQL 起步，分库分表预留;账务库暂不上分布式 DB | 强事务是账务命脉(06 篇：金融账务核心：多币种账户与复式记账怎么设计);量级到了再演进 |
| 消息 | Kafka(事件)+ 延迟队列(状态轮询/超时任务) |
技术选型说明：具体技术栈可以等价替换，但强事务关系库、事件总线、注册配置与缓存承担的系统角色不变。 | 规则引擎 | 轻量自研 DSL 或嵌入式引擎(路由/计费/TM 规则) | 商业规则引擎笨重，可运营性优先 | | 部署 | K8s + 多 AZ;二期起多 Region(数据主权：欧盟数据留欧) | GDPR 与各辖区数据本地化要求 | | 合规组件 | 名单数据、电子核身、工商数据外采;筛查引擎本地化部署,SaaS 仅作数据源与异步复核 | 05 篇：跨境支付合规风控：从 KYB 到交易监控结论：数据密集型组件不自建;同步卡点 P99<200ms 决定引擎必须本地(05 篇：跨境支付合规风控：从 KYB 到交易监控 §3.3) | | 安全 | HSM/KMS 管密钥、报文签名验签、PCI 级敏感数据加密、全链路审计日志 | 金融基线 | | 可观测性 | 指标(业务级：成功率/时效/头寸水位)+ 链路追踪 + 资金级告警(账实差异、隔离校验) | 监控要到"业务语义"层 |
6. 非功能要求(NFR)基线
| 项 | 基线 |
|---|---|
| 可用性 | 交易链路 99.95%;记账核心 99.99%;渠道故障不影响其他渠道(舱壁隔离) |
| 一致性 | 资金不错不丢：双重出款率 = 0;账实差异 = 0(出现即 P0) |
| 性能 | API P99 < 500ms(不含渠道);记账 TPS 按峰值 10 倍余量设计 |
| 容灾 | RPO≈0(账务库同步复制),RTO < 30min;EOD 可断点重跑 |
| 安全合规 | 最小权限、四眼原则(冲正/放行/费率变更)、渗透测试年检、SOC2/ISO27001 路线(详见 20 篇：安全与数据合规：金融平台不能后补的横切能力) |
| 演练与验证 | 新渠道上线 Penny Test(生产小额真实资金全链路验证);渠道 failover、EOD 断点重跑、灾备切换定期演练(07 篇：渠道网关与智能路由：连接全球资金网络 §6) |
7. 分期演进路线
一期(0-9 个月):MVP，借力起步
- 里程碑 M0"最小可收款"(0-4 个月)：单走廊先行——USD 本地清算 VA 收款 → 合规筛查 → 结汇提现(CNY)全链路上生产，账务/对账/申报数据在真实资金上锤炼通过后，再横向扩币种与 Payout。全功能齐头并进会让记账核心+对账+渠道联调的联合风险在末期集中爆发，单走廊验证后横向扩展基本是配置问题;
- 渠道：1 家聚合服务商 + 2 家境内结汇合作方(一主一备保温，07 篇：渠道网关与智能路由：连接全球资金网络 §7 决策点 1);牌照走合作模式(05 篇：跨境支付合规风控：从 KYB 到交易监控)，法人主体与协议结构按 18 篇：法人主体与资金结构：跨境支付架构真正的地基先行确定;
- 产品：多币种 VA 收款 + 结汇提现 + 基础 Payout(对公)+ 实时价/当日价换汇;
- 系统：订单中心、记账核心(自研，一步到位含 legal_entity 维度)、渠道网关(2-3 个适配器)、基础筛查(外采引擎)、渠道对账、简版计费(注意：简版≠松约束，"费率匹配不到即拒单"的强规则一期必须保留，否则上线即漏计费——10 篇：计费引擎设计：复杂费率如何准确、可解释、可运营 §2);
- 刻意不做：锁汇、账单制后付费、对私人民币付款、自持 SWIFT BIC。
二期(9-18 个月)：能力纵深
- 牌照：香港 MSO / 新加坡 MPI 自持;核心走廊银行直连;
- 产品：锁汇(背对背)、智能路由多渠道、T+0 结算(高等级商户)、批量发薪;
- 系统：头寸自动平盘与流动性预测、差错中心完整版、TM 规则+案件系统、申报自动化、多 Region 部署。
三期(18 个月+)：规模与壁垒
- 牌照：欧美自持(EMI/MTL),CIPS 间接参与者;自有 BIC;
- 产品：全球商户(非中国主体)、API 生态/嵌入式金融(为平台型客户提供收付能力);
- 系统：路由智能化(成功率模型)、TM 机器学习、账务分库分表、渠道 2-4 周快速接入流水线。
8. 全系列回顾与遗留决策清单
系列文档：01 总览 → 02 收款 → 03 付款(含人民币/计费)→ 04 换汇头寸 → 05 合规风控 → 06 账户记账 → 07 渠道路由 → 08 清结算对账 → 09 架构(本篇)。
跨篇遗留决策点汇总(待 Review 时逐项拍板):
| # | 决策点 | 出处 |
|---|---|---|
| 1 | VA 供给策略与首批渠道名单 | 02/07 |
| 2 | 目标商户范围(仅中国 vs 全球) | 02 |
| 3 | 人民币对私付款是否做、合规方案 | 03 |
| 4 | 计费收入结构(显性费 vs FX 加点)与账单制授信 | 03 |
| 5 | LP 选择、敞口限额、资金枢纽选址(HK vs SG) | 04 |
| 6 | 牌照路线图(先 MSO 还是 MPI)与合规供应商选型 | 05 |
| 7 | 禁入行业清单与风险偏好 | 05 |
| 8 | 结算周期/留存金政策 | 08 |
| 9 | 团队技术栈确认与自研/外采边界 | 09 |
核心结论
- 订单、账务和渠道状态分别拥有不同事实。
- 核心账务应独立部署并保持最严格的一致性。
- 技术选型应服务领域约束和团队能力，而不是反过来。