CN113971608A - 交易渠道的管理方法以及装置 - Google Patents

Abstract

本发明涉及一种交易渠道的管理方法以及装置，其中方法包括：监听交易渠道在接收到交易渠道调用方发送的交易请求后生成的通知消息；根据通知消息以及交易渠道的当前渠道状态统计交易渠道的交易请求数据；判断交易请求数据是否满足变更当前渠道状态的预设条件；若满足预设条件，则将当前渠道状态变更为预设条件对应的预设状态，通过对当前渠道状态的变更，不仅能够在交易渠道故障时避免后续的交易请求再次通过此交易渠道造成的交易请求处理时间较长，也能够在交易渠道正常时避免造成其他交易渠道的较大的压力。

Description

交易渠道的管理方法以及装置

技术领域

本发明涉及互联网技术领域，特别涉及一种交易渠道的管理方法以及装置。

背景技术

随着互联网领域的快速发展，互联网购物已经成为人们常用的购物方式，在互联网购物中，用户对某一购物网站下单而后在交易系统中进行支付。

目前，绝大部分的交易系统均会接入多个交易渠道，当某一交易渠道出现异常时，若继续发起交易请求，可能会导致支付失败或出现长时间等待，用户体验较差，因此，如何对交易渠道进行管理，从而能够及时发现状态异常的交易渠道是亟需解决的问题。

发明内容

为解决上述技术问题，本发明提供了一种交易渠道的管理方法以及装置，具体方案如下：

第一方面，提供了一种交易渠道的管理方法，应用于智能路由中，所述方法包括：监听交易渠道在接收到交易渠道调用方发送的交易请求后生成的通知消息；根据所述通知消息以及所述交易渠道的当前渠道状态统计所述交易渠道的交易请求数据；判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件；若满足所述预设条件，则将所述当前渠道状态变更为所述预设条件对应的预设状态。

在一个较佳的实施方式中，所述根据所述通知消息以及所述交易渠道的当前渠道状态统计所述交易渠道的交易请求数据包括：若所述当前渠道状态为正常状态，则根据所述通知消息的数量以及所述通知消息中的交易结果统计正常交易总请求数，正常交易成功请求数，正常交易连续失败请求数以及连续失败请求时间；若所述当前渠道状态为半开闭状态，则所述根据通知消息的数量以及所述通知消息中的交易结果统计半开闭交易总请求数，半开闭交易成功请求数以及半开闭交易失败请求数。

在一个较佳的实施方式中，若所述当前渠道状态为所述正常状态，所述方法还包括：若所述交易渠道的接口模式为同步模式，则根据所述通知消息的数量确定正所述正常交易总请求数，根据所述通知消息中的交易结果确定所述正常交易成功请求数，所述正常交易连续失败请求数以及所述正常交易连续失败持续时间；若所述交易渠道的接口模式为异步模式，则所述根据通知消息中受理类通知消息的数量统计所述正常交易总请求数，根据结果类通知消息中的交易结果确定所述正常交易成功请求数，所述正常交易连续失败请求数以及所述正常交易连续失败持续时间。

在一个较佳的实施方式中，若所述当前渠道状态为所述正常状态，则所述判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件之前还包括：根据所述正常交易总请求数与所述正常交易成功请求数确定交易渠道的失败率；若所述交易渠道的接口模式为同步模式，则所述判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件为：判断失败率是否满足第一预设熔断条件或所述交易请求数据是否满足第二预设熔断条件；其中，所述第一预设熔断条件以及所述第二预设熔断条件用于触发智能路由的熔断器开启，从而将正常状态变更为熔断状态；所述第一预设熔断条件为所述失败率大于等于第一失败率阈值；所述第二预设熔断条件为所述正常交易连续失败请求数大于正常交易连续失败请求数阈值且所述正常交易连续失败持续时间大于正常交易连续失败持续时间阈值。

在一个较佳的实施方式中，若所述交易渠道的接口模式为异步模式且仅有所述失败率满足所述第一预设熔断条件，该方法还包括：根据从数据库调用的实时交易请求数据确定实际失败率；所述判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件为：判断所述实际失败率是否满足所述第一预设熔断条件。

在一个较佳的实施方式中，若所述当前渠道状态为半开闭状态，则所述判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件之前还包括：获取所述交易渠道预先配置的探测样本数；根据所述半开闭交易总请求数，所述探测样本数以及第二失败率阈值确定提前熔断错误阈值以及提前恢复成功阈值。

