一种业务路由方法和装置与流程

本发明涉及网络技术，特别涉及一种业务路由方法和装置。
背景技术：
：在一个业务处理中，可以分为两端，一端是发起业务处理请求的请求端，另一端是根据上述请求进行业务处理的处理端。并且，可以用于处理业务的处理端的数量可以有多个，例如，处理端A、处理端B等都可以执行相同的业务处理。在请求端和处理端之间可以设置一业务中间平台，该平台可以负责接收请求端发送的业务处理请求，并将请求发送至其中一个处理端进行处理。当有多个处理端都可以处理本次业务时，平台可以按照一定的规则由多个处理端中选择一个处理端，并将业务处理请求发送过去。相关技术中，对于某次业务处理请求对应的业务来说，发送至不同的处理端可以具有不同的处理成功率，比如，发送至处理端A执行本次处理，业务处理成功率可以较高，而如果发送至处理端B执行本次处理，业务处理成功率较低，很可能导致本次业务失败。现有技术中通常采用随机选择一个处理端，或者选择请求端账户上一次业务成功对应的处理端，但是由于每次业务处理的结果都具有很大的随机性，上述选择处理端的方式仍然不能保证将请求送往成功率高的处理端，从而影响业务处理的成功率。技术实现要素：有鉴于此，本发明提供一种业务路由方法和装置，以提高业务处理的成功率。具体地，本发明是通过如下技术方案实现的：第一方面，提供一种业务路由方法，所述方法包括：在接收到业务处理请求时，获取所述业务处理请求携带的处理影响参数，所述处理影响参数能够影响本次业务处理的成功与否；在预存储的处理结果表中，获取与所述处理影响参数对应的多个处理端，每个处理端具有各自对应的处理成功率，所述处理成功率是处理端在所述处理影响参数下执行处理的成功率，且所述处理成功率是根据历史数据的统计结果；根据所述处理成功率，选择一个处理端，将所述业务处理请求发送至所述处理端进行处理。第二方面，提供一种业务路由装置，所述装置包括：参数获取模块，用于在接收到业务处理请求时，获取所述业务处理请求携带的处理影响参数，所述处理影响参数能够影响本次业务处理的成功与否；处理确定模块，用于在预存储的处理结果表中，获取与所述处理影响参数对应的多个处理端，每个处理端具有各自对应的处理成功率，所述处理成功率是处理端在所述处理影响参数下执行处理的成功率，且所述处理成功率是根据历史数据的统计结果；处理选择模块，用于根据所述处理成功率，选择一个处理端，将所述业务处理请求发送至所述处理端进行处理。本发明实施例的业务路由方法和装置，通过对业务处理的处理影响参数对应的业务处理请求，分别统计不同的处理端处理该请求的成功率，能够使得对处理端的成功率统计更加准确，并根据该统计成功率选取处理端，也更能够选择到更合适的处理端，提高业务处理的成功率。附图说明图1为本发明实施例提供的一种业务处理的系统架构图；图2为本发明实施例提供的一种业务路由方法的流程图；图3为本发明实施例提供的一种业务路由方法的应用场景；图4为本发明实施例提供的一种渠道选择流程图；图5为本发明实施例提供的一种业务路由装置的结构示意图；图6为本发明实施例提供的另一种业务路由装置的结构示意图。具体实施方式图1示例了一个业务处理的系统架构，请求端11发送的业务处理请求，可以被业务中间平台12接收，并且由业务中间平台12为本次业务处理选择一个处理端，假设平台选择的处理端是处理端13，则平台将业务处理请求转发至处理端13，由处理端13进行业务处理，并反馈成功或失败的处理结果。由于不同的处理端具有不同的处理成功率，如果选择不当，将导致业务处理失败，因此对于平台而言，选择合适的处理端以使得业务处理成功率较高，是非常重要的。本申请实施例为了提高平台在选择处理端时的准确性，提供了一种业务路由方法，该方法将主要描述如何选择处理端，图2示例了一种业务路由方法的流程，该方法可以由图1中的业务中间平台执行。可以包括：在步骤201中，在接收到业务处理请求时，获取所述业务处理请求携带的处理影响参数，所述处理影响参数能够影响本次业务处理的成功与否。本步骤中，该业务处理请求可以是一个支付请求，其中携带的处理影响参数可以是能够影响本次支付处理成功或失败的因素，比如，将一个支付请求发送给某一个处理端处理时，本次支付请求对应的信用卡的卡号、或者发起本次请求的客户端位于移动设备或者位于PC上、或者本次支付的支付币种等，都可能影响到处理成功与否。例如，将支付请求发送给某一个处理端进行处理，若该支付请求的支付币种是人民币，处理端处理时很可能会成功；而如果支付请求用的支付币种是美元，将可能导致处理端本次处理失败。因此，本步骤中的处理影响参数是能够影响本次业务处理的成功与否的因素。在步骤202中，在预存储的处理结果表中，获取与所述处理影响参数对应的多个处理端，每个处理端具有各自对应的处理成功率。本例子中，业务中间平台12可以存储有处理结果表，该处理结果表的数量可以有多个。每个处理结果表中可以包括如下对应关系：处理影响参数、处理端、以及对应的处理成功率。其中，所述处理成功率是处理端在所述处理影响参数下执行处理的成功率；例如，假设处理成功率是80％，即在某个处理端，处理一个携带所述的处理影响参数的业务处理请求时，处理成功的概率是80％。此外，所述处理成功率是根据历史数据的统计结果，比如可以根据最近一个月的某个处理端在一组处理影响参数下执行处理的总业务笔数和成功业务笔数，得到对应的成功率。比如，对于某组处理影响参数来说，对于该组参数的业务处理请求在一个处理端的成功率是85％，在另一处理端的成功率是90％。在步骤203中，根据所述处理成功率，选择一个处理端，将所述业务处理请求发送至所述处理端进行处理。例如，根据步骤201中获取的处理影响参数，在处理结果表中可以得到多个处理端，即该多个处理端都处理过该组处理影响参数对应的业务处理请求。所述的多个处理端的处理成功率不同，在根据成功率选择处理端时，可以选取成功率最高的处理端来处理本次业务；或者，也可以将成功率作为其中一个参考因素，综合其他因素一起来确定选择的处理端，比如，某个成功率最高的处理端当前的状态是故障中，那就可以选择成功率较低的另一个处理端。本例子的业务路由方法，通过对业务处理的处理影响参数对应的业务处理请求，分别统计不同的处理端处理该请求的成功率，能够使得对处理端的成功率统计更加准确，并根据该统计成功率选取处理端，也更能够选择到更合适的处理端，提高业务处理的成功率。如下结合一个应用场景为例，来详细描述本申请的业务路由方法。该示例的应用场景可以是对信用卡支付请求的处理，如图3所示，在本例子中，假设用户使用卡号前六位(即卡BIN号)为“543210”的某信用卡，在Android手机31上的APP进行购物并以美元付款，当他点击确认支付后，一个支付处理请求就会发送至业务中间平台32。其中，该支付处理请求中可以携带处理影响参数如下：本次请求支付的信用卡的卡BIN号、支付设备APP信息、支付币种。在其他的例子中，支付设备还可以是PC等其他设备，不一定是APP；并且支付币种也可以是美元之外的其他币种。业务中间平台32可以连接多个支付网关，例如，支付网关33、支付网关34、支付网关35等，而这些支付网关又可以连接分别连接自己对接的处理设备，该处理设备可以是收单行、卡组织等单位网络，支付网关可以将由平台接收到的支付处理请求转发给处理设备进行处理。可以将支付网关及其连接的处理设备看做一个支付处理渠道，平台选择一个支付网关发送支付处理请求，也相当于选择了一个支付渠道处理本次支付处理业务，支付渠道也相当于本申请所述的处理端，不同的渠道有不同的支付处理成功率。业务中间平台32对支付渠道的选择，取决于平台侧存储的处理结果表，处理结果表中包括不同的渠道在不同的处理影响参数下的成功率统计数据，根据该处理结果表进行支付渠道的选择，有助于提高支付处理的成功率。下面将先说明平台侧的处理结果表的生成，再说明如何根据处理结果表进行渠道选择。根据历史数据生成处理结果表：图3中的业务中间平台32，已经为很多的支付处理请求分配过支付渠道，并且也能够获知支付渠道是否成功执行对支付请求的处理，平台可以根据这些历史记录数据，生成处理结果表。详细说明如下：假设每一笔支付业务的处理，都包括如下信息：支付申请时间、支付成功时间、支付订单号、支付流水号、支付渠道的渠道标识、支付币种、支付设备、卡BIN号(卡号前六位)、卡种类、发卡银行、发卡国家。预先设置一个统计时间段，并将所述统计时间段分为多个统计时间分段。例如，统计时间段可以是“一个月”，将这一个月分为四周，每一周作为一个统计时间分段。具体实施中，为了方便统计，可以为每一笔支付业务信息的数据，在原有信息的基础上增加一个周标签的字段，用于标识该数据是属于哪周，比如一个月中的第一周、第二周等。周标签的添加方法可以如下：whento_char(gmt_create,'yyyyMMdd')>＝{YYYYMMDD-8}andto_char(gmt_create,'yyyyMMdd')<{YYYYMMDD-1}then'week_1'whento_char(gmt_create,'yyyyMMdd')>＝{YYYYMMDD-15}andto_char(gmt_create,'yyyyMMdd')<{YYYYMMDD-8}then'week_2'whento_char(gmt_create,'yyyyMMdd')>＝{YYYYMMDD-22}andto_char(gmt_create,'yyyyMMdd')<{YYYYMMDD-15}then'week_3'whento_char(gmt_create,'yyyyMMdd')>＝{YYYYMMDD-29}andto_char(gmt_create,'yyyyMMdd')<{YYYYMMDD-22}then'week_4'每一周的历史处理记录都可以包括多笔支付业务的处理，其中，每一笔支付业务处理的记录包括：处理影响参数、业务处理的处理端即渠道标识、在本周内与所述处理影响参数和渠道对应的业务处理数量(即该渠道处理所述参数对应的支付处理请求的总支付笔数)、在本周内与所述处理影响参数和处理端对应的业务成功数量(即处理支付成功的笔数)。根据所述历史处理记录，分别统计每周内的处理成功率，所述处理成功率对应所述处理影响参数和处理端。例如，处理影响参数是卡BIN号、支付设备、支付币种，处理端是支付渠道，以渠道标识表示。如下的表1示例了统计数据：表1以周为单位的数据统计以上述表1的其中一行数据为例，“第一周，543210，APP，美元，Code-1，75％”，该数据的意思可以是，渠道code-1在第一周的时段内，处理具有如下参数“543210，APP，美元”的支付请求时，总共处理了100笔这种请求，只有75笔处理成功，25笔处理失败。接着可以将多个统计时间分段的处理成功率进行加权求和，且权重按照各个统计时间分段距离当前时间的时间距离进行区分，得到所述统计时间段的处理成功率。比如，第一周的权重可以是0.1，第二周的权重0.2，第三周的权重0.3，第四周的权重0.4，即距离当前越靠近的数据，越具有价值。仍以表1为例，对于处理影响参数和支付渠道“543210，APP，美元，Code-1”，将其对应的四周的数据进行加权求和，如下：处理成功率＝75％*0.1+80％*0.2+63％*0.3+86％*0.4在处理结果表中，“543210，APP，美元，Code-1”对应的成功率如下表2表2处理结果表的部分内容(卡BIN号级别)需要说明的是，在表2的处理结果表中，可以包括很多行数据，上表2只是示例了其中一行数据，不同行数据，具有不同的处理影响参数和支付渠道的组合，即处理影响参数和支付渠道至少一个不同。此外，上述的表1和表2是以“卡BIN号，支付设备，支付币种，支付渠道”为例，其中，由于同一卡BIN号的卡是同一个发卡行发布的同一种卡，通常在支付授权的通过率上有一致的表现，所以以卡BIN号作为一个维度来统计，使得成功率的统计精度更高更准确；但是，卡BIN号属于一种统计粒度较细的级别，这种细粒度级别在一周的统计时段中有可能支付申请笔数太少而出现较大的成功率波动，影响统计效果。因此，本实施例可以设置一个数量阈值，如果一周中“卡BIN号，支付设备，支付币种，支付渠道”这个粒度的业务处理数量未达到预设的数量阈值，则不再统计该组合对应的成功率，即表2的处理结果表中不再包括“卡BIN号，支付设备，支付币种，支付渠道”对应的成功率。同时，为了在较细粒度的统计无法实现时仍然能够得到较优的渠道推荐，本实施例还统计了两个处理结果表，这两个处理结果表比卡BIN号对应的处理结果表的成功率统计精度低。例如，可以分别为发卡银行级别的处理结果表、以及发卡国家级别的处理结果表。例如，对于发卡银行级别的处理结果表，可以这样生成：在统计周数据时，统计每周的“发卡银行、支付设备、支付币种、渠道标识”对应的成功率，即相当于将表1的卡BIN号字段更改为发卡银行，同样再对四周的成功率进行加权求和。如下的表3示例了一个发卡银行级别的处理结果表：表3处理结果表的部分内容(发卡银行级别)发卡银行支付设备支付币种渠道标识处理成功率某某行PC美元Code-181％此外，发卡国家级别的处理结果表的生成方式同上，不再赘述。平台可以根据采集的历史数据，定期更新上述的处理结果表，以提高结果表的准确性。例如，平台可以每日定时根据采集的最新数据计算。使用处理结果表选择支付渠道：图3中的业务中间平台32在接收到支付处理请求后，可以根据上述生成的处理结果表进行支付渠道的选择，渠道的选择可以依据多种因素，渠道的业务处理成功率可以是其中一个参考因素。本实施例中，平台需要获取与本次请求对应的可选的多个渠道分别具有的成功率，如图4所示，可以按照该流程获取可选的多个渠道：在步骤401中，获取支付处理请求中的处理影响参数。例如，获取到的请求中的处理影响参数可以包括：卡BIN号、APP信息、支付币种美元。在步骤402中，查找第一处理结果表中是否包括所述处理影响参数。例如，平台可以先在表2所示的卡BIN号级别的处理结果表(该表可以称为第一处理结果表)中查找步骤401得到的处理影响参数。若所述第一处理结果表包括所述处理影响参数，则继续执行403。若第一处理结果表未查找到所述处理影响参数，则继续执行404。在步骤403中，在第一处理结果表中获取对应所述处理影响参数的多个处理端、以及各个处理端分别对应的成功率。例如，在表2中只示例了“543210、APP、美元”对应的渠道code-1的成功率是76.8％，其实表2中对应该组合“543210、APP、美元”的渠道可以有多个，还可以包括code-2、code-3等渠道，每个渠道都有各自对应的成功率，比如，“543210、APP、美元、code-2”的成功率是80％，又比如，“543210、APP、美元、code-3”的成功率是86％。在步骤404中，在第二处理结果表中查找所述处理影响参数，获得参数对应的多个处理端及成功率，第一处理结果表的成功率统计精度高于所述第二处理结果表。例如，如果卡BIN号级别的处理结果表中未找到步骤401的参数，则在发卡银行级别的处理结果表中查找，该发卡银行级别的处理结果表的成功率统计精度低于卡BIN号的处理结果表的精度。比如，从图3中查找到的“某某行、APP、美元”对应的渠道code-1的成功率是81％”，当然，该组合还可以对应多个渠道。在步骤405中，根据所述处理成功率，选择一个处理端。例如，以步骤403得到的渠道成功率为例，可以将这三个渠道的成功率排序，code-3—86％，code-2—80％，code-1—76.8％。可以选择其中成功率最高的code-3，作为处理本次支付请求的渠道。或者，也可以综合其他因素，比如结合渠道的状态，如果code-3渠道当前处于不可用状态，则可以选择code-2渠道。本例子的业务路由方法，通过依据支付设备、支付币种等多个维度的信息统计渠道的成功率，使得成功率的统计更加准确；并且，通过得到卡BIN号、发卡行等多个级别的处理结果表，可以更全面的获取对应某次支付请求的渠道推荐；此外，通过对预设时间段内数据的统计加权的方法，平抑了单次支付波动带来的影响，不会因为单次的异常而导致推荐渠道的较大偏差。即使一个没有历史记录的新卡，本申请同样可以通过新卡的卡BIN等处理影响参数，在平台上的历史表现给出最优渠道推荐；该方法可以实现将每一笔信用卡支付申请分配至适合这张卡的支付成功率较高的支付渠道。本申请实施例还提供了一种业务路由装置，以执行上述的业务路由方法。该装置的结构可以参见图5所示，可以包括：参数获取模块51、处理确定模块52和处理选择模块53。参数获取模块51，用于在接收到业务处理请求时，获取所述业务处理请求携带的处理影响参数，所述处理影响参数能够影响本次业务处理的成功与否；处理确定模块52，用于在预存储的处理结果表中，获取与所述处理影响参数对应的多个处理端，每个处理端具有各自对应的处理成功率，所述处理成功率是处理端在所述处理影响参数下执行处理的成功率，且所述处理成功率是根据历史数据的统计结果；处理选择模块53，用于根据所述处理成功率，选择一个处理端，将所述业务处理请求发送至所述处理端进行处理。在一个例子中，当所述业务处理请求是支付请求时，所述处理影响参数，包括如下至少一个：卡BIN号、支付设备、支付币种。在一个例子中，所述预存储的处理结果表，包括：多个处理结果表，不同的处理结果表具有不同的成功率统计精度；处理确定模块52，在用于获取与所述处理影响参数对应的多个处理端时，包括：在第一处理结果表中查找所述处理影响参数，若所述第一处理结果表包括所述处理影响参数，则获取对应的多个处理端；若所述第一处理结果表未查找到所述处理影响参数，则在第二处理结果表中查找所述处理影响参数，所述第一处理结果表的成功率统计精度高于所述第二处理结果表。如图6所示，该装置还可以包括：记录获取模块54和成功率统计模块55。记录获取模块54，用于预先设置一个统计时间段，并将所述统计时间段分为多个统计时间分段；分别获取每个统计时间分段内业务处理的历史处理记录，所述历史处理记录包括：所述处理影响参数、业务处理的处理端、在所述统计时间分段内与所述处理影响参数和处理端对应的业务处理数量、在所述统计时间分段内与所述处理影响参数和处理端对应的业务成功数量；成功率统计模块55，用于根据所述历史处理记录，分别统计每个统计时间分段内的处理成功率，所述处理成功率对应所述处理影响参数和处理端；将多个统计时间分段的处理成功率进行加权求和，且权重按照各个统计时间分段距离当前时间的时间距离进行区分，得到所述统计时间段的处理成功率，作为所述处理结果表中与处理影响参数和处理端对应的成功率。在一个例子中，成功率统计模块55，还用于若在所述统计时间段的至少其中一个统计时间分段内，业务处理数量未达到预设的数量阈值，则在所述处理影响参数对应的处理结果表中，不再统计记录所述处理影响参数和处理端对应的处理成功率。以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。当前第1页1 2 3