架构设计-支付宝、京东、美团、去哪儿的支付系统架构整体设计详解!!!

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 架构设计-支付宝、京东、美团、去哪儿的支付系统架构整体设计详解!!!支付产品模块是按照支付场景来为业务方提供支付服务。这个模块一般位于支付网关之后,支付渠道之前。

架构设计-支付宝、京东、美团、去哪儿的支付系统架构整体设计详解!!!

支付产品模块是按照支付场景来为业务方提供支付服务。这个模块一般位于支付网关之后,支付渠道之前。 它根据支付能力将不同的支付渠道封装成统一的接口,通过支付网关来对外提供服务。所以,从微服务的角度,支付产品本身也是一个代理模式的微服务,它透过支付网关响应业务方请求, 进行一些统一处理后,分发到不同的支付渠道去执行,最后将执行结果做处理后,通过支付网关再回传给业务方。

支付产品在支付系统参考架构图中之位置,请看下图所示:

img_90f7c679d73c0140d41806aa67fe879e.jpe

产品分类

在不同的公司由于接入渠道和应用的差异,对支付产品分类略有不同。综合支付场景和流程,支付产品可以分为如下几类:

img_3c9cd648bdb293b6a64e3856de8d87b3.jpe

支付产品是由支付系统对支付渠道进行封装而对业务方提供的支付能力。整体上来说,可以提供如下支付产品:

1. 快捷支付

用户在完成绑卡之后,在支付的时候,不需要再输入卡或者身份信息,仅需要输入支付密码就可以完成支付。对于小额度的支付,甚至可以开通小额免密,直接完成支付。 这种支付方式不会打断用户的体验,是目前主要的在线支付方式。一般快捷支付产品是通过封装银行或者第三方支付平台提供的快捷支付接口或者代付接口来实现的。

2. 网银支付

用户在支付的时候,需要跳转到银行网银页面来完成支付。在网银页面,需要输入用户的卡号和身份信息。这种支付方式会中断用户当前的体验,一般仅用于PC Web上的支付。 网银支付是封装银行提供的网银支付来实现。

3. 协议支付

协议支付也称代收或者代扣,代收指渠道授权商户可以从用户的银行账户中扣款,一般用于定期扣款,不用于日常消费。比如水电煤气、有线电视费。协议支付是通过封装银行、第三方支付提供的代扣或者快捷接口来实现。

4. 平台支付

使用微信、支付宝等第三方支付平台来完成支付。使用时,一般需要用户预先安装支付平台系统(手机上),注册并登录到第三方支付平台,并且已经在该平台上完成绑卡等操作。 由于微信、支付宝已经被大量使用,用户也产生对这些平台的信任,平台支付往往是电商公司的主要支付方式。

5. 外卡支付

对于由海外支付的需求,还需要提供外卡支付支持。 国内不少支付渠道都能支持外卡支付,如支付宝全球购等。直接对接Paypal,也是目前用的最多的外卡支付渠道。 关于外卡支付,以后会有专文介绍。

6. 话费支付

对于有包月小额类型的支付,手机话费也是一个不错的选择。目前也有一些平台可以支持话费支付,比如虹软、联动优势等。

7. 虚币支付

不少公司会有自己的虚拟币,比如京豆、Q币等。这些虚币也可以作为一种支付方式。

8. 账户支付

也成为余额支付、零钱支付等。 指为用户建立本地账户, 支持充值,之后可以使用这个账户来完成支付。

9. 信用支付

如京东的白条,蚂蚁花呗等,指使用信用账户进行透支,类似信用卡支付。

10. 代付

和代扣相反,代付是平台将钱打给用户。

每一种支付方式的详细功能将在后续的各个章节中介绍。 这里先简要介绍支付产品模块的通用功能。

模块功能

支出产品根据其支付能力,对外提供不同的功能。整体上来说,一般支付产品需要提供如下接口:

img_4ad26fd0478f02c75fe4b21fb9a0eb61.png

