CN107592345A - 交易限流装置、方法及交易系统 - Google Patents

Abstract

本发明提供了一种交易限流装置、方法及交易系统，其中，该装置包括：交易处理装置，用于根据限流策略，调用外部服务装置提供的服务处理当前交易请求，将服务调用日志数据发送至数据分析装置；数据分析装置，用于对服务调用日志数据进行分析，确定每一服务处理交易请求的当前服务性能数据；根据历史服务性能数据，确定每一服务处理交易请求的历史平均服务性能数据；限流决策装置，用于将当前服务性能数据与历史平均服务性能数据进行比较，根据比较结果，生成当前时间段内处理交易请求的限流策略，将该限流策略发送至每一交易处理装置。上述技术方案实现了在对交易请求进行限流时保证弹性可扩展集群的稳定，也保证了交易系统的稳定运行。

Description

交易限流装置、方法及交易系统

技术领域

本发明涉及交易限流技术领域，特别涉及一种交易限流装置、方法及交易系统。

背景技术

随着互联网金融的快速发展，尤其是第三方快捷支付发展迅猛，各金融机构都面临潜在的性能容量风险及系统稳定性风险。快捷支付具有交易量突发增长和难以预测的特点，在“双十一”及“春节”这一类大促的节日，交易会出现瞬时峰值和持续峰值，同时交易量很难准确预测。在这样的场景下，若没有一个合适的限流装置，将会导致系统响应缓慢甚至宕机，影响全国所有的接入的支付机构的交易，给银行带来巨大的经济损失和舆论影响。

面对海量交易，较为常用的解决方式有通过升级硬件资源、优化系统的架构以及增加限流措施。升级硬件资源，会在一定程度上缓解性能压力，但同时也会带来成本的增加，商业银行的成本控制必然不允许设备无限制的升级，同时，由于峰值时间的短暂性，升级设备也会带来资源的浪费。优化系统的架构，可以带来系统处理能力的提升，但系统架构优化的空间是有限的，达到瓶颈后就很难再有很大的提升。增加限流措施，是目前比较成熟的一种做法，通过限制涌入系统的流量，解决了系统的拥堵问题，保证了系统的稳定性。

目前，商业银行常用的限流方式有：1、预设计数器，实时计算当前服务器的并发数，通过预设的并发阀值，拒绝超过并发阀值的请求，来控制系统可以同时处理的请求数。2、预设配置文件，通过计算服务器的预设场景的实际值与配置文件中的参数值进行比较，若实际值大于参数文件中设计的值，则拒绝交易，控制当前服务器的并发数。3、根据主机系统的超时率等性能参数信息，与预设的参数值进行比较，通过拒绝部分下游应用的交易请求，来保证主机的稳定。

但是在快捷支付这一类高并发应用，因为交易的峰值变化较大，通常使用Paas云及Iaas云来保证集群的弹性可扩展、高可用及资源的合理利用。在这样的场景下，交易集群的设备数会动态变化，因此服务器中预设的并发阀值和预设配置文件的参数值，与集群中单台服务器的实际能够支持的并发能力并不能够很好的匹配，在集群设备扩展的情况下，仍然可能导致某个后台服务的堵塞、集群性能下降，甚至会导致系统雪崩。另外，平台调用的服务往往不止后端主机的服务，任何一个后端服务的性能下降，都会导致整个集群服务能力的下降，因此，仅保证主机的稳定，并不能够保证整个交易集群的高可用。

因此，现有交易限流方案并不能够保证弹性可扩展交易集群的稳定，以及交易系统的稳定运行。

发明内容

本发明实施例提供了一种交易限流装置，用以在对交易请求进行限流时保证弹性可扩展集群的稳定，该装置包括：数据分析装置、限流决策装置和多个交易处理装置；其中：

交易处理装置，用于根据限流决策装置发来的当前时间段内处理交易请求的限流策略，调用外部服务装置提供的服务处理当前交易请求，将处理当前交易请求的服务处理日志数据写入服务调用日志数据中，将预设时长内的服务调用日志数据发送至数据分析装置；

数据分析装置，用于对服务调用日志数据进行分析，确定每一服务处理交易请求的当前服务性能数据；根据各服务处理交易请求的历史服务性能数据，确定每一服务处理交易请求的历史平均服务性能数据；

限流决策装置，用于定时读取当前服务性能数据和历史平均服务性能数据，将当前服务性能数据与历史平均服务性能数据进行比较，根据比较结果，生成当前时间段内处理交易请求的限流策略，将当前时间段内处理交易请求的限流策略发送至每一交易处理装置。

本发明实施例还提供了一种交易限流方法，用以在对交易请求进行限流时保证弹性可扩展集群的稳定，该方法包括：

根据当前时间段内处理交易请求的限流策略，调用外部服务装置提供的服务处理当前交易请求，将处理当前交易请求的服务处理日志数据写入服务调用日志数据中，将预设时长内的服务调用日志数据发送；

对服务调用日志数据进行分析，确定每一服务处理交易请求的当前服务性能数据；根据各服务处理交易请求的历史服务性能数据，确定每一服务处理交易请求的历史平均服务性能数据；

定时读取当前服务性能数据和历史平均服务性能数据，将当前服务性能数据与历史平均服务性能数据进行比较，根据比较结果，生成当前时间段内处理交易请求的限流策略，将当前时间段内处理交易请求的限流策略发送。

