一种分布式框架的聚合支付方法和系统

技术领域

本发明涉及软件支付技术领域，具体涉及一种分布式框架的聚合支付方法及系统。

背景技术

随着电子支付越来越发达，互联网支付方式也越来越多，在使用过程中，现有的支付方式可以连接多个支付接口，以满足不同支付接口的使用，提高支付效率。

而现有的支付系统有：Dubbo阿里开源的分布式框架、SpringBoot和Spring CloudGateway，其中，Dubbo阿里开源的分布式框架。Dubbo一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用、智能容错和负载均衡，以及服务自动注册和发现。同时也是一个分布式服务框架，致力于提供高性能和透明化RPC远程服务调用方案，以及SOA服务治理方案。SpringBoot:简化新Spring应用和初始搭建及开发过程的框架， Spring boot根据我们选择的依赖配置，可以自动启动我们想要的所有功能，并且只需单击一下即可启动应用程序。此外，它还简化了应用程序的部署过程。 Spring CloudGateway:Spring公司推出的一种实用的微服务网关，为了提升网关的性能，SpringCloudGateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。

上述现有的三个支付系统中都存在一定的缺点，具体为，Dubbo阿里开源的分布式框架的服务提供方与调用方接口依赖方式太强，调用方对提供方的抽象接口存在强依赖关系，需要严格的管理版本依赖，服务方与调用方的不一致导致应用无法编译成功等一系列问题，服务对平台敏感，难以简单复用，通常在提供对外服务时，都会以REST的方式提供出去，这样可以实现跨平台的特点； SpringBoot依赖太多，一个spring boot项目就有很多M，缺少服务的注册和发现等解决方案，缺少监控集成方案，安全管理方案；Spring CloudGateway 依赖Netty和Webflux不是Servlet编程模型，有一定的适用产品，不是Servlet 下工作，不能生成WAR包；不支持Springboot1.x。

发明内容

为了克服上述现有技术存在的问题，本发明提供一种分布式框架的聚合支付方法及系统。

本发明的技术方案是：

一种分布式框架的聚合支付方法，包括以下步骤：

对商户传入的报文进行验签、解密、验参；

根据报文中参数筛选交易通道；

根据设定的限额条件筛选最优交易通道；

判断最优交易通道是否可用，若可用，则获取该交易通道上的头文件；若不可用则重新筛选交易通道；

通过http/https请求上游，获取交易结果；

响应上游信息进行本系统的成本计费、用户计费。

作为本发明的进一步技术方案为，所述对商户传入的报文进行验签、解密、验参；具体为：

检查报文所传的支付方式的产品编号是否在指定的支付方式范围内；

对报文进行解密获取报文信息；

对报文信息进行验参，获取报文参数。

作为本发明的进一步技术方案为，所述对商户传入的报文进行验签、解密、验参；还包括：

采用Quartz实现任务的调度工作，定时执行商户入网信息的匹配，待审核任务，并经过设定的时间表定时定点唤起一个线程，线程执行实现准备好的代码逻辑，并将代码逻辑的业务推送到系统ACTIVEMQ，由MQ承载相关的量，进行分布式处理，完成定时器业务调度任务。

作为本发明的进一步技术方案为，所述根据报文中参数筛选交易通道；具体包括：根据报文中的参数来选择根据平台商户号、交易商户号或子商户号作为支付产品筛选交易通道。

作为本发明的进一步技术方案为，所述根据设定的限额条件筛选最优交易通道；具体为：以启用状态、支付方式的产品编码以及限额三个条件，筛选出合适的交易通道。

作为本发明的进一步技术方案为，所述判断最优交易通道是否可用，若可用，则获取该交易通道上的头文件；若不可用则重新筛选交易通道；具体为：当最优交易通道属于单商户模式，并绑定在其上面的通道商户可用，则获取该交易通道上的头文件，若不可用则重新筛选交易通道。

作为本发明的进一步技术方案为，所述判断最优交易通道是否可用，若可用，则获取该交易通道上的头文件；若不可用则重新筛选交易通道；具体为：当最优交易通道属于集群模式，获取集群内通道商户优先级，选择最高商户可用，且支持该支付方式产品，则确认该交易通道可用，否则重新筛选交易通道。

