机票业务监控执行系统及方法与流程

本发明属于数据监控处理技术领域，涉及一种机票业务的监控处理系统及方法。

背景技术：

机票资源供应系统用于向下对接不同供应商的外部接口，向上提供统一标准的查询、验舱验价、占位、出票等服务。系统依赖的外部接口分布且独立，接入的供应商越多，对服务的延迟和容错管理挑战越大，因此系统和业务监控对于这样一个底层业务支撑系统来说必不可少。传统的系统和业务监控，异常发生时，管理员、运维和技术人员需要在收到报警后，开始介入操作，甚至需要24小时的值班值守，人力成本高，且响应不及时。现有技术中的系统监控，也有几种改进的解决方案，但均有各自缺陷：

1.zabbix能够监视系统参数，保证服务器的安全运营，提供通知机制让系统管理员快速定位解决问题。zabbix提供的是系统性能指标监控，如cpu、内存使用、磁盘io、网络连接等，但当外部接口调用失败，或是指定业务场景异常，则无法完成监控。

2.elk(elasticsearch+logstash+kiabana)是开源实时日志分析工具，能够通过系统埋点收集和分析日志进行统计搜索，完成可视化的业务监控。elk可以提供数据展示，但需要人工值守，且不提供异常后的接口熔断和自动恢复。

3.hystrix提供了依赖系统间的延迟和容错处理，能隔离远程系统，防止级联失败，在外部接口出现超时、异常时自动熔断，隔离该接口调用，避免由此导致自身系统出现问题，并能延时恢复。hystrix是以单接口为单元进行监控，无法串行业务流程，也无法精确判断业务是否恢复，不能够及时止损。

综上所述，目前没有成熟的方案能够针对机票依赖的外部接口进行自动监控，并根据业务场景需要自动关闭和自动恢复业务流，实现无人职守监控并自动执行操作。

技术实现要素：

为解决上述问题，本发明公开了一种机票业务监控执行系统及其实现方法，能够针对机票依赖的外部接口进行自动监控，并根据业务场景需要自动关闭和自动恢复业务流，实现无人职守监控并自动执行操作。

为了达到上述目的，本发明提供如下技术方案：

机票业务监控执行系统，包括信息采集模块、统计模块、开启控制器和关闭控制器，

所述信息采集模块用于在外部接口调用的开始点对接口的本次调用进行计数，输入到统计模块，统计该接口的总请求数；并在外部接口调用的结束点判断接口的调用结果是否异常或超时，若非则计算本次调用的耗时输入到统计模块；若异常，则进行异常分析后获取异常信息将异常信息输入到统计模块，当超时或出现不可忽略的异常时触发关闭控制器开始工作；

所述统计模块用于存储每次外部接口调用的数据，数据包括总请求数、耗时和异常信息；

所述关闭控制器用于监控出现异常的接口，在每个接口每时间单位发生第一次异常或超时时，开启一个监控任务，各监控任务彼此独立且具有生命周期；每个任务每时间单位计算一次本接口在m1～mx时间段内的异常率和平均耗时，当异常率和平均耗时其中任一超过阈值时触发供应商关闭，停止该供应商的所有接口的所有任务，触发开启控制器工作检测该供应商，其中m1为本任务开始时间单位,mx为计算时的时间单位；

所述开启控制器用于对关闭控制器关闭的供应商进行业务恢复检测，在供应商重新启动前按顺序循环调用供应商的查询、验舱验价、占位、出票、取消占位接口，当所有接口流程成功时为成功轮，并计算自该成功轮开始、后续若干轮的成功率，当成功率超过开启阈值时开启该供应商。

进一步的，所述关闭控制器开启的监控任务初始时具有等待期，在等待期不触发关闭。

具体的，异常率和平均耗时通过如下公式计算：

异常率＝uniqueexeceptcount/(querycount-skipcount)*100％

平均耗时＝timecost/(querycount-execeptcount)

