⽀支付体系架构与实践

陈宗（铁手）
资深研发工程师
陈宗 资深研发工程师

• 花名铁⼿手，14年年加⼊入蘑菇街。参与美联⽀支付
技术历次重⼤大优化与演进，主导⽀支付体系中
交易易和⽀支付系统的平台化架构，并持续钻研
和改进具有电商特⾊色的⽀支付平台。⽬目前在⽀支
付团队负责⽀支付基础平台架构和研发⼯工作。
• 支付系统 1.x
• 支付体系2.0 架构实践
• 支付平台性能提升
• 支付平台稳定性提升
• 总结展望
 支付系统 1.x

ӱ‫ۓ‬ᔮᕹ

• 业务简单、玩法单一
තᱷ‫ݣ‬ཛྷࣘ ඪ՞ཛྷࣘ

• 快速支撑系统
Ⴠ᭲ᗑ‫ى‬ ᨴ‫ۓ‬ཛྷࣘ

• 实现核心功能 ඪ՞ᔮᕹ

ӣොඪ՞
 发展历程

• 业务超高速发展

• 电商交易、支付金融业务复杂度剧增

• 支付核心链路大促峰值达到日常百倍以上
 业务问题

೅‫כ‬Իฃ
ኪࠟԻฃ
ᶼࠓ
• 烟囱型结构，难扩展
ଠ‫ޞ‬ᨻԣ
ଠ‫ޞ‬០ᲀ
• 业务野蛮生长，无模型抽象 ଠ‫ޞ‬ᭅᩇ

ᩅྃනྃ
ᰂᣟӱ‫ۓ‬
• 业务边界模糊，耦合严重 ᩅྃᬮྃ

ၾᩇദ‫מ‬ ᬮྃ

ᦇ௳
ӱ‫ۓ‬ᕚ ඪ՞ᔮᕹ
 තᱷ‫ݣ‬ཛྷࣘ ඪ՞ཛྷࣘ

系统问题
Ⴠ᭲ᗑ‫ى‬ ᨴ‫ۓ‬ཛྷࣘ

ඪ՞ᔮᕹ

DB

• 巨大臃肿单体PHP应用 ‫ܔ‬DB

• 系统间严重耦合 තᱷ‫ݣ‬ཛྷࣘ

• 弱稳定性 ඪ՞ཛྷࣘ Ⴠ᭲ᗑ‫ى‬ ᨴ‫ۓ‬ཛྷࣘ

• 单点性能瓶颈 ඪ՞ᔮᕹ

DB_1 DB_2 DB_3

DB࣮ፗೆ‫ړ‬
 资金问题

• 支付接入无授权

• 各项业务收入、支出难核算

• 数据一致性挑战
• 支付系统 1.x
• 支付体系2.0 架构实践
• 支付平台性能提升
• 支付平台稳定性提升
• 总结展望
 如何做？

• 系统拆分、服务化

• 确定边界、业务建模

• 沉淀基础服务

• 构建资金核算体系
 确定边界

• 业务、场景、技术划分边界

• 核心子系统划分为：

• 收银台、交易核心、支付核心、网关

• 账务、会计、清算、合规
 ኪࠟԻฃ

 

Իฃ໐ஞ  ࠟಁ᭗Ꭳ


තᱷ‫ݣ‬


ӣො
ඪ՞໐ஞ  Ⴠ᭲ᗑ‫ى‬ 
ඪ՞


ᨴ‫ۓ‬ տᦇ Ⴔᓒ ‫ݳ‬ᥢ
ᔮᕹ ᔮᕹ ᔮᕹ ᔮᕹ

ඪ՞ଘ‫ݣ‬
 ኪࠟԻฃ ଠ‫ޞ‬០ᲀ ፗඎ ᰂᣟӱ‫ۓ‬ ٌ՜

ӱ‫ۓ‬ᔮᕹ

տާᨴಁ ଘ‫ݣ‬ᭇᯈ ჉ວඪ՞ ඪ՞വគ $3,ള‫ف‬

