公司新闻

首页 > 公司新闻 > 正文

从0到1实现一套聚合支付系统

2018年09月11日 热度:648 ℃

内容来源:本文来自中生代技术走进盒子支付线下活动分享,转载请联系作者及中生代技术。

大家好,我是来自盒子科技研发部支付线刘恒,目前主要是负责公司的一个聚合支付系统的研发工作。今天主要是讲一下我们聚合支付系统从2016年年初到现在技术演变。

首先我会从那三个方向,第一是聚合支付的介绍,聚合支付在我们公司它承担一个什么样的地位,第二是在我们公司有什么样的使用场景。第三是从公司开始做聚合支付最开始的版本是什么样子的,在这个版本之上,我们做了什么样的优化,然后到了现在发展成什么样的架构。

01

聚合支付的介绍

_____

它主要是针对一个微小商户进行一个收款工具,让商家他那边会有一个好哒商户通,第一个可以实时的收听语音报告,当前用户付款多少钱,第二个就是他可以去实时查看账单,了解当天的营业额。

还有一个产品就是我们公司的一个pos机。这个主要是一款生态pos,它里面不仅继承了我们一个我们这个具备支付系统提供的服务,就比如微信支付宝,它们还集成了一个刷卡的功能,就是磁条卡芯片卡,还有各种支付方式。

这次我们讲的聚合支付,只是涉及到交易流,不涉及到资金流,资金流是其他项目组负责。

02

1.0系统

_____

好,进入项目背景。

第一个就是工期短,基本上所有的项目都会遇到,天天都在赶工程。

我们是从2016年过年前一周,然后忽然被拉入一个群,说是有个项目要做一做,当时老大让一周上线,

第二是业务不熟。不知道聚合支付到底做什么事情,它的支付流程是什么样的?虽然说之前做过支付相关业务,但是每个公司支付业务是完全不一样的。当时做微信支付宝,微信APP ID是什么东西还不知道,所以说就在这种情况下开始着手,还有就是一个当时的交易量,当时的交易量是只有前端的一两个产品在使用,每天的交易笔数也很小,就几千笔。

第三个就是人员的缺乏,因为当时就做系统研发,只有我和另外一个新同事。

就在这种背景下,我们就搭建了第一套系统架构,即虚线圈住的,我负责交易前置,同事负责交易网关,当时就直接操作DB没有做任何的其他的优化。

当时就做这样一个简单的架构,第一个开发比较快,直接拿需求进行改代码,方便测试以及上线。当时是2016年3月份4月份就上线了,也很快。后来就是在经过了三四个月交易量比较猛增的情况下,就发现这个系统感觉各种瓶颈就出来了。

• 接口膨胀,特别涉及到某些相似的业务,就比如说那个消费、撤销、退款接口,就每个业务类型都有这几个接口,随着业务的发展,也不好维护,开发每次来个需求都要去考虑,到底是改哪个接口,要不要都改。

• 动态扩容。因为聚合支付很多交易都是异步的,用户下单时,我们会立即返回就下单成功,或者下单失败,但是这个交易有没有消费成功,我们需要设置定时的任务去查询最终付款结果。

定时调度,它需要定时、定点、定量的去拉取一批订单进行处理,如果拉取的数据太多,内存直接爆了,拉取太少,有很多交易得不到执行。在分布式环境如何充分提升并发的前提下充分使用机器的资源变得越来越紧迫。

• 配置分散,传统方式是将配置文件存放在每一个节点,每次升级都需要运维手动改。风险较高而且相当不好维护。

03

2.0系统

_____

在这个前提下,我们开始着手设计2.0。当初有几个大的方向:

• 稳定:支付系统的根基

• 支付体验:用户使用支付功能时感知零延迟

• 低耦合:模块之间减少依赖,需求变动风险控制在最小范围

在这个过程中也是试了很多种方案,要么程序复杂,你写完的话可能只有自己懂,后续不好维护;要么性能跟不上去。所以我们也尝试了各种方案,最后演变为如下系统架构。

首先将服务划分为三条线,上面绿色的,和中间那个红色的和最下面一条橙色的。绿色的就是我们把交易核心、交易网关独立出来。任务作业和那个查询网关独立部署。这两条业务线通过MQ进行解耦,然后我们再独立查询服务,对前端业务仅仅提供一个流水查询功能而已。

业务流程如下:

业务发起一笔消费,首先进入支付核心初始化流水、风控风险识别、渠道路由、渠道网关报文组装、上送、渠道应答。异步交易发送消息至MQ集群,任务作业监听消息,put缓存,定时任务拉取进行状态查询,业务方通过查询服务查看该笔交易支付状态

前置优化水平方向