querycount为总请求数之和，execeptcount为总异常数之和，skipcount为忽略异常数之和，timecost为总耗时之和，uniqueexeceptcount为唯一的异常键个数。

进一步的，所述开启控制器调用查询接口时从供应商航线中随机抽取一条，进行查询；调用验舱验价时从查询结果中随机选定一个机票资源，进行验舱验价；调用占位接口时以选定的机票资源，随机选取预置乘机人和联系人进行占位，生成供应商订单号。

进一步的，所述开启控制器进行业务恢复检测时生成的订单自动取消，重试有间隔。

机票业务监控执行方法，包括如下步骤：

步骤1，在外部接口调用的开始点对接口的本次调用进行计数，统计该接口的总请求数；

步骤2，在外部接口调用的结束点判断接口的调用结果是否异常或超时，若非，则计算本次调用的耗时；若异常，则进行异常分析后，获取异常信息并统计，当超时或出现不可忽略的异常时执行步骤3；

步骤3，监控出现异常的接口，在每个接口每时间单位发生第一次异常或超时时，开启一个监控任务，各监控任务彼此独立且具有生命周期；每个任务每时间单位计算一次本接口在m1～mx时间段内的异常率和平均耗时，当异常率和平均耗时其中任一超过阈值时触发供应商关闭，停止该供应商的所有接口的所有任务，执行步骤4，其中m1为本任务开始时间单位,mx为计算时的时间单位；

步骤4，对步骤3中关闭的供应商进行业务恢复检测，在供应商重新启动前按顺序循环调用供应商的查询、验舱验价、占位、出票、取消占位接口，当所有接口流程成功时为成功轮，并计算自该成功轮开始、后续若干轮的成功率，当成功率超过开启阈值时开启该供应商。具体的调用方式参见对本发明系统的描述。

进一步的，所述关闭控制器开启的监控任务初始时具有等待期，在等待期不触发关闭。

具体的，异常率和平均耗时通过如下公式计算：

异常率＝uniqueexeceptcount/(querycount-skipcount)*100％

平均耗时＝timecost/(querycount-execeptcount)

querycount为总请求数之和，execeptcount为总异常数之和，skipcount为忽略异常数之和，timecost为总耗时之和，uniqueexeceptcount为唯一的异常键个数。

进一步的，所述开启控制器调用查询接口时从供应商航线中随机抽取一条，进行查询；调用验舱验价时从查询结果中随机选定一个机票资源，进行验舱验价；调用占位接口时以选定的机票资源，随机选取预置乘机人和联系人进行占位，生成供应商订单号。

进一步的，所述步骤4中生成的订单自动取消，重试有间隔。

与现有技术相比，本发明具有如下优点和有益效果：

1.实时监控外部供应商接口的响应时间和异常情况，能够对数据进行统计及实时可视化展示，此外能够在数据(瞬时值、平均值等)发生异常时实时报警，并且自动执行关闭业务。

2.执行关闭时基于时间和任务二个维度计算数据，判断接口超时、异常比例超过阈值时，自动执行关闭供应商，并提供报警,算法精确优化，检查精度高，响应及时。由于每次异常开启一个独立任务，互不干涉，能够实现有目的监控，每个任务有精准的时间区间，可以将延迟控制到尽可能小。

3.采用结合机票业务流程的循环检测方法对外部接口进行恢复检查，自动重试其业务流程，精确判断供应商接口状态，并在供应商恢复后第一时间自动执行打开供应商操作，判断准确，响应及时，对客无感知，不影响用户体验。

附图说明

图1为机票业务标准流程图。

图2为本发明系统流程图。

图3为本发明采集数据的存储结构。

图4为关闭控制器中监控任务示例。

图5为开启控制器中检测轮次示例。

具体实施方式

以下将结合具体实施例对本发明提供的技术方案进行详细说明，应理解下述具体实施方式仅用于说明本发明而不用于限制本发明的范围。