架构设计-支付宝、京东、美团、去哪儿的支付系统架构整体设计详解!!!

1. 签约和解约

在快捷支付、代扣等产品中,用户在使用前,需要先完成签约。签约可以在渠道侧进行,一般第三方支付采用这种方式,当电商需要接入时,让第三方给授权。 银行和银联的签约一般是在电商侧进行, 电商侧负责收集用户的信息,调用银行和银联的接口进行签约。签约后,后续的支付行为就使用签约号来进行,无需再输入个人信息。 和签约相对应,解约则是取消签约关系。

2. 支付

支付是少不了的操作。 不同产品中支付行为不一样。快捷支付是在电商服务器上发起,请求渠道进行支付;网银支付则是跳转到银行支付网关上进行; 而账户支付、虚币支付,则是在本地进行的。

3. 撤销和退款

有些渠道区分撤销和退款,比如银联、农行等,撤销指取消当天在渠道侧未结算的交易; 而退款仅针对已经结算的交易。有些渠道则不作区分。

4. 查询签约状态

对于需要签约的交易,可以通过这个接口来查询签约状态。

5. 查询订单状态

通过这个接口来查询支付清单状态以及退款的订单状态。

6. 预授权

预授权交易用于受理方向持卡人的发卡方确认交易许可。受理方将预估的消费金额作为预授权金额,发送给持卡人的发卡方。

7. 预授权撤销

对已成功的预授权交易,在结算前使用预授权撤销交易,通知发卡方取消付款承诺。预授权撤销交易必须是对原始预授权交易或追加预授权交易最终承兑金额的全额撤销。

8. 预授权完成交易

对已批准的预授权交易,用预授权完成做支付结算。

9. 预授权完成撤销

预授权完成撤销交易必须是对原始预授权完成交易的全额撤销。预授权完成撤销后的预授权仍然有效。

10. 对账

通过FTP或者HTTP方式提供对账文件供商户侧对账。

11. 余额查询

查询商户的交易账户的余额,避免由于余额不足导致交易失败。 注意,不是客户的余额。 当然,不是所有的银行或者第三方支付都提供这个接口。

业务流程

上述操作,除了对账、查单外,每个操作实现的主流程,一般会包括参数校验,支付路由,生成订单,风险评估,调用渠道服务,更新订单和发送消息这7步,对于一些比较复杂的服务,还会涉及到异步同通知处理的步骤。

img_97ce3038488aa11166585fd6e9d0d0e8.png

1. 执行参数校验

所有的支付操作,都需要对输入执行参数校验,避免接口受到攻击。

验证输入参数中各字段的有效性验证,比如用户ID,商户ID,价格,返回地址等参数。

验证账户状态。交易主体、交易对手等账户的状态是处于可交易的状态。

验证订单:如果涉及到预单,还需要验证订单号的有效性,订单状态是未支付。为了避免用户缓存某个URL地址,还需要校验下单时间和支付时间是否超过预定的间隔。

验证签名。签名也是为了防止支付接口被伪造。 一般签名是使用分发给商户的key来对输入参数拼接成的字符串做MD5 Hash或者RSA加密,然后作为一个参数随其他参数一起提交到服务器端。如支付网关设计所介绍,签名验证也可以在网关中统一完成。

2. 根据支付路由寻找合适的支付服务

根据用户选择的支付方式确定用来完成该操作的合适的支付渠道。用户指定的支付方式不一定是最终的执行支付的渠道。比如用户选择通过工行信用卡来执行支付,但是我们没有实现和工行的对接,而是可以通过第三方支付,比如支付宝、微信支付、易宝支付,或者银联来完成。那如何选择合适的支付渠道,就通过支付路由来实现。支付路由会综合考虑收费、渠道的可用性等因素来选择最优方案。

3. 评估交易风险

检查本次交易是否有风险。风控接口返回三种结果:阻断交易、增强验证和放行交易。