• 接入层:将共性的接口统一。比如说下单,所有的业务,不管微信支付,还有其他的全部归为下单,具体的业务,通过一个serviceId参数进行识别

• 服务层:共性逻辑,也就是核心逻辑全部抽离出来,然后进行统一下沉,作为底层服务,上层业务全部通过serviceId配置化实现,这样的话尽量去少改动核心业务逻辑。

• 缓存层:随着交易量的增长,特别是在第一代的时候,里面很多业务查询都是直接操作DB了,对DB有很大的性能影响。所以我们就是在DB之上将所有消费交易信息全部缓存,后续所有的操作查询和更新全部操作缓存层主要为了提升了服务的性能。


前置优化垂直拆分:

• 核心交易:负责交易的核心链路,用户感知最明显。比如支付失败,用户立马能知道,立马就会投诉或者打电话给客服,该模块也包含退款等业务。

• 任务作业:将处理中的交易进行状态同步,和核心交易通过消息解耦

• 查询服务:仅仅是对公司内部提供一个交易状态的查询功能

任务作业内部查询策略设计为两个队列、一个批处理

• 内存队列:基于DelayQueue设计的延迟队列,通过制定算法策略,就是比如说延迟十秒、间隔五秒,或者是很多银行使用2的N次方进行查询。

该队列主要是针对单笔交易执行快速状态同步,提升用户体验。

• 缓存队列:基于我们公司Codis缓存集群,结合分布式调度框架Elastic-Job设计。主要是针对状态延迟的订单,进行批量状态同步

• DB批处理:也是结合Elastic-Job设计,主要是提供人工干预的入口,当渠道延迟比较长、或者渠道异常的情况下,执行批量状态同步

分片策略:

• 任务分片:目的在于把一个任务分散到不同的机器上运行,既可以解决单机计算能力上限的问题,也能降低部分任务失败对整体系统的影响。elastic-job并不直接提供数据处理的功能,框架只会将分片项分配各个运行中的作业服务器(其实是Job实例,部署在一台机器上的多个Job实例也能分片),

PS:开发者需要自行处理分片项与真实数据的对应关系。框架也预置了一些分片策略:平均分配算法策略,作业名哈希值奇偶数算法策略,轮转分片策略。同时也提供了自定义分片策略的接口。

• 数据分片:订单号取模存储(zset)

数据结构:

• 有序集合(zset):按照分片逻辑,将订单号取模,存放至对应的队列中

• string:交易明细序列化存储

设计思路:

1. MQ消费者(作业节点),接收到消息后,将数据存放在缓存

2. 作业节点根据分片项、score范围,定时从对应的缓存队列中获取指定数量的订单号

3. 业务循环处理,根据订单号再去缓存中获取对应的详细信息

4. 执行查询逻辑

注意事项:

zset元素数据过期,需要业务自己处理,可以单独建立检测机制,也可以每次执行业务时执行判断,过期则移除,不然集合会越来越大。

• 渠道隔离:在高并发访问下,系统所依赖的渠道稳定性对系统的影响非常大,依赖有很多不可控的因素,比如网络连接变慢,资源突然繁忙,暂时不可用,我们选在知名的容错开源框架Hystrix,隔离方案选择thread。

• 查询网关:在交易系统中,查询业务量一般时支付业务的6倍,甚至更高,这样对查询服务性能就会有更高的要求。减少对核心交易影响,提升稳定性。

通道商户缓存:通道信息(机构号、商户号、密钥等)属于静态信息,在初次使用时存放至分布式缓存系统中(设置有效期,防止僵尸数据),同时增加手动修改的入口,方便人工干预。

• 千里之堤毁于蚁穴:我们用容错的方式就是让这种蚁穴不要变大,在依赖的服务不可用时,服务调用方应该通过一些技术手段,向上提供有损服务,保证业务柔性可用。

• 线程池资源隔离:Java的Servlet容器,无论是Tomcat还是Jetty都是多线程模型,都用Worker线程来处理请求。当业务请求打满Worker线程的最大值之后,剩余请求会被放到等待队列(或者拒绝掉),如果等待队列也塞满之后,那这台Web Server就会拒绝服务。

如果你的服务是QPS较高的服务,那基本上这种场景下,你的服务也会跟着被拖垮。假如上游服务也没有设置合理的超时时间,故障就会扩散。这种故障逐级放大的过程,就是服务雪崩效应。

我们采用容错框架Hystrix来解决此问题。通过Hystrix命令模式,将每个类型的业务请求封装成对应的命令请求。每个命令请求对应一个线程池,创建好的线程池是被放入到ConcurrentHashMap中。