机票业务的标准流程如图1所示，图中的每个步骤为一个独立接口，主要包括以下几个接口：

1.查询:指定出发日期和航线，返回包含航班、舱位、价格、余位数的列表，其中航班、舱位、价格的组合构成了一个机票资源。

2.验舱验价：选定一个机票资源，返回价格是否变化(验价)，余位数是否充足(验舱)。

3.占位：选定一个机票资源，指定乘机人、联系人信息，为其占位并生成供应商订单号。

4.支付：根据供应商订单号，向供应商支付票款。

5.出票：支付成功后，根据供应商订单号向供应商索取票号。

6.退改签规则查询：选定一个机票资源,返回其退票改期的规则及费用。

7.取消占位：占位成功后，根据供应商订单号取消订单。

其中1～5接口为机票预订的必经流程，6、7为非必经流程。

除查询接口外，每个步骤接口的入参都有唯一的入参标识，验舱验价、占位、退改签规则查询为机票资源号，支付、出票、取消占位为供应商订单号。入参标识用于唯一标识一类请求。除入参标识外，对于每一个接口，还有如下几个关键参数：供应商编码，用于唯一标识一家供应商；接口名，即查询、验舱验价、占位等，用于标识接口；异常码，是针对每一类接口异常定义的一套异常码，用于唯一标识一类异常。

外部供应商可能会在任意一个步骤发生异常，但其他步骤正常。如：仅查询接口异常，或查询、验舱验价正常，仅占位接口异常等。鉴于此，本方法对每家供应商的每一个外部接口，都独立拆分进行最小粒度监控。

本发明系统对每一个外部接口的调用，都会监控其开始点和结束点，在这两点上进行一系列的信息监控、统计和事件触发。本发明在技术实现上使用了aop(aspect-orientedprogramming)面向切片的编程，保证代码一致、高复用。

本发明系统包括信息采集模块、统计模块、开启控制器和关闭控制器。

其中，信息采集模块用于在外部接口调用的开始点对接口的本次调用进行计数，输入到“统计模块”，统计该接口的总请求数；并在外部接口调用的结束点判断接口的调用结果是否异常或超时，若非则计算本次调用的耗时输入到统计模块；若异常，则进行异常分析后获取异常信息将异常信息输入到统计模块，当超时或出现不可忽略的异常时发出通知并触发关闭控制器开始工作，在接下来一段时间内单独监控该接口。

我们定义一类可忽略的异常，此类异常并非由外部接口错误导致，主要为接口入参错误，如：格式错误、编码错误、资源错误、乘客信息有误、订单号错误等。本发明中，可忽略的异常不需要触发关闭控制器，但需要输入到统计模块进行存储。

统计模块用于收集每次外部接口调用的数据，如总请求数、耗时、异常信息等，并按照本方法定义的数据类型和数据结构进行存储。数据可供实时展示，更重要的是作为关闭控制器和开启控制器的判断依据。

本发明以redis实现数据结构设计及存储，redis为内存数据库，实时性好、支持并发高、分布式方便扩展，适用于本方法的实时监控，可快速更新数据和执行操作。以redis的hash结构存储统计数据，最小的监控粒度为“供应商+接口”，最小时间粒度为1分钟，每个供应商接口每分钟会生成储一份“统计数据”和一份“异常详情数据”。

以东航(mu)的查询(query)接口为例，redis的key设计如图3所示为：前缀+供应商编码+接口名+时间戳(分钟)。前缀s代表统计(statistics)，d代表详情(detail)。

s_mu_query_201703151211：东航查询接口在2017-03-1512:11的统计数据

d_mu_query_201703151211：东航查询接口在2017-03-1512:11的异常详情数据

统计数据的内容包含当前分钟的：总请求数，总异常数，忽略异常数，总耗时。通过redis的hincrby命令进行计数，保证实时性和原子性。每次统计时，数量增幅为1，总耗时增幅为一次耗时。