本发明实施例还提供了一种交易系统，用以实现安全可靠的交易请求，该系统包括：

请求接入装置,用于接收支付机构的交易请求；

如上述的交易限流装置；

外部服务装置，用于提供交易处理装置所需调用的服务；

服务包括：加解密服务、验证签名服务、上主机扣款服务、登记数据库服务、主机服务以及短信发送服务。

本发明实施例提供了一种计算机设备，用以对交易请求进行限流，该计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行上述计算机程序时实现如上的交易限流方法。

本发明实施例提供了一种计算机可读存储介质，用以对交易请求进行限流，该计算机可读存储介质存储有执行如上的交易限流方法的计算机程序。

与现有技术相比较，本发明实施例提供的交易限流方案，根据对外部服务装置构成的弹性可扩展集群的每一服务的服务调用日志数据，分析出弹性可扩展集群中每一服务的当前服务性能数据，结合当前服务性能数据以及该服务的历史服务性能数据，生成当前时间段内可靠的限流策略，交易处理装置可以根据该限流策略，决定是否以及如何调用外部服务装置提供的外部服务来处理当前交易请求，实现了在对交易请求进行限流时保证弹性可扩展集群的稳定，另外，也保证了应用上述交易限流方案的交易系统的稳定运行。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1是本发明实施例中交易限流装置及交易系统的结构示意图；

图2是本发明实施例中请求接入装置的结构示意图；

图3是本发明实施例中交易处理装置的结构示意图；

图4是本发明实施例中数据分析装置的结构示意图；

图5是本发明实施例中限流决策装置的结构示意图；

图6是本发明实施例中交易限流方法的流程示意图；

图7是本发明实施例中请求处理的流程示意图；

图8是本发明又一实施例中基于机器学习的交易限流装置的实现流程示意图；

图9是本发明实施例中限流策略执行单元的实现流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施方式和附图，对本发明做进一步详细说明。在此，本发明的示意性实施方式及其说明用于解释本发明，但并不作为对本发明的限定。

考虑到现有交易限流方案并不能够保证弹性可扩展交易集群的稳定，为了弹性可扩展交易集群的稳定以及确保交易系统的稳定运行，必须提供一种交易限流装置和方法，能够准实时地分析出集群能够服务的性能上限，控制整个交易集群的所有服务器的并发数并进行动态调整，避免交易并发数超过系统的承受上限，导致系统的过载甚至崩溃。

基于上述问题，发明人提出了一种基于机器学习的交易限流装置及方法，通过大数据挖掘分析以及实时计算等机器学习手段，由本装置在秒级分析出弹性可扩展交易集群能够对外提供交易服务的性能上限，并自动判断是否需要调整交易系统的限流策略，在交易出现瞬间峰值、持续峰值、系统某个依赖的服务出现响应缓慢或应用服务器云扩容等场景下，不需要人工参与，自动调整限流相关参数及策略，在必要的场景下，实现队列等待、削峰、服务降级等限流操作，保证系统提供的对外服务不会因为这些异常导致过载甚至崩溃。

本发明实施例提供的基于机器学习的交易限流装置及方法包括：商业银行的支付系统在收到支付机构的请求后，将请求分发至交易处理装置进行处理，并保证所有的交易处理装置间负载均衡；交易处理装置根据限流决策装置分发的限流策略，决定是否以及如何调用包括数据库服务、主机服务以及短信发送服务等外部服务，完成交易后将交易处理结果返回给支付机构；数据分析装置和限流决策装置，会根据实时的服务调用情况，定时生成对应的限流策略，并推送给交易处理装置。

机器学习(Machine Learning)是一门多领域交叉学科，涉及概率论、统计学、逼近论、凸分析、算法复杂度理论等多门学科，主要针对已存在的大数据进行学习来对将来进行数据预测。本专利中涉及的机器学习，是指利用历史服务调用的大数据分析获取各服务的平均性能情况，同时对当前时段内的服务性能进行实时分析，获取各服务的实时负载情况，并预测各服务后续的性能趋势。本发明将利用历史大数据分析及实时计算分析的结果，来制定对应的限流策略。

下面对该交易限流装置、方法及交易系统进行详细介绍。

图1是本发明实施例中交易限流装置及交易系统的结构示意图，如图1所示，该交易系统包括：

请求接入装置1,用于接收支付机构的交易请求；

如下文所述的交易限流装置，包括：交易处理装置2、数据分析装置4和限流决策装置5；

外部服务装置3，用于提供交易处理装置所需调用的服务；

本发明实施例中提到的服务包括：加解密服务、验证签名服务、上主机扣款服务、登记数据库服务、主机服务以及短信发送服务等；所述外部服务装置为弹性可扩展集群。

具体实施时，图1为本发明的系统结构图，如图1所示，本发明提出的含有基于机器学习的交易限流装置的交易处理系统包括请求接入装置1、交易处理装置2、外部服务装置3、数据分析装置4、限流决策装置5，其中，交易限流装置由交易处理装置2、数据分析装置4、限流决策装置5共同组成，由交易处理装置1、外部服务装置3共同组成完成的高可用系统。通过请求接入装置1、交易处理装置2和外部服务装置3，完成一笔请求的处理，其中交易处理装置2负责各外部服务装置3提供的外部服务的调用及限流策略的执行。交易处理装置2、数据分析装置4和限流决策装置5配合完成数据的采集、数据实时分析及限流策略的决策。