1) 阻断交易,说明该交易是高风险的,需要终止,不执行第5个步骤;

2) 增强验证,说明该交易有一定的风险,需要确认下是不是用户本人在操作。这可以通过发送短信验证码或者其他可以验证用户身份的方式来做校验,验证通过后,可以继续执行该交易。

3) 放行交易,即本次交易是安全的,可以继续往下走。

4. 生成交易订单

将订单信息持久化到数据库中。当访问压力大的时候,数据库写入会成为一个瓶颈。

5. 调用支付渠道提供的服务

所有的支付服务都需要第三方通道来完成执行。一般银行渠道的调用比较简单,可以直接返回结果。一些第三方支付,支付宝,微信支付等,会通过异步接口来告知支付结果。

6. 更新订单

对于同步返回的结果,需要在主线程中更新订单的状态,标记是支付成功还是失败。对于异步返回的渠道,需要在异步程序中处理。

7. 发送消息

通过消息来通知相关系统关于订单的变更。风控,信用BI等,都需要依赖这数据做准实时计算。

8. 异步通知

如上述流程,其中涉及到调用远程接口,其延迟不可控。如果调用方一直阻塞等待,很容易超时。引入异步通知机制,可以让调用方在主线程中尽快返回,通过异步线程来得到支付结果。对于通过异步来获取支付结果的渠道接口,也需要对应的在异步通知中将结果返回给调用方。 异步通知需要调用方提供一个回调地址,一般以http或者https的方式。这就有技术风险,如果调用失败,还需要重试。而重试不能过于频繁,需要逐步拉大每一次重试的时间间隔。 在异步处理程序中,订单根据处理结果变更状态后,也要发消息通知相关系统。

支付系统架构整体设计

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

架构设计-支付宝、京东、美团、去哪儿的支付系统架构整体设计详解!!!

支付宝

我们先看看业内最强的支付宝系统。架构图如下:

img_43c26d0d8b6634a7580091072feefa25.jpe

这个整体架构上并没有与众不同之处。在模块划分上,这个图显示的是最顶层的划分,也无法告知更多细节。 但支付宝架构文档有两个搞支付平台设计的人必须仔细揣摩的要点。 一个是账务处理。在记账方面,涉及到内外两个子系统,外部子系统是单边账,满足线上性能需求;内部子系统走复式记账,满足财务需求。在清结算这个章节中也是基于这个模型来详细介绍如何记账、对账和平账。

img_aaedc5d080b984f20a7871b97d6202c5.jpe

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

京东金融

来自京东支付平台总体架构设计 。如下图:

img_63f0de1099d025fc13698ee82bb4ec3b.jpe

京东金融是在网银在线的基础上发展起来的。 网银在线的原班技术人员有不少来自易宝公司,在京东收购之后,又引入了支付宝的人才。

因而从架构上受这两个公司的影响很大。

去哪儿

这是来自去哪儿公司分享的支付产品架构。请看下图:

img_d2e0692ff44fe04fb8b59c6fabde5c08.jpe

美团的支付平台架构

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

img_347713a9c0605a9b84c64dadbfa83de9.jpe

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

参考架构

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

img_0fd1e77fcbdd932dfe1cfc6abf81eadd.jpe

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

支撑层: 用来支持核心系统的基础软件包和基础设施, 包括运维监控系统、日志分析系统等。

核心层: 支付系统的核心模块,内部又分为两个部分: 支付核心模块以及支付服务模块。

产品层: 通过核心层提供的服务组合起来,对最终用户、商户、运营管理人员提供的系统。

支撑系统

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

运维监控: 支付系统在下运行过程中不可避免的会受到各种内部和外部的干扰,光纤被挖断、黑客攻击、数据库被误删、上线系统中有bug等等,运维人员必须在第一时间内对这些意外事件作出响应,又不能够一天24小时盯着。这就需要一个运维监控系统来协助完成。