作为本发明的进一步技术方案为，通过http/https请求上游，获取交易结果；还包括：

利用redis的hexists函数判断交易流水号是否存在来确定锁是否被占用，

通过lua脚本执行的原子性，对交易流水号来set key保证判断超时操作的原子性；

利用Hash结构数据来实现可重入特性，并且确保了只有锁的持有者才能释放锁。

一种分布式框架的聚合支付系统，其特征在于，包括：

协调模块，负责协调处理各个子模块注册信息，保证分布下模块之间相互通信；

子系统服务模块，提供基础服务并给其它子模块进行调用，以完成系统业务的处理；

应用模块，通过RPC调用Service服务模块，以实现业务需求；

定时器，定时启动指定的应用，调用Service服务模块，在指定的时间点完成相应的业务需求；

消息队列模块，用于实现各个服务模块的业务解耦；

消息接收器，接收消息队列模块的消息进行业务处理；

HTTP和反向代理web服务器，负责商户访问系统的转发；

Redis数据库，实现系统的订单的缓存、分布式锁；

文件储存器，负责在分布式的环境下储存商户信息；

数据库集群，实现主备储存模式及数据库共享。

作为本发明的进一步技术方案为，所述子系统服务模块包括：

应用程序接口API，包括交易API、PC收银台、银行回调、通知接收、代付 API；

应用模块，包括：运营后台、会计后台、商户后台、销售后台、代理商后台、风控后台，通过RPC调用Service服务模块实现业务需求；

基础服务模块，包括用户服务、账户服务、运营服务、通道服务、风控服务、产品服务、会计服务、计费服务、限额服务、短信服务、鉴权服务并提供出去给其它子模块进行调用，以完成系统业务的处理；

核心交易服务模块，包括订单与交易、打款、支付渠道；

数据服务模块，包括对账、数据中心、清结算、报表。

本发明的有益效果为：

本发明具有可扩展性，每个微服务都可以独立进行横向扩展，根据业务实际增长情况来进行快速扩展；配合现在的容器技术，可在软件开发流程、部署、服务维护等各方面产生效率提升；

本发明独立的可升级性，每个微服务都可以独立进行服务升级、更新，不用依赖于其它服务，结合持续集成工具可以进行持续发布，开发人员就可以独立快速完成服务升级发布流程；

本发明故障和资源的隔离性，在系统中出现不好的资源操作行为时，例如内存泄露、数据库连接未关闭等情况，将仅仅只会影响单个微服务模块。

附图说明

图1为本发明提出的一种分布式框架的聚合支付方法流程图；

图2为本发明提出的一种分布式框架的聚合支付系统原理图；

图3为本发明提出的一种分布式框架的聚合支付系统结构图；

图4为本发明提出的子系统服务模块结构图。

具体实施方式

以下将结合实施例和附图对本发明的构思、具体结构及产生的技术效果进行清楚、完整地描述，以充分地理解本发明的目的、特征和效果。显然，所描述的实施例只是本发明的一部分实施例，而不是全部实施例，基于本发明的实施例，本领域的技术人员在不付出创造性劳动的前提下所获得的其他实施例，均属于本发明保护的范围。

参见图1，为本发明提出的一种分布式框架的聚合支付方法流程图；

如图1所示，一种分布式框架的聚合支付方法，包括以下步骤：

步骤101，对商户传入的报文进行验签、解密、验参；

步骤102，根据报文中参数筛选交易通道；

步骤103，根据设定的限额条件筛选最优交易通道；

步骤104，判断最优交易通道是否可用，若可用，则获取该交易通道上的头文件；若不可用则重新筛选交易通道；

步骤105，通过http/https请求上游,获取交易结果；

步骤106，响应上游信息进行本系统的成本计费、用户计费。

本发明实施例中，对商户传入的报文进行验签、解密、验参；具体包括：

检查报文所传的支付方式的产品编号是否在指定的支付方式范围内；

对报文进行解密获取报文信息；

对报文信息进行验参，获取报文参数。

