支付系统-架构设计
设计
目标
- 简化逻辑:边界清晰、无冗余逻辑、方便测试
- 分布式:容器化部署、无状态、可扩展、低耦合
- 高用性:机房多主、自动扩容、数据库最终一致
拆分
- 业务:代金券、活动
- 支付中心:商品管理、价格管理、发货路由
- 支付网关:下单、支付、代扣、通知、后督(订单二次确认)、对账、渠道服务
实现
网关体系
- 支付网关:接受下单请求、校验签名、生成订单、操作DB、调用渠道服务
- 代扣网关:处理签约请求、代扣请求、互斥逻辑
- 通知网关:处理渠道通知
渠道服务集合
原则
- 无db操作
- 无订单操作
- 只接受请求并响应对应数据
- 不关心上层逻辑
微服务化
渠道微服务化,可以在国际化业务中带来更便捷的差异化部署
面向协议编程
- pay(用户触发扣款或签约)
- method:alipay/wechat/unionpay
- from: WEB/MWEB/APP/SDK/BANK/SERVER
- type: pay/sign_pay
- confirm_pay(确认支付,用户二次验证)
- refund(退款)
- transfer(转账)
扩展&配置
- etcd配置管理
- 简化配置
- 使用field tag生成json
- 管理后台根据field json生成配置表单
支付网关系统
支付调用时序图
签约
数据库高可用
- 跨DC同步:基于otter进行同步,双向同步(多机房使用星型结构)
- 同DC高可用:基于mycat和mgr,实现大容量、高可用db集群
- mgr的心跳检测:二次开发mycat,对mgr节点状态实时检测并增删故障db
- 应用层:去除自增主键,按机房、机器生成无冲突、有序的流水号,防止多机房数据冲突
部署架构
交互
配置
核心交易系统是将配置信息存储在etcd
容器内
渠道
- 基础目录:
/foo/bar/pay/config
- 每个渠道占用一个文件夹,每个渠道账户占用一个
文件
,例如微信存放在/foo/bar/pay/config/wechat
目录下,appId: 2088123456 所在的配置信息存储在/foo/bar/pay/config/wechat/2088123456