首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >ZERO TO ONE,宜信支付系统架构总体剖析

ZERO TO ONE,宜信支付系统架构总体剖析

作者头像
宜信技术学院
修改2019-06-28 11:18:38
4810
修改2019-06-28 11:18:38
举报
文章被收录于专栏:宜信技术实践宜信技术实践

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

一、系统目标

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

  • 可伸缩

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

  • 可测试

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

  • 可监控

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

  • 可报警

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

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

  • 可配置

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

  • 安全性

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

  • 高可用

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

  • 高性能

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

二、业务痛点

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

  • 业务量的突然增长

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

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

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

  • 如何应对滚雪球效应

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

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

  • 系统存在的单点故障

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

宜信支付系统目前所有的节点包括中间件都是双备。

  • 如何避免操作风险

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

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

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

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

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

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

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

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

  • 外挂系统

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

  • 支付安全问题

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

  • 促销活动

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

  • 业务创新

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

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

作者:冯忠旗

来源:宜信技术学院

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、系统目标
  • 二、业务痛点
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档