本发明中，对商户传入的报文进行验签、解密、验参；通过基于Quartz+MQ 实现分布式架构下的定时任务调度，采用Quartz实现任务的调度工作，定时执行商户入网信息的匹配，待审核任务，并经过设定的时间表定时定点唤起一个线程，线程执行实现准备好的代码逻辑，并将代码逻辑的业务推送到系统 ACTIVEMQ，由MQ承载相关的量，进行分布式处理，完成定时器业务调度任务。

参见图2，检查报文所传的支付方式的产品编号是否在指定的支付方式范围内；具体为：制定的支付方式包括：微信支付，支付宝支付，云闪付支付，QQ 支付，京东支付，网银支付，快捷支付。

对报文进行解密获取报文信息；具体为：对报文进行解密获取产品版本号、交易金额、产品名称；每个支付产品都必须指定支付方式，即报文实例中的 q1_FrpCode字段。并且不同的产品报文存在差异，但是核心字段必须都得具备，如版本号，交易金额，产品名称等。

本发明实施例中，根据报文中参数筛选交易通道；具体包括：根据报文中的参数来选择根据平台商户号、交易商户号或子商户号作为支付产品筛选交易通道。

本发明实施例中，根据设定的限额条件筛选最优交易通道；具体为：以启用状态、支付方式的产品编码以及限额三个条件，筛选出合适的交易通道。

本发明实施例中，判断最优交易通道是否可用，若可用，则获取该交易通道上的头文件；若不可用则重新筛选交易通道；具体为：当最优交易通道属于单商户模式，并绑定在其上面的通道商户可用，则获取该交易通道上的头文件，若不可用则重新筛选交易通道。

本发明实施例中，判断最优交易通道是否可用，若可用，则获取该交易通道上的头文件；若不可用则重新筛选交易通道；具体为：当最优交易通道属于集群模式，获取集群内通道商户优先级，选择最高商户可用，且支持该支付方式产品，则确认该交易通道可用，否则重新筛选交易通道。

关于配置简约，灵活的路由系统实现了不同的支付类型的切换，根据商户传入产品参数，商户号，金额进行一系列地匹配检索，搜索出最优的符合支付方式的交易通道。

本系统采用双活机房架构，实现了高并发、高可用的需要，拆分为账务，计费，订单，用户，各类交易等独立的服务。同时来承载各个子系统正常运作，大大提高了各个子系统所承载的量。本系统将支付业务从500的TPS增大到了3600+。很大程度上满足了交易需求，增大了业务量。

参见图3，为本发明提出的一种分布式框架的聚合支付系统结构图。

如图3所示，一种分布式框架的聚合支付系统，包括：

协调模块，负责协调处理各个子模块注册信息，保证分布下模块之间相互通信；

子系统服务模块，提供基础服务并给其它子模块进行调用，以完成系统业务的处理；

应用模块，通过RPC调用Service服务模块，以实现业务需求；

定时器，定时启动指定的应用，调用Service服务模块，在指定的时间点完成相应的业务需求；

消息队列模块，用于实现各个服务模块的业务解耦；

消息接收器，接收消息队列模块的消息进行业务处理；

HTTP和反向代理web服务器，负责商户访问系统的转发；

Redis数据库，实现系统的订单的缓存、分布式锁；

文件储存器，负责在分布式的环境下储存商户信息；

数据库集群，实现主备储存模式及数据库共享。

Zookeeper(协调模块)，负责协调处理各个子模块注册信息，保证分布下模块之间相互通信方式。

Service(子系统服务模块)这个模块包括用户服务、账户服务、运营服务、通道服务、风控服务、产品服务、会计服务、计费服务、限额服务、短信服务、鉴权服务并提供出去给其它子模块进行调用，以完成系统业务的处理。

Web(应用模块)包括：运营后台、会计后台、商户后台、销售后台、代理商后台、风控后台等。主要面对PC端用户群体。应用模块可以通过RPC调用Service 服务模块，以实现业务需求。

Timer(定时器)，定时器是定时启动指定的应用，该应用会调Service服务模块，以便在指定的时间点完成相应的业务需求。

ActiveMQ(消息队列)，在这台聚合支付分布式环境下，需要通过业务解耦来提供系统性能以及业务处理能力，因此引进消息队列来实现各个服务模块的业务解耦，提高服务的并发能力。

