AICon上海|与字节、阿里、腾讯等企业共同探索Agent 时代的落地应用 了解详情
写点什么

“ 付钱拉 ” 支付系统架构

  • 2020-02-13
  • 本文字数:3254 字

    阅读完需:约 11 分钟

“ 付钱拉 ” 支付系统架构

本文以「付钱拉」后台支付系统为背景,是「付钱拉」支付系统架构系列的第一篇文章,旨在剖析其总体架构实践。本文主要抛砖引玉,简要分析「付钱拉」的架构设计理念,具体的技术实现和最佳实践后续会在其他系列文章详细介绍。


1536655986305062172.png


「付钱拉」支付系统每天平均处理订单量 100w-200w 笔,账单交易日交易量在 300 万笔以上、每个月处理支付交易流水在 300 亿左右、对接银行和三方有 30 多家以及接入商户几千个。从刚开始系统仅仅处于能用阶段,日交易量几千笔到现在,系统架构根据业务的不断发展迭代多个阶段。主要从以下几个方面来分享:


一、系统目标


「付钱拉」支付系统需要满足持续不断的业务增长,系统设计的时候有以下目标。


  • 可伸缩


随着业务量的增长,单个节点不足以满足性能问题,就要各个系统模块支持横向扩展和分部署部署。


  • 可测试


测试是代码质量的最后一道防线,「付钱拉」系统支持分布式部署,但是目前的框架给测试也带来许多困难,比如开发人员在本地测试的时候,不同的开发人员相互争抢 MQ 消息。


  • 可监控


作为支付系统,和钱打交道,不允许任何出错,实时性要求非常高。如果瞬间发送一个问题,可能影响的交易金额就不可估计了。所以如何及时发现问题,监控系统就是「付钱拉」的眼睛。


  • 可报警


满足了监控,报警就必不可少。但是往往监控项目和场景会非常多,如何选择哪些项目为出警项,哪些为关注项就非常重要。如果全部为出警项,对于报警接受人员,可能造成狼来了的效应,当出现真正需要报警的时候,重视度就会降低。


其次是报警方式,无非是推送和拉取模式,通过监控页面,监控室,短信,邮件等。


  • 可配置


在支付系统有很多的参数,并且随时可以发生变化,如果每次变化都需要重启系统,肯定是不可以的。比如响应码状态的配置,银行维护配置,交易处理时间段等等,可配置就可以解决此类问题,保证客户端无感知。


  • 安全性


安全性能对至于任何系统都是命脉,对于支付系统更加像心脏一样。安全性主要有两个方面,一个是用户数据安全,一个系统支付安全。用户数据安全要求展示层面、存储层面、内部交互层面和外部通信层面都必须是安全的;支付安全,包括人为操作导致的支付损失和系统 bug 导致的支付损失。


  • 高可用


高可用要求系统能够一直提供稳定的服务,满足 SLA 的要求。「付钱拉」为了提供高可用服务,所有的系统组件拒绝单点部署,从业务模块,数据库,消息中间,定时服务和 Nginx 等都做了集群功能。


  • 高性能


高性能要求提供快速的响应时间,「付钱拉」有大量的互联网类型的支付交易,对交易的实时响应时间要求非常高,不可以让用户端感觉支付非常慢。「付钱拉」对整个支付环节的做法是拆分,通过分步和异步提高并发能力。


二、业务痛点


以下就「付钱拉」系统随着业务的演变,不同阶段遇到的业务痛点,从而架构层面都做了哪些改变。


  • 业务量的突然增长


「付钱拉」系统刚上线的时候每天交易量最多也就 1Q 笔左右,不到两个月的时间系统每天的交易量从 1w 要增加到 200W 笔,这时候系统初始的架构不能够满足系统的业务增长量。


做的第一件事,分布式部署。系统业务模块做拆分,一个大的块功能模块拆分成好几个模块来实现,并且每个模块都是无状态的,这样才可以支持横向扩展。