在一个较佳的实施方式中，若所述交易渠道的接口模式为同步模式，则所述判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件为：判断所述半开闭失败请求数是否满足第三预设熔断条件；若不满足，则判断所述半开闭成功请求数是否满足第一预设恢复条件；若不满足，则判断所述半开闭总请求数是否大于等于所述探测样本数；若是，则判断实际半开闭交易失败请求数是否满足第四预设熔断条件或第二预设恢复条件；其中，所述第三预设熔断条件以及所述第四预设熔断条件用于触发熔断器开启，所述第一预设恢复条件以及所述第二预设恢复条件用于触发熔断器关闭；所述第三预设熔断条件为半开闭失败请求数大于等于所述提前熔断错误阈值；所述第一预设恢复条件为所述半开闭成功请求数大于所述提前恢复成功阈值；所述第四预设熔断条件为所述实际半开闭失败请求数大于等于所述半开闭失败请求数阈值；所述第二预设恢复条件为所述实际半开闭失败请求数小于所述半开闭失败请求数阈值；所述实际半开闭失败请求数是根据所述半开闭交易总请求数以及所述半开闭交易成功请求数确定的，所述半开闭交易失败请求数阈值是所述根据半开闭交易总请求数以及所述第二失败率阈值确定的。

在一个较佳的实施方式中，若所述接口模式为异步模式，则在所述判断实际半开闭交易失败请求数是否满足第四预设熔断条件或第二预设恢复条件之前还包括：判断所述半开闭交易总请求数是否等于所述半开闭交易失败请求数与所述半开闭交易成功请求数之和；若等于，则判断所述实际半开闭交易失败请求数是否满足所述第四预设熔断条件或所述第二预设恢复条件。

在一个较佳的实施方式中，若所述预设状态为熔断状态，则将所述当前渠道状态变更为所述预设条件对应的预设状态之后还包括：获取预先配置的所述交易渠道的唤醒时间；在所述熔断状态的持续熔断时间达到所述唤醒时间后，将所述熔断状态变更为半开闭状态。

第二方面，提供一种交易渠道的管理装置，应用于智能路由中，所述装置包括：监听模块，用于监听交易渠道在接收到交易渠道调用方发送的交易请求后生成的通知消息；统计模块，用于根据所述通知消息以及所述交易渠道的当前渠道状态统计所述交易渠道的交易请求数据；判断模块，用于判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件；变更模块，用于若满足所述预设条件，则将所述当前渠道状态变更为所述预设条件对应的预设状态。

本发明中对正常状态或半开闭状态的交易渠道，在交易请求数据异常或者样本探测结果达不到恢复条件时，及时开启熔断器，避免后续的交易请求再次通过此交易渠道造成的交易请求处理时间较长以及异常订单的数量增多，另一方面，对半开闭状态的交易渠道，在样本探测结果达到恢复条件时，及时关闭熔断器，将渠道状态恢复为正常状态，能够及时开放正常状态的交易渠道，避免其他交易渠道的较大的压力，从而从整体上提高了交易系统的稳定性。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例中交易渠道的管理方法流程图；

图2为本发明实施例中不同渠道状态的切换示意图；

图3为本发明实施例中交易请求数据统计流程图；

图4为本发明实施例中正常状态下对于是否满足预设条件的判断流程图；

图5为本发明实施例中半开闭状态下下对于是否满足预设条件的判断流程图；

图6为本发明实施例中交易渠道的管理装置的示意图；

图7为本发明实施例中电子设备的架构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清除明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处描述的具体实施例仅用以解释本发明，并不用于限定本发明。

下面将结合附图对本发明中一种交易渠道的管理方法以及系统具体阐述。

如图1所示，一种交易渠道的管理方法，应用于智能路由中，该包括：

S101、监听交易渠道在接收到交易渠道调用方发送的交易请求后生成的通知消息。

在本步骤中，交易渠道可以为某种业务通道下的不同交易处理方细分为虚拟渠道，如某银行某卡类型等。交易渠道调用方向交易渠道发送交易请求，交易渠道在接收到交易请求后生成通知消息，若交易渠道的接口模式为同步模式，那么交易渠道直接生成交易结果的通知消息发送给交易渠道调用方，若交易渠道的接口模式为异步模式，那么交易渠道先是根据交易请求生成受理类通知消息发送给交易渠道调用方，再是生成包含交易结果的结果类通知消息回调给交易渠道调用方，此时结果类通知消息为回调类信息。

S102、根据通知消息以及交易渠道的当前渠道状态统计交易渠道的交易请求数据。

在本发明中，每一渠道设置相应的熔断器，渠道状态包括正常状态，半开闭状态以及熔断状态，熔断器的原理如图2所示，熔断器关闭，此时渠道状态为正常状态，交易请求可以正常走此渠道。当达到熔断条件时，熔断器开启，此时所有交易请求无法走到此渠道。渠道熔断器开启后，到达渠道熔断策略配置的唤醒时间，该渠道会被唤醒并进入半开闭状态，这时智能路由会根据渠道熔断策略配置探测样本，探测样本用于探测该渠道的熔断器进一步开启还是关闭，此时，少量的满足探测样本数量要求的交易请求能够走此渠道。当样本探测结果满足相应的熔断条件时，熔断器关闭，此时渠道进入熔断状态，当样本探测结果满足相应的恢复条件时，渠道恢复到正常状态，此时，交易请求均可以正常走此通道。