请求接入装置1，由硬件设备F5、行内通讯前置(运行于SUSE 11SP4操作系统上，为行内自行研发前置软件)、HaProxy(运行于SUSE 12操作系统上的开源软件，行内定制开发)共同组成；交易处理装置2部署于行内搭建的PaaS云中，可根据交易流量进行弹性伸缩，装置所用宿主机为SUSE 12操作系统的虚拟机，flume、kafka及HDFS等组件为行内基于开源产品定制开发的软件(部分组件采购)；数据分析装置4，由行内搭建的Hadoop集群、基于开源产品定制化开发(部分采购)的各软件组成；限流决策装置5为行内自行研发的多个软件，软件部署在SUSE 12操作系统上，相关限流算法为行内自行开发，并逐步通过压测和生产验证进行调优。通过这五个装置的相互协作，共同实现不需要人工介入的，能够进行准确限流的高可用交易处理系统。

与现有技术相比较，本发明实施例提供的交易限流方案，根据对外部服务装置构成的弹性可扩展集群的每一服务的服务调用日志数据，分析出弹性可扩展集群中每一服务的当前服务性能数据，结合当前服务性能数据以及该服务的历史服务性能数据，生成当前时间段内可靠的限流策略，交易处理装置可以根据该限流策略，决定是否以及如何调用外部服务装置提供的外部服务来处理当前交易请求，实现了在对交易请求进行限流时保证弹性可扩展集群的稳定，另外，也保证了应用上述交易限流方案的交易系统的稳定运行。

具体实施时，上述当前服务性能数据即为实时的性能数据。

第一，对请求接入装置1进行详细介绍。

请求接入装置1：用于实现支付机构请求的接入和报文转换，同时，保证实际处理请求的交易处理装置2的负载均衡。不同的支付机构的通讯方式和报文格式都可能不同，请求接入装置服务将其请求统一转换为交易处理装置2可以处理的格式。同时，请求接入装置1通过心跳检测机制，保证交易处理装置2新增、删除、重启或者宕机等场景，不影响交易请求的处理。请求接入装置1支持多种负载均衡算法，通常我们采用最小连接数(leastConn，新的连接请求被派发至具有最小连接数目的后端服务器)的调度算法。

图2是本发明实施例中请求接入装置的结构示意图，在一个实施例中，如图2所示，请求接入装置1可以包括：心跳检测单元11、报文转换单元12、辅助均衡单元13，其中：

心跳检测单元11，用于检测各个交易处理装置的状态，确定出正常状态的交易处理装置；

报文转换单元12，用于将接收到的交易请求转换为交易处理装置所需格式的交易请求；

负载均衡单元13，用于根据负载均衡算法，将交易处理装置所需格式的交易请求发送至正常状态的交易处理装置。

具体实施时，心跳检测单元11：用于检测交易处理装置2的可用性，保障交易不会发送至故障的交易处理装置2上，导致交易成功率降低。

具体实施时，报文转换单元12：用于将不同的支付机构的通讯方式和报文格式，统一转换为交易处理装置2可以处理的格式。

具体实施时，负载均衡单元13：用于保证所有交易处理装置2的负载均衡，本单元支持多种负载均衡算法，根据本发明的实施例采用最小连接数的算法。

第二，对交易限流装置进行详细介绍。

如图1所示，该交易限流装置可以包括：多个交易处理装置2、数据分析装置4和限流决策装置5；其中：

交易处理装置2，用于根据限流决策装置发来的当前时间段内处理交易请求的限流策略，调用外部服务装置提供的服务处理当前交易请求，将处理当前交易请求的服务处理日志数据写入服务调用日志数据中，将预设时长内的服务调用日志数据发送至数据分析装置；

数据分析装置4，用于对服务调用日志数据进行分析，确定每一服务处理交易请求的当前服务性能数据；根据各服务处理交易请求的历史服务性能数据，确定每一服务处理交易请求的历史平均服务性能数据；

限流决策装置5，用于定时读取当前服务性能数据和历史平均服务性能数据，将当前服务性能数据与历史平均服务性能数据进行比较，根据比较结果，生成当前时间段内处理交易请求的限流策略，将当前时间段内处理交易请求的限流策略发送至每一交易处理装置；

所述外部服务装置为弹性可扩展集群。

下面对该交易限流装置进行详细介绍。

首先，介绍交易处理装置2。

交易处理装置2：用于处理不同的交易，根据交易流程的配置，调用如加解密、验证签名、上主机扣款、登记数据库等不同的服务，在调用各类服务时，根据不同的限流策略及服务的重要程度，执行多种不同的交易限流方式。在服务调用完成后，会将本次服务调用的耗时、服务处理结果等数据通过flume(由Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统)传输至数据分析装置4，为后续数据分析和限流策略决策提供数据支撑。每调用一次服务，交易处理装置2会记录一笔日志，flume抓取日志，写入至HDFS(分布式文件系统)和Kafka(一种开源的高吞吐量的分布式发布订阅消息系统)中，供后续Spark Sreaming(UC Berkeley AMP lab所开源的类Hadoop MapReduce的通用并行框架)进行实时分析及存量服务调用的大数据分析。

具体实施时，交易处理装置2的数目可以随着弹性可扩展集群(外部服务装置)的变化而变化。

图3是本发明实施例中交易处理装置的结构示意图，如图3所示，在一个实施例中，交易处理装置2可以包括：限流策略执行单元21、外部服务装置调用单元22、服务监控单元23，其中：