做的第二件事,解决数据库大表问题。「付钱拉」系统有两张大表,一个是支付记录表,另外一个是支付日志轨迹表。系统刚开始支付记录只有一张表来存储,一个月的数据量这张表就已经 6000W 了,如果一个开发人员因为疏忽 sql 忘记按照索引查询,对数据库来说可能就像蝴蝶效应一样。为了快速解决问题,「付钱拉」做了一些改变,读写数据分离、冷数据清除和部分功能借助缓存来减少数据库压力。这些都是能够快速去解决问题的,长期方案「付钱拉」采用分库分表的方式。


  • 如何应对滚雪球效应


「付钱拉」系统最初消息队列是按照不同的支付类型来拆分的,但是随着后端三方和银行的不断接入,不同的三方网络和处理能力都不一样。导致同样的支付类型下面,一个三方宕机从而堵塞其他三方的交易,产生滚雪球效应,雪球越滚越大,最后直至拖垮所有交易。


针对这种情况,「付钱拉」做的改变是隔离,按照商户、三方、和支付类型做彻底隔离,确保不同的业务和商户各行其道,相互不受影响。这个改变就好比,原来是单行道,现在变成了多行道,就像高速公路一样。


  • 系统存在的单点故障


任何的单点都是存在风险的,不要相信任何软件或者功能是多么的无坚不摧。举一个例子,「付钱拉」系统之前使用消息中间件是单节点,并且运行一直非常稳定,从来没有出现过故障。但是有一天,它所在的物理机器网卡掉了,瞬间它不能提供服务。所以从这个案例讲,单点故障也许不是你本身的故障,但是如果单点就可能发生风险,


「付钱拉」目前所有的节点包括中间件都是双备。


  • 如何避免操作风险


操作风险可以认为是人为风险。作为互联网系统,如果因为操作风险导致一个小 bug,可能充其量就是影响用户体验,立即修复即可。但是对于支付系统,每笔交易都是真金白银,不可以有任何一个小小的操作风险。


「付钱拉」经验总结操作风险主要有以下几种:上线操作风险、代码未审核风险、生产环境变更风险、订单修改风险、测试风险。如何避免这些操作风险,其他系列会详细展开讨论。


  • 系统是否具备自我保护能力


系统具备自我保护能力,就是容错,快速失败,降级和限制使用。系统具备自我保护能力,就是当因为各种原因发生不可预期的问题的时候,它能够自己解决问题。


容错,比如发生一笔交易,发生了网络异常,如果明确知道这笔交易没有发往三方,那么就可以尝试在发送一次来提高成功率;「付钱拉」有一个自动重路由功能,第一次路由到的通道如果交易失败,符合一定条件,会自动重路由去尝试别的通道,这就是很好的容错;还有一种容错场景,一般系统如果发生 OOM 异常一定会死掉。如果能够在设计系统的时候,预留一部分内存,然后当发生 OOM 的时候,去 catch 住处理掉,这样一个小小的容错就能够避免系统一次 OOM.


快速失败原则,如果系统启动的时候,明确知道缺少哪些东西,就算启动了服务也不可用,那这时候启动的时候就让启动直接失败;还有针对实时类交易,如果超过响应时间,就快速失败响应用户,而不是无休止等待。


服务降级是在系统达到一定访问量的时候,如果不能满足服务要求,必须要做的事情。「付钱拉」在针对商户活动日的时候,就做了服务降级。


限制,如果系统资源无限制使用,没有管控,一定会在某个时间点发生事故,比如数据库和内存等。「付钱拉」主要做了以下限制:限制各个模块的连接数的个数,因为横向扩展一定会引发这个问题;限制内存的使用,内存过大会导致频繁的 GC 和 OOM; 限制 woker 线程的个数;限制三方的并发数量。


  • 外挂系统


外挂系统主要是用来支撑核心系统,但是它的引入又不可以影响核心系统。「付钱拉」有两个外挂系统个,一个是日志轨迹系统,一个是实时预警系统。具体的实现会在其他系列讨论。


  • 支付安全问题


「付钱拉」的支付安全主要来自外在安全和内在安全两个方面。外在安全包括用户敏感数据展示、存储、内部交互、外部通信和人为操作;内在安全主要指系统并发导致的资金支付风险。


  • 促销活动