在本步骤中，通知消息中包含有相应的渠道标识，智能路由在监听到通知消息后，根据渠道标识获取相应的当前渠道状态。在不同的当前渠道状态下，对应的预设条件不同，因此不同的当前渠道状态所需要的统计的交易请求数据不同，并且在不同接口模式下，通知消息的种类不同，因此，本发明是根据通知消息的数量以及通知消息的类型以及当前渠道状态统计交易渠道的交易请求数据。

交易请求数据包括交易总请求数，交易成功请求数，交易失败请求数，正常交易连续失败请求数以及正常交易连续失败持续时间，其中交易总请求数为监听到的交易渠道调用方发起的交易请求的数量，交易成功请求数为监听到的交易成功的交易请求的数量，交易成功请求数为监听到的交易失败的交易请求的数量，正常交易连续失败请求数为监听到的连续交易失败的交易请求的数量，正常交易连续失败持续时间为监听到的连续交易失败所持续的时间。

S103、判断交易请求数据是否满足变更当前渠道状态的预设条件。

S104、若满足预设条件，则将当前渠道状态变更为预设条件对应的预设状态。

在上述步骤中，若当前渠道状态为正常状态，那么根据交易请求数据判断是否满足相应的熔断条件，从而触发熔断器开启，将正常状态变更为熔断状态，若当前渠道状态为半开闭状态，那么根据当前交易数据判断是否满足相应的熔断条件以及恢复条件，从而触发熔断器开启或关闭，将半开闭状态变更为熔断状态或正常状态。

在本发明中，智能路由监听交易渠道在接收到交易渠道调用方发送的交易请求后生成的通知消息，并根据通知消息以及交易渠道的当前渠道状态统计交易渠道的交易请求数据，从而适用于在对不同的渠道状态以及不同接口模式下的交易请求数据的统计，具有较为广泛的适用范围，进一步地判断交易请求数据是否满足变更当前渠道状态的预设条件，若满足预设条件，则将当前渠道状态变更为预设条件对应的预设状态，从而能够一方面，对正常状态或半开闭状态的交易渠道，在交易请求数据异常或者样本探测结果达不到恢复条件时，及时开启熔断器，避免后续的交易请求再次通过此交易渠道造成的交易请求处理时间较长，从而导致的用户体验较差，另一方面，对半开闭状态的交易渠道，在样本探测结果达到恢复条件时，及时关闭熔断器，将渠道状态恢复为正常状态，能够及时开放正常状态的交易渠道，避免其他交易渠道的较大的压力，从而本发明能够减少异常订单的数量，从而提高用户体验，提高企业的收益，也从而提高了整个交易系统的稳定性。更进一步地，对渠道状态变更后，智能路由能够自动摘除并自动路由到下一优先级的交易渠道，降低人工参与度，提高交易系统的稳定性、健壮性。

在一个较佳的实施方式中，根据通知消息以及交易渠道的当前渠道状态统计交易渠道的交易请求数据包括：

若当前渠道状态为正常状态，则根据通知消息的数量以及通知消息中的交易结果统计正常交易总请求数，正常交易成功请求数，正常交易连续失败请求数以及连续失败请求时间；

若当前渠道状态为半开闭状态，则根据通知消息的数量以及通知消息中的交易结果统计半开闭交易总请求数，半开闭交易成功请求数以及半开闭交易失败请求数。

在本步骤中，对于不同的当前渠道状态，所对应的预设条件不同，因此所统计的交易请求数据有所不同，在正常状态下，除了要统计正常交易总请求数以及正常交易成功请求数外，还要统计正常交易连续失败请求数以及正常交易连续失败持续时间，在半开闭状态下，除了要统计半开闭交易总请求数以及半开闭交易成功请求数，还要统计半开闭交易失败请求数。

在本发明中，当交易渠道处于不同的渠道状态时，对应于统计不同的交易请求数据，从而适用于不同渠道状态下的渠道管理，具有较宽的适用范围。

在一个较佳的实施方式中，若当前渠道状态为正常状态，该方法还包括：

若交易渠道的接口模式为同步模式，则根据通知消息的数量统计正常交易总请求数，根据通知消息中的交易结果统计正常交易成功请求数，正常交易连续失败请求数以及正常交易连续失败持续时间；

若交易渠道的接口模式为异步模式，则根据通知消息中受理类通知消息的数量统计正常交易总请求数，根据结果类通知消息中的交易结果统计正常交易成功请求数，正常交易连续失败请求数以及正常交易连续失败持续时间。

在本步骤中，智能路由可以根据渠道标识确定交易渠道的接口模式，在同步模式下，一则通知消息即表示一个交易请求以及一个交易结果，在异步模式下，通知消息分为受理类通知消息以及结果类通知消息，受理类通知消息即表示一个交易请求，结果类通知消息即表示一个交易结果。

本实施方式中的方法同样适用于在半开闭状态下半开闭交易总请求数，半开闭交易成功请求数以及半开闭交易失败请求数的确定。

如图3所示，为本发明中交易请求数据的确定流程，在智能路由监听到一则通知消息后，获取渠道标识，根据渠道标识获取当前渠道状态。