限流策略执行单元21，用于根据当前时间段内处理交易请求的限流策略，为交易请求配置交易处理流程；

外部服务调用单元22，用于根据配置的交易处理流程以及调用服务的预设重要程度，调用外部服务装置提供的服务处理当前交易请求；

服务监控单元23，用于在服务调用完成后，将处理当前交易请求的服务处理日志数据写入服务调用日志数据中，将预设时长内的服务调用日志数据发送至数据分析装置。

具体实施时，限流策略执行单元21：用于执行具体的限流策略，根据不同的限流策略，对交易执行不同方式的限流。

具体实施时，外部服务调用单元22：用于调用外部服务。根据交易流程的配置，调用不同的服务如验证签名、上主机、数据库处理等，完成交易的全流程处理。

具体实施时，服务监控单元23：用于在每次服务调用完成后，服务监控单元会将服务调用耗时、处理结果等信息的记录到日志中，flume抓取日志，将其写入至数据分析装置4的HDFS(分布式文件系统)和Kafka(一种开源的高吞吐量的分布式发布订阅消息系统)中，为后续数据分析和限流策略决策提供数据支撑。本单元保证了在交易处理装置2弹性伸缩或某个外部服务出现异常的情况，能够及时将服务的性能情况反馈至数据分析装置4，完成限流策略的更新。

在一个实施例中，限流策略执行单元21具体用于在判断交易处理流程中调用的服务存在关键服务，关键服务为故障状态时，拒绝当前交易请求。

具体实施时，一个交易请求可能需要顺序调用多个服务依次完成该交易请求，也可以将该交易请求分成多个小请求，例如登录请求，扣款请求等，处理每一个请求需要调用一个相应的服务。限流策略执行单元21会先根据限流策略判断配置的当前交易流程中，需要调用的服务是否存在关键服务，如果判断该关键服务的状态故障不可用，那么会拒绝整个交易请求，这样处理的好处是：某一个关键服务不可用，交易都应该直接拒绝，以减少不必要的服务调用，节省系统资源。

在一个实施例中，外部服务调用单元22具体用于：

在判断交易处理流程中调用的服务为关键服务时，当根据限流策略判断需要对调用关键服务的请求进行限流时，将关键服务的请求加入关键服务的等待队列；

在判断交易处理流程中调用的服务为非关键服务时，当根据限流策略判断需要对调用非关键服务的请求进行限流时，跳过当前非关键服务的请求。

具体实施时，限流策略执行单元21会先根据限流策略判断配置的当前交易流程中，需要调用的服务是否存在关键服务，首先判断该关键服务的状态可用时，再判断该关键服务是否需要限流，根据限流策略执行队列等待、削峰、服务降级等限流操作，保证系统提供的对外服务不会因为这些异常导致过载甚至崩溃。具体实现过程、原理及优点请参见下文中的步骤S301至步骤S310。

其次，介绍数据分析装置4。

数据分析装置4：用于完成各类服务性能的实时分析，为限流决策提供数据支撑。使用Spark Streaming(UC Berkeley AMP lab所开源的类Hadoop MapReduce的通用并行框架)配合Kafka(一种开源的高吞吐量的分布式发布订阅消息系统)完成对交易处理装置2上送的服务调用日志的实时分析，获取各类服务的实时的性能情况，另外，利用Spark大数据分析，定时统计每一个服务的历史耗时平均值，作为限流决策的基准值。同时，提供数据存储功能，存储服务性能的分析结果和限流策略的存储。

图4是本发明实施例中数据分析装置的结构示意图，在一个实施例中，当前服务性能数据包括：服务处理交易请求的当前耗时；历史服务性能数据包括服务处理交易请求的历史平均耗时；数据分析装置4可以包括：数据分析单元41、分析结果存储单元42、限流策略存储单元43，其中：

数据分析单元41，用于对每个交易处理装置发来的服务调用日志数据进行分析，确定各服务处理交易请求的当前耗时；根据各服务处理交易请求的历史服务性能数据，确定每一服务处理交易请求的历史平均耗时；

分析结果存储单元42，用于存储各服务处理交易请求的当前耗时和历史平均耗时；

限流策略存储单元43，用于存储限流决策装置生成的限流策略；

当前耗时、历史平均耗时和限流策略供限流决策装置读取，以及作为历史服务性能数据存储。

具体实施时，数据分析单元41：用于完成交易处理装置2发送来的服务调用数据的实时分析。使用Spark Streaming(UC Berkeley AMP lab所开源的类Hadoop MapReduce的通用并行框架)配合Kafka(一种开源的高吞吐量的分布式发布订阅消息系统)完成对交易处理装置2上送的服务调用日志的实时分析，获取各类服务的实时的性能情况。同时，使用Spark定时进行大数据分析，根据各类服务历史上所有调用的数据，分析出该服务的历史平均耗时情况。

具体实施时，分析结果存储单元42：用于存储当前服务性能分析的结果及历史所有服务调用的数据。

具体实施时，限流策略存储单元43：用于存储限流决策装置5生成的限流策略，为限流策略分发提供数据存储。

再次，介绍限流决策装置5。

