支付中台架构（支付中台 思维导图）

今天给各位分享支付中台架构的知识，其中也会对支付中台 思维导图进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、【支付系统设计从0到1】深度解析支付宝产品架构
• 2、云数智能零售未支付的订单怎么弄
• 3、通联支付的组织架构
• 4、高频交易支付架构并不复杂
• 5、"企业搭建中台架构,有什么好处?"
• 6、支付宝mPass架构

【支付系统设计从0到1】深度解析支付宝产品架构

支付宝作为最老牌的支付机构，其支付系统的架构和使用的技术是很值得我们在设计与实现支付系统时作为参考的，这篇文章为大家深度解析支付宝的产品架构。

支付宝的系统采用的是一个典型的从渠道到产品到服务到支付渠道的应用架构，其中服务根据业务的发展，一方面考虑平衡业务的增长与创新，另一方面考虑系统的安全、稳定、可伸缩。所以系统架构设计上需要构建稳定的基础业务服务，通过服务重用实现业务敏捷，同时保障核心安全稳定。

对于各类的支付场景，其典型处理模式如上图所示，互联网商户访问渠道系统，通过API平台接入，经过产品层，封装订单处理，然后调用收银台或者直接调用交易，交易过程中附加计费、营销、风控，然后到支付处理，支付处理再到清算处理和账户会计处理，最后通过渠道通信前置调用银行渠道完成支付交易落地。

支付交易的处理在上述流程下就很好理解了，首先，业务系统通过收银台或者支付API将交易发到支付系统，支付系统通过账务交易记录账务并给到会计系统，然后通过清算模块与银行渠道完成支付落地，最后将清算模块与会计记录进行核算。

账务和会计相关我之前专门有一篇文章分析，此处就不再赘述。

传送门： 【支付系统设计从0到1】支付宝架构中记账功能设计分析

在支付清算这页里我们看到，支付宝分了支付系统和清算系统作为联机交易，其实这就是我们之前讲的支付系统设计中的支付产品和支付渠道，然后通过记账指定给到账务系统里再做记账，联机记录交易流水，异步做复式记账。这其实也是我们在设计支付清算系统的时候的一个原则：为提高交易性能，交易必须与账务分离，以提高交易处理性能和效率，从而有针对性的分块解决复杂业务逻辑。所以，我们在支付系统设计中一般是将记账为分2个步骤，支付成功后系统同步记录流水账，异步通知会计系统做复式记账，如下图所示。

支付系统中实现四种的支付方式，充值，提现，内转，充退等。而清算系统完成跟渠道之间的渠道管理、任务调度、实时处理以及文件处理、还有接收异步清算处理。

支付宝架构中的交易系统就是我们之前支付系统架构设计中支付产品所实现的功能，包括各种支付方式的实现（担保交易、即时到账交易、货到付款交易等）。

另外，这里面还包括了：数据持久、流程引擎、规则引擎、超时处理、资金处理、产品账接入、收费接入、商户通知、统一事件等。

商户通知和统一事件通过消息系统异步交易时间处理。

云数智能零售未支付的订单怎么弄

点击未支付的订单，即可支付。

一套中台架构软件，实现电商、门店、分销一体化管理，会员精准营销，全渠道业务拓展，业财融合，全渠道订单、商品、结算、库存、会员管理，支持多语言多币种，敏捷二开。

企业的智能账务平台，能够为各类业务场景提供账户、支付渠道、订单管理、账单系统、资金托管、金融增值等服务。

通联支付的组织架构

目前公司下设受理市场事业部、金融服务事业部、新兴支付事业部、技术支持中心、计划财务部、综合管理部，并正在各地设立分支机构。管理团队

董事长：万建华

曾任招商银行总行常务副行长，中国银联筹备组组长，中国银联党委书记，总裁。

常务副总裁：单怀光

单怀光先生，清华大学工程力学数学系计算数学专业毕业，高级工程师，享受政府特殊津贴。

1970年5月至1977年3月在中科院计算所第九研究室任项目组负责人；1977年3月至1984年1月任香港中银集团电脑部系统开发部经理；1984年1月至1985年1月负责筹建中国银行南京分行（省分行）电脑部；1985年1月至2001年7月历任中国工商银行科技部副主任、副总经理、总工程师和总经理等职；2001年7月至2002年11月，任工商银行海外数据中心总经理；2001年12月至2007年3月，任中国银联首席技术顾问；2004年底至2008年8月，任银联数据服务公司总裁。

副总裁：郑毓华

郑毓华先生，硕士研究生毕业，高级会计师。

郑毓华先生1968年参加工作，1987年至1995年任职于深圳市石化集团公司，先后任财务部部长、总会计师；1995年至2001年任深圳市石化集团公司董事、副总经理，深圳市高级会计师职称评审委员会组长；郑毓华先生是银联商务公司主要创建人之一，2002年至2009年元月担任银联商务有限公司董事、常务副总裁。