若当前渠道状态为正常状态，则进一步判断该通知消息是否为非终态消息，非终态的消息即为受理类消息，终态的消息即为包含交易结果的通知消息，在同步模式下，通知消息均为终态，在异步模式下，通知消息可能为终态也可能为非终态，因此，若该通知消息为非终态，那么即为受理类通知消息，递增正常交易总请求数；若该通知消息不为非终态，那么进一步判断其交易结果是成功还是失败；若为失败，那么递增正常交易连续失败请求数，同时进一步判断交易连续失败总请求数是否为1，若为1，那么当前交易时间即为交易连续失败开始时间；若为成功，递增交易成功请求数，并且将正常交易连续失败请求数归零，此时当前交易时间即为交易连续失败结束时间，正常交易连续失败持续时间即为交易连续失败结束时间与交易连续失败开始时间之差；进一步地，对应终态下，还需要判断该通知消息是否为回调类消息，同步模式下，通知消息均不为回调类消息，因此，递增交易总请求数，异步模式下，由于该交易请求的受理类通知消息已经递增过一次交易总请求数，因此，不再递增交易总请求数。

若当前渠道状态为半开闭状态，若交易渠道的接口模式为同步模式，则根据通知消息的数量统计半开闭交易总请求数，根据通知消息中的交易结果统计半开闭交易成功请求数以及半开闭交易失败请求数；若交易渠道的接口模式为异步模式，则根据通知消息中受理类通知消息的数量统计确定半开闭交易总请求数，根据结果类通知消息中的交易结果统计半开闭交易成功请求数以及半开闭交易失败请求数，具体如图3所示，在此不再赘述。

本发明中，对于不同渠道状态以及不同模式下均具有相应的交易请求数据的确定方法，实现了同步模式和异步模式的差异性化处理。

进一步地，智能路由中记录到本地的交易请求数据，会定时同步到远程redis(REmote DIctionary Server，数据结构服务器)，用于后续汇总计算。智能路由中的定时器会查找到符合清理时间的渠道，然后计算当前时间之前的一段时间内该渠道的交易总请求数和交易成功请求数的hash field，定时器执行时会将窗口外的hash field清理。

在一个较佳的实施方式中，若当前渠道状态为正常状态，则判断交易请求数据是否满足变更当前渠道状态的预设条件之前还包括：

根据正常交易总请求数与正常交易成功请求数确定交易渠道的失败率；

若交易渠道的接口模式为同步模式，则判断交易请求数据是否满足变更当前渠道状态的预设条件为：

判断失败率是否满足第一预设熔断条件或交易请求数据是否满足第二预设熔断条件；

其中，第一预设熔断条件以及第二预设熔断条件用于触发智能路由的熔断器开启，从而将正常状态变更为熔断状态；第一预设熔断条件为失败率大于等于第一失败率阈值；第二预设熔断条件为正常交易连续失败请求数大于正常交易连续失败请求数阈值且正常交易连续失败持续时间大于正常交易连续失败持续时间阈值。

在本实施例中，对于正常状态下的交易渠道，对于交易请求数据的判断包括两个方面，一方面是根据交易请求数据中的正常交易总请求数以及正常交易成功请求数确定失败率，具体的，失败率＝1-(正常交易成功请求数/正常交易总请求数)，从而在失败率大于等于第一失败率阈值时确定为满足预设条件，触发熔断器开启，另一方面是根据交易请求数据中的正常交易连续失败请求数以及正常交易连续失败持续时间来判断，在正常交易连续失败请求数大于正常交易连续失败请求数阈值且正常交易连续失败持续时间大于正常交易连续失败持续时间阈值，确定为满足预设条件，触发熔断器开启，也即是，只要满足第一预设熔断条件或第二预设熔断条件中的任意一个，即触发熔断器开启。

在一个较佳的实施方式中，若交易渠道的接口模式为异步模式且仅有失败率满足第一预设熔断条件，该方法还包括：

根据从数据库调用的实时交易请求数据确定实际失败率；

判断交易请求数据是否满足变更当前渠道状态的预设条件为：

判断实际失败率是否满足第一预设熔断条件。

在本发明中，在渠道状态为正常状态的情况下，若交易渠道的接口模式为异步模式，那么存在以下情况：第一是失败率满足第一预设熔断条件，交易请求数据不满足第二预设熔断条件，第二是失败率不满足第一预设熔断条件，交易请求数据满足第二预设熔断条件，第三是失败率满足第一预设熔断条件，交易请求数据满足第二预设熔断条件，第四是失败率不满足第一预设熔断条件，交易请求数据不满足第二预设熔断条件，对于第二种和第三种情况，直接触发熔断器开启，对于第四种情况无法触发熔断器开启，而对于第一种情况，由于异步模式下存在时间差异，可能智能路由本地统计而后计算的失败率不是真实失败率，因此需要从数据库调用的实时交易请求数据确定实际失败率，具体的计算方法同失败率的计算方法，而后判断实际失败率是否满足第一预设熔断条件。

在本发明中，对于异步模式下由失败率所确定的触发熔断器开启，提供滑动窗口偏移值配置化，提供double-check实际失败率机制，防止误熔断，从而提高了渠道状态变更的准确性。

