互联网业务链路调用情况的统计、展示方法及装置
技术领域
本申请涉及互联网技术领域,尤其涉及一种互联网业务链路调用情况的统计方法及装置,以及一种互联网业务链路调用情况的展示方法及装置。
背景技术
随着互联网的发展,互联网业务越来越丰富,为了方便互联网业务(简称“业务”)的执行,会为建立若干应用,各司其职,这就出现为了一个业务能够顺利执行,会调用多个应用,在调用过程中就形成了一个链路,并且有些业务的调用链路非常复杂。
在执行一个业务时,每次调用都会生成一个调用日志,记录了一些静态属性和动态属性,静态属性可以包含请求应用、接收应用和调用方法等信息;动态属性可以包含业务请求时间、业务完成时间、完成情况等信息。当业务出现错误时,可以通过查询调用日志来解决问题。
但目前,还没有从业务角度考虑业务链路的调用情况,换句话说,还没有从整体业务的角度,对整个业务的链路的调用情况进行统计。
发明内容
本申请实施例提供一种互联网业务链路调用情况的统计方法,用于提供一种从业务角度对整个业务的链路的调用情况进行统计的方案。
本申请实施例提供一种互联网业务链路调用情况的统计装置,用于提供一种从业务角度对整个业务的链路的调用情况进行统计的方案。
本申请实施例提供一种互联网业务链路调用情况的统计方法。
本申请实施例提供一种互联网业务链路调用情况的统计方法。
本申请实施例采用下述技术方案:
一种互联网业务链路调用情况的统计方法,包括:
获取针对互联网业务链路的调用日志,每条业务链路具有唯一链路标识,且对应至少一个调用日志,每个调用日志中包含静态属性、动态属性;
将相同唯一链路标识对应的调用日志进行聚合,生成单个链路树,每个单个链路树中包含根据调用日志生成的静态属性;
根据每个单个链路树中包含的静态属性,生成链路结构标识;
将相同链路结构标识对应的单个链路树进行聚合,生成整合链路树,每个整合链路树中包含根据调用日志生成的动态属性;
根据整合链路树中包含的动态属性,统计互联网业务不同链路的调用情况。
优选地,每个调用日志中还包含业务类型标识,则所述方法还包括:
将相同业务类型标识对应的整合链路树进行聚合,生成业务链路树,所述业务链路树中包含根据调用日志生成的静态属性和动态属性;
根据业务链路树中包含的静态属性和动态属性,统计不同类型的互联网业务中业务链路的调用情况。
优选地,获取针对互联网业务链路的调用日志,包括:
获取指定时段的针对互联网业务链路的调用日志。
优选地,每个调用日志的静态属性中还包含请求应用和接收应用,则
将相同唯一链路标识对应的调用日志进行聚合,生成单个链路树,包括:
根据指定请求应用和/或接收应用,将相同唯一链路标识对应的调用日志进行聚合,生成单个链路树。
优选地,所述方法还包括:
将不同整合链路树以及对应的调用情况以映射关系保存在数据库中。
优选地,所述方法还包括:
将不同互联网业务类型以及对应的调用情况以映射关系保存在数据库中。
一种互联网业务链路调用情况的统计装置,包括:日志获取单元、第一聚合单元、结构生成单元、第二聚合单元以及统计单元,其中,
所述日志获取单元,用于获取针对互联网业务链路的调用日志,每条业务链路具有唯一链路标识,且对应至少一个调用日志,每个调用日志中包含静态属性、动态属性;
所述第一聚合单元,用于将相同唯一链路标识对应的调用日志进行聚合,生成单个链路树,每个单个链路树中包含根据调用日志生成的静态属性;
所述结构生成单元,用于根据每个单个链路树中包含的静态属性,生成链路结构标识;
所述第二聚合单元,用于将相同链路结构标识对应的单个链路树进行聚合,生成整合链路树,每个整合链路树中包含根据调用日志生成的动态属性;
所述统计单元,用于根据整合链路树中包含的动态属性,统计互联网业务不同链路的调用情况。
优选地,每个调用日志中还包含业务类型标识,则所述装置还包括:第三聚合单元,其中,
所述第三聚合单元,用于将相同业务类型标识对应的整合链路树进行聚合,生成业务链路树,所述业务链路树中包含根据调用日志生成的静态属性和动态属性;
所述统计单元,用于根据业务链路树中包含的静态属性和动态属性,统计不同类型的互联网业务中业务链路的调用情况。
优选地,所述日志获取单元,具体用于:
获取指定时段的针对互联网业务链路的调用日志。
优选地,每个调用日志的静态属性中还包含请求应用和接收应用,则
所述第一聚合单元,具体用于:
根据指定请求应用和/或接收应用,将相同唯一链路标识对应的调用日志进行聚合,生成单个链路树。
优选地,所述装置还包括:数据存储单元,具体用于:
将不同整合链路树以及对应的调用情况以映射关系保存在数据库中。
优选地,所述数据存储单元,具体用于:
将不同互联网业务类型以及对应的调用情况以映射关系保存在数据库中。
一种互联网业务链路调用情况的展示方法,其特征在于,包括:
接收针对整合链路树和/或互联网业务类型的查看请求;
根据所述查看请求,将保存在数据库中的、所述整合链路树和/或互联网业务类型对应调用情况,进行展示。
一种互联网业务链路调用情况的展示装置,其特征在于,包括:查看请求获取单元以及调用情况展示单元,其中,
所述查看请求获取单元,用于接收针对整合链路树和/或互联网业务类型的查看请求;
所述调用情况展示单元,用于根据所述查看请求,将保存在数据库中的、所述整合链路树和/或互联网业务类型对应调用情况,进行展示。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:根据获取的互联网业务链路的调用日志中的唯一链路标识,对调用日志以及包含的静态和动态属性进行聚合,生成单个链路树;再根据静态属性,将相同结构的单个链路树进行聚合,生成整合链路树,并根据整合链路树中的动态属性,对不同链路的调用情况进行统计。达到了从业务角度对整合业务的链路的调用情况进行统计的目的。此外,还可以将不同整合链路树和不同互联网业务类型对应的调用情况保存在数据库中,以便用户可以对调用情况进行查询。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为本申请实施例1提供的一种互联网业务链路调用情况的统计方法的流程示意图;
图2为本申请实施例2提供的一种互联网业务链路调用情况的统计装置的结构框图;
图3为本申请实施例3提供的一种互联网业务链路调用情况的展示方法的流程示意图;
图4为本申请实施例4提供的一种互联网业务链路调用情况的展示装置的结构框图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
以下结合附图,详细说明本申请各实施例提供的技术方案。
实施例1
如前所述,目前只是在业务执行时,对每次发生的调用都会生成给一个调用日志,记录了一些静态属性和动态属性,当出现问题时可以通过翻看日志来解决。比如,一个互联网业务,通过应用A调用应用B,再调用应用C来完成,并在每次调用时都生成调用日志,当出现问题时,可以翻看调用日志找到具体哪个应用出现问题,并解决。但是,目前还没有从业务角度对业务链路的调用情况进行分析,比如,对于一条业务链路而言,出错的概率有多高,在高峰时段是否能够胜任,具体哪个环节出问题的概率最高,等等。也就是,还没有从整体业务的角度,对整个业务的链路的调用情况进行统计,那么也就无法有针对性的对业务链路进行优化,想要提高业务的可用性和稳定性也无从下手。所以,发明人提出了一种互联网业务链路调用情况的统计方法,用于提供一种从业务角度对整个业务的链路的调用情况进行统计的方案。该方法的流程示意图如图1所示,包括下述步骤:
步骤11:获取针对互联网业务链路的调用日志。
在每个互联网业务执行的过程中,都会产生一条业务链路,该链路中会至少有一个应用,通过调用应用来完成这个业务,如果有多个应用,就可以通过依次调用来完成这个业务,每次调用都会生成一个调用日志,所以每条业务链路都会至少对应一个调用日志。
在业务开始时,可以生成一个全局唯一的链路标识(下文简称“Trace ID”),每次调用一个应用时,这个Trace ID都可以记录在这次调用的调用日志中而不会变更,所以该调用日志就可以包含所属业务链路的Trace ID;除此之外,调用日志中还可以包含静态属性和动态属性,静态属性可以表示业务链路的基本信息,比如调用方法,可以通过RPC(Remote Procedure Call Protocol,远程过程调用协议)实现调用;IPC(Inter process communication,进程间通信)等实现调用;动态属性可以表示trace的动态信息,比如,业务发生时间、业务完成时间、请求文件的大小、返回文件的大小,耗时,业务状态等等。
在本步骤中,就可以先获取针对互联网业务的调用日志,每个日志中就包含了两种属性以及所属业务链路的Trace ID。比如,对于“业务链路1”而言,通过应用A调用应用B,再调用应用C来实现(简称“A→B→C”),应用A会生成调用日志a,其中记录了调用方法为RPC,业务发生时间、业务完成时间,耗时,业务状态;类似地,应用B生成了调用日志b,应用C生成了调用日志c;每个调用日志中还都包含了“业务链路1”的唯一链路标识Trace 1。
在实际应用中,可能出现不同时段的业务量是不同的情况,比如,9:00-18:00属于工作时间,互联网业务可能就不如19:00-22:00的休闲时间多。而不同时段,对于调用情况中的一些属性也是要求不同的,比如,休闲时间的调用过程的耗时可以较长,而休闲时间,为了最大程度满足可用性,调用过程的耗时需要尽量缩短。所以,为了达到分别统计不同时段的互联网业务链路调用情况的目的,在一种实施方式中,获取针对互联网业务链路的调用日志,可以包括:获取指定时段的针对互联网业务链路的调用日志。
步骤12:将相同唯一链路标识对应的调用日志进行聚合,生成单个链路树。
在步骤11中,已经获取到了调用日志,但这些调用日志都还只是单独的个体,上一步骤已经介绍,每个互联网业务执行的过程中,都会产生一条业务链路,每条业务链路下,又会至少对应一个调用日志,并且极大多数业务链路会对应很多调用日志,由于每个调用日志都包含所属业务链路的Trace ID,所以就可以将相同Trace ID对应的调用日志进行聚合从而生成单个的链路树(下文简称“trace”)。由于单个trace就是将相同Trace ID对应的调用日志进行聚合得到的,所以每个单个trace中可以包含根据调用日志生成的静态属性,当然调用日志的动态属性也可以包含在单个trace中,但不是必需的。比如,依旧以步骤11中的“业务链路1”为例,Trace 1就会对应一个单个链路树trace 1,表示“业务链路1”执行中调用应用的过程,根据调用日志a、b、c中的调用方法等静态属性,就可以聚合生成单个trace 1的静态属性,也就形成了Trace 1与单个trace 1的对应关系,这对关系中还包含各种静态属性(及属性值)。
既然每个调用日志都记录了调用的情况,那么调用日志中也就还可以包含请求应用和接收应用,比如,依旧以“A→B→C”为例,调用日志b中请求应用就为应用A,接收应用就为应用C,或者应用B还可能有两个调用日志,第一个调用日志b1中请求应用为应用A、接收应用为应用B,而另一个调用日志b2中请求应用为应用B、接收应用为应用C。
在实际应用中,可能根据不同的需求,忽略或暂时没有必要将某个或某些应用加入到单个trace中来统计调用情况,比如,入口应用(最开始发起业务的应用),或者出口应用(最终完成业务的应用),或者中间的应用,为了达到在生成单个trace时能够灵活取舍应用的目的,在一种实施方式中,本步骤可以包括:根据指定请求应用和/或接收应用,将相同唯一链路标识对应的调用日志进行聚合,生成单个链路树。比如,应用A为入口应用,统计时不想统计与应用A相关的调用情况,那么就可以将应用A排除在外。
在实际提供互联网业务,往往会利用计算机集群的分布式处理能力,所以,在该步骤中,可以利用“MapReduce”的思路更高效的进行处理。具体地,先提取所有计算机中的调用日志中的包含的所属业务链路的Trace ID,并将同一个Trace ID对应的所有调用日志移动至一个计算机中,这样,每个计算机中,就都是不同Trace ID的所有调用日志,之后在每个计算机中生成单个trace。
步骤13:根据每个单个链路树中包含的静态属性,生成链路结构标识。
在步骤12中生成了不同Trace ID对应的单个trace,虽然每个trace与TraceID具有对应关系,且由于Trace ID是全局唯一的,所以trace也是全局唯一,但是,步骤11中已经介绍,静态属性可以表示业务链路的基本信息,比如,调用方法,又如步骤12中介绍的请求应用和接收应用,是相对固定的,也就是说,即使trace与Trace ID的对应关系全局唯一,但是有可能出现不同的trace中的静态属性相同。比如,都用同一种调用方法,相同的请求应用和接收应用。所以就可以根据每个单个trace包含的静态属性,生成链路结构标识(下文简称“trace Key”)。可以认为只要静态属性是相同的,那么链路的结构就是相同的,比如“业务链路1”中,调用关系都是“A→B→C”,且调用方法都可以是RPC,那么就可以认为链路的结构是相同的。
生成trace Key的实现方式可以是根据多个静态属性(及属性值)生成多个字段的文件,也可以采用HASH函数对多个静态属性(及属性值)进行数值映射。
在上一步骤中介绍了可以利用“MapReduce”的思路进行处理,在本步骤中,就可以在每个计算机中,根据每个单个trace,生成trace Key。
步骤14:将相同链路结构标识对应的单个链路树进行聚合,生成整合链路树。
在步骤12中,已经生成了单个trace,但这些单个trace也只是针对某一个调用链路而言的,在上一步骤中已经介绍,虽然Trace ID与对应的trace是全局唯一的,但是不同的trace也是有相同的链路结构的,所以本步骤就可以将相同的trace Key对应的单个trace进行聚合,生成整合trace。这个整合trace就是针对某一种业务链路而言的。
具体地,就可以是将具有相同trace Key的单个trace中对应的调用日志的部分或全部动态属性整合在一起,比如可以以列表的形式,通过行列整合调用日志的动态属性,生成的每个整合trace中也就包含了调用情况的动态属性,当然也可以包含静态属性,但是静态属性是相同,所以也就不是必需的。比如,可以将多个“A→B→C”的单个trace的整合在一起,形成“业务链路1”的所有调用情况,这其中就包含所有“A→B→C”对应的调用日志的动态属性(及属性值)。
步骤15:根据整合链路树中包含的动态属性,统计互联网业务不同链路的调用情况。
在步骤14中已经生成了整合trace,并且包含了整个链路的动态属性,所以就可以根据整合trace中包含的动态属性,来统计互联网业务中针对不同链路的调用情况。
动态属性中可以包含业务发生时间、业务完成时间、请求文件的大小、返回文件的大小,耗时,业务状态等等。比如平均文件大小、平均完成时间、每个调用环节的品均耗时等;业务状态中还可以包括00(成功)、01(失败)、02(超时失败)等属性值,所以也可以统计一条业务链路的成功率。
这个步骤也可以利用“MapReduce”的思路进行处理,具体地,先以相同traceKey作为键,将单个trace作为值;然后将所有相同trace Key单个trace移动到一个计算机中,通过聚合生成整合trace,在聚合后,就可以根据整合trace中的动态属性,统计互联网业务不同链路的调用情况。
为了达到方便用户浏览的目的,在一种实施方式中,还可以将不同整合链路树以及对应的调用情况以映射关系保存在数据库中。当用户输入某条链路时,就可以根据映射关系,查找这条链路对应的调用情况,并进行展示。
在实际应用中,对于一条业务链路的调用情况的统计,也只能是片面的针对单独的业务链路,而在实际的互联网业务中,业务是可以分为不同类型的,比如大多数网站会有注册、登记业务,考试网站会有报名、查询业务,购物网站会有搜索、下单、支付、退款等业务。完成某个业务,可能会有不同的业务链路作为支持,而不同的链路的重要性也可能不尽相同,所有,为了达到更加全面的对互联网业务链路的调用情况进行统计,也就可以从互联网业务类型的角度来考虑。
具体地,可以在业务开始时,生成一个业务码(下文简称“btype”),来表示不同的业务类型,每次调用一个应用时,这个btype就可以记录在这次调用的调用日志中而不会变更,所以每个调用日志中就还可以包含业务类型的标识,通过btype来表示,比如btype=register(注册),btype=Payment(支付),btype=Face_to_Face_Payment(当面支付),等。
调用日志中有了业务码,那么单个trace中也就可以有对应的业务码,同理,整合trace中也就可以有对应的业务码。所以本实施例还可以有
步骤16:将相同业务类型标识对应的整合链路树进行聚合,生成业务链路树。
在步骤12和步骤14中,都分别根据Trace ID和trace Key,生成了单个trace和整合trace,在本步骤中,类似地,根据btype,将相同btype对应的整合trace进行聚合,聚合的过程,也可以和前步骤类似,可以将具有相同btype的整合trace中的部分或全部动态属性整合在一起,比如可以以列表的形式,通过行列将所有整合链路树的静态属性和动态属性进行整合,生成业务链路树。该业务trace中,就包含了某个业务类型的所有调用情况。
在整合后,就可以根据业务链路树中包含的静态属性和动态属性,统计不同类型的互联网业务中业务链路的调用情况了,具体地,可以统计每个应用被调用的次数,从而通过调用比例来确定出应用的重要性,还可以根据步骤15中确定出的每条链路的成功率,综合的判断每个应用或每条链路的重要性,还可以推断出应用之间的强弱依赖关系。
这个步骤也可以利用“MapReduce”的思路进行处理,具体地,先以相同btype作为键,将整合trace作为值;然后将所有相同btype的整合trace移动到一个计算机中,通过聚合生成业务trace,在聚合后,就可以根据业务trace中的静态属性和动态属性,统计不同类型的互联网业务中业务链路的调用情况。
上一步骤中为了达到方便用户浏览的目的,将不同整合链路树以及对应的调用情况以映射关系保存在数据库中,类似地,本步骤也可以将不同互联网业务类型以及对应的调用情况以映射关系保存在数据库中。当用户输入某个业务类型时,就可以根据映射关系,查找这个业务类型对应的调用情况,并进行展示。
采用实施例1提供的该方法,根据获取的互联网业务链路的调用日志中的唯一链路标识,对调用日志以及包含的静态和动态属性进行聚合,生成单个链路树;再根据静态属性,将相同结构的单个链路树进行聚合,生成整合链路树,并根据包含的动态属性,对不同链路的调用情况进行统计。达到了从业务角度对整合业务的链路的调用情况进行统计的目的。此外,还可以为调用日志添加业务类型,从而可以根据相同的业务类型,将整合链路树再次进行聚合,生成业务链路树,也就更加立体地,从不同业务类型的角度,对不同业务的调用情况进行了统计;为了达到方便用户浏览的目的,还有将调用情况与不同链路和不同业务类型链路,以映射的关系进行存储。
实施例2
基于相同的发明构思,实施例2提供了一种互联网业务链路调用情况的统计装置,用于提供一种从业务角度对整个业务的链路的调用情况进行统计的方案。图2为该装置的结构框图,该装置包括:日志获取单元21、第一聚合单元22、结构生成单元23、第二聚合单元24以及统计单元25,其中,
日志获取单元21,可以用于获取针对互联网业务链路的调用日志。
在实际应用中,本实施例可以通过分布式计算机集群来完成,当日志获取单元21被触发后,去获取散落保存在所有计算机中的调用日志,每条业务链路具有唯一链路标识,且对应至少一个调用日志,每个调用日志中包含静态属性、动态属性以及所属业务链路的Trace ID。
由于各个时间段对于业务链路的要求可能不用,所以,在一种实施方式中,日志获取单元21可以用于:获取指定时段的针对互联网业务链路的调用日志。比如,根据调用日志中的业务发生时间,进行筛选。
第一聚合单元22,可以用于将相同唯一链路标识对应的调用日志进行聚合,生成单个链路树。
当获取到所有调用日志后,就可以调用第一聚合单元22,用于将具有相同Trace ID的调用日志都移动到一台计算机中,比如,Trace 1~Trace 100的调用日志被全部移动到计算机1中,Trace 101~Trace 200的调用日志被全部移动到计算机2中,等等,这里可以假设N个Trace ID对应的调用日志被均匀分配到所有的计算机中,更加提高效率。
之后每台计算机,开始并行分别对每个Trace ID的调用日志进行聚合,生成单个trace;由于每个调用日志中包含了静态属性,所以每个单个trace中包含根据调用日志生成的静态属性。
在实际应用中,可以根据实际的需求忽略或重点对某个或某些应用的统计,所以,可以在每个调用日志的静态属性中加入请求应用和接收应用,则
第一聚合单元22,还可以用于:根据指定请求应用和/或接收应用,将相同唯一链路标识对应的调用日志进行聚合,生成单个trace。生成的单个trace就可以包含(或不包含)某个应用的属性。
结构生成单元23,可以用于根据每个单个链路树中包含的静态属性,生成链路结构标识。
当每台计算机为每个Trace ID生成单个trace后,提取每个单个trace中的静态属性,生成链路结构标识(trace Key);该trace Key可以表示链路的结构。
第二聚合单元24,可以用于将相同链路结构标识对应的单个链路树进行聚合,生成整合链路树。
当生成trace Key后,就可以触发第二聚合单元24,先将所有相同的traceKey的单个trace移动到一台计算机上。之后每台计算机,开始并行分别对每个trace Key的单个trace进行聚合,生成整合trace;由于每个调用日志中包含了动态属性,所以每个整合trace中也就包含了动态属性。
统计单元25,可以用于根据整合链路树中包含的动态属性,统计互联网业务不同链路的调用情况。
当整合trace全部生成完后,就可以调用统计单元25,每台计算机,可以根据聚合后的动态属性(及属性值)分别对不同链路的调用情况进行统计。
为了达到方便用户浏览的目的,该装置还可以包括数据存储单元,可以用于将不同整合链路树以及对应的调用情况以映射关系保存在数据库中。
在实际的互联网业务中,是业务是可以分为不同类型的,所以每个调用日志中还可以包含业务类型标识,且链路树中包含对应的业务类型标识,则
该装置还可以包括第三聚合单元,
该第三聚合单元,可以用于将相同业务类型标识对应的整合链路树进行聚合,生成业务链路树。
具体地,业务类型标识可以以业务码(btype)来标识,该btype保存在每个调用日志中,在生成单个trace和整个trace后,btype会一直保存在聚合后的属性中。在触发第三聚合单元后,先将所有相同的btype的整合trace移动到一台计算机上。之后每台计算机,开始并行分别对每个btype的整合trace进行聚合,生成业务trace;由于每个调用日志中包含了静态属性和动态属性,所以每个业务trace中也就包含了静态属性和动态属性。
在聚合后,还可以继续调用统计单元25,可以用于根据业务链路树中包含的静态属性和动态属性,统计不同类型的互联网业务中业务链路的调用情况。
当业务trace全部生成完后,就可以继续调用统计单元25,每台计算机,可以根据聚合后的静态和动态属性(及属性值)分别对不同类型的互联网业务中业务链路的调用情况进行统计。
为了达到方便用户浏览的目的,还可以继续调用数据存储单元,用于将不同互联网业务类型以及对应的调用情况以映射关系保存在数据库中。
采用实施例2提供的该装置,通过分布式计算机集群效率较高的优点,根据获取的互联网业务链路的调用日志中的唯一链路标识,对调用日志以及包含的静态和动态属性进行聚合,生成单个链路树;再根据静态属性,将相同结构的单个链路树进行聚合,生成整合链路树,并根据包含的动态属性,对不同链路的调用情况进行统计。达到了从业务角度对整合业务的链路的调用情况进行统计的目的。此外,还可以为调用日志添加业务类型,从而可以根据相同的业务类型,将整合链路树再次进行聚合,生成业务链路树,也就更加立体地,从不同业务类型的角度,对不同业务的调用情况进行了统计;为了达到方便用户浏览的目的,还有将调用情况与不同链路和不同业务类型链路,以映射的关系进行存储。
实施例3
在实施例1中已经介绍,为了达到方便用户浏览的目的,可以将不同整合链路树和不同业务类型对应的调用情况以映射关系保存在数据库中,所以本实施例就提供一种互联网业务链路调用情况的展示方法,用于满足用户对调用情况的查看。该方法的流程示意图如图3所示,包括下述步骤:
步骤31:接收包含整合链路树和/或互联网业务类型的查看请求。
该步骤中,可以创建一个图形界面,并且还可以建立针对整合链路树和/或互联网业务类型的选项,以便用户通过图形界面以及选项,发送查看请求。
步骤32:选取在数据库中与查看请求对应的调用情况,并进行展示。
由于实施例1中可以将不同整合链路树以及对应的调用情况以映射关系保存在数据库中,该可以将不同互联网业务类型以及对应的调用情况以映射关系保存在数据库中。所以本步骤就可以根据查看请求,调取保存在数据库中的、与查看请求中整合链路树和/或互联网业务类型对应的调用情况,并在图形界面中进行展示。
实施例4
基于相同的发明构思,实施例4提供了一种互联网业务链路调用情况的展示装置。图4为该装置的结构框图,该装置包括:查看请求获取单元41以及调用情况展示单元42,其中,
查看请求获取单元41,可以用于接收包含整合链路树和/或互联网业务类型的查看请求;
调用情况展示单元42,可以用于选取在数据库中与查看请求对应的调用情况,并进行展示。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。