副总裁：黄兴海

黄兴海先生，金融学博士，高级经济师。

黄兴海先生1989年8月起就职于中国人民银行总行国际司，获得高级经济师资格；1995年8月至1998年初就职于美国华盛顿国际货币基金组织(IMF)，担任中国董事顾问；1998年9月至2001年10月，担任国家开发银行国际金融局调研处主管；2001年10月至2008年5月，创建中国银联国际业务部，历任国际业务部总经理兼银联香港代表处首席代表、国际业务总部副总裁兼银联香港分公司总经理；2004年12月被聘为交通银行信用卡中心管理委员会独立委员；2008年5月2009年7月，担任上海国际信托投资有限公司总经理、副董事长。

副总裁：熊文森

熊文森先生，清华大学计算机系毕业。

熊文森先生在IT行业工作多年，曾就职于招商银行总行电脑部，先后担任部门经理、助理总经理、副总经理职务；1999年至2004年担任深圳奥尊信息技术公司总裁；2003年被评为华南10大IT人物；2004年4月至2006年9月，从事支付行业的自主创业；2007年9月到2008年8月，担任银商资讯公司常务副总经理，2008年9月至2009年，担任开联信息技术公司总裁。

助理总裁：黄远昌

黄远昌先生，硕士研究生毕业。

黄远昌先生长期在中国人民银行南京分行工作，历任科技处处长、计划资金处处长，货币信贷管理处处长；2000年7月至2002年10月，担任江苏银行卡网络服务中心总经理；2002年10月至2003年8月，担任中国银联南京分公司总经理；2003年8月至2008年4月，担任银联商务有限公司副总裁。

高频交易支付架构并不复杂

支付系统是整个交易系统中相当核心的一部分功能，以我们的交易中台为例，通过领域方式的拆分，支付架构隶属于订单团队，在整个用户下单之后进行支付，支付之后成单进入交易履约流程。

支付系统由于本身和金融相关，不像其他高频系统面对海量请求可以大量使用缓存，异步mq等方式解决三高问题。支付系统对数据一致性要求更高，所以对于其架构设计原则还是有自己特点的。

构建一个支撑每秒十万只读系统并不复杂，无非是通过一致性哈希扩展缓存节点，水平扩展web服务器等。每秒钟数十万数据更新操作，在任何数据库上都是不可能的任务，首先需要对订单表进行分库分表。

在进行数据库操作时，一般会用ID（UID）字段，所以选择以UID进行分库分表。

分库策略我们选择了“二叉树分库”，所谓“二叉树分库”指：在进行数据库扩容时，以2倍数进行扩容。比如：1台扩容2台，2台扩容4台，以此类推。最后把Order库分了8个库中，每个库10个表。

根据uid计算数据库编号：

分库信息 = (uid / 10) % 8 + 1

根据uid计算表编号：

表编号 = uid %10

订单系统的ID必须具有全局唯一的特征，简单的方式是利用数据库的序列，每操作一次就能获得一个全局唯一的自增ID，如果支持每秒10w订单，那每秒至少需要生成10w订单ID，通过数据库自增ID显然无法完成上述请求。所以通过内存计算获取全局唯一的订单ID。

JAVA领域著名的唯一ID应该是UUID了，不过UUID太长且包含字母，不适合做订单ID。

通过反复比较筛选，借鉴Twitter的算法实现全局唯一ID。

三部分组成：

最终订单结构：

分库分表信息 + 时间戳 + 机器号 + 自增序号

还是按照第一部分根据uid计算数据库编号和表编号的算法，当uid＝9527时，分库信息＝1，分表信息＝7，将他们进行组合，两位的分库分表信息即为”17”。

我们通过对order表uid维度的分库分表，实现了order表的超高并发写入与更新，通过uid和订单ID查询订单信息。

上面方案虽然简单，但是保持两个order表机器的数据一致是很麻烦的事情。

两个表集群显然是在不同的数据库集群中，如果写入与更新中引入强一致性的分布式事务，这无疑会大大降低系统效率，增长服务响应时间，这是我们所不能接受的，所以引入了消息队列进行异步数据同步，为了实现数据的最终一致性。

当然消息队列的各种异常会造成数据不一致，所以我们又引入了实时服务监控，实时计算两个集群的数据差异，并进行一致性同步。

所谓数据库高可用指的是：

当数据库由于各种原因出现问题时，能实时或快速的恢复数据库并修补数据。

从整体集群角度看，就像没有出任何问题一样，需要注意的是，这里的恢复数据库服务并不一定是指修复原有数据库，也包括将服务切换到另外备用的数据库。

数据库高可用的主要工作是数据恢复月数据修补，一般我们完成这两项工作的时间长短，作为衡量高可用好坏的标准。