如图4所示为本发明渠道状态为正常状态下的判断流程，智能路由会中的定时器会定期查询符合条件的交易渠道，并获取交易渠道的熔断策略，将当前时间作为统计结束时间，将当前时间与熔断策略中预先配置的时间间隔的差值作为统计开始时间，而后进一步判断接口模式是否为异步模式，若为异步模式还需要在确定统计结束时间时减去熔断策略中预先配置的异步时间，无论为同步模式还为异步模式，在确定统计结束时间以及统计开始时间后，即获取这段时间内的正常交易总请求数，如果正常交易总请求数大于等于熔断策略中的最小请求数，那么进一步统计其中正常成功交易请求数，正常交易连续失败请求数以及正常交易连续失败持续时间，否则，不进一步统计。而后，计算失败率，判断是否满足第一预设熔断条件或第二预设熔断条件，如果判断结果为满足，在同步模式下，触发熔断器开启，在异步模式下，进一步判断是否为仅满足第一预设熔断条件，若是则进一步确定实际失败率，判断是否满足第一预设熔断条件，若满足，则触发熔断器开启。

在一个较佳的实施方式中，若当前渠道状态为半开闭状态，则判断交易请求数据是否满足变更当前渠道状态的预设条件之前还包括：

获取交易渠道预先配置的探测样本数；

根据半开闭交易总请求数，探测样本数以及第二失败率阈值确定提前熔断错误阈值以及提前恢复成功阈值。

在本实施例中，对于半开闭状态下的交易渠道，智能路由先要获取其预先配置的探测样本数，探测样本数即为在半开闭状态下能够进入到交易渠道中的交易请求数。

在确定半开闭交易总请求数以及探测样本数后，将半开闭交易总请求数以及探测样本数的最大值作为基数，提前熔断错误阈值＝基数*第二失败率阈值*系数，系数的取值是预先配置的，提前恢复成功阈值＝基数-提前熔断错误阈值。

在一个较佳的实施方式中，若交易渠道的接口模式为同步模式，则判断交易请求数据是否满足变更当前渠道状态的预设条件为：

判断半开闭失败请求数是否满足第三预设熔断条件；

若不满足，则判断半开闭成功请求数是否满足第一预设恢复条件；

若不满足，则判断半开闭总请求数是否大于等于探测样本数；

若是，则判断实际半开闭交易失败请求数是否满足第四预设熔断条件或第二预设恢复条件；

其中，第三预设熔断条件以及第四预设熔断条件用于触发熔断器开启，第一预设恢复条件以及第二预设恢复条件用于触发熔断器关闭；第三预设熔断条件为半开闭失败请求数大于等于提前熔断错误阈值；第一预设恢复条件为半开闭成功请求数大于提前恢复成功阈值；第四预设熔断条件为实际半开闭失败请求数大于等于半开闭失败请求数阈值；第二预设恢复条件为实际半开闭失败请求数小于半开闭失败请求数阈值；实际半开闭失败请求数是根据半开闭交易总请求数以及半开闭交易成功请求数确定的，半开闭交易失败请求数阈值是根据半开闭交易总请求数以及第二失败率阈值确定的。

如图5所示为本发明中半开闭状态下的判断流程，首先，判断半开闭失败请求数是否大于等于提前熔断错误阈值，若是则满足第三预设熔断条件，触发熔断器开启，若否，则进一步判断半开闭成功请求数是否提前恢复成功阈值，若是则满足第一预设恢复条件，触发熔断器关闭，若否则进一步判断半开闭总请求数是否大于等于探测样本数，若否则表明不满足改变半开闭状态的条件，若是则进一步计算实际半开闭失败请求数以及半开闭交易失败请求数阈值，实际半开闭失败请求数＝半开闭交易总请求数-半开闭交易成功请求数确定的，半开闭交易失败请求数阈值＝根据半开闭交易总请求数*第二失败率阈值，进一步比较实际半开闭交易失败请求数与半开闭交易失败请求数阈值的大小，若实际半开闭失败请求数大于等于半开闭失败请求数阈值，则满足第四预设熔断条件，触发熔断器开启，若实际半开闭失败请求数小于半开闭失败请求数阈值，则满足第二预设恢复条件，触发熔断器关闭。

在一个较佳的实施方式中，若接口模式为异步模式，则在判断实际半开闭交易失败请求数是否满足第四预设熔断条件或第二预设恢复条件之前还包括：

判断半开闭交易总请求数是否等于半开闭交易失败请求数与半开闭交易成功请求数之和；

若等于，则判断实际半开闭交易失败请求数是否满足第四预设熔断条件或第二预设恢复条件。

在本实施例中，继续参考图5，在判断为半开闭总请求数大于等于探测样本数后，进一步判断接口模式，对于同步接口模式，直接判断实际半开闭交易失败请求数是否满足第四预设熔断条件或第二预设恢复条件，而对于异步模式，则在此之前需要进一步判断半开闭交易总请求数是否等于半开闭交易失败请求数与半开闭交易成功请求数之和，只有满足这一条件，才进一步判断是对半开闭状态熔断或者恢复，若不满足这一条件，那么则不满足半开闭状态变更的条件。