异常详情数据主要服务于关闭控制器，并且作为展示和分析关闭原因的依据，因此异常详情不记录忽略异常。异常键为入参标识和异常码的唯一组合，不同的异常键，分别通过hincrby命令进行计数加1。这样设计的目的，是把具有相同入参和异常的请求归为一类，不重复计算。比如，当一次异常发生后，用户可能会重复尝试多次相同的操作，要过滤掉这部分操作对统计占比的影响，防止由此触发的关闭控制器误判和误关闭。

通过统计模块获取数据后，能够将数据内容进行展示，数据内容样例如下表1所示：

表1

上表为10分钟内4家供应商的统计数据，分别为查询、验舱验价、占位、支付、出票五个必经流程接口，其中每一个单元格内具体内容为：

异常率(不可忽略异常量/(总调用量-忽略异常量))[关闭阈值]

平均耗时秒数[关闭阈值]

以东航查询接口为例，表示共有391次调用，10次不可忽略异常，异常率为2.6％(超过60％需要关闭)；非异常时的平均耗时为3.3秒(超过20秒需要关闭)。

关闭控制器用于在每个接口，每分钟发生第一次异常或超时时，开启一个监控任务t1，从当前分钟m1开始，最多持续10分钟，即t1的生命周期可记为m1～m10。需要说明的是，前述的当发生异常或超时时开启监控任务的时间间隔“每分钟”仅为示例，根据需要，也可以调整该时间间隔，同样的，监控任务的生命周期“10分钟”也可以根据需要改变。

以t1为例，其任务为每分钟(mx，x代表分钟数1～10，可以根据需要调整)计算一次本接口在m1～mx时间段内的异常率和平均耗时。当任何一个超过阈值，则触发关闭，当任意任务触发供应商关闭后，该供应商的所有接口的所有任务都会停止。若满10分钟不超阈值，则本次任务结束。不同分钟mx发生了异常会开启不同的任务tx，每个任务的逻辑相同但作用的时间段互不干涉。由于每次异常开启一个独立任务，互不干涉，能够实现有目的监控，每个任务有精准的时间区间，可以将关闭延迟控制到尽可能小。

异常率和平均耗时通过如下方式计算：

从redis中读取m1～mx分钟内所有统计数据s1～sx，分别对每个字段求和，得到：总请求数之和querycount，总异常数之和execeptcount，忽略异常数之和skipcount，总耗时之和timecost。

从redis中读取m1～mx分钟内异常详情d1～dx包含的所有异常键，去掉重复的异常键，得到唯一的异常键个数uniqueexeceptcount。

异常率＝uniqueexeceptcount/(querycount-skipcount)*100％

平均耗时＝timecost/(querycount-execeptcount)

为了减少接口扰动带来的影响，任务的前3分钟为等待期，在等待期不触发关闭。等待期时间也可以根据需要调整。

图4模拟了一次关闭控制发生的场景，第一行表示在第1、3、4、6、7、8分钟发生了异常(深灰色)，第二行表示该分钟内的异常率，可见6～8分钟为系统异常高峰期。t1、t3、t4、t6、t7、t8表示因为发生的异常开启6个不同的任务(灰色)。设定异常率的阈值为50％，由数据可见，t1、t3、t4在各自执行时间段内均未超过阈值，t6在3分钟等待期后因异常率超过阈值触发了关闭，其他任务也同时停止。

触发关闭后还会做关闭记录，包含了忽略异常占比、非重复异常比，为后续分析关闭原因、统计供应商接口质量提供数据支持。

忽略异常占比和非重复异常比通过如下公式计算：

忽略异常占比＝skipcount/execeptcount

非重复异常比＝uniqueexeceptcount/(execeptcount-skipcount)

关闭控制器触发关闭后，触发开启控制器工作，发起该供应商的开启控制流程。

开启控制器以供应商为粒度进行，关注其查询、验舱验价、占位、出票、取消占位五个接口，按顺序调用这些接口：