日志分析: 日志是支付系统统计分析、运维监控的重要依据。公司需要提供基础设施来支持日志统一收集和分析。

短信平台: 短信在支付系统中有重要作用: 身份验证、安全登录、找回密码、以及报警监控,都需要短信的支持。

安全机制: 安全是支付的生命线。 SSL、证书系统、防刷接口等,都是支付的必要设施。

统计报表: 支付数据的可视化展示,是公司进行决策的基础。

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

支付核心系统

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

用户从支付应用启动支付流程。

支付应用根据应用和用户选择的支付工具来调用对应的支付产品来执行支付。

支付路由根据支付工具、渠道费率、接口稳定性等因素选择合适的支付渠道来落地支付。

支付渠道调用银行、第三方支付等渠道提供的接口来执行支付操作,最终落地资金转移。

支付服务系统

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

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

客户信息管理:包括对用户、商户的实名身份、基本信息、协议的管理;

卡券管理: 对优惠券、代金券、折扣券的制作、发放、使用流程的管理;

支付通道管理: 通道接口、配置参数、费用、限额以及QOS的管理;

账户和账务系统: 管理账户信息以及交易流水、记账凭证等。这里的账务一般指对接线上系统的账务,采用单边账的记账方式。 内部账记录在会计核算系统中。

订单系统: 一般订单系统可以独立于业务系统来实现的。这里的订单,主要指支付订单。

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

会计核算: 提供会计科目、内部账务、试算平衡、日切、流水登记、核算和归档的功能。

资金管理: 管理公司在各个支付渠道的头寸,在余额不足时进行打款。 对第三方支付公司,还需要对备付金进行管理。

清算分润: 对于有分润需求的业务,还需要提供清分清算、对账处理和计费分润功能。

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

想要学习Java高架构、分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频免费获取 架构设计-支付宝、京东、美团、去哪儿的支付系统架构整体设计详解!!!  

支付应用

支撑系统、核心系统和服务系统,在每个互联网公司的架构上都是大同小异的,都是必不可少的模块。而支付应用是每个公司根据自己的业务来构建的,各不相同。