在一个较佳的实施方式中，若预设状态为熔断状态，则将当前渠道状态变更为预设条件对应的预设状态之后还包括：

获取预先配置的交易渠道的唤醒时间；

在熔断状态的持续熔断时间达到唤醒时间后，将熔断状态变更为半开闭状态。

在本实施例中，对于处于熔断状态的交易渠道，智能路由获取其预先配置的唤醒时间，当熔断状态的持续熔断时间达到唤醒时间后，将熔断状态改变为半开闭状态，并进一步地根据交易渠道的熔断策略中的探测样本数为其配置探测样本，允许部分交易请求进入该交易渠道，并根据探测结果进一步判断是对其进一步熔断还是恢复，从而一方面，能够在交易渠道的故障排除后，及时将其状态恢复，另一方面，能够在交易渠道仍然没有故障排除时，仍然将其保持熔断状态，避免后续交易请求进入该交易渠道从而造成的交易请求处理时间较长的问题。

进一步地，在满足探测时间后，开启统计探测样本的探测结果。当监听到探测结果时，智能路由对探测样本数的统计采用二级递减机制，应用程序各机器本地和远程redis均初始化配置探测样本，先递减本地探测样本数，成功后再递减远程redis探测样本数，防止流量高峰压向redis；若本地探测样本数小于0，那么不再递减本地探测样本数，若大于等于0，那么获取远程探测样本数，并判断是否等于0，若等于0，则延迟一段时间进行半开闭熔断开启或者关闭的判断，而后判断远程探测样本数是否小于0，若不等于0，则直接判断远程探测样本数是否小于0，若为小于0，则递减远程探测样本数，若否则不递减远程探测样本数。

在实际应用中，部分渠道接口在查询渠道相关数据用于展示时，需展示半开闭渠道是否可用，这时智能路由仅需判断探测样本数是否用尽，先判断本地，再判断远程，先获取本地探测样本数，若本地探测样本数小于等于0，则表示已经耗尽，若否则判断远程探测样本数是否小于等于0，若是，则表示已经耗尽，否则表示没有耗尽，从而可以有效减少远程redis的访问、同时防止结果丢失，渠道状态被搁置的情况。

如图6所示，本发明还提供了一种交易渠道的管理装置，应用于智能路由中，该装置包括：

监听模块601，用于监听交易渠道在接收到交易渠道调用方发送的交易请求后生成的通知消息；

统计模块602，用于根据通知消息以及交易渠道的当前渠道状态统计交易渠道的交易请求数据；

判断模块603，用于判断交易请求数据是否满足变更当前渠道状态的预设条件；

变更模块604，用于若满足预设条件，则将当前渠道状态变更为预设条件对应的预设状态。

在一个较佳的实施方式中，统计模块602包括第一统计单元，用于若当前渠道状态为正常状态，则根据通知消息的数量以及通知消息中的交易结果统计正常交易总请求数，正常交易成功请求数，正常交易连续失败请求数以及连续失败请求时间；第二统计单元，用于若当前渠道状态为半开闭状态，则根据通知消息的数量以及通知消息中的交易结果统计半开闭交易总请求数，半开闭交易成功请求数以及半开闭交易失败请求数。

在一个较佳的实施方式中，第一统计单元还包括第一统计子单元，用于若交易渠道的接口模式为同步模式，则根据通知消息的数量确定正常交易总请求数，根据通知消息中的交易结果确定正常交易成功请求数，正常交易连续失败请求数以及正常交易连续失败持续时间；第二统计子单元，用于若交易渠道的接口模式为异步模式，则根据通知消息中受理类通知消息的数量统计正常交易总请求数，根据结果类通知消息中的交易结果确定正常交易成功请求数，正常交易连续失败请求数以及正常交易连续失败持续时间。

在一个较佳的实施方式中，该装置还包括确定模块，用于根据正常交易总请求数与正常交易成功请求数确定交易渠道的失败率；若交易渠道的接口模式为同步模式，判断模块603还用于判断失败率是否满足第一预设熔断条件或交易请求数据是否满足第二预设熔断条件；其中，第一预设熔断条件以及第二预设熔断条件用于触发智能路由的熔断器开启，从而将正常状态变更为熔断状态；第一预设熔断条件为失败率大于等于第一失败率阈值；第二预设熔断条件为正常交易连续失败请求数大于正常交易连续失败请求数阈值且正常交易连续失败持续时间大于正常交易连续失败持续时间阈值。

在一个较佳的实施方式中，若交易渠道的接口模式为异步模式且仅有失败率满足第一预设熔断条件，确定模块还用于根据从数据库调用的实时交易请求数据确定实际失败率；判断模块603还用于判断实际失败率是否满足第一预设熔断条件。

在一个较佳的实施方式中，该装置还包括获取模块，用于获取交易渠道预先配置的探测样本数；确定模块还用于根据半开闭交易总请求数，探测样本数以及第二失败率阈值确定提前熔断错误阈值以及提前恢复成功阈值。

