ZERO TO ONE 【「付钱拉」】支付系统架构系列之:总体剖析

冯忠旗 2018-09-11 浏览量:1399

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

1467598037900015883.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等等的创新来满足各种各样的业务需求。在这个过程中还要处理各种特殊的接入的第三方。

2.png

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

发现文章有错误、对内容有疑问,都可以通过关注宜信技术学院微信公众号(CE_TECH),在后台留言给我们。我们每周会挑选出一位热心小伙伴,送上一份精美的小礼品。快来扫码关注我们吧!
分享硬核IT 专注金融