තᱷ‫ݣ‬
ඪ՞ᷚഴ ਫ‫ݷ‬๐‫ۓ‬
ദ๦ᰄ๦
‫ܜ‬๐‫ۓ‬ ඪ՞ᖫഭ Ⴠ᭲᪠ኧ
ᦈ‫ڹܔ‬ᗝ
ඪ՞ૡٍ Ⴠ᭲ᦈ‫ܔ‬
‫ݳ‬ᕅӾஞ ᦈ‫ܔ‬඙֢
ඪ՞ၾ௳
ᦇᩇ ૧Კ॒ቘ ᗑ‫ڹى‬ᗝ
տާࠟಁᨴ‫ܔ‬ ࠟಁ᭗Ꭳ
Իฃ໐ஞ ඪ՞໐ஞ Ⴠ᭲ᗑ‫ى‬ ӣො
ඪ՞տާ๐‫ۓ‬
ඪ՞

ᩒᰂ
‫ړ‬୯ጭᦕ ‫ᦕྍݶ‬ᨴ ಸ෈୚ක
ᯈᗝ ႴᓒӾஞ ಓᓕ
ᓕቘ
෭‫ڔ‬࿤௛ ୑ྍᦕᨴ ‫ྍݶ‬ᥢ‫ڞ‬
ଘ‫ݣ‬ ٖक़੒ᨴ
ᑀፓᓕቘ ୑ଉᤑᨴ ‫ݳ‬ᥢ‫ᦤڂ‬
ᩒᰂ‫ښ‬೟
ᥢ‫ڞ‬ᓕቘ ᨴಁᓕቘ ‫ݳ‬ᥢᗑ‫ى‬
տᦇᔮᕹ ᨴ‫ۓ‬ᔮᕹ Ⴔᓒᔮᕹ ‫ݳ‬ᥢᔮᕹ

੒ᨴᔮᕹ

ඪ՞ଘ‫ݣ‬

7HVOD 5DSWRU &RUJL 3LJHRQ 0HWD%DVH .9VWRUH

/XUNHU 6SLULW 6HQWU\ ܴၥᔮᕹ Hawkeye Vaccum

चᏐඪඅଘ‫ݣ‬
 交易核心

• 抽象基础交易类型 ള‫ف‬
තᱷ
‫ݣ‬
ᰄ๦
ᦈ‫ܔ‬
• 多表聚合 ӱ‫ۓ‬ ᭦ᬋ
ᦈ‫ܔ‬ ඪ՞
ᔮᕹ ඙֢ ໐ஞ
॒ቘ
ࠟಁ
• 订单关联 ᭗Ꭳ

• 授权鉴权

DB
Իฃ໐ஞ

ඪ՞ᨴ‫ܔ‬ ඪ՞ၾ௳
 基础交易类型抽象

೅‫כ‬Իฃ
ኪࠟԻฃ
೅‫כ‬Իฃ
ᶼࠓ
• 抽象基础交易类型 ଠ‫ޞ‬ᨻԣ
ଠ‫ޞ‬០ᲀ ‫ܨ‬෸Իฃ
ଠ‫ޞ‬ᭅᩇ
• 担保交易、
ᩅྃනྃ
ᰂᣟӱ‫ۓ‬ ᫨ᨴ
ᩅྃᬮྃ
• 即时交易、
ၾᩇദ‫מ‬ ᬮྃ ŏ

• 充值、提现、 ᦇ௳
ӱ‫ۓ‬ᕚ Իฃ໐ஞ

• 退款、转账……
 多表聚合 & 订单关联

೅‫כ‬ඪ՞‫ܔ‬
• 订单唯一约束

• 任何订单可追溯初始单 ೅‫כ‬ମᱻ‫ܔ‬ ୑ଉᭅྃ‫ܔ‬

೅‫כ‬ᭅྃ‫ܔ‬ ଘ‫ݣ‬ಕ֧‫ܔ‬