在一个较佳的实施方式中，若交易渠道的接口模式为同步模式，判断模块603还用于判断半开闭失败请求数是否满足第三预设熔断条件；若不满足，则判断半开闭成功请求数是否满足第一预设恢复条件；若不满足，则判断半开闭总请求数是否大于等于探测样本数；若是，则判断实际半开闭交易失败请求数是否满足第四预设熔断条件或第二预设恢复条件；其中，第三预设熔断条件以及第四预设熔断条件用于触发熔断器开启，第一预设恢复条件以及第二预设恢复条件用于触发熔断器关闭；第三预设熔断条件为半开闭失败请求数大于等于提前熔断错误阈值；第一预设恢复条件为半开闭成功请求数大于提前恢复成功阈值；第四预设熔断条件为实际半开闭失败请求数大于等于半开闭失败请求数阈值；第二预设恢复条件为实际半开闭失败请求数小于半开闭失败请求数阈值；实际半开闭失败请求数是根据半开闭交易总请求数以及半开闭交易成功请求数确定的，半开闭交易失败请求数阈值是根据半开闭交易总请求数以及第二失败率阈值确定的。

在一个较佳的实施方式中，若接口模式为异步模式，判断模块603还用于判断半开闭交易总请求数是否等于半开闭交易失败请求数与半开闭交易成功请求数之和；若等于，则判断实际半开闭交易失败请求数是否满足第四预设熔断条件或第二预设恢复条件。

在一个较佳的实施方式中，若预设状态为熔断状态，获取模块还用于获取预先配置的交易渠道的唤醒时间；变更模块604还用于在熔断状态的持续熔断时间达到唤醒时间后，将熔断状态变更为半开闭状态。

本发明中的交易渠道的管理装置的有益效果参见交易渠道的管理方法的阐述，在此不再赘述。

本发明还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行交易渠道的管理方法。

本实施例执行过程及所能实现的技术效果请参照应用于交易渠道的管理方法中的描述，此处不再赘述。

本发明还提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如前所述的交易渠道的管理方法，该方法的执行过程及所能实现的技术效果请参照如前的描述，此处不再赘述。

本发明还提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如前所述的交易渠道的管理方法，该方法的执行过程及所能实现的技术效果请参照如前的描述，此处不再赘述。

其中，图7示例性的展示出了电子设备的系架构，具体可以包括处理器710，视频显示适配器711，磁盘驱动器712，输入/输出接口713，网络接口714，以及存储器720。上述处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720之间可以通过通信总线730进行通信连接。

其中，处理器710可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本发明所提供的技术方案。

存储器720可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器720可以存储用于控制计算机系统运行的操作系统721，用于控制计算机系统的低级别操作的基本输入输出系统(BIOS)。另外，还可以存储网页浏览器723，数据存储管理系统724，以及设备标识信息处理系统725等等。上述设备标识信息处理系统725就可以是本发明实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本发明所提供的技术方案时，相关的程序代码保存在存储器720中，并由处理器710来调用执行。