1.以5-15天的随机出发日期，从供应商航线中随机抽取一条，进行查询。上述5-15天日期区间可以根据需要调整。

2.从查询结果中随机选定一个机票资源，进行验舱验价。

3.以选定的机票资源，随机选取预置乘机人和联系人进行占位，生成供应商订单号。

4.调用支付接口会产生交易和实际费用，因此跳过支付步骤。

5.以供应商订单号尝试出票，预期结果为未支付且未出票。

6.以供应商订单号取消占位，释放机票资源，结束本轮。

当所有接口流程成功时，则本轮结果为成功，任何一步失败，则本轮结果为失败。完成一轮后，若成功间隔5秒，若失败间隔15秒，然后进行下一轮。

因为开启控制器会随机选择航线和机票资源，不同轮之间可以认为入参唯一，因此不需要考虑由于相同的入参导致了相同异常的问题。另外，随机查询分散了出发日期、航线和航班，并且生成订单会自动取消，重试有间隔，因此不会造成对机票资源的损耗或恶意占位。

每成功一轮，就开始计算自本轮起10轮的成功率，超过开启阈值(默认60％)则认为达到恢复条件。如图5，每轮结果深灰色表示失败，浅灰色表示成功，其中第1、3、4、6、9、10、11、12轮失败，第2、5、7、8、13、14、15、16轮成功。第2轮成功，计算2～11轮，成功占比40％；第5轮成功，计算5～14轮，成功占比50％；第7轮成功，计算7～16轮，成功占比60％，完成开启。

结果检查由成功轮触发，且满足阈值后立即执行开启，由图5的数据可以看出，13轮之后开始恢复正常，本方法在第16轮完成开启。在避免开启误判的同时，保证了业务恢复判断的精度高，响应快。

本发明方法整体流程如图2所示，包括如下步骤：

步骤1，在外部接口调用的开始点对接口的本次调用进行计数，统计该接口的总请求数；

步骤2，在外部接口调用的结束点判断接口的调用结果是否异常或超时，若非，则计算本次调用的耗时；若异常，则进行异常分析后，获取异常信息并统计，当超时或出现不可忽略的异常时发出通知并执行步骤3；

本步骤中，统计的异常信息包括统计数据和详情数据，其中，统计数据包括总请求数、耗时、忽略异常数，总耗时，详情数据包括不同异常键对应的数量。这些数据用于可视化展示和步骤3的关闭控制。展示数据包括异常率、不可忽略异常量、总调用量-忽略异常量、异常率关闭阈值、平均耗时秒数、耗时关闭阈值。

步骤3，监控出现异常的接口，在每个接口每分钟发生第一次异常或超时时，开启一个生命周期最多为10分钟的监控任务，任务每分钟计算一次本接口在m1～mx时间段内的异常率和平均耗时，其中m1为本任务开始分钟,mx为计算时的分钟；当异常率和平均耗时其中任一超过阈值时触发供应商关闭，停止该供应商的所有接口的所有任务，执行步骤4；

异常率和平均耗时根据步骤3中获取的总请求数、耗时和异常数据获得，具体计算公式及相应示例参见本发明系统中详细描述。

本步骤中在出发供应商关闭后还会进行关闭记录，关闭记录包括忽略异常占比、非重复异常比。

作为改进，每个监控任务初始前3分钟为等待期，在等待期不触发关闭。

步骤4，对步骤3中关闭的供应商进行业务恢复检测，关注供应商查询、验舱验价、占位、出票、取消占位接口，在供应商重新启动前按顺序循环调用这些接口，当所有接口流程成功时为成功轮，并计算自该成功轮开始、后续若干轮的成功率，当成功率超过开启阈值时开启该供应商。具体的调用方式参见对本发明系统的描述。

本发明方案所公开的技术手段不仅限于上述实施方式所公开的技术手段，还包括由以上技术特征任意组合所组成的技术方案。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围。