ᭅྃᭅ‫ܔ‬ ଘ‫ݣ‬ᭅ֧‫ܔ‬
 支付接入管控

• 基于业务接入分配的业务标识码，添加授权入口，分配
token

• 业务系统请求支付，带token进入，鉴权
 支付核心

• 抽象4种支付类型 ೰ե ᗑ‫ى‬ඪ՞ Ⴠ᭲
ᖫഭ ඪ ᗑ‫ى‬
០ᲀඪ՞ ՞
Իฃ
• 充值、提现、退款、转账 ໐ஞ
ٌ՜ૡٍ
ᦕ
૧Კ ୯
ᨴ‫ۓ‬
॒ቘ
• 支付工具组件化 ඪ՞ૡٍ ໐ஞ

ඪ՞໐ஞ

• 抽象数十种支付工具 DB

• 支付编排 Ⴔᓒ ‫ݳ‬ᥢ
 支付编排

• 插件式开发

• 规则可配置化

ඪ՞ ᗑ‫ى‬ඪ՞ ០ᲀඪ՞
ඪ՞
ඪ՞ ඪ՞ ඪ՞ ೰ե
ᭌೠ ಗᤈ ᭌೠ ૡٍ ಗᤈ
Իฃ ᥢ‫ڞ‬ ᧗࿢ ᖫഭ
۱ ᗑ‫ى‬ᭅྃ ០ᲀᭅྃ
ᦈ‫ܔ‬ ᥢ‫ڞ‬
ඪ՞ૡٍ

ඪ՞೰եᖫഭ

ඪ՞ᖫഭ
 异常处理机制

• 支付异常分类 ᕁ۱ඪ՞ ᕁ۱ᭅྃ

౮‫ۑ‬Ӥಸ
<
• 重复支付
սణ‫ڭ‬ඪ՞ ౮‫ۑ‬Ӥಸ ୑ଉᓕቘᕟկ սణ‫ڭ‬ᭅྃ

• 部分支付 <
୑ଉӤಸ

ጮ՞ᗦඪ՞

• 金额不一致 1 ᮱‫ړ‬ඪ՞୑ଉᭅྃ

• 其他异常全额退款
 渠道网关

• 网关服务抽象 Ⴠ᭲᪠ኧ Ⴠ᭲ᭇᯈ

Ⴠ᭲ᦈ‫ܔ‬ ಸ෈᫨ഘ
• 支付、退款、提现、 ඪ՞ ӣො
໐ஞ Ⴠ᭲‫ړ‬ᕟ क़᮱᭗ᦔ ඪ՞

• 签约、查询 ᗑ‫ى‬໐ஞ ᗑ‫ڹى‬ᗝ

Ⴠ᭲ᗑ‫ى‬

• 网关核心、网关前置
Gateway
资金核算体系

ඪ՞໐ஞ

‫ړ‬୯ ‫ྍݶ‬ ୑ྍ Ⴔᓒ ٖक़ ‫ྍݶ‬ ಸ෈

෭‫ڔ‬
ጭᦕ ᦕᨴ ᦕᨴ Ӿஞ ੒ᨴ ᥢ‫ڞ‬ ୚ක

ᑀፓ ᥢ‫ڞ‬ ୑ଉ ᨴಁ ᩒᰂ ᥢ‫ڞ‬ ‫ݳ‬ᥢ ‫ݳ‬ᥢ

ᓕቘ ᓕቘ ᤑᨴ ᓕቘ ᧣೟ ᓕቘ ‫ᦤڂ‬ ᗑ‫ى‬

տᦇᔮᕹ ᨴ‫ۓ‬ᔮᕹ Ⴔᓒᔮᕹ ‫ݳ‬ᥢᔮᕹ

 平台统一上下文

• 唯一业务标识码（四要素），链路传递

• merchantId（商户）

• orderType（订单类型）

• subType（订单场景）

• payOrgNo（支付机构）
 数据一致性挑战

• CAS

• 幂等 & 异常补偿

• 对账
 CAS

• 交易核心、支付核心通过状态CAS防止并发

