最全最强解析:支付宝钱包系统架构内部剖析(架构图)
- 格式:pdf
- 大小:1.29 MB
- 文档页数:10
支付系统账户体系的设计云时代隶属于杭州云韦科技有限公司,提供技术的互联网金融基础设施,致力于协助有意参与互联网金融业务的企业客户确定战略方向和整体解决方案,并提供业界专业的架构和系统来确保其业务安全稳定地运行,同时符合监管要求。
云时代核心管理团队在互联网行业和金融行业均拥有丰富的经验。
其对互联网金融的深刻理解和对互联网金融基础设施研发的专注,形成公司独特的竞争力。
每个公司根据其业务和公司发展的不同阶段,所设计的支付系统也会有所不同。
我们先看看互联网公司的一些典型的支付系统架构。
支付宝先看看业内最强的支付宝系统,支付宝的支付系统整体架构设计这个整体架构上并没有与众不同之处。
在模块划分上,这个图显示的是最顶层的划分,也无法告知更多细节。
但支付宝架构强点在两个方面,一个是账务处理,分为内外两个子系统,外部子系统是单边账,内部子系统走复式记账。
不少支付平台是从这里得到启发来搞定的对账系统。
另一个亮点是柔性事务处理,利用消息机制来实现跨系统的事务处理,避免数据库锁导致的性能问题。
支付系统从架构上来说,分为三层:支撑层:用来支持核心系统的基础软件包和基础设施,包括运维监控系统、日志分析系统等。
核心层:支付系统的核心模块,内部又分为两个部分:支付核心模块以及支付服务模块。
产品层:通过核心层提供的服务组合起来,对最终用户、商户、运营管理人员提供的系统。
支撑系统支撑系统是一个公司提供给支付系统运行的基础设施。
主要包括如下子系统:运维监控:支付系统在下运行过程中不可避免的会受到各种内部和外部的干扰,光纤被挖断、黑客攻击、数据库被误删、上线系统中有bug等等,运维人员必须在第一时间内对这些意外事件作出响应,又不能够一天24小时盯着。
这就需要一个运维监控系统来协助完成。
日志分析:日志是支付系统统计分析、运维监控的重要依据。
公司需要提供基础设施来支持日志统一收集和分析。
短信平台:短信在支付系统中有重要作用:身份验证、安全登录、找回密码、以及报警监控,都需要短信的支持。
移动支付系统的技术框架分析随着智能手机和移动互联网的普及,移动支付系统作为新型支付方式受到广泛的关注和应用。
作为一种立足于智能手机等移动终端的支付解决方案,移动支付系统的技术框架是支撑其运行的核心要素。
本文将从几个方面对移动支付系统的技术框架进行分析,旨在帮助读者更加深入地了解移动支付系统。
一、基本架构移动支付系统的基本架构分为前端和后端两个部分。
前端主要涉及用户的移动终端,即智能手机或平板电脑等移动设备上的移动支付应用程序;后端则包括移动支付服务器、银行卡处理系统、第三方支付平台等。
前后端通过网络进行连接,实现各种支付业务的处理。
具体来说,移动支付系统的前端主要有移动支付应用、支付宝、微信支付等。
这些应用都可以通过IOS、Android等操作系统支持,为用户提供移动支付操作接口。
后端的移动支付服务器主要负责接收前端软件发送的支付请求,并进行处理,完成支付操作。
对于后端,鉴于移动支付不同于传统的POS机支付,因此移动支付系统需要与银行卡处理系统进行相应的对接工作,包括银行账户验证、资金扣划等。
同时,移动支付系统也需要有第三方支付平台的支持,通过与第三方支付平台的合作,为用户提供更加便捷、安全的支付方式。
二、技术要素移动支付的技术要素包括移动支付应用、支付接口、安全认证、交易流程等。
首先,移动支付应用是整个支付系统的前置要素,是用户与银行、第三方支付平台及商户之间的桥梁,用户通过移动支付应用来完成支付操作。
其次,支付接口是移动支付系统与商户进行接口对接的必备要素。
支付接口主要有两种,一种是服务器接口,一种是SDK接口。
其中服务器接口主要应用于Web和APP类型的网站和应用,SDK接口可以嵌入到APP中,实现与第三方支付平台的对接。
安全认证是移动支付系统的重要组成部分。
移动支付系统采用加密技术、数字签名等手段来保证支付过程的安全性,用户在进行支付操作时需要通过密码、指纹等安全认证手段对身份进行验证。
支付宝和蚂蚁花呗的技术架构及实践每年“双11”都是一场电商盛会,消费者狂欢日。
今年双11的意义尤为重大,它已经发展成为全世界电商和消费者都参与进来的盛宴。
而对技术人员来说,双十一无疑已经成为一场大考,考量的角度是整体架构、基础中间件、运维工具、人员等。
一次成功的大促准备不光是针对活动本身对系统和架构做的优化措施,比如:流量控制,缓存策略,依赖管控,性能优化……更是与长时间的技术积累和打磨分不开。
下面我将简单介绍支付宝的整体架构,让大家有个初步认识,然后会以本次在大促中大放异彩的“蚂蚁花呗”为例,大致介绍一个新业务是如何从头开始准备大促的。
因为涉及的内容要深入下去是足够写一个系列介绍,本文只能提纲挈领的让大家有个初步认识,后续可能会对大家感兴趣的专项内容进行深入分享。
架构支付宝的架构设计上应该考虑到互联网金融业务的特殊性,比如要求更高的业务连续性,更好的高扩展性,更快速的支持新业务发展等特点。
目前其架构如下:整个平台被分成了三个层:1. 运维平台(IAAS):主要提供基础资源的可伸缩性,比如网络、存储、数据库、虚拟化、IDC等,保证底层系统平台的稳定性;2. 技术平台(PAAS):主要提供可伸缩、高可用的分布式事务处理和服务计算能力,能够做到弹性资源的分配和访问控制,提供一套基础的中间件运行环境,屏蔽底层资源的复杂性;3. 业务平台(SAAS):提供随时随地高可用的支付服务,并且提供一个安全易用的开放支付应用开发平台。
架构特性逻辑数据中心架构在双十一大促当天业务量年年翻番的情况下,支付宝面临的考验也越来越大:系统的容量越来越大,服务器、网络、数据库、机房都随之扩展,这带来了一些比较大的问题,比如系统规模越来越大,系统的复杂度越来越高,以前按照点的伸缩性架构无法满足要求,需要我们有一套整体性的可伸缩方案,可以按照一个单元的维度进行扩展。
能够提供支持异地伸缩的能力,提供N+1的灾备方案,提供整体性的故障恢复体系。
因此在瞬息万变的互联网产品环境中,需要研发接入支付系统来加入商业行为的闭环,支付系统能够帮助企业更好地实现商业化,利用那些为用户而生的支付体系产品,实现用户积累、商业变现。
对于支付系统,有针对不同行业的支付系统,有支付宝,微信支付,paypal的通用网关支付,也有聚合了不同网关的聚合系统。
不论你是对支付行业感兴趣,亦或自己研发支付系统,本篇内容会对你有价值。
以下为正文。
从产品分类、模块功能和业务流程,了解支付产品服务的设计支付产品模块是按照支付场景来为业务方提供支付服务。
这个模块一般位于支付网关之后,支付渠道之前。
它根据支付能力将不同的支付渠道封装成统一的接口,通过支付网关来对外提供服务。
所以,从微服务的角度,支付产品本身也是一个代理模式的微服务,它透过支付网关响应业务方请求,进行一些统一处理后,分发到不同的支付渠道去执行,最后将执行结果做处理后,通过支付网关再回传给业务方。
支付产品在支付系统参考架构图中之位置,请看下图所示:产品分类在不同的公司由于接入渠道和应用的差异,对支付产品分类略有不同。
综合支付场景和流程,支付产品可以分为如下几类:支付产品是由支付系统对支付渠道进行封装而对业务方提供的支付能力。
整体上来说,可以提供如下支付产品:1. 快捷支付用户在完成绑卡之后,在支付的时候,不需要再输入卡或者身份信息,仅需要输入支付密码就可以完成支付。
对于小额度的支付,甚至可以开通小额免密,直接完成支付。
这种支付方式不会打断用户的体验,是目前主要的在线支付方式。
一般快捷支付产品是通过封装银行或者第三方支付平台提供的快捷支付接口或者代付接口来实现的。
2. 网银支付用户在支付的时候,需要跳转到银行网银页面来完成支付。
在网银页面,需要输入用户的卡号和身份信息。
这种支付方式会中断用户当前的体验,一般仅用于PC Web上的支付。
网银支付是封装银行提供的网银支付来实现。
3. 协议支付协议支付也称代收或者代扣,代收指渠道授权商户可以从用户的银行账户中扣款,一般用于定期扣款,不用于日常消费。
资金处理平台
财务会计
支付清算
核算中心
交易
柔性事务
支付宝的开源分布式消息中间件–Metamorphosis(MetaQ)
Metamorphosis (MetaQ) 是一个高性能、高可用、可扩展的分布式消息中间件,类似于LinkedIn 的Kafka,具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性,适用于大吞吐量、顺序消息、广播和日志数据传输等场景,在淘宝和支付宝有着广泛的应用,现已开源。
Metamorphosis是淘宝开源的一个Java消息中间件。
关于消息中间件,你应该听说过JMS规范,以
及一些开源实现,如ActiveMQ和HornetQ等。
Metamorphosis也是其中之一。
Metamorphosis 的起源是我从对linkedin的开源MQ–现在转移到apache的kafka的学习开始的,这是一个设计很独特的MQ系统,它采用pull机制,而不是一般MQ的push模型,它大量利用
了zookeeper做服务发现和offset存储,它的设计理念我非常欣赏并赞同,强烈建议你阅读一下它的设计文档,总体上说metamorphosis的设计跟它是完全一致的。
但是为什么还需要meta呢?
简单概括下我重新写出meta的原因:
1.Kafka是scala写,我对scala不熟悉,并且kafka整个社区的发展太缓慢了。
2.有一些功能是kakfa没有实现,但是我们却需要:事务、多种offset存储、高可用方案(HA)等
3.Meta相对于kafka特有的一些功能:
文本协议设计,非常透明,支持类似memcached stats的协议来监控broker
纯Java实现,从通讯到存储,从client到server都是重新实现。
提供事务支持,包括本地事务和XA分布式事务
支持HA复制,包括异步复制和同步复制,保证消息的可靠性
支持异步发送消息
消费消息失败,支持本地恢复
多种offset存储支持,数据库、磁盘、zookeeper,可自定义实现支持group commit,提升数据可靠性和吞吐量。
支持消息广播模式
一系列配套项目:python客户端、twitter storm的spout、tail4j等。
因此meta相比于kafka的提升是巨大的。
meta在淘宝和支付宝都得到了广泛应用,现在每天支付宝每天经由meta路由的消息达到120亿,淘宝也有每天也有上亿的消息量。
Meta适合的应用
日志传输,高吞吐量的日志传输本来就是kafka的强项;
消息广播功能,如广播缓存配置失效;
数据的顺序同步功能,如mysql binlog复制;
分布式环境下(broker,producer,consumer都为集群)的消息路由,对顺序和可靠性有极高要求的场景;
作为一般MQ来使用的其他功能。
作者:雪姬
来源:移动支付网(微信公众号:mpaypass)
人人都是产品经理()中国最大最活跃的产品经理学习、交流、分享平台。