浅析支付系统的整体架构

12 评论 96181 浏览 615 收藏 9 分钟

本文主要是简单地描述支付系统的整体架构。

支付的典型架构

每个公司根据其业务和公司发展的不同阶段,所设计的支付系统也会有所不同。我们先看看互联网公司的一些典型的支付系统架构。

支付宝

先看看业内最强的支付宝系统,支付宝的支付系统整体架构设计

这个整体架构上并没有与众不同之处。在模块划分上,这个图显示的是最顶层的划分,也无法告知更多细节。 但支付宝架构强点在两个方面,一个是账务处理,分为内外两个子系统,外部子系统是单边账,内部子系统走复式记账。 不少支付平台是从这里得到启发来搞定的对账系统。

另一个亮点是柔性事务处理,利用消息机制来实现跨系统的事务处理,避免数据库锁导致的性能问题。

京东金融

来自京东支付平台总体架构设计

京东金融是在网银在线的基础上发展起来的。 网银在线的原班技术人员有不少来自易宝公司,在京东收购之后,又引入了支付宝的人才。因而从架构上受这两个公司的影响很大。

去哪儿

来自去哪儿公司分享的支付产品架构

美团

来自美团的支付平台规划架构 。这是2015年的文档。 2016年美团才拿到支付牌照。 从这个架构,大家也能知道为什么美团必须拿到支付牌照。

这些架构文档全部来自互联网公开资料。 对于架构是否真实反映实际系统情况,需要大家自行判断。 我们以这些文档为基础,分析支付系统的应有的软件架构。

参考架构

一般来说,支付系统典型架构会包含如下模块:

支付系统从架构上来说,分为三层:

  1. 支撑层: 用来支持核心系统的基础软件包和基础设施, 包括运维监控系统、日志分析系统等。
  2. 核心层: 支付系统的核心模块,内部又分为两个部分: 支付核心模块以及支付服务模块。
  3. 产品层: 通过核心层提供的服务组合起来,对最终用户、商户、运营管理人员提供的系统。

支撑系统

支撑系统是一个公司提供给支付系统运行的基础设施。 主要包括如下子系统:

  1. 运维监控: 支付系统在下运行过程中不可避免的会受到各种内部和外部的干扰,光纤被挖断、黑客攻击、数据库被误删、上线系统中有bug等等,运维人员必须在第一时间内对这些意外事件作出响应,又不能够一天24小时盯着。这就需要一个运维监控系统来协助完成。
  2. 日志分析: 日志是支付系统统计分析、运维监控的重要依据。公司需要提供基础设施来支持日志统一收集和分析。
  3. 短信平台: 短信在支付系统中有重要作用: 身份验证、安全登录、找回密码、以及报警监控,都需要短信的支持。
  4. 安全机制: 安全是支付的生命线。 SSL、证书系统、防刷接口等,都是支付的必要设施。
  5. 统计报表: 支付数据的可视化展示,是公司进行决策的基础。

远程连接管理、分布式计算、消息机制、全文检索、文件传输、数据存储、机器学习等,都是构建大型系统所必须的基础软件,这里不再一一详细介绍。

支付核心系统

支付核心系统指用户执行支付的核心流程,包括:

  1. 用户从支付应用启动支付流程。
  2. 支付应用根据应用和用户选择的支付工具来调用对应的支付产品来执行支付。
  3. 支付路由根据支付工具、渠道费率、接口稳定性等因素选择合适的支付渠道来落地支付。
  4. 支付渠道调用银行、第三方支付等渠道提供的接口来执行支付操作,最终落地资金转移。

支付服务系统

支持支付核心系统所提供的功能。服务系统又分为基础服务系统、资金系统、风控和信用系统。

基础服务系统提供支撑线上支付系统运行的基础业务功能:

  1. 客户信息管理:包括对用户、商户的实名身份、基本信息、协议的管理;
  2. 卡券管理: 对优惠券、代金券、折扣券的制作、发放、使用流程的管理;
  3. 支付通道管理: 通道接口、配置参数、费用、限额以及QOS的管理;
  4. 账户和账务系统: 管理账户信息以及交易流水、记账凭证等。这里的账务一般指对接线上系统的账务,采用单边账的记账方式。 内部账记录在会计核算系统中。
  5. 订单系统: 一般订单系统可以独立于业务系统来实现的。这里的订单,主要指支付订单。

资金系统指围绕财务会计而产生的后台资金核实、调度和管理的系统,包括:

  1. 会计核算: 提供会计科目、内部账务、试算平衡、日切、流水登记、核算和归档的功能。
  2. 资金管理: 管理公司在各个支付渠道的头寸,在余额不足时进行打款。 对第三方支付公司,还需要对备付金进行管理。
  3. 清算分润: 对于有分润需求的业务,还需要提供清分清算、对账处理和计费分润功能。

风控系统是支付系统必备的基础功能,所有的支付行为必须做风险评估并采取对应的措施;信用系统是在风控基础上发展的高级功能,京东的白条,蚂蚁花呗等,都是成功的案例。

支付应用

支撑系统、核心系统和服务系统,在每个公司的架构上应该是大同小异的,都是必不可少的模块。而支付应用是每个公司根据自己的业务来构建的,各不相同。 总的来说,可以按照使用对象分为针对最终用户的应用、针对商户的应用、针对运营人员的运营管理、BI和风控后台。

总结

这一章节简单描述支付系统的整体架构。后续我们将以此为基础,分别介绍各个模块的设计。

#专栏作家#

凤凰牌老熊,微信公众号:凤凰牌老熊,人人都是产品经理专栏作家,10多年企业应用和互联网软件架构设计经验,关注互联网金融和大数据领域。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 受益匪浅,感谢

    来自浙江 回复
  2. 感谢大神

    来自北京 回复
  3. 希望作者能出一本支付产品设计的专著啊

    回复
  4. 有没有支付路由设计的干货贴?

    回复
  5. 感谢

    来自上海 回复
  6. 文章很有参考价值,跟着看了系列文章了,之前先看了清结算的文章不是很明白,看完这边文章再回头看清结算系统的文章另有收获!感谢大神分享!

    来自上海 回复
  7. 稳!

    回复
  8. 好深奥

    来自浙江 回复
  9. 膜拜,受教了

    来自广东 回复
  10. 老哥稳~

    来自浙江 回复
  11. 学到了

    来自浙江 回复
  12. 好有道理啊

    回复