• update PayOrder set status=‘complete’ where id=1 and

status=‘process’

• 基于KVstore的分布式缓存锁

• 解决重复支付问题
 幂等 & 异常补偿 ӣොඪ՞

; හഝӧӞᛘ

Ⴠ᭲ᗑ‫ى‬

;
• 全链路接口保持幂等 හഝӧӞᛘ

ඪ՞໐ஞ
• 超时、网络异常等问题 ; හഝӧӞᛘ

Իฃ໐ஞ
• 基于Corgi准实时补偿
; හഝӧӞᛘ
• 异常表补偿 ኪࠟԻฃ

ඪ՞ࢧ᧣ᤑؑ๢‫ګ‬
 对账

• 对账是数据一致性最后一道防护

• 内部业务准实时对账

• T+1 基于账单，内外对账
 准实时对账

• 支持多数据源 හഝრ

• 低延时
ཛྷࣳ᫨ഘ

‫ݻ݌‬੒ᨴ
ᯈᗝ
Ӿஞ
ᛔਧԎ᷇ሲ ᥢ‫ڞ‬ᯈᗝ ۖா‫ے‬᫹

୑ଉᛔ༄ ੒ᨴᕮຎ᭗Ꭳ
ӱ‫ۓ‬੒ᨴଘ‫ݣ‬
 疗效？

• 快速支撑业务

• 16年快速融合淘世界、美丽说支付系统

• 业务细分，来源管控

• 准确的资金核算，各业务资金情况清晰明了

• 解决资金监管问题
• 支付系统 1.x
• 支付体系2.0 架构实践
• 支付平台性能提升
• 支付平台稳定性提升
• 总结展望
 性能提升

• 核心链路分库分表：全链路水平扩展

• 服务调用异步化

• 热点账户问题优化

• 事务切分
 DB水平拆分

՞ྃො‫ړ‬
• 核心链路为例 Իฃ໐ஞ ପ

• DB基于Raptor分库分表
՞ྃො‫ړ‬
ඪ՞໐ஞ
• 全局ID唯一 ପ

ᨴ‫ۓ‬ᔮᕹ ᨴಁ‫ړ‬ପ Ⴠ᭲ᗑ‫ى‬ አಁ‫ړ‬ପ

 异步化

• 拆分&服务化带来更多系统依赖，异步化是最好的解耦
方式

• 支付核心链路非实时业务，可以异步化处理

• 异步化有益于提升链路性能
 支付消息

• 基于支付交易核心订单数据

• 解耦、简化业务方数据获取

PayOrder PayOrderMsg ០ᲀၚۖ

Parser Topic
Pigeon Parser Corgi Producer ඪ՞౮‫ۑ‬Ꭸ‫מ‬

3D\2UGHU 3LJHRQ &RUJL

ᷚഴ

PayOrderMsg
Builder ŏŏ

ඪ՞ၾ௳ಸ ӱ‫ۓ‬ො
 外部支付异步化

• 同步获取三方支付凭证

• 跨外部网络

• max RT >1s

• 支付链路整体阻塞
 外部支付异步化

• 异步获取

• 独立渠道前置

• avg RT 200->5ms
 异步并行

• 支付核心链路多为IO密集型
አಁ‫ັ௳מ‬
჉ວ‫ݗف‬ Ⴠ᭲჉ວ
ᧃ
• 利用Tesla框架异步服务调用
᷐ଶັᧃ
୑ྍଚᤈ
• 取决于最长的请求IO时间
սణັᧃ

჉ວ‫ݗف‬ አಁ‫ᧃັ௳מ‬ ᷐ଶັᧃ սణັᧃ Ⴠ᭲჉ວ

Ԁᤈ
 资金核算体系异步化

• 数据异步准实时同步

• pigeon（数据变更事件中间件）
ඪ՞໐ஞ

• 实时链路解耦 SLJHRQ
V\QF SLJHRQ