输入/输出接口713用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口714用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线730包括一通路，在设备的各个组件(例如处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，存储器720，总线730等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本发明方案所必需的组件，而不必包含图中所示的全部组件。

本发明的计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置从网络上被下载和安装，或者从存储器被安装，或者从ROM被安装。在该计算机程序被处理器执行时，执行本发明的实施例的方法中限定的上述功能。

需要说明的是，本发明的实施例的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明的实施例中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(Radio Frequency，射频)等等，或者上述的任意合适的组合。

上述计算机可读介质可以是上述服务器中所包含的；也可以是单独存在，而未装配入该服务器中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该服务器执行时，使得该服务器：响应于检测到终端的外设模式未激活时，获取终端上应用的帧率；在帧率满足息屏条件时，判断客户是否正在获取终端的屏幕信息；响应于判断结果为客户未获取终端的屏幕信息，控制屏幕进入立即暗淡模式。

可以以一种或多种程序设计语言或其组合来编写用于执行本发明的实施例的操作的计算机程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在客户计算机上执行、部分地在客户计算机上执行、作为一个独立的软件包执行、部分在客户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到客户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本发明所提供的交易渠道的管理方法以及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种交易渠道的管理方法，其特征在于，应用于智能路由中，所述方法包括：

监听交易渠道在接收到交易渠道调用方发送的交易请求后生成的通知消息；

根据所述通知消息以及所述交易渠道的当前渠道状态统计所述交易渠道的交易请求数据；

判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件；

若满足所述预设条件，则将所述当前渠道状态变更为所述预设条件对应的预设状态。

2.根据权利要求1所述的方法，其特征在于，所述根据所述通知消息以及所述交易渠道的当前渠道状态统计所述交易渠道的交易请求数据包括：

若所述当前渠道状态为正常状态，则根据所述通知消息的数量以及所述通知消息中的交易结果统计正常交易总请求数，正常交易成功请求数，正常交易连续失败请求数以及连续失败请求时间；

若所述当前渠道状态为半开闭状态，则所述根据通知消息的数量以及所述通知消息中的交易结果统计半开闭交易总请求数，半开闭交易成功请求数以及半开闭交易失败请求数。

3.根据权利要求2所述的方法，其特征在于，若所述当前渠道状态为所述正常状态，所述方法还包括：

若所述交易渠道的接口模式为同步模式，则根据所述通知消息的数量确定正所述正常交易总请求数，根据所述通知消息中的交易结果确定所述正常交易成功请求数，所述正常交易连续失败请求数以及所述正常交易连续失败持续时间；

若所述交易渠道的接口模式为异步模式，则所述根据通知消息中受理类通知消息的数量统计所述正常交易总请求数，根据结果类通知消息中的交易结果确定所述正常交易成功请求数，所述正常交易连续失败请求数以及所述正常交易连续失败持续时间。

4.根据权利要求2所述的方法，其特征在于，若所述当前渠道状态为所述正常状态，则所述判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件之前还包括：

根据所述正常交易总请求数与所述正常交易成功请求数确定交易渠道的失败率；

若所述交易渠道的接口模式为同步模式，则所述判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件为：

判断失败率是否满足第一预设熔断条件或所述交易请求数据是否满足第二预设熔断条件；

其中，所述第一预设熔断条件以及所述第二预设熔断条件用于触发智能路由的熔断器开启，从而将正常状态变更为熔断状态；所述第一预设熔断条件为所述失败率大于等于第一失败率阈值；所述第二预设熔断条件为所述正常交易连续失败请求数大于正常交易连续失败请求数阈值且所述正常交易连续失败持续时间大于正常交易连续失败持续时间阈值。

5.根据权利要求4所述的方法，其特征在于，若所述交易渠道的接口模式为异步模式且仅有所述失败率满足所述第一预设熔断条件，该方法还包括：

根据从数据库调用的实时交易请求数据确定实际失败率；

所述判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件为：

判断所述实际失败率是否满足所述第一预设熔断条件。

6.根据权利要求2所述的方法，其特征在于，若所述当前渠道状态为半开闭状态，则所述判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件之前还包括：

获取所述交易渠道预先配置的探测样本数；

根据所述半开闭交易总请求数，所述探测样本数以及第二失败率阈值确定提前熔断错误阈值以及提前恢复成功阈值。

7.根据权利要求6所述的方法，其特征在于，若所述交易渠道的接口模式为同步模式，则所述判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件为：

判断所述半开闭失败请求数是否满足第三预设熔断条件；

若不满足，则判断所述半开闭成功请求数是否满足第一预设恢复条件；

若不满足，则判断所述半开闭总请求数是否大于等于所述探测样本数；

若是，则判断实际半开闭交易失败请求数是否满足第四预设熔断条件或第二预设恢复条件；

其中，所述第三预设熔断条件以及所述第四预设熔断条件用于触发熔断器开启，所述第一预设恢复条件以及所述第二预设恢复条件用于触发熔断器关闭；所述第三预设熔断条件为半开闭失败请求数大于等于所述提前熔断错误阈值；所述第一预设恢复条件为所述半开闭成功请求数大于所述提前恢复成功阈值；所述第四预设熔断条件为所述实际半开闭失败请求数大于等于所述半开闭失败请求数阈值；所述第二预设恢复条件为所述实际半开闭失败请求数小于所述半开闭失败请求数阈值；所述实际半开闭失败请求数是根据所述半开闭交易总请求数以及所述半开闭交易成功请求数确定的，所述半开闭交易失败请求数阈值是所述根据半开闭交易总请求数以及所述第二失败率阈值确定的。

8.根据权利要求7所述的方法，其特征在于，若所述接口模式为异步模式，则在所述判断实际半开闭交易失败请求数是否满足第四预设熔断条件或第二预设恢复条件之前还包括：

判断所述半开闭交易总请求数是否等于所述半开闭交易失败请求数与所述半开闭交易成功请求数之和；

若等于，则判断所述实际半开闭交易失败请求数是否满足所述第四预设熔断条件或所述第二预设恢复条件。

9.根据权利要求1至8任一项所述的方法，其特征在于，若所述预设状态为熔断状态，则将所述当前渠道状态变更为所述预设条件对应的预设状态之后还包括：

获取预先配置的所述交易渠道的唤醒时间；

在所述熔断状态的持续熔断时间达到所述唤醒时间后，将所述熔断状态变更为半开闭状态。

10.一种交易渠道的管理装置，其特征在于，应用于智能路由中，所述装置包括：

监听模块，用于监听交易渠道在接收到交易渠道调用方发送的交易请求后生成的通知消息；

统计模块，用于根据所述通知消息以及所述交易渠道的当前渠道状态统计所述交易渠道的交易请求数据；

判断模块，用于判断所述交易请求数据是否满足变更所述当前渠道状态的预设条件；

变更模块，用于若满足所述预设条件，则将所述当前渠道状态变更为所述预设条件对应的预设状态。

Images