限流决策装置5：用于定时读取各类服务的实时耗时情况，并通过机器学习分析出各类服务的耗时趋势，生成对应的限流策略，同时将限流策略分发至所有的交易处理装置。限流决策装置5会通过大数据分析，根据各类服务历史上所有服务调用的情况，分析出该服务的历史平均耗时情况，在进行限流决策时，若本次分析时间段内，服务的耗时超过历史平均耗时的200％，则开始对服务进行限流，限流策略为队列等待(该等待队列的执行队列深度，来源于历史数据分析，根据该服务耗时为历史平均值时的最大并发数来设置)；若本次分析时间段内，服务的耗时超过历史平均耗时的400％，则对服务限流的策略进行进一步的调整，若服务调用的并发呈下降趋势，则服务限流策略为继续队列等待，若呈上升趋势，则服务限流策略为拒绝服务，不再对外提供服务；若本次分析时间段内，服务的耗时超过历史平均耗时的500％，则服务限流策略为拒绝服务，由交易处理装置2根据服务是否为关键服务进行交易的削峰或服务降级。

图5是本发明实施例中限流决策装置的结构示意图，如图5所示，在一个实施例中，限流决策装置5可以包括：限流策略生成单元51、限流策略分发单元52；其中：

限流策略生成单元51，用于定时读取当前耗时和历史平均耗时，将当前耗时和历史平均耗时进行比较，根据比较结果，生成当前时间段内处理交易请求的限流策略；

限流策略分发单元52，用于将当前时间段内处理交易请求的限流策略发送至每一交易处理装置。

具体实施时，限流策略生成单元51：用于定时读取各类服务的实时耗时情况，并通过Spark的机器学习算法分析出各类服务的耗时趋势，生成对应的限流策略。在进行限流决策时，若本次分析时间段内，服务的耗时超过历史平均耗时的200％，则开始对服务进行限流，限流策略为队列等待(等待队列的执行队列深度，来源于历史数据分析，根据该服务耗时为历史平均值时的最大并发数来设置)；若本次分析时间段内，服务的耗时超过历史平均耗时的400％，则对服务限流的策略进行进一步的调整，若服务调用的并发呈下降趋势，则服务限流策略为继续队列等待，若呈上升趋势，则服务限流策略为拒绝服务，不再对外提供服务；若本次分析时间段内，服务的耗时超过历史平均耗时的500％，则服务限流策略为拒绝服务，由交易处理装置2根据服务是否为关键服务进行交易的削峰或服务降级。

具体实施时，限流策略分发单元52：将生成的限流策略存储在限流策略存储单元43中之后，将最新的限流策略分发至所有的交易处理装置2中，若分发失败，则不断重试，直至下一次限流策略分发成功。在交易处理装置2新增时，限流策略分发单元会通过Zookeeper(开源的分布式协调服务，Google Chubby的开源实现)自动感知到，并将最新的限流策略分发至新增的交易处理装置2上。

在一个实施例中，限流策略可以包括：

若当前时间段内，服务处理交易请求的当前耗时超过历史平均耗时的200％，则将调用服务的请求加入服务的等待队列；

若当前时间段内，服务处理交易请求的当前耗时超过历史平均耗时的400％，则根据服务的负载情况，预测服务的性能趋势，若性能趋势为下降趋势，则将调用服务的请求加入服务的等待队列；若性能趋势为上升趋势，则拒绝调用服务的请求；

若当前时间段内，当前耗时超过历史平均耗时的500％，则拒绝调用服务的请求。

第三，对外部服务装置3进行介绍。

外部服务装置3用于提供各类外部服务所述外部服务例如包括上主机扣款、登记数据库、验证签名、发送短信等。每一类的服务，都存在其对应的性能上限，同时，由于调用并发数、架构优化或机器资源等可能出现的变动，各类服务的性能也随时可能出现变化。

基于同一发明构思，本发明实施例中还提供了交易限流方法，如下面的实施例。由于交易限流方法解决问题的原理与交易限流装置相似，因此交易限流方法的实施可以参见交易限流装置的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图6是本发明实施例中交易限流方法的流程示意图，如图6所示，该方法可以包括如下步骤：

步骤10：根据当前时间段内处理交易请求的限流策略，调用外部服务装置提供的服务处理当前交易请求，将处理当前交易请求的服务处理日志数据写入服务调用日志数据中，将预设时长内的服务调用日志数据发送；

步骤20：对服务调用日志数据进行分析，确定每一服务处理交易请求的当前服务性能数据；根据各服务处理交易请求的历史服务性能数据，确定每一服务处理交易请求的历史平均服务性能数据；

步骤30：定时读取当前服务性能数据和历史平均服务性能数据，将当前服务性能数据与历史平均服务性能数据进行比较，根据比较结果，生成当前时间段内处理交易请求的限流策略，将当前时间段内处理交易请求的限流策略发送；

所述外部服务装置为弹性可扩展集群。

在一个实施例中，根据当前时间段内处理交易请求的限流策略，调用外部服务装置提供的服务处理当前交易请求，将处理当前交易请求的服务处理日志数据写入服务调用日志数据中，将预设时长内的服务调用日志数据发送，包括：

根据当前时间段内处理交易请求的限流策略，为交易请求配置交易处理流程；

根据配置的交易处理流程以及调用服务的预设重要程度，调用外部服务装置提供的服务处理当前交易请求；

在服务调用完成后，将处理当前交易请求的服务处理日志数据写入服务调用日志数据中，将预设时长内的服务调用日志数据发送。

在一个实施例中，根据当前时间段内处理交易请求的限流策略，为交易请求配置交易处理流程可以包括：