在业务线做促销的时候,交易量剧增,但是受限于指定的支付通道和并发处理能力,如果交易量超过了处理能力,为了满足其他商户不受影响,「付钱拉」针对不同的商户做了服务降级处理。


  • 业务创新


现实业务场景往往比理想的业务场景复杂的多,「付钱拉」在不同的支付类型上做了多种业务创新和封装。比如超级快捷,Token 支付,快捷服务化,鉴权服务化,动态重路由,代扣 Plus 等等的创新来满足各种各样的业务需求。在这个过程中还要处理各种特殊的接入的第三方。


1536656005256006056.png


系统架构和业务的演进是不间断的,没有终点,没有银弹。只要矢志不移的去改变,是适应才可以满足业务需求,「付钱拉」的架构和业务改进也将是持续不断的,比如动态路由,比如服务治理等等。虽然目前市面各家系统架构实际众多,但是也都各自有特性。本文以「付钱拉」系统实践来简要剖析支付系统的架构特点,后续会在其他系列对本文中提到的点进行详细讨论。


本文转载自宜信技术学院网站。


原文链接:http://college.creditease.cn/detail/171


2020-02-13 21:481410

评论

发布
暂无评论
发现更多内容

【记】滑动拼图验证码在搜索中的作用

宙哈哈

Python html 验证码

拿到大厂前端offer的前端开发是怎么回答面试题的

hellocoder2029

JavaScript 前端

NCCL源码解析①:初始化及ncclUniqueId的产生

OneFlow

人工智能 深度学习

深圳高新技术企业申请条件以及流程简单说明

行云管家

高新企业 高新技术 高新

协同存储,为边缘计算创造更大价值

阿里云CloudImagine

云计算 边缘计算

GPT-4问世;LLM训练指南;纯浏览器跑Stable Diffusion

OneFlow

人工智能 深度学习

21天吃透这套字节面试题后,我成功跳槽进了字节,税后25K

做梦都在改BUG

Java 数据结构 面试 算法

2023秋招前端面试必会的面试题

Geek_02d948

JavaScript 前端

彻底搞懂nodejs事件循环

coder2028

JavaScript 前端

前端常考面试题整理

hellocoder2029

JavaScript 前端

如何评估某活动带来的大盘增量 | 得物技术

得物技术

AI 数据

深入nodejs的event-loop

coder2028

JavaScript 前端

Nautilus Chain 现已推出测试网“Triton ”,有哪些潜在的机会?

西柚子

ArkUI中的线程和看门狗机制

OpenHarmony开发者

OpenHarmony

一文读懂Js中的this指向

hellocoder2029

JavaScript 前端

一文彻底搞懂前端缓存机制

hellocoder2029

JavaScript 前端

前端常考vue面试题(必备)

yyds2026

Vue 前端

《三体》问题

蓬蒿

CPU 寄存器 延时

【小程序案例】支付宝小程序-MQTT模器,IoT设备通过WSS接入阿里云IoT物联网平台——设备接入类

阿里云AIoT

JavaScript windows 物联网

3.15 数据库吐槽大会

NineData

数据库 mongodb 云计算 程序员 图数据库

SpringBoot中事件与通知

石臻臻的杂货铺

spring springboot

前端经典面试题(有答案)

coder2028

JavaScript 前端

基于rsync实现海量文件高速传输的解决方案

镭速

你需要知道的webpack高频面试题

Geek_02d948

JavaScript 前端

一文彻底读懂webpack常用配置

Geek_02d948

JavaScript 前端

通过微信小程序体验阿里云IoT物联网平台——设备接入类

阿里云AIoT

物联网

认识一下,我们是应用社交「幕后大佬」 IM 家族

融云 RongCloud

即时通讯 IM

行云管家堡垒机客服电话是多少?谁知道?

行云管家

网络安全 数据安全 堡垒机 行云管家

美团前端高频面试题集锦

Geek_02d948

JavaScript 前端

2023秋招前端面试必会的面试题

coder2028

JavaScript 前端

LeetCode题解:137. 只出现一次的数字 II,哈希表,JavaScript,详细注释

Lee Chen

JavaScript LeetCode

“ 付钱拉 ” 支付系统架构_行业深度_冯忠旗_InfoQ精选文章