本发明涉及数据处理领域,特别涉及一种与银行进行交互重试的方法和系统。
背景技术:
现代的互联网金融应用为了实现自身需求,其系统内部需要和大量的银行接口进行交互调用,比如充值、提现、还款等。在交互过程中,存在各种跨机房、跨网段、跨运营商的场景,由于距离较远、网络稳定性不确定等因素,会经常性发生交互失败。交互失败后,一般会采用重试等机制来解决交互失败的问题。传统同类方法因其设计思路、理念的不同,主要有以下缺点:
1.无法快速开发,无法方便的应用于各种各样需要重试的业务。传统方案只能根据某一具体业务实行重试,比如充值、提现、投资等,没有抽象出一套灵活的、可扩展的,方便快速适用的解决方法。需要为每一种业务定义重试记录表、编写定时调度代码,开发过程繁琐,存在大量逻辑相似或重复的代码。
2.重试的触发时间无法灵活配置。传统方案只能根据事先配置好的策略进行简单的定时重试,比如每x秒,重试一次。无法指定重试停止条件,无法根据不同业务信息参数,指定重试触发时间、最大重试次数等。
3.重试过程、结果无法追踪。传统方法仅仅是单纯反复调用,行为比较单一,比如定时查询,调用某一银行接口,没有记录调用结果过程上下文等,无法跟踪、定位、调试重试过程中遇到的异常问题。
4.手工操作。传统方法往往会提供一个后台管理界面,由管理员或客服人员在后台执行重试逻辑。比如充值场景,当用户充值,调用银行接口时发生网络异常,需要商户登录后台管理界面,自行针对该笔业务进行查询、重试,最终达到业务成功或失败结果。此种方案在当今的互联网信息技术中,显得十分笨拙,当交互异常大量发生时,需要消耗大量的人力、时间去进行手工操作。
技术实现要素:
针对现有技术中的缺陷,本发明提出了一种与银行进行交互重试的方法和系统,提供了一种更加完善,方便的与银行接口交互的重试方法。
具体的,本发明提出了以下具体的实施例:
本发明实施例1公开了一种与银行进行交互重试的方法,应用于包括客户端以及服务端的系统中,该方法包括:
当在触发调用银行接口的操作时,客户端判断所述调用的返回结果是否满足预设的重试条件;
若判断结果为是,判断待进行的重试是同步模式还是异步模式;
若为同步模式,则以预设时间段为周期进行预设次数的重试,并将重试的结果输入状态机,以及执行与状态机所反馈的结果对应的处理流程;
若为异步模式,则向服务端发送异步重试消息,并将调用银行接口的结果返回给调用方。
在一个具体的实施例中,当重试为同步模式时,所述重试为同步阻塞式重新调用银行接口。
本发明实施例还提出了一种与银行进行交互重试的方法,应用于包括客户端以及服务端的系统中,该方法包括:
服务端接收客户端发送的异步重试消息;
根据所述异步重试消息获取重试任务配置信息;
基于所述重试任务配置信息确定下次重试的执行时间,并创建重试任务;
初始化所创建的重试任务;
将所述重试任务持久化到存储设备上。
在一个具体的实施例中,还包括:
定时获取所述存储设备上的重试任务;
执行所获取的重试任务。
在一个具体的实施例中,还包括:
获取所述执行的执行结果;
将所述执行结果发送给状态机;
接收所述状态机所反馈的输出结果;
执行与所述输出结果对应的处理流程。
本发明实施例还提出了一种客户端,应用于包括客户端以及服务端的系统中,该客户端包括:
第一判断模块,用于当在触发调用银行接口的操作时,判断所述调用的返回结果是否满足预设的重试条件;
第二判断模块,用于当所述第一判断模块的判断结果为是时,判断待进行的重试是同步模式还是异步模式;
执行模块,用于当重试为同步模式时,则以预设时间段为周期进行预设次数的重试,并将重试的结果输入状态机,以及执行与状态机所反馈的结果对应的处理流程;
发送模块,用于当重试为异步模式时,向服务端发送异步重试消息,并将调用银行接口的结果返回给调用方。
在一个具体的实施例中,当重试为同步模式时,所述重试为同步阻塞式重新调用银行接口。
本发明实施例还提出了一种服务端,应用于包括客户端以及服务端的系统中,该服务端包括:
接收模块,用于接收客户端发送的异步重试消息;
获取模块,用于根据所述异步重试消息获取重试任务配置信息;
创建模块,用于基于所述重试任务配置信息确定下次重试的执行时间,并创建重试任务;
初始化模块,用于初始化所创建的重试任务;
存储模块,用于将所述重试任务持久化到存储设备上。
在一个具体的实施例中,还包括:
第一执行模块,用于定时获取所述存储设备上的重试任务;
执行所获取的重试任务。
在一个具体的实施例中,还包括:
第二执行模块,用于获取所述执行的执行结果;
将所述执行结果发送给状态机;
接收所述状态机所反馈的输出结果;
执行与所述输出结果对应的处理流程。
以此,本发明实施例提出了一种与银行进行交互重试的方法和系统其,应用于包括客户端以及服务端的系统中,该方法包括:当在触发调用银行接口的操作时,判断所述调用的返回结果是否满足预设的重试条件;若判断结果为是,判断待进行的重试是同步模式还是异步模式;若为同步模式,则以预设时间段为周期进行预设次数的重试,并将重试的结果输入状态机,以及执行与状态机所反馈的结果对应的处理流程;若为异步模式,向服务端发送异步重试消息,并将调用银行接口的结果返回给调用方。提供了一种更加完善,方便的与银行接口交互的重试方法。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本发明的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1是本发明客户端使用方流程示意图;
图2是本发明异步重试消息接受方流程示意图;
图3是本发明异步重试调度方流程示意图;
图4是本发明客户端功(业务系统)能模块示意图;
图5是本发明服务器端功能模块示意图;
图6是本发明客户端(业务系统)、银行、服务器端流程关系示意图;
图7是本发明重试任务持久化一种实现的软件设计模式示意图;
图8是本发明实施例提出的一种客户端的结构示意图;
图9是本发明实施例提出的一种服务端的结构示意图。
具体实施方式
在下文中,将更全面地描述本公开的各种实施例。本公开可具有各种实施例,并且可在其中做出调整和改变。然而,应理解:不存在将本公开的各种实施例限于在此公开的特定实施例的意图,而是应将本公开理解为涵盖落入本公开的各种实施例的精神和范围内的所有调整、等同物和/或可选方案。
实施例1
本发明实施例1公开了一种与银行进行交互重试的方法,应用于包括客户端以及服务端的系统中,如图1所示,该方法包括:
步骤101、当在触发调用银行接口的操作时,所述客户端判断所述调用的返回结果是否满足预设的重试条件;
步骤102、若判断结果为是,判断待进行的重试是同步模式还是异步模式;
步骤103、若为同步模式,则以预设时间段为周期进行预设次数的重试,并将重试的结果输入状态机,以及执行与状态机所反馈的结果对应的处理流程;
步骤104、若为异步模式,则向服务端发送异步重试消息,并将调用银行接口的结果返回给调用方。
具体地,在异步模式下,会立即返回结果给触发此次的调用方,然后在另一台服务器端执行重试逻辑。
具体的,在一个实施例中,如图1所示,可以包括以下具体的步骤:
1、用户操作或某种业务操作触发调用银行接口;
2、根据调用返回结果,判断是否满足重试条件,比如:如果出现网络异常就进行重试;
3、如果不满足重试条件,则将调用结果返回给调用方;
4、如果满足重试条件,则进一步判断是否是同步模式或异步模式;
5、如果是同步模式,则按照设定以某个时间间隔,进行最大n次重试;
6、将步骤5中结果输入状态机,根据状态机输出,执行不同处理的逻辑,包括但不限于:直接将调用银行接口结果返回给调用方、转为继续异步处理;
7、步骤4中判断如果是异步模式,则发送异步重试消息,并将调用银行接口的结果返回给调用方。
其中,在一个具体的实施例中,当重试为同步模式时,所述重试为同步阻塞式重新调用银行接口。
实施例2
为了对本发明进行进一步的说明,本发明实施例2还公开了一种与银行进行交互重试的方法,应用于包括客户端以及服务端的系统中,该方法包括:
所述服务端接收客户端发送的异步重试消息;
根据所述异步重试消息获取重试任务配置信息;
基于所述重试任务配置信息确定下次重试的执行时间,并创建重试任务;
初始化所创建的重试任务;
将所述重试任务持久化到存储设备上。
在一个具体的实施例中,该方法还包括:
定时获取所述存储设备上的重试任务;
执行所获取的重试任务。
在一个具体的实施例中,该方法还包括:
获取所述执行的执行结果;
将所述执行结果发送给状态机;
接收所述状态机所反馈的输出结果;
执行与所述输出结果对应的处理流程。
具体的,为了实现上述目的,综合实施例1以及实施例2,本发明提供一种模块设计方法包含以下几个关键模块:
1.客户端;其中,客户端包括:
同步重试逻辑模块:用于同步阻塞式执行重试调用;
异步重试逻辑模块:用于发送异步重试消息。
2.服务端;其中,服务端包括:
异步重试消息接受模块:用于接受异步重试消息;
重试任务模块:用户提供重试任务创建、持久化、配置读取、下次重试执行时间计算等功能;
重试任务调度模块:用于定时获取重试任务并执行。
3、公共模块,其中,公共模块包括:
状态机模块:用于将调用结果状态输入后,输出下一步状态;
后续处理逻辑模块:用于接受状态机输出状态,并根据状态执行下一步操作。
在一个具体的实施例中,重试任务模块是对各种业务重试进行的一种抽象,其中会包含但不限于以下信息:
1)业务子系统标示,业务类型,业务操作记录id,接口调用传入、传出参数等信息,这些信息使用字符串持久化,且各种类型的业务系统均可提供。本方法可利用这些信息重现调用现场,并进行重试,所以本方法可方便快速应用于各种不同业务,减少代码开发量。
2)提供异步重试逻辑模块(图4)、异步重试消息接受模块(图5)、重试任务调度模块(图5)。通过消息将异步重试用“重试任务”这个概念实体化并进行持久化保存,然后通过重试任务调度,定时执行重试;异步重试不会阻塞用户操作。
3)提供重试配置子模块以及执行时间表达式计算模块功能(图5),可以配置以下信息:
最大重试次数、当前重试次数、下次执行时间表达式。
通过表达式,比如“下次重试时间=当前时间+当前重试次数*10分钟”,类似公式的方式来灵活配置、计算下一次触发重试实际。
4)重试任务持久化子模块(图5),将重试上下文持久化保存,方便快速跟踪重试过程、结果;
5)本方法采用接口化设计,其中同步、异步重试逻辑模块、后续处理逻辑模块、重试任务持久化子模块、重试任务配置模块、执行时间表达式计算模块,均设计为接口。本方法使用者可根据自身需求实现任意接口,实现自己的扩展。比如重试任务持久化子模块可使用不同类型数据库进行扩展实现(如图7)。
6)提供同步、异步重试逻辑模块以及重试任务调度,实现自动按照设定进行重试(图4、图5);
各模块之间的整体关系,如图6所示,各步骤如下:
1、客户端发起对银行的请求;
2、返回结果满足重试条件;
3、如果是同步模式,进行同步重试,每间隔一段时间,发起对银行请求。此时同步阻塞客户端;
4、如果是异步模式,发送异步消息至服务器端,创建、初始化、持久化重试任务;
5、服务器端的重试任务调度模块定时发起对银行的重试请求。
在一个具体实施流程中,以提现业务为例来进行说明:
客户端流程,如图1所示:
001:用户发起提现申请;
002:提现子系统的申请接口接受用户请求,对用户资金进行“提现冻结”并调用银行或银行支付的提现申请接口;
003:银行接收本次提现申请。有可能出现:网络异常,调用结果未知;银行放回通用返回码,表明该笔提现申请状态,比如“已受理”“受理失败”等;如果重试条件是“网络异常”,则会进入下一步,否则直接将结果返回给调用者。
004:判断是否满足提现重试条件。
005:如果满足重试条件,则进入判断是否使用了同步重试模式,如果是,则进入006,否则进入009;
006:按照设定,会每隔x秒用同一笔提现订单id(业务操作记录id)调用一次银行提现申请接口;
007:将重试结果作为输入状态传入状态机,假定提现申请状态机设定为:输入网络异常状态,则输出执行异步处理状态;输入“已受理”状态,则输出“提现申请成功”状态,返回调用方;输入“受理失败”状态,则输出“提现失败”状态,执行“提现解冻”处理逻辑;
008:根据007输出状态进行后续处理;
009:如果进入异步重试模式,则发送一条异步消息;
0010:流程结束,表示将最终调用结果返回给业务系统、用户等。
而在服务器端,异步重试消息接收者实施流程,可以如图2所示。
101:接受上述009发送的提现申请异步重试消息;
102:根据消息中的数据,创建重试任务,其中业务子系统标示:提现,业务类型:提现申请,业务操作记录id:提现订单id,传入、传出参数:提现申请接口传入、传出参数值,包括提现金额、用户id等。读取重试配置模块中关于最大次数,执行时间表达式设置,假设下一次执行时间是:当前时间+5分钟,初始化重试任务各项属性;
103:将上述生成的重试任务持久化到某设备上,包括但不限于:文件、内存、关系型数据库、非关系型数据库等;
104:流程结束。
而在服务器端,异步重试任务调度实施流程,可以如图3所示。
201:异步重试调度程序,按照设定每x秒,苏醒并启动;
202:通过重试任务模块,查询需要重试的任务集合;
203:判断是否存在重试任务,如果存在进入204,如果没有进入207;
204:遍历重试任务集合,读取任务对应的重试配置,获取重试地址,即提现申请接口地址,根据重试任务中的传入参数等,再次调用接口,执行重试;
205:将重试结果作为输入状态传入状态机,假定提现申请异步重试状态机设定为:输入网络异常状态,则输出“执行订单查询然后再更新状态”;输入“已受理”状态,则输出“提现申请成功”状态,执行新订单状态为提现申请成功;输入“受理失败”状态,则输出“提现失败”状态,执行“提现解冻”处理逻辑;
206:根据上述步骤,执行不同处理逻辑。
207:流程结束,等待下一次苏醒。
实施例3
本发明实施例3还公开了一种客户端,应用于包括客户端以及服务端的系统中,如图8所示,该客户端包括:
第一判断模块801,用于当在触发调用银行接口的操作时,判断所述调用的返回结果是否满足预设的重试条件;
第二判断模块802,用于当所述第一判断模块的判断结果为是时,判断待进行的重试是同步模式还是异步模式;
执行模块803,用于当重试为同步模式时,则以预设时间段为周期进行预设次数的重试,并将重试的结果输入状态机,以及执行与状态机所反馈的结果对应的处理流程;
发送模块804,用于当重试为异步模式时,则向服务端发送异步重试消息,并将调用银行接口的结果返回给调用方。
在一个具体的实施例中,当重试为同步模式时,所述重试为同步阻塞式重新调用银行接口。
实施例4
本发明实施例4还公开了一种服务端,应用于包括客户端以及服务端的系统中,如图9所示,该服务端包括:
接收模块901,用于接收客户端发送的异步重试消息;
获取模块902,用于根据所述异步重试消息获取重试任务配置信息;
创建模块903,用于基于所述重试任务配置信息确定下次重试的执行时间,并创建重试任务;
初始化模块904,用于初始化所创建的重试任务;
存储模块905,用于将所述重试任务持久化到存储设备上。
在一个具体的实施例中,还包括:
第一执行模块,用于定时获取所述存储设备上的重试任务;
执行所获取的重试任务。
在一个具体的实施例中,还包括:
第二执行模块,用于获取所述执行的执行结果;
将所述执行结果发送给状态机;
接收所述状态机所反馈的输出结果;
执行与所述输出结果对应的处理流程。
以此,本发明实施例提出了一种与银行进行交互重试的方法和系统其,应用于包括客户端以及服务端的系统中,该方法包括:当在触发调用银行接口的操作时,判断所述调用的返回结果是否满足预设的重试条件;若判断结果为是,判断待进行的重试是同步模式还是异步模式;若为同步模式,则以预设时间段为周期进行预设次数的重试,并将重试的结果输入状态机,以及执行与状态机所反馈的结果对应的处理流程;若为异步模式,则向服务端发送异步重试消息,并将调用银行接口的结果返回给调用方。提供了一种更加完善,方便的与银行接口交互的重试方法。
本领域技术人员可以理解附图只是一个优选实施场景的示意图,附图中的模块或流程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中,也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本发明序号仅仅为了描述,不代表实施场景的优劣。
以上公开的仅为本发明的几个具体实施场景,但是,本发明并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明的保护范围。