APP(消息接收器)，消息接收器是负责接收ActiveMQ的消息，从而进行一定的业务处理，其中包括：支付完成处理、消息补单、成本计费通知、用户计费通知、商户通知等模块。

Nginx，负责商户访问系统的转发。保证商户的访问能合理到达南基模块或旗锐模块。从而保证系统单边运行、双边运行的。从而提高系统的灵活性。

Redis实现系统的订单的缓存、分布式锁等机制。

DFS(文件储存器)，由fastdfs来搭建的集群组成，负责在分布式的环境下储存商户信息，如：图片、对账文件、核心txt文等，满足了聚合支付系统文件储存的需求。

DB(数据库集群)是由Mysql组成的数据库集群，实现主备储存模式，就是交易订单信息先储存到主数据库，然后主数据库再同步到从数据库中。这样就保证的数据的稳定性，不易丢失。同时双边机房共享数据库。

参见图4，为本发明提出的子系统服务模块结构图；

如图4所示，子系统服务模块包括：

应用程序接口API，包括交易API、PC收银台、银行回调、通知接收、代付 API；

应用模块，包括：运营后台、会计后台、商户后台、销售后台、代理商后台、风控后台，主要面对PC端用户群体，应用模块通过RPC调用Service服务模块，实现业务需求；

基础服务模块，包括用户服务、账户服务、运营服务、通道服务、风控服务、产品服务、会计服务、计费服务、限额服务、短信服务、鉴权服务并提供出去给其它子模块进行调用，以完成系统业务的处理；

核心交易服务模块，包括订单与交易、打款、支付渠道；

数据服务模块，包括对账、数据中心、清结算、报表。

本系统对于商户入网、订单反查这类定时任务的操作，采用自主研发的Quartz+MQ策略。采用Quartz实现任务的调度工作，定时去执行商户入网信息的匹配，待审核等相关任务，并经过设定的时间表定时定点唤起一个线程，线程执行实现准备好的代码逻辑，并代码逻辑的业务推送到系统ACTIVEMQ，由MQ 承载相关的量，进行一定的分布式处理，最后完成定时器业务调度任务。

本系统利用redis的hexists函数判断交易流水号是否存在来确定锁是否被占用，然后通过lua脚本执行的原子性，通过对交易流水号来set key保证判断超时等操作的原子性；最后利用Hash结构数据来实现可重入特性，并且确保了只有锁的持有者才能释放锁；保证了本系统对于同一笔交易流水号不会存在的唯一性，不造成数据库的数据冗余。

本系统采用Apache Sharding Sphere的原理，结合我们的聚合系统的特性，将数据库的实例按照年月来划分表，同时在我们系统自主设计了一套代码逻辑来根据，运用系统规定的交易流水号规则来处理数据，并将此数据经过数据的截取、分析，最后存到相应的数据库表中，实现是系统数据库的分库分表的功能。

本发明具有可扩展性，每个微服务都可以独立进行横向扩展，根据业务实际增长情况来进行快速扩展；配合现在的容器技术(如Docker)，可在软件开发流程、部署、服务维护等各方面产生效率提升。

其中横向拓展为运用k8s的特性，根据应用的CPU、内存为主要核心参考因素，一旦应用的CPU运行超过90％，内存运用剩余10G，系统就会运用docker 作为载体，新部署一个代码业务逻辑一样的应用，这时服务节点就会多个应用来承载相应的量，完成相应的业务工作。

本发明独立的可升级性，每个微服务都可以独立进行服务升级、更新，不用依赖于其它服务，结合持续集成工具可以进行持续发布，开发人员就可以独立快速完成服务升级发布流程；

本发明故障和资源的隔离性，在系统中出现不好的资源操作行为时，例如内存泄露、数据库连接未关闭等情况，将仅仅只会影响单个微服务模块。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和 /或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/ 或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的系统。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令系统的制造品，该指令系统实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上对本发明进行了详细介绍，但是本发明不限于上述实施方式，在本领域普通技术人员所具备的知识范围内，还可以在不脱离本发明宗旨的前提下做出各种变化。不脱离本发明的构思和范围可以做出许多其他改变和改型。应当理解，本发明不限于特定的实施方式，本发明的范围由所附权利要求限定。