一种业务专线的决策方法、装置、设备和计算机可读介质
技术领域
本申请涉及计算机技术领域,尤其涉及一种业务专线的决策方法、装置、设备和计算机可读介质。
背景技术
在金融网络***中,业务专线可以用于各个金融机构之间的金融数据交换。其中,金融机构泛指从事金融活动的机构,例如网联、银联、各类银行、第三方支付机构、证券、基金、保险公司等等。在业务专线的使用过程中,可能出现由于各种原因导致的网络链路异常。例如,两个对手金融机构之间的专线链路,可能出现由于短时间内大量的业务流量等原因导致的网络链路堵塞。再例如,第三方支付机构与网联/银联之间的链路,可能出现由于其中一方的某机房***故障等原因而导致的专线异常。
通常,可以通过从日志中查询并分析业务专线的历史业务数据,来判断所述业务专线是否出现异常,然后对异常的专线进行剔除。在现有的基于日志采集的数据源的决策方法中,需要***将自身每一笔业务以日志的方式输出并存储,然后对日志进行解析、关联汇总、统计计算,在这一数据处理的过程中,数据会被写入外部的稳定的存储***,例如一个分布式文件***,这会导致大量的由于数据复制、磁盘I/O等产生的数据延时,使得当前的业务专线决策的时效性不高,通常为分钟级。然而,对于大型清算组织而言,决策的时效性至关重要。例如,一些大型清算组织与对手机构之间建立的业务专线,每分钟处理的业务总量会达到数百万级,每个业务专线处理的业务量也能达到十万级,若其中一个专线出现故障而不能及时发现,将在短时间内导致大量的业务异常。鉴于此,需要提供一种低延时、高时效的业务专线决策方案。
发明内容
有鉴于此,本申请实施例提供了一种业务专线的决策方法、装置、设备及计算机可读介质,用于提高业务专线决策的时效。
为解决上述技术问题,本说明书实施例是这样实现的:
本说明书实施例提供的一种业务专线的决策方法,包括:以预定时间间隔,基于消息中心获取业务专线在预定时间段内的业务统计信息,所述预定时间间隔小于第一时长,所述预定时间段小于第二时长,所述消息中心用于缓存业务专线的业务信息;根据所述业务统计信息,计算业务指标信息;基于所述业务指标信息和预设的业务指标阈值,确定所述业务专线的状态信息;根据所述业务专线的状态信息,对所述业务专线进行决策。
本说明书实施例提供的一种业务专线的决策装置,包括:获取模块,用于以预定时间间隔,基于消息中心获取业务专线在预定时间段内的业务统计信息,所述预定时间间隔小于第一时长,所述预定时间段小于第二时长,所述消息中心用于缓存业务专线的业务信息;计算模块,用于根据所述业务统计信息,计算业务指标信息;判定模块,用于基于所述业务指标信息和预设的业务指标阈值,确定所述业务专线的状态信息;决策模块,用于根据所述业务专线的状态信息,对所述业务专线进行决策。
本说明书实施例提供的一种业务专线的决策设备,包括:
至少一个处理器;以及,
与所述至少一个处理器通信连接的存储器;其中,
所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够:
以预定时间间隔,基于消息中心获取业务专线在预定时间段内的业务统计信息,所述预定时间间隔小于第一时长,所述预定时间段小于第二时长,所述消息中心用于缓存业务专线的业务信息;根据所述业务统计信息,计算业务指标信息;基于所述业务指标信息和预设的业务指标阈值,确定所述业务专线的状态信息;根据所述业务专线的状态信息,对所述业务专线进行决策。
本说明书实施例提供的一种计算机可读介质,其上存储有计算机可读指令,所述计算机可读指令可被处理器执行以实现上述业务专线的决策方法。
本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果:
提供了一种业务专线的决策方法,首先以小于第一时长的预定时间间隔基于消息中心获取业务专线在小于第二时长的预定时间段内的业务统计信息,并根据所述业务统计信息计算业务指标信息,然后基于所述业务统计信息和预设的指标阈值来确定所述业务专线的状态信息,最后基于该状态信息来对所述业务专线进行决策。基于该方案,通过消息中心来实时数据采集而非基于日志的数据采集***来进行数据采集,与传统业务专线决策方法相比,避免在使用日志数据采集过程中由于数据复制、磁盘I/O等导致的延时,提高了业务专线决策的时效性。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1示出了根据实施例的业务专线的决策方法的流程示意图;
图2示出了根据实施例的业务专线决策方法的决策流程的示意图;
图3示出了根据实施例的业务专线决策方法的决策链路的示意图;
图4示出了根据实施例的业务专线的决策装置的结构示意图;
图5示出了根据实施例的业务专线的决策设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
以下结合附图,详细说明本申请各实施例提供的技术方案。
图1示出了根据实施例的业务专线的决策方法的流程示意图。从程序角度而言,流程的执行主体可以为搭载于应用服务器的程序或应用客户端。
如图1所示,该流程可以包括以下步骤:
S110:以预定时间间隔,基于消息中心获取业务专线在预定时间段内的业务统计信息,所述预定时间间隔小于第一时长,所述预定时间段小于第二时长,所述消息中心用于缓存业务专线的业务信息。
其中,业务专线是指用于进行数据网络传输的专用链路,以使得用户数据的传输安全可靠,在两个终端和/或服务器之间可以设置多个业务专线。通常,为了增强业务的负载能力和稳定性,在指定的两个或多个节点之间会设置多条业务专线,例如,在银行机构与第三方支付机构之间可以设置多条业务专线,用于银行机构与第三方支付机构之间的各类信息的传递,例如进行支付、退款、查询等业务处理等。
其中,业务统计信息反映了在业务专线上进行的业务情况的统计信息。例如,业务统计信息包括业务专线上在预定时间段内的业务请求数量信息、***成功/失败数量信息、通信成功/失败数量信息等,但是不限于此。
其中,消息中心可以是用于缓存业务专线的业务信息的设备,具体地,基于消息中心中获取业务统计信息具体可以指基于实时数据采集数据源来得到业务统计信息。根据实施例,基于消息中心获取业务统计信息的实现方式可以如下:对于某业务专线,定期收集使用该业务专线进行数据传输的每台应用在预定时间段内的单台业务统计信息并发送至消息中心,再基于消息中心中的各个单台业务统计信息汇总得到该业务专线在预定时间段内的总的业务统计信息,然后以预定时间间隔对前述统计的预定时间段的业务统计信息进行查询。
其中,所述预设时间间隔可以是指一定的频率来获取业务统计信息,所述预设时间间隔可以小于第一时长,所述第一时长可以不大于60秒,更优地,可以不大于20s,更优地,可以不大于10s。例如,可以每3s查询一次业务专线的业务统计信息。其中,所述预定时间段可以是当前时刻之前的最近一段时间,所述预定时间段可以小于第二时长,所述第二时长可以不大于60秒,更优地,可以不大于20s,更优地,可以不大于10s。例如,每次统计的业务统计信息可以是基于当前时刻的前5s内的业务数据的统计信息。其中,第一时长和第二时长可以相同或不同。预设时间间隔的时长与预定时间段的时长可以相同或不同。例如,预设时间间隔可以是2s-3s,预设时间段的时长可以是5s-10s。
在此提供以基于日志数据来作为备用数据源的方案,确保了在无法从单数据源正常获取数据的情况下,整个业务专线决策***的可用性,提高了***的稳定性。
S120:根据所述业务统计信息,计算业务指标信息。
其中,业务指标信息可以表示基于业务统计信息计算的指标,可以用于表示业务专线的状态。根据实施例,业务指标信息可以包括单位时间内业务请求数量信息、单位时间内***成功率/失败率、单位时间内通信成功率/失败率等,但是不限于此。其中,单位时间可以是指每秒时间,即业务指标可以是秒级指标。
根据实施例,所述根据所述业务统计信息计算业务指标信息之前,还可以包括:校验所述业务统计信息是否符合业务指标信息计算条件,得到第一校验结果;若所述第一校验结果为否,则退出本次决策过程;所述根据所述业务统计信息计算业务指标信息,具体包括,若所述第一校验结果为是,则根据所述业务统计信息计算业务指标信息。
根据实施例,所述校验所述业务统计信息是否符合业务指标信息计算条件,具体可以包括:校验是否获取到所需的全部业务统计信息。例如,当业务专线上在预定时间段内的业务请求数量信息、***成功/失败数量信息、通信成功/失败数量信息这三者全部获取到时,认为完整性校验通过,第一校验结果为是,可以使用获取的上述业务统计信息来计算业务指标信息。例如,当前述三类数据中的至少一者无法获取到时,或者其中获取到的业务请求数量信息为零时,则认为完整性校验不通过,第一校验结果为否,则不再继续进行指标计算,直接退出本次决策过程。
S130:基于所述业务指标信息和预设的业务指标阈值,确定所述业务专线的状态信息。
其中,所述预设的业务指标阈值可以用来与所述业务指标信息进行对比,根据对比结果,以得到相应的业务专线的状态信息。业务指标阈值可以表示该业务专线在正常使用状态下的运行参数。
根据实施例,所述业务指标阈值可以是根据业务专线的历史业务统计信息进行计算得到的,也可以是根据经验设定的。需要说明的是,无论在哪种情况下,该用于进行异常判定的业务指标阈值均是预设的。即使当业务指标阈值是根据历史数据计算得到的情况下,该业务指标阈值是提前进行离线计算得到并存储的,而不是在实时决策的过程中实时计算的。这样的设置使得,可以避免由于指标阈值的计算导致的决策链路的不必要的延时、提高决策链路的时效。
S140:根据所述业务专线的状态信息,对所述业务专线进行决策。
其中,所述状态信息可以表示所述业务专线为正常状态或异常状态。其中,对所述业务专线进行决策可以包括当业务专线为正常状态时,不对所述业务专线执行任何操作;当所述业务专线为异常状态时,对所述业务专线执行剔除操作和/或执行针对所述业务专线的告警通知。
其中,对所述专线进行剔除是指交易不再通过此专线到达对手机构。例如,若第三方支付机构与网联之间有N条业务专线,在数据对等分配的情况下,每条专线承载1/N的业务量,若剔除了其中的一条业务专线,则由剩余的N-1条业务专线来承载所有的业务,在在数据对等分配的情况下,每条专线承载1/(N-1)的业务量。
根据可选的实施例,所述根据所述业务专线的状态信息对所述业务专线进行决策,具体包括:若所述业务专线的状态信息表示所述业务专线为异常状态,则判断所述业务专线是否满足专线剔除条件;若满足所述专线剔除条件,对所述业务专线进行剔除操作。
根据实施例,所述专线剔除条件可以包括例如,至少预订数量的专线可以使用、至少预定比例的专线可以使用、在同一区域范围内至少预定数量的专线可以使用、在同一区域范围内至少预定比例的专线可以使用等条件,但是不限于此。
在该实施例中,当所述业务专线异常时,不是直接进行剔除操作,而是仅在满足预定的专线剔除条件的情况下才执行剔除操作,即,基于当前机构所有专线的配置情况,进行风险防控,以保证处于可使用状态的专线的最少量,以确保业务***的整体稳定可用性。
另外,根据实施例,可以针对判断为异常的业务专线,向开发维护人员等发送告警通知,以便维护人员对异常业务专线进行人工干预。
根据上述一个或更多个实施例,提供了一种业务专线的决策方法。现有方案主要采用分钟级监控/决策能力,耗时较长,本申请提供的方案中,通过基于消息中心实时数据采集数据源而非基于日志数据汇总数据源来获取业务专线的指标信息,数据延时低,提高了秒级决策的时效性。另外,在对异常专线执行剔除之前,进行剔除条件判断,保证了最少量的业务专线量,避免由于业务专线数量过少等原因导致的相关业务信息无法传输。
在上述实施例的基础上,本申请还提供了以下改进的业务专线决策方法的实施方案。
根据可选的实施例,所述业务专线的决策方法,还包括:当S110的基于消息中心获取业务专线的业务统计信息失败时,可选地,可以基于业务专线的日志数据来获取业务专线的业务统计信息。其中,获取日志数据具体可以采用基于日志分析的以业务为核心的监控平台,例如XFLUSH平台。这里,基于***日志数据采集数据源来获取业务统计信息的数据延迟约为30s,而前述实时数据采集数据源来获取数据的方式的数据延迟约为5s,因此,本申请的业务专线的决策方法默认采用基于消息中心的实时数据采集***,仅当实时数据采集***故障时,才采用基于***日志作为数据源。
在该实施例中,提供了使用***日志作为备用数据源,当实时数据数据源不可用时,自动切换至日志数据数据源,保证决策***模型的正常运行,保证决策方案的正常实施例,提高了决策***的稳定性。
根据可选的实施例,S130中,预设的指标阈值可以是根据所述业务专线的历史业务信息预先计算的基线阈值。具体地,可以在S110之前计算所述基线阈值。具体地,获取业务专线在按照预定规则选择的日期内预定时间段的历史业务统计信息;基于所述历史业务统计信息,计算所述业务专线与所述预定时间段对应的基线阈值。
其中,所述历史业务统计信息可以包括历史业务请求数量信息、历史***成功/失败数量信息、历史通信成功/失败数量信息等,但是不限于此。其中,根据所述历史业务统计信息计算的基线阈值可以包括单位时间的总业务量基线阈值、***成功数基线阈值、***成功率基线阈值、通信成功率基线阈值等,但是不限于此。
其中,所述按照预定规则选择的日期可以为例如在当前日期之前的按照一定规则选取的若干天数。其中,基线阈值的计算可以以例如1分钟作为时间窗口,统计计算前述选择的日期内每天相同一分钟内历史业务统计信息数据分布的基线,然后将其作为待决策日对应该分钟内的业务统计信息的基线阈值。例如,判断某业务专线在今天10:00:00-10:01:00这一时段的业务指标是否异常,可以基于该业务专线的在选择的历史日期内每天的10:00:00-10:01:00这一时间段的历史业务统计信息计算的基线阈值作为业务指标阈值来判断。再例如,判断某业务专线在今天10:00:00-10:00:05、10:00:10-10:00:15、10:00:20-10:00:22等任一时段的秒级业务指标是否异常,用于判断的业务指标阈值,可以是基于该业务专线的在选择的历史日期内每天的10:00:00-10:01:00这一时间段的历史业务统计信息计算的基线阈值。
根据实施例,S130中,所述基于所述业务指标信息和预设的业务指标阈值确定所述业务专线的状态信息,具体可以包括:获取所述业务专线的与所述预定时间段对应的基线阈值;基于所述基线阈值,判断所述业务指标信息是否满足第一判定条件;若满足所述第一判定条件,将所述业务专线的状态信息确定为异常状态。
其中,所述第一判定条件是以所述基线阈值作为参数的判定条件。作为示例,第一判定条件可以是TPS>=TPS_THRESHOLD&&(CSS<=CSS_BASELINE||(SYS_TSSY<=SYS_TSSY_BASELINE&&SYS_TSS<=SYS_TSS_BASELINE)),其中,TPS表示每秒交易请求数量,TPS_THRESHOLD表示,CSS表示每秒通信成功率,CSS_BASELINE表示通信成功率基线阈值,SYS_TSSY表示每秒***成功数,SYS_TSSY_BASELINE表示每秒***成功数基线阈值,SYS_TSS表示每秒***成功率,SYS_TSS_BASELINE表示每秒***成功率基线阈值,若满足该判定条件,则专线异常。
在该实施例中,所述与预定时间段对应的基线阈值可以是提前计算的,而不是实时计算的,这避免了在进行异常判断时不必要的数据延迟。另外,基于历史业务统计信息计算的基线阈值实质上是一个预测值,并且是对应的业务专线在对应的时间段内的预测值,与传统的判定方法中利用固定的值进行判定的方式相比,判断更准确,对专线异常情况的识别更敏感。
根据实施例,所述基于所述基线阈值判断所述业务指标信息是否满足第一判定条件之前,还可以包括:校验是否获取到所需的全部基线阈值,得到第二校验结果;若所述第二校验结果为否,则基于经验阈值判断所述业务指标信息是否满足第二判定条件;若满足所述第二判定条件,将所述业务专线的状态信息确定为异常状态;所述基于所述基线阈值判断所述业务指标信息是否满足第一判定条件,具体包括,若所述第二校验结果为是,则基于所述基线阈值,判断所述业务指标信息是否满足第一判定条件。
具体地,校验是否获取到所需的全部基线阈值,可以是,校验是否获取到例如对应时间的历史业务请求数量信息、历史***成功/失败数量信息、历史通信成功/失败数量信息三者中的全部。例如,若仅获取到前述三者中的一部分,或者历史业务请求数量信息为零,则完整性校验不通过。
具体地,在完整性校验不通过的情况下,将判定方法切换为使用经验阈值作为指标阈值来进行判定。其中,经验阈值可以是预先设定的阈值信息,作为示例,每秒业务请求数量信息的经验阈值可以为30,每秒***成功率的经验阈值可以为60%,每秒通信成功率的经验阈值可以为50%。具体地,第二判定条件可以是以经验阈值作为参数的判定条件。基于前述示例,第二判定条件可以是TPS>=30&&(CSS<60%||SYS_TSS<50%),若满足该条件,则认为业务专线异常。
在上述实施例中,使用基于历史业务统计数据计算的基线阈值来与业务专线的对应时间段的指标信息比较得到判定信息,该基线阈值由于是根据对应时间段的历史数据计算得到的,使得判定结果更准确可靠,对于专线异常的判定也更敏感。另外,使用经验阈值作为备用的指标阈值,采用基线阈值判定与经验阈值判定的双保险,以确保在保证业务效果的前提下,精准快速识别业务专线的异常。
在业务专线进行数据传输过程中,可能发生由于网络等原因导致的数据链路抖动,例如,按照一定时间顺序进行的业务,先发送的业务的处理回执可能会因数据抖动而晚于后发送的业务的处理回执,或者按照第一时间间隔发送的两个业务请求,其收到的处理回执之间的第二时间间隔不同于第一时间间隔。进行业务专线的秒级决策,需要解决在秒级环境下,数据抖动偏差增大的问题。
根据可选的实施例,所述校验所述业务统计信息是否符合业务指标信息计算条件,得到第一校验结果,还可以包括:校验所述业务统计信息对应的统计时段是否满足预定的时间范围,得到第一校验结果。具体地,若所述第一校验结果为否,则退出本次决策过程;若所述第一校验结果为是,则根据所述业务统计信息计算业务指标信息。
具体地,在使用业务统计信息计算业务指标信息之前,还需要校验所述业务指标信息是否满足一定的数据抖动阈值条件,即校验所述业务统计信息对应的统计时段是否在预定的时间范围内。更具体地,例如,若业务统计信息中的业务总量统计信息的对应统计时段与业务成败统计信息的对应统计时段之间的偏差小于预定阈值,则可以使用二者来计算业务成败率。例如,若业务统计信息中的业务总量统计信息的对应统计时段与通信成败统计信息的对应统计时段之间的偏差小于预定阈值,则可以使用二者来计算通信成败率。例如,所述的预定阈值可以是30s,即,当获取的两个或更多个业务统计信息对应的实际统计时段的彼此间的偏差不大于30s时,可以无需进行数据对齐,可以直接使用所述获取的两个或更多个业务统计信息来计算业务指标信息。
根据实施例,根据所述业务统计信息计算业务指标信息,具体包括:采用第一时间段的业务成败统计信息和第二时间段的业务总量统计信息,计算所述预定时间段的业务成功率,其中,所述第一时间段与所述预定时间段以及所述第二时间段与所述预定时间段的时间偏差均不大于第三时长。其中,所述第三时长可以为30s,可选地,所述第三时长可以为20s,可选地,所述第三时长可以为10s,可选地,所述第三时长可以为5s,但是不限于此。
具体地,例如,待决策的是业务专线在10:00:30-10:00:35这段时间的状态,理想的情况是获取到10:00:30-10:00:35这一时段的例如业务总量统计信息和业务成败统计信息,并利用二者来计算在10:00:30-10:00:35这一时段的***成败率。然而,由于数据抖动等原因,可能无法准确统计到10:00:30-10:00:35这一时段的业务统计信息,此时,需要判断实际获取的业务统计信息对应的业务数据的实际时间段,若实际统计时段与预定统计时段之间的偏差不大于预定的第三时长时,可以直接使用获取的所述实际统计时段进行业务指标的计算。例如,若所述第三时长为30s,则当实际获取的业务统计信息对应的时间段处于10:00:00-10:01:05这一段时间中,例如10:00:00-10:00:05、10:00:13-10:00:18、10:00:40-10:00:45等时间段内对应的业务统计信息均可以用于计算待决策的10:00:30-10:00:35这一时段的业务指标。
当出现数据抖动,但是数据抖动偏差满足预定的阈值范围的情况下,对业务指标数据的准确性影响不大,此时可以不进行数据对齐的操作,直接使用满足预定偏差的业务统计数据来计算业务指标数据,提高了专线决策的时效。
为了进一步减少在秒级决策情景中数据抖动导致的对决策结果的影响,本申请使用下述改进的数据处理方法来计算业务指标信息。
根据可选的实施例,所述根据所述业务统计信息计算业务指标信息,具体可以包括:根据业务异常量统计信息和业务总量统计信息,通过下式计算业务成功率信息:业务成功率信息=(业务总量统计信息-业务异常量统计信息)/业务总量统计信息。
具体地,当所述业务数量信息包括每秒业务总数和每秒通信失败数时,可以通过下式计算每秒通信成功率:每秒通信成功率=(每秒业务总数-每秒通信失败数)/每秒业务总数。当所述业务数量信息包括每秒业务总数和每秒***失败数,可以通过下式计算每秒***成功率:每秒***成功率=(每秒业务总数-每秒***失败数)/每秒业务总数。
实际业务场景中,例如在晚上有很多批处理任务的情况下,交易曲线会出现陡增或陡降的场景,例如,单位时间交易量在上一秒为2000笔/秒,在下一秒为100笔/秒。在容忍一定的数据抖动偏差(例如,30s)的情况下,假设作为分母的业务交易量数据点在00:00:25~00:00:30,而作为分子的交易成功量数据点在00:00:00~00:00:05,那么在计算成功率过程中,数据错位将会导致决策值不准确,进而造成误决策。更具体地,假设在00:00:00~00:00:05的真实业务交易量为10000笔,其中交易成功数9980笔,交易失败数为20笔;假设在00:00:25~00:00:30的真实业务交易量为500笔,其中交易成功数为499笔,交易失败数为1笔;那么,在00:00:00~00:00:05和00:00:25~00:00:30时的真实交易成功率均为499/500(0.9998)。若根据成功数来计算,假设出现数据抖动,实际获取到的是00:00:00~00:00:05的业务交易量和00:00:25~00:00:30的交易成功数,那么,计算得到的交易成功率为499/10000=0.0499,显然与真实的交易成功率0.9998相差较大,可能会导致误决策。而根据本申请的方案,根据失败数来计算,假设出现数据抖动,实际获取的是00:00:00~00:00:05的业务交易量和00:00:25~00:00:30的交易失败数,那么,计算得到的交易成功率为(10000-1)/10000=9999/10000=0.9999,与真实的交易成功率0.9998相差较小,可以有效避免数据抖动导致的误决策。
在该实施例中,基于***失败数而不是***成功数来计算***成功率,基于通信失败数而不是通信成功数来计算***成功率,可以在一定程度上降低数据抖动对计算的决策指标的准确性的影响,有效解决了秒级环境下数据抖动偏差增大的问题。
基于上述实施例,可以在获取的数据满足预定偏差阈值的情况下不进行数据对齐而直接将数据用于计算指标,同时利用失败数而非成功数来计算指标,二者结合,既大大提高了秒级情形下的决策时效、同时有有效解决了秒级情形下的数据抖动,在秒级环境下做到了误差与时效的平衡。
综合上述一个或更多个实施例,本申请提供的业务专线的决策方法,可以实现低延时(例如,30s内)的数据收集、异常识别并精准做出***决策;同时,使用多数据源、多指标阈值,全方位确保决策方案的稳定运行。
图2示出了根据实施例的业务专线决策方法的决策流程的示意图,以更清楚地描述本申请的方案。如图2所示,业务专线决策方法的决策流程可以包括以下四个阶段:第一阶段,待决策业务专线的配置获取及统计信息获取阶段;第二阶段,数据完整性校验阶段;第三阶段,业务专线异常判定阶段;第四阶段,业务专线决策剔除阶段。
第一阶段包括获取关键配置信息和当前专线相关数据。一方面,可以获取待决策的业务专线的配置列表信息,所述配置列表信息可以包括待决策的业务专线标识、每条专线的权重,还可以包括每条专线的区域信息、地址信息等。其中,所述权重信息可以包括该专线承载的交易量分流比例,例如,在总共有N条专线的情况下,M1*L1+M2*L2+......+Mn*Ln表示总的交易量信息,其中,Ln表示第n条专线的分流情况,专线正常使用为1,专线异常为0;其中,Mn表示第n条专线的权重信息,当业务信息在所有的业务主线中平均分配的情况下,M1=M2=……=Mn=1/N,但是不限于此。根据实施例,可以以预定的周期定期遍历所有的业务专线,以查询所有的业务专线最新的配置列表,其中,包括该业务专线最新的分流和权重信息。所述预定的周期可以是例如每20s、每30s、每60s,在此不做具体限定。
另一方面,第一阶段在前述获取专线当前配置信息的基础上,对于分流信息不为0的专线,可以获取待决策的业务专线的秒级统计信息,其中,信息的获取可以使用双数据源,优选实时数据采集数据源,在实时数据采集数据源故障的情况下备选***日志数据数据源,其中当实时数据采集的数据丢失率达到一定阈值(例如,约20%、约30%等,此阈值根据历史数据计算得到或者根据经验设定)时,则执行数据源的自动切换。其中,获取的业务统计信息可以指单位时间的业务统计信息,例如,每秒的业务统计信息,更具体地,可以包括专线每秒总交易量、专线每秒***交易失败数和专线每秒***通信失败数,但是不限于此。其中,每个业务统计信息的对应的统计时段可以选为最近5s、最近10s等,通常不大于最近60s。
第二阶段主要对获取的秒级统计数据、基线阈值进行完整性校验并根据校验结果进行后续操作。一方面,对获取的专线业务统计信息的完整性进行校验,例如,当获取的秒级数据中每秒交易请求数量、每秒***失败数、每秒通信失败数三者中的至少一者缺失时,认为完整性校验不通过,异常退出本次决策过程;例如,当获取的每秒交易请求数量为零时,也认为完整性校验不通过,异常退出本次决策过程。除此之外,还要校验获取的专线业务统计信息的时间偏差是否满足预定偏差阈值,若不满足,则认为校验不通过,异常退出本次决策过程。例如,预定偏差阈值可以是综合评估时效和误差率得到的结果,例如,可以为30s。例如,预期获取的数据是00:00:15~00:00:20的数据指标,但是实际取得的数据是00:00:00~00:00:05,在预定偏差阈值内,即在可接受的误差范围内,校验通过。在此需要说明的是,在实际获取的数据满足预定偏差阈值的情况下,无需进行数据对齐操作,可以直接使用实际获取的业务统计信息来计算业务指标信息。如果要求将获取的数据完全对齐,所有参与指标计算的统计数据均需要根据同步时效最差的统计数据来确定,导致整体的决策链路时间延长。本申请提供的方案,通过设定预定偏差阈值、可以直接使用一定偏差范围内的获取的数据,使得在准确的前提下,提高了决策的时效。
另一方面,第二阶段校验获取的基线阈值的完整性。具体地,可以获取业务专线的在按照预定规则选择的日期内预定时间段的历史业务统计信息,然后基于所述历史业务统计信息计算所述业务专线的与所述预定时间段对应的基线阈值。其中,对基线阈值的计算可以采用例如3-sigma算法模型来计算,但是不限于此,也可以使用本领域已知的可用于基于历史数据来计算基线阈值的其他方法。其中,所述基线阈值可以包括通信成功率基线阈值、***成功率基线阈值、交易量基线阈值、***成功量基线阈值等。
第三阶段,可以采取选定的判定方法对业务专线进行判定。具体地,在成功获取到基线阈值的情况下,则使用基线阈值进行判定。在未取得基线阈值的情况下,则切换为使用经验阈值进行判定,例如,所述经验阈值中的通信成功率阈值可以为0.5、***成功率阈值可以为0.5、交易量阈值可以为30。
第四阶段,可以对异常专线进行是否剔除的判断,并根据判断结果进行剔除和/或告警操作。具体地,根据前述第一阶段中获取的所有业务专线的配置情况,进行风险防控,若异常专线占总数的比例超出预定比例阈值,则不剔除当前被判断为异常的专线,可选地,可以进行告警;若异常专线占总数的比例未超出预定比例阈值,则对当前被判断为异常的专线进行剔除。作为示例,所述预定比例阈值可以是50%,但是不限于此。另外,待剔除的专线可以被添加到自动剔除队列中等待自动剔除,也可以发送至维护人员进行手动剔除。
图3示出了根据实施例的业务专线决策方法的决策链路的示意图,以更清楚地描述本申请的方案。
如图3所示,其中的实时决策链路是实时进行业务异常识别和决策的平台。可以定期调度该实时决策链路以对业务专线进行决策。具体地,首先查询业务专线的配置信息,包括当前机构的业务专线分流比例等信息;然后查询业务专线的业务统计信息和指标阈值信息,其中,业务统计信息可以通过实时数据采集数据源来获取,备选地,可以通过***日志采集数据源来获取,其中,指标阈值信息可以是通过离线计算链路得到的基线阈值信息,备选地,可以使用经验阈值信息作为指标阈值信息;再基于获取的业务统计信息计算业务指标信息,然后结合业务指标阈值信息进行专线是否异常的判断,其中,在计算业务指标信息时使用***/通信失败信息而非***/通信成功数信息,以减少数据抖动对计算结果的影响;最后,将决策结果发送至决策平台,由决策平台根据决策管理预案决定是否进行专线剔除和/或监控告警操作。根据上述实时决策链路得到的专线决策结果,来管理专线的业务承载比例。例如,若决策结果为进行专线剔除,即该被决策专线不再承载业务,可以重新配置各个业务专线的分流比例,并通过例如超级网关来按照比例将业务发送至对应的专线。例如,第三方交易机构与网联/银联之间共有10条专线,在对等分配的情况下,每条专线都承载1/10的交易量,若剔除其中1条异常专线,则剩余每条专线承载的交易量为1/9。
如图3中所示,通过离线计算链路来预先计算用来进行异常判定的基线阈值。具体地,可以定期调用离线基线阈值计算模型,并查询业务专线的历史业务数据;然后根据业务专线的历史业务统计数据,计算出相应的基线阈值,并存储该基线阈值以备实时决策链路使用。具体地,以按照预定规则选择的历史日期内的目标时间段内的业务统计信息为基础,计算基线阈值,以作为未来日期内目标时间段内的业务统计信息的预测值。例如,可以统计当前日期之前1天、2天、3天、7天、14天、21天、30天中每天的00:00:00-06:00:00这一时段内每分钟的承载交易量、通信失败量、***失败量等信息,计算得到该时段00:00:00-06:00:00的承载交易量、通信失败量、***失败量等信息的基线阈值,作为今天该时段00:00:00-06:00:00的预测值。在此例中,计算的目标时段的长度为6小时,在这种情况下,可以每隔6小时计算一次基线阈值;但是此处仅作为示例示出,目标时段的长度可以是根据需要任意设定的,例如可以为2小时,那么可以每个2小时计算一次基线阈值。另外,为了确保基线阈值能够准确地反映业务专线的最新的业务处理状态,进而确保基于基线阈值的决策的准确性,每次使用的基线阈值均是新计算的基线阈值,即,对明天的某一时间段内业务数据进行异常判断所使用的基线阈值,与对今天的同一时间段内业务数据进行异常判断所使用的基线阈值不同,前者是更新后的基线阈值。
基于同样的思路,本说明书实施例还提供了上述方法对应的装置。图4示出了根据实施例的业务专线的决策装置的结构示意图。
如图4所示,该装置可以包括:
获取模块410,用于以预定时间间隔,基于消息中心获取业务专线在预定时间段内的业务统计信息,所述预定时间间隔小于第一时长,所述预定时间段小于第二时长,所述消息中心用于缓存业务专线的业务信息;
计算模块420,用于根据所述业务统计信息,计算业务指标信息;
判定模块430,用于基于所述业务指标信息和预设的业务指标阈值,确定所述业务专线的状态信息;
决策模块440,用于根据所述业务专线的状态信息,对所述业务专线进行决策。
根据实施例,所述获取模块410,还用于当基于消息中心获取业务专线的业务统计信息失败时,则基于业务专线的日志数据来获取业务专线的业务统计信息。
根据实施例,所述计算模块420,具体包括:第一校验单元,用于在根据所述业务统计信息计算业务指标信息之前,校验所述业务统计信息是否符合业务指标信息计算条件,得到第一校验结果;第一执行单元,用于若所述第一校验结果为否,则退出本次决策过程,若若所述第一校验结果为是,则根据所述业务统计信息计算业务指标信息。
根据实施例,所述第一执行单元,具体用于:若所述第一校验结果为是,则采用第一时间段的业务成败统计信息和第二时间段的业务总量统计信息,计算所述预定时间段的业务成功率,其中,所述第一时间段与所述预定时间段以及所述第二时间段与所述预定时间段的时间偏差均不大于第三时长。
根据实施例,所述计算模块420,具体用于:根据业务异常量统计信息和业务总量统计信息,通过下式计算业务成功率信息:业务成功率信息=(业务总量统计信息-业务异常量统计信息)/业务总量统计信息。
根据实施例,所述判定模块430包括:阈值获取单元,用于获取所述业务专线的与所述预定时间段对应的基线阈值,其中,根据所述业务专线的历史业务信息预先计算的基线阈值作为预设的指标阈值;第二校验单元,用于校验是否获取到所需的全部基线阈值,得到第二校验结果;第二执行单元,用于若所述第二校验结果为是,则基于所述基线阈值作为指标阈值来判断所述业务指标信息是否满足第一判定条件,若所述第二校验结果为否,则基于经验阈值作为指标阈值来判断所述业务指标信息是否满足第二判定条件。
根据实施例,所述决策模块440包括:第三校验单元,用于当所述业务专线的状态信息表示所述业务专线为异常状态时,判断所述业务专线是否满足专线剔除条件;第三执行单元,用于若满足专线剔除条件,则对所述业务专线进行剔除操作。
可以理解,上述的各模块是指计算机程序或者程序段,用于执行某一项或多项特定的功能。此外,上述各模块的区分并不代表实际的程序代码也必须是分开的。
基于同样的思路,本说明书实施例还提供了上述方法对应的设备。
图5示出了根据实施例的业务专线的决策设备的结构示意图。如图5所示,设备500可以包括:
至少一个处理器510;以及,
与所述至少一个处理器通信连接的存储器530;其中,
所述存储器530存储有可被所述至少一个处理器510执行的指令520,所述指令被所述至少一个处理器510执行,以使所述至少一个处理器510能够:以预定时间间隔,基于消息中心获取业务专线在预定时间段内的业务统计信息,所述预定时间间隔小于第一时长,所述预定时间段小于第二时长,所述消息中心用于缓存业务专线的业务信息;根据所述业务统计信息,计算业务指标信息;基于所述业务指标信息和预设的业务指标阈值,确定所述业务专线的状态信息;根据所述业务专线的状态信息,对所述业务专线进行决策。
基于同样的思路,本说明书实施例还提供了上述方法对应的计算机可读介质。该计算机可读介质上存储有计算机可读指令,所述计算机可读指令可被处理器执行以实现上面任一实施例中所述的业务专线的决策方法。
上述对本说明书特定实施例进行了描述,在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置、设备实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本说明书实施例提供的装置、设备与方法是对应的,因此,装置、设备也具有与对应方法类似的有益技术效果,由于上面已经对方法的有益技术效果进行了详细说明,因此,这里不再赘述对应装置、设备的有益技术效果。
在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray,FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字***“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等,目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的***、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本发明的实施例可提供为方法、***、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于***实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。