总体来说,可以按照使用对象分为针对最终用户的应用、针对商户的应用、针对运营人员的运营管理、BI和风控后台。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
5月前
|
Java Docker 容器
美团大牛精心整理SpringBoot学习笔记,从Web入门到系统架构
近期慢慢复工,为了准备面试,各路码友们都开始磨拳擦脚,背面试题、知识点。小编最近得一良友赠送了一份关于SpringBoot的学习笔记,简直不要好用,理论解析言简意赅,每一步操作都有图片展示。这么好的东西肯定不能私藏,为了感谢大家在2019年里的支持,我现在将这份笔记赠送给大家,祝大家前程似锦,Offer不断!
|
2月前
|
Ubuntu Linux
查看Linux系统架构的命令,查看linux系统是哪种架构:AMD、ARM、x86、x86_64、pcc 或 查看Ubuntu的版本号
查看Linux系统架构的命令,查看linux系统是哪种架构:AMD、ARM、x86、x86_64、pcc 或 查看Ubuntu的版本号
236 3
|
4月前
|
存储 边缘计算 Cloud Native
“论模型驱动架构设计方法及其应用”写作框架,软考高级,系统架构设计师
模型驱动架构设计是一种用于应用系统开发的软件设计方法,以模型构造、模型转换和精化为核心,提供了一套软件设计的指导规范。在模型驱动架构环境下,通过创建出机器可读和高度抽象的模型实现对不同问题域的描述,这些模型独立于实现技术,以标准化的方式储存,利用模型转换策略来驱动包括分析、设计和实现等在内的整个软件开发过程。
147 3
|
15天前
|
监控 Android开发 iOS开发
深入探索安卓与iOS的系统架构差异:理解两大移动平台的技术根基在移动技术日新月异的今天,安卓和iOS作为市场上最为流行的两个操作系统,各自拥有独特的技术特性和庞大的用户基础。本文将深入探讨这两个平台的系统架构差异,揭示它们如何支撑起各自的生态系统,并影响着全球数亿用户的使用体验。
本文通过对比分析安卓和iOS的系统架构,揭示了这两个平台在设计理念、安全性、用户体验和技术生态上的根本区别。不同于常规的技术综述,本文以深入浅出的方式,带领读者理解这些差异是如何影响应用开发、用户选择和市场趋势的。通过梳理历史脉络和未来展望,本文旨在为开发者、用户以及行业分析师提供有价值的见解,帮助大家更好地把握移动技术发展的脉络。
|
4月前
|
存储 数据采集 数据挖掘
“湖仓一体架构及其应用”写作框架,系统架构设计师
随着5G、大数据、人工智能、物联网等技术的不断成熟,各行各业的业务场景日益复杂,企业数据呈现出大规模、多样性的特点,特别是非结构化数据呈现出爆发式增长趋势。在这一背景下,企业数据管理不再局限于传统的结构化OLTP(On-Line Transaction Processing)数据交易过程,而是提出了多样化、异质性数据的实时处理要求。传统的数据湖(Data Lake)在事务一致性及实时处理方面有所欠缺,而数据仓库(Data Warehouse)也无法应对高并发、多数据类型的处理。因此,支持事务一致性、提供高并发实时处理及分析能力的湖仓一体(Lake House)架构应运而生。湖仓一体架构在成本、
|
4月前
|
存储 消息中间件 API
“论微服务架构及其应用”写作框架,软考高级,系统架构设计师
论微服务架构及其应用近年来,随着互联网行业的迅猛发展,公司或组织业务的不断扩张,需求的快速变化以及用户量的不断增加,传统的单块(Monolithic)软件架构面临着越来越多的挑战,已逐渐无法适应互联网时代对软件的要求。在这一背景下,微服务架构模式(MicroserviceArchitecturePattern)逐渐流行,它强调将单一业务功能开发成微服务的形式,每个微服务运行在一个进程中;采用HTTP等通用协议和轻量级API实现微服务之间的协作与通信。这些微服务可以使用不同的开发语言以及不同数据存储技术,能够通过自动化部署工具独立发布,并保持最低限制的集中式管理。
164 4
|
3月前
|
存储 搜索推荐 API
业务系统架构实践问题之单系统内架构形态中,起步时的domain设计问题如何解决
业务系统架构实践问题之单系统内架构形态中,起步时的domain设计问题如何解决
|
3月前
|
存储 搜索推荐 API
业务系统架构实践问题之分层架构中的四层定位是什么
业务系统架构实践问题之分层架构中的四层定位是什么
|
4月前
|
边缘计算 Cloud Native IDE
“论SOA在企业集成架构设计中的应用”写作框架,系统架构设计师
企业应用集成(Enterprise Application Integration, EAI)是每个企业都必须要面对的实际问题。面向服务的企业应用集成是一种基于面向服务体系结构(Service-OrientedArchitecture,SOA)的新型企业应用集成技术,强调将企业和组织内部的资源和业务功能暴露为服务,实现资源共享和系统之间的互操作性,并支持快速地将新的应用以服务的形式加入到已有的集成环境中,增强企业IT环境的灵活性。
|
4月前
|
运维 监控 Cloud Native
“论云原生架构及其应用”写作框架,系统架构设计师
近年来,随着数字化转型不断深入,科技创新与业务发展不断融合,各行各业正在从大工业时代的固化范式进化成面向创新型组织与灵活型业务的崭新模式。在这一背景下,以容器和微服务架构为代表的云原生技术作为云计算服务的新模式,已经逐渐成为企业持续发展的主流选择。云原生架构是基于云原生技术的一组架构原则和设计模式的集合,旨在将云应用中的非业务代码部分进行最大化剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等),使业务不再有非功能性业务中断困扰的同时,具备轻量、敏捷、高度自动化的特点。云原生架构有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用
124 0