在判断交易处理流程中调用的服务存在关键服务，关键服务为故障状态时，拒绝当前交易请求。

在一个实施例中，根据配置的交易处理流程以及调用服务的预设重要程度，调用外部服务装置提供的服务处理当前交易请求，可以包括：

在判断交易处理流程中调用的服务为关键服务时，当根据限流策略判断需要对调用关键服务的请求进行限流时，将关键服务的请求加入关键服务的等待队列；

在判断交易处理流程中调用的服务为非关键服务时，当根据限流策略判断需要对调用非关键服务的请求进行限流时，跳过当前非关键服务的请求。

在一个实施例中，当前服务性能数据可以包括：服务处理交易请求的当前耗时；历史服务性能数据包括服务处理交易请求的历史平均耗时；

对服务调用日志数据进行分析，确定每一服务处理交易请求的当前服务性能数据；根据各服务处理交易请求的历史服务性能数据，确定每一服务处理交易请求的历史平均服务性能数据，可以包括：

对每个交易处理装置发来的服务调用日志数据进行分析，确定各服务处理交易请求的当前耗时；根据各服务处理交易请求的历史服务性能数据，确定每一服务处理交易请求的历史平均耗时；

存储各服务处理交易请求的当前耗时和历史平均耗时；

存储限流决策装置生成的限流策略。

在一个实施例中，定时读取当前服务性能数据和历史平均服务性能数据，将当前服务性能数据与历史平均服务性能数据进行比较，根据比较结果，生成当前时间段内处理交易请求的限流策略，将当前时间段内处理交易请求的限流策略发送，包括：

定时读取当前耗时和历史平均耗时，将当前耗时和历史平均耗时进行比较，根据比较结果，生成当前时间段内处理交易请求的限流策略；

将当前时间段内处理交易请求的限流策略发送至每一交易处理装置。

图7是本发明实施例中请求处理的流程示意图；如图7所示，本发明实施例提供的交易限流方法中请求处理的步骤可以包括：

步骤S101：请求接入装置1接受到支付机构的请求。

步骤S102：完成报文签名校验之后，若签名正确，则通过报文转换单元12将请求转换为交易处理装置所需的通讯格式。

步骤S103：在最小连接数的负载均衡算法时，负载均衡单元13会将转换好的请求发送至负载最低的可用交易处理装置2。

步骤S104：限流策略执行单元21会根据当前交易的配置流程，依次调用不同的服务，在调用服务时，会根据限流策略，选择拒绝、等待或者直接调起服务处理。

步骤S105：外部服务调用单元，使用RPC格式调用，调起具体的服务，并将处理结果返回至交易处理装置2。

步骤S106：在交易流程处理完成之后，将交易的处理结果，根据和各支付机构约定的报文格式及通讯格式，返回给各支付机构。

步骤S107：请求处理流程结束。

步骤S108：在每一次服务调用完成之后，服务监控单元23都会将各服务的处理返回结果及调用所需时间，通过flume传输至数据分析单元41，供后续数据分析使用。该步骤保证了在弹性扩展的云系统架构下，因交易处理装置2的数目增加或者减少，或者某个外部服务的服务能力扩大或者减少的场景下，应用能够通过交易快速采集到性能变化数据。

图8是本发明又一实施例中基于机器学习的交易限流装置的实现流程示意图，如图8所示，该实现步骤可以包括：

步骤S201：服务监控单元23将各服务的处理返回结果及调用所需时间，通过flume传输至数据分析单元41。

步骤S202：数据分析单元41收到flume传输过来的服务调用日志后，使用SparkStreaming在秒级(根据不同服务分析的时效要求，在10s至30s内不等)完成数据分析，获取每秒的服务的平均耗时情况。同时，定时使用Spark进行历史全量服务调用数据的大数据分析，分析出服务的历史平均耗时。

步骤S203：分析结果存储单元42将每秒的分析结果存储在HDFS中，供后续查询和数据分析。

步骤S204：限流策略生成单元51，定时读取各服务的平均耗时，实时分析出各类服务的耗时趋势，生成对应的限流策略，保证了在弹性扩展的云系统架构下，能够根据生产实际的服务性能情况，快速调整各服务的限流策略。具体限流策略的生成，见限流策略生成单元51的详细描述。

步骤S205：限流策略存储单元43将步骤S204的最新限流策略保存下来，供后续查询。

步骤S206：限流策略分发单元52监听ZooKeeper中交易处理装置2的变化情况，根据ZooKeeper中最新的装置列表，将最新的限流策略分发至所有的交易处理装置2，保证在弹性扩展的云系统架构中，限流策略能够在集群所有服务器中生效。

步骤S207：交易处理装置2会缓存当前的限流策略，并接受请求接入装置1发送过来的各类请求，按照交易流程的配置调起各类服务。

步骤S208：限流策略执行单元21会先判断当前交易流程的配置中，是否有关键服务的限流策略为拒绝交易(某一个关键服务不可用，交易都应该直接拒绝，以减少不必要的服务调用)。若有，则进入步骤S209，否则进入步骤S210。

步骤S209：返回当前服务器繁忙，交易结束。

步骤S210：根据交易流程的配置，依次调用各类外部服务。

步骤S211：在交易流程处理完成后，返回交易处理结果。