‫ړ‬୯ ‫ྍݶ‬ ୑ྍ Ⴔᓒ ٖक़ ‫ྍݶ‬ ಸ෈

෭‫ڔ‬
ጭᦕ ᦕᨴ ᦕᨴ Ӿஞ ੒ᨴ ᥢ‫ڞ‬ ୚ක
SLJHRQ
ᑀፓ ᥢ‫ڞ‬ ୑ଉ ᨴಁ ᩒᰂ ᥢ‫ڞ‬ ‫ݳ‬ᥢ ‫ݳ‬ᥢ
ᓕቘ ᓕቘ ᤑᨴ ᓕቘ ᧣೟ ᓕቘ ‫ᦤڂ‬ ᗑ‫ى‬

տᦇᔮᕹ ᨴ‫ۓ‬ᔮᕹ Ⴔᓒᔮᕹ ‫ݳ‬ᥢᔮᕹ

 账务-热点账户

• 单边记账

• 内部户，账务不记账，会计补分录

• 异步记账

• 平台户异步记账，定时汇总记账

• 二级子账户
账务-记账事务切分
VWDUW

VWDUW
‫ܔ‬ᬟᨴҘ

୑ྍᦕᨴҘ ൊ‫ᦕྍ୑ف‬ᨴ‫ᦤڂ‬ ᨴ‫ڊۓ‬ᨴ ‫ڊ‬ᨴ०ᨳ

1 ᫨ᨴ०ᨳ
1 ‫ڊ‬ᨴ౮‫ۑ‬
ๅෛ᷐֟

<
1 < ᨴ‫فۓ‬ᨴ ‫ف‬ᨴ०ᨳ ୑ྍᤑᨴ
ൊ‫ف‬ၞ࿜
ᦕᨴ०ᨳ
ᦕᨴԪ‫ۓ‬ ‫ف‬ᨴ౮‫ۑ‬

<

ᦕᨴ౮‫ۑ‬ ᦕᨴ ᫨ᨴ౮‫ۑ‬
 性能压测

• 构建压测模型，模拟线上真实场景

• 压测数据进影子库，正常业务无侵入

• 单机性能压测，集群链路压测

• 识别系统稳定性、容量配比等
 疗效？

• 链路DB扩容为2台物理机器，支付稳定 3000QPS。理论
值可达1w QPS以上

• 应用服务器利用率，只需原有机器的1/3

• 链路性能
• 支付系统 1.x
• 支付体系2.0 架构实践
• 支付平台性能提升
• 支付平台稳定性提升
• 总结展望
 稳定性提升

• 监控先行，关键指标管控

• 核心链路剥离

• 服务依赖治理

• 限流、降级
 核心链路监控

• `
 ኪࠟԻฃ

核心链路分离 


໐ஞ ᭗አ
 ࠟಁ᭗Ꭳ

电商平台特性
Իฃ໐ஞ
•


• 剥离核心链路 තᱷ‫ݣ‬



• 核心支付链路 ໐ஞ ᭗አ  ໐ஞ ᭗አ 
ӣො
ඪ՞
ඪ՞໐ஞ Ⴠ᭲ᗑ‫ى‬

• 通用支付服务 

໐ஞ
տᦇ Ⴔᓒ ‫ݳ‬ᥢ
᭗አ ᔮᕹ ᔮᕹ ᔮᕹ

ᨴ‫ۓ‬ᔮᕹ

ඪ՞ଘ‫ݣ‬
 服务依赖

• 梳理支付平台内强弱依赖，特别针对于核心下单链路

• 弱依赖做好降级开关

• 强依赖服务做好SLA保障
 限流、降级

• 限流是保护系统不挂的最后一道防线

• 基于tesla服务框架限流

• 基于spirit细粒度限流降级系统
• 支付系统 1.x
• 支付体系2.0 架构实践
• 支付平台性能提升
• 支付平台稳定性提升
• 总结展望
 总结与展望

• 支付体系上层业务面向电商特色

• 性能容量找寻一切可改进点

• 支付系统稳定性为先

• 支付平台配置统一化