我们认为，数据库运维应该和项目组分开，当数据库出现问题时，应由DBA实现统一恢复，不需要项目组操作服务，这样便于做到自动化，缩短服务恢复时间。

如上图所示，web服务器将不再直接连接从库DB2和DB3，而是连接LVS负载均衡，由LVS连接从库。

这样做的好处是LVS能自动感知从库是否可用，从库DB2宕机后，LVS将不会把读数据请求再发向DB2。

同时DBA需要增减从库节点时，只需独立操作LVS即可，不再需要项目组更新配置文件，重启服务器来配合。

再来看主库高可用结构图：

如上图所示，web服务器将不再直接连接主库DB1，而是连接KeepAlive虚拟出的一个虚拟ip，再将此虚拟ip映射到主库DB1上，同时添加DB_bak从库，实时同步DB1中的数据。

正常情况下web还是在DB1中读写数据，当DB1宕机后，脚本会自动将DB_bak设置成主库，并将虚拟ip映射到DB_bak上，web服务将使用 健康 的DB_bak作为主库进行读写访问。

这样只需几秒的时间，就能完成主数据库服务恢复。

组合上面的结构，得到主从高可用结构图：

数据库高可用还包含数据修补，由于我们在操作核心数据时，都是先记录日志再执行更新，加上实现了近乎实时的快速恢复数据库服务，所以修补的数据量都不大，一个简单的恢复脚本就能快速完成数据修复。

支付系统除了最核心的支付订单表与支付流水表外，还有一些配置信息表和一些用户相关信息表。如果所有的读操作都在数据库上完成，系统性能将大打折扣，所以我们引入了数据分级机制。

我们简单的将支付系统的数据划分成了3级：

使用本地内存缓存有一个数据同步问题，因为配置信息缓存在内存中，而本地内存无法感知到配置信息在数据库的修改，这样会造成数据库中数据和本地内存中数据不一致的问题。

为了解决此问题，我们开发了一个高可用的消息推送平台，当配置信息被修改时，我们可以使用推送平台，给支付系统所有的服务器推送配置文件更新消息，服务器收到消息会自动更新配置信息，并给出成功反馈。

举个简单的例子，我们目前订单的处理能力是平均10万下单每秒，峰值14万下单每秒，如果同一秒钟有100万个下单请求进入支付系统，毫无疑问我们的整个支付系统就会崩溃，后续源源不断的请求会让我们的服务集群根本启动不起来，唯一的办法只能是切断所有流量，重启整个集群，再慢慢导入流量。

我们在对外的web服务器上加一层“粗细管道”，就能很好的解决上面的问题。

请看上面的结构图，http请求在进入web集群前，会先经过一层粗细管道。入口端是粗口，我们设置最大能支持100万请求每秒，多余的请求会被直接抛弃掉。出口端是细口，我们设置给web集群10万请求每秒。

剩余的90万请求会在粗细管道中排队，等待web集群处理完老的请求后，才会有新的请求从管道中出来，给web集群处理。

这样web集群处理的请求数每秒永远不会超过10万，在这个负载下，集群中的各个服务都会高校运转，整个集群也不会因为暴增的请求而停止服务。

如何实现粗细管道？nginx商业版中已经有了支持，相关资料请搜索

nginx max_conns，需要注意的是max_conns是活跃连接数，具体设置除了需要确定最大TPS外，还需确定平均响应时间。

"企业搭建中台架构,有什么好处?"

企业搭建中台架构可以带来多方面的好处，例如：

1. 提高业务响应速度和创新能力：中台架构可以让企业更快速地响应市场变化，提高业务部门的创新能力。

2. 降低成本：中台架构可以通过共享基础设施、数据和技术能力等，降低企业的 IT 成本，并提高 IT 资源的利用效率。

3. 提高质量和可靠性：中台架构可以通过统一管理、共享数据和服务，避免重复造轮子，并保证数据的一致性和可靠性，提高业务的质量和可靠性。

4. 提高可扩展性和可维护性：中台架构可以将业务流程和业务逻辑进行模块化和重用，方便拓展和维护，并降低项目的风险。

5. 促进业务协同和协作：中台架构可以改善不同业务部门之间的信息孤岛问题，促进业务协同和协作，实现各个业务部门之间的互相配合。

6. 加强数据安全和合规性：中台架构可以通过安全管理平台，加强数据的保护和管理，加强数据合规性。

总之，中台架构能够帮助企业快速响应市场需求，降低 IT 成本，提高业务质量、可靠性和灵活性，实现跨部门合作和信息共享。对于长期发展的企业来说，中台架构是非常必要的战略举措。

支付宝mPass架构

客户端(支付宝) [框架Android、iOS、h5、小程序]、[UI库]、[组件]

移动中台(研发、测试、发布、分析)

后台连接(网关、数据同步、多媒体智能)

支付中台架构的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于支付中台 思维导图、支付中台架构的信息别忘了在本站进行查找喔。