图9是本发明实施例中限流策略执行单元的实现流程示意图，本发明实施例中限流策略执行单元是限流装置生效的处理单元，在实际调用服务之前，会先判断是否有关键服务为拒绝服务，若有关键服务为拒绝服务，则为拒绝交易，上述步骤S208已经进行描述，下面将描述无关键服务为拒绝服务的交易处理流程，即步骤S210的详细流程，参见图9，其步骤可以包括如下：

步骤S301：外部服务调用单元31根据交易处理流程，依次调用各类外部服务。

步骤S302：在处理每个服务之前，会先判断当前交易流程是否处理完成。如交易流程已经处理完成，则进入步骤S303，否则进入步骤S304。

步骤S303：交易处理结束，返回交易的处理结果。

步骤S304：根据交易流程的定义，判断当前服务是否为主服务，即核心服务(交易流程中，该服务必须成功，否则交易失败)，若是，则进入步骤S305，否则进入步骤S308。

步骤S305：判断当前服务是否需要限流，若是，则进入步骤S306，否则进入步骤S310。

步骤S306：针对每个服务，均有一个公共的缓冲等待队列，用来控制同一时间服务的调用并发数，该缓存等待队列的执行队列深度，来源于历史数据分析，根据该服务耗时为历史平均值时的最大并发数来设置。

步骤S307：在等待队列中的服务完成排序，开始处理前，先判断在队列中的等待时间是否超过其超时时间，若是，则进入步骤S303，否则进入步骤S310。

步骤S308：当前服务非关键服务(即高并发场景下，可以不执行，可通过后续补偿措施完成，对交易实际处理结果无影响)，判断当前服务是否需要限流，若需要，则进入步骤S309，否认进入步骤S310。

步骤S309：当前服务需要限流，直接跳过当前服务，进入步骤S301，根据服务调用结果及交易流程的定义，决定交易是否结束或进行下一次服务的调用。

步骤S310：调用对应的外部服务装置，进入步骤S301，根据服务调用结果及交易流程的定义，决定交易是否结束或进行下一次服务的调用。

本发明实施例提供了一种计算机设备，用以对交易请求进行限流，该计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行上述计算机程序时实现如上的交易限流方法。

本发明实施例提供了一种计算机可读存储介质，用以对交易请求进行限流，该计算机可读存储介质存储有执行如上的交易限流方法的计算机程序。

本发明实施例提供了一种基于机器学习的交易限流装置及方法，通过大数据挖掘分析以及实时计算，能够在秒级计算出当前所有装置所有调用服务的负载情况，并结合历史大数据分析、实时的负载情况、当前一段时间内的服务并发度的趋势，自动调整交易限流策略，保证交易集群的稳定性，其优点如下：

1、不需要预设参数，通过集群秒级的数据分析，完成限流参数和策略的调整，保证在弹性扩展的云系统架构下，限流控制策略的准确性。

2、能够根据系统所有后台服务的性能变化，自动调整集群的限流策略，保证包括主机服务在内的任意一个服务出现性能变化时，能够及时调整限流策略，保证集群的高可用。

3、支持多样的限流策略，根据具体服务的性能情况，不需要人为决策，能够自动选择队列等待、削峰、服务降级等不同的限流策略，进行自动且灵活的限流。

显然，本领域的技术人员应该明白，上述的本发明实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明实施例不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明实施例可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (15)

1.一种交易限流装置，其特征在于，包括：数据分析装置、限流决策装置和多个交易处理装置；其中：

交易处理装置，用于根据限流决策装置发来的当前时间段内处理交易请求的限流策略，调用外部服务装置提供的服务处理当前交易请求，将处理当前交易请求的服务处理日志数据写入服务调用日志数据中，将预设时长内的服务调用日志数据发送至数据分析装置；

数据分析装置，用于对所述服务调用日志数据进行分析，确定每一服务处理交易请求的当前服务性能数据；根据各服务处理交易请求的历史服务性能数据，确定每一服务处理交易请求的历史平均服务性能数据；

限流决策装置，用于定时读取所述当前服务性能数据和历史平均服务性能数据，将当前服务性能数据与历史平均服务性能数据进行比较，根据比较结果，生成当前时间段内处理交易请求的限流策略，将所述当前时间段内处理交易请求的限流策略发送至每一所述交易处理装置；

所述外部服务装置为弹性可扩展集群。

2.如权利要求1所述的交易限流装置，其特征在于，所述交易处理装置包括：

限流策略执行单元，用于根据当前时间段内处理交易请求的限流策略，为所述交易请求配置交易处理流程；

外部服务调用单元，用于根据配置的交易处理流程以及调用服务的预设重要程度，调用外部服务装置提供的服务处理当前交易请求；

服务监控单元，用于在服务调用完成后，将处理当前交易请求的服务处理日志数据写入服务调用日志数据中，将预设时长内的服务调用日志数据发送至数据分析装置。

3.如权利要求2所述的交易限流装置，其特征在于，所述限流策略执行单元具体用于在判断交易处理流程中调用的服务存在关键服务，所述关键服务为故障状态时，拒绝当前交易请求。

4.如权利要求2所述的交易限流装置，其特征在于，所述外部服务调用单元具体用于：

在判断交易处理流程中调用的服务为关键服务时，当根据限流策略判断需要对调用所述关键服务的请求进行限流时，将所述所述关键服务的请求加入关键服务的等待队列；

在判断交易处理流程中调用的服务为非关键服务时，当根据限流策略判断需要对调用所述非关键服务的请求进行限流时，跳过当前非关键服务的请求。