注意:尽管线程池提供了线程隔离,也必须要有超时设置,不能无限制的阻塞以致于线程池一直饱和。

Hystrix线程监控

实时展示当前各个业务线程池资源使用情况,研发人员可以以此为参考,确定资源是否够用、是否需要升级机器资源等。


2.0之后我们是全面对接我们公司监控平台,主要从以下几点进行监控:

• 节点耗时监控:如说哪个时间点、哪个节点耗时比较慢,通过百分比的形式,可以比较直观的看出问题。

• 成功率的监控:折线图定时刷新数据,将各个时间点的交易记录数、成功笔数、失败笔数进行汇总计算,渠道接口异常时可以第一时间发出告警

• 应答码监控:应答码TOP排行榜,方便研发分析数据,提前将问题通知给渠道,减少后续可能出现更大的问题;部分应答码重点监控,通过设定告警阀值,超过阀值短信及电话告警,研发第一时间接入处理,减少可能造成的损失。

• 邮件巡检报告:用于第二天研发进行数据分析。

以上就是盒子科技聚合支付系统演变的大致过程,在 2017年的到现在没有出现任何技术故障和业务故障,没有造成一笔长款、短款的出现,系统具备良好的伸缩性,能够保证公司近两年业务的快速发展。

04

下一步需要做什么

_____

那么在系统稳定的基础之上,下一步我们还需要做哪些事情呢?

• 全链路的监控:我们现在链路监控只是从前端到后端有一个请求的跟踪号,但是这个都分散在我们业务日志里面的。所以说我们下一步就准备做一个全链路的监控,就相当于把每一个每笔交易,它具体在哪个时间点在哪个机器上,然后在哪个渠道,然后它状态做的什么变更,做一个完整的记录,通过一个可视化的界面提供出来,方便客服、运营等其他协作部门使用。

• 智能路由:遇到渠道异常、临时停用渠道等等情况下,需要将用户切换至其他渠道,目前都是人工通过拉取数据手工操作的,所以下一步我们就想如何让我们的路由更加智能。

• 动态分片:主要包括数据分片、任务分片,业务量持续倍数增长的情况,各个环节的分片策略如何做到自动化实现,充分使用各个机器的性能。(本文完)

往期推荐:

技术琐话 

以分布式设计、架构、体系思想为基础,兼论研发相关的点点滴滴,不限于代码、质量体系和研发管理。

发表评论
◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

相关文章

【商标注册】准旗市场监督管理局商标注册指南

【商标注册】准旗市场监督管理局商标注册指南

★不忘初心砥砺前行★每日一学《党章》总纲:各项工作都要把_____,作为总的出发点和检验标准。(        )A.是否有利于发展社会主义社会的生产力B.是否有利于增强社会主义国家的综合国力C.是否...

北创营员|王朋:利楚扫呗,不依靠支付赚钱的“第四方”支付企业

REC武汉利楚扫呗,是国内首批从事第四方支付服务技术以及产品研发的科技企业,是全国自主研发移动端融合支付的先驱者。创始人王鹏,北创营全国五期班学员。创业这条路2009年,我在上大学3个月后辍学创业,今...

在境外使用移动支付是一种怎么样的体验?

在境外使用移动支付是一种怎么样的体验?

随着每年出境游的人数在激增,中国消费者的消费习惯也在悄然影响和改变着全球的商业格局。在中国早就已经普遍的移动支付,也伴随着中国游客的脚步走出国门,进入到越来越多的国家和市场。过去一年的时间,我去了印度...

医保卡可以移动支付啦!

医保卡可以移动支付啦!

你是否也曾想过不带钱包、社保卡就能在定点药店买药?这样好的事情 如今实现啦寇小妹从市人社局了解到8月27日起,参加城镇职工医保的参保职工或下载“雅安人社”APP,使用医保卡移动支付功能即可通过手机实现...

【手把手教你怎样通过微信或支付宝支付税款!】内蒙古税务实现微信和支付宝 双第三方支付

【手把手教你怎样通过微信或支付宝支付税款!】内蒙古税务实现微信和支付宝 双第三方支付

税月伴你行——专业的视角,及时的纳税指导,为您办税提供最有用的涉税信息。如果本文对您有所帮助,真心希望大家在文末顺便点赞,我们将为您提供更多更有价值的信息。第三方支付是指具备一定实力和信誉保障的独立机...

20180904-第三方支付算费的那点事

20180904-第三方支付算费的那点事

今天有幸和大家一起交流第三方支付算费的那点事,主要抛砖引玉,互相学习。下面就开始正式的分享。一、背景介绍在支付业务中,经常会碰到两件事情,一个是问商户的收费,一个是给渠道的成本。 这两个账算清楚了,那...