5.如权利要求1所述的交易限流装置，其特征在于，所述当前服务性能数据包括：服务处理交易请求的当前耗时；所述历史服务性能数据包括服务处理交易请求的历史平均耗时；

所述数据分析装置包括：

数据分析单元，用于对每个交易处理装置发来的服务调用日志数据进行分析，确定各服务处理交易请求的当前耗时；根据各服务处理交易请求的历史服务性能数据，确定每一服务处理交易请求的历史平均耗时；

分析结果存储单元，用于存储各服务处理交易请求的当前耗时和历史平均耗时；

限流策略存储单元，用于存储限流决策装置生成的限流策略；

所述当前耗时、历史平均耗时和限流策略供限流决策装置读取，以及作为历史服务性能数据存储。

6.如权利要求5所述的交易限流装置，其特征在于，所述限流决策装置包括：

限流策略生成单元，用于定时读取当前耗时和历史平均耗时，将当前耗时和历史平均耗时进行比较，根据比较结果，生成当前时间段内处理交易请求的限流策略；

限流策略分发单元，用于将所述当前时间段内处理交易请求的限流策略发送至每一所述交易处理装置。

7.如权利要求6所述的交易限流装置，其特征在于，所述限流策略包括：

若当前时间段内，服务处理交易请求的当前耗时超过历史平均耗时的200％，则将调用服务的请求加入所述服务的等待队列；

若当前时间段内，服务处理交易请求的当前耗时超过历史平均耗时的400％，则根据服务的负载情况，预测服务的性能趋势，若性能趋势为下降趋势，则将调用服务的请求加入所述服务的等待队列；若性能趋势为上升趋势，则拒绝调用服务的请求；

若当前时间段内，当前耗时超过历史平均耗时的500％，则拒绝调用服务的请求。

8.一种交易限流方法，其特征在于，包括：

根据当前时间段内处理交易请求的限流策略，调用外部服务装置提供的服务处理当前交易请求，将处理当前交易请求的服务处理日志数据写入服务调用日志数据中，将预设时长内的服务调用日志数据发送；

对所述服务调用日志数据进行分析，确定每一服务处理交易请求的当前服务性能数据；根据各服务处理交易请求的历史服务性能数据，确定每一服务处理交易请求的历史平均服务性能数据；

定时读取所述当前服务性能数据和历史平均服务性能数据，将当前服务性能数据与历史平均服务性能数据进行比较，根据比较结果，生成当前时间段内处理交易请求的限流策略，将所述当前时间段内处理交易请求的限流策略发送；

所述外部服务装置为弹性可扩展集群。

9.如权利要求8所述的交易限流方法，其特征在于，根据当前时间段内处理交易请求的限流策略，调用外部服务装置提供的服务处理当前交易请求，将处理当前交易请求的服务处理日志数据写入服务调用日志数据中，将预设时长内的服务调用日志数据发送，包括：

根据当前时间段内处理交易请求的限流策略，为所述交易请求配置交易处理流程；

根据配置的交易处理流程以及调用服务的预设重要程度，调用外部服务装置提供的服务处理当前交易请求；

在服务调用完成后，将处理当前交易请求的服务处理日志数据写入服务调用日志数据中，将预设时长内的服务调用日志数据发送。

10.如权利要求8所述的交易限流方法，其特征在于，所述当前服务性能数据包括：服务处理交易请求的当前耗时；所述历史服务性能数据包括服务处理交易请求的历史平均耗时；

对所述服务调用日志数据进行分析，确定每一服务处理交易请求的当前服务性能数据；根据各服务处理交易请求的历史服务性能数据，确定每一服务处理交易请求的历史平均服务性能数据，包括：

对每个交易处理装置发来的服务调用日志数据进行分析，确定各服务处理交易请求的当前耗时；根据各服务处理交易请求的历史服务性能数据，确定每一服务处理交易请求的历史平均耗时；

存储各服务处理交易请求的当前耗时和历史平均耗时；

存储限流决策装置生成的限流策略。

11.如权利要求10所述的交易限流方法，其特征在于，定时读取所述当前服务性能数据和历史平均服务性能数据，将当前服务性能数据与历史平均服务性能数据进行比较，根据比较结果，生成当前时间段内处理交易请求的限流策略，将所述当前时间段内处理交易请求的限流策略发送，包括：

定时读取当前耗时和历史平均耗时，将当前耗时和历史平均耗时进行比较，根据比较结果，生成当前时间段内处理交易请求的限流策略；

将所述当前时间段内处理交易请求的限流策略发送至每一所述交易处理装置。

12.一种交易系统，其特征在于，包括：

请求接入装置,用于接收支付机构的交易请求；

如权利要求1至7任一所述的交易限流装置；

外部服务装置，用于提供交易处理装置所需调用的服务；

所述服务包括：加解密服务、验证签名服务、上主机扣款服务、登记数据库服务、主机服务以及短信发送服务；所述外部服务装置为弹性可扩展集群。

13.如权利要求12所述的交易系统，其特征在于，所述请求接入装置包括：

心跳检测单元，用于检测各个交易处理装置的状态，确定出正常状态的交易处理装置；

报文转换单元，用于将接收到的交易请求转换为交易处理装置所需格式的交易请求；

负载均衡单元，用于根据负载均衡算法，将交易处理装置所需格式的交易请求发送至正常状态的交易处理装置。

14.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求8至11任一所述方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有执行权利要求8至11任一所述方法的计算机程序。