CN107018042A - 用于在线服务系统的追踪方法及追踪系统 - Google Patents

Abstract

本发明公开了一种用于在线服务系统的追踪方法及追踪系统。其中在线服务系统包括用于实现服务请求的多个服务节点，每次服务请求由唯一的服务请求ID标识。追踪方法包括：实时获取在线服务系统中实现服务请求的关联消息，并将其存储至消息队列，其中每个服务请求的关联消息是涉及实现该特定服务请求的至少两个服务节点的服务请求关联消息；使用服务请求ID作为存储项标识，对消息队列中的关联消息进行分布式列式存储，其中按照服务节点划分某一存储项的各列。由此，通过以服务请求ID为存储项标识，将对应于同一服务请求的涉及不同业务节点的关联消息以列存储的方式进行存储，可以得到实现某一服务请求所涉及的业务节点的跟踪链，以方便后续查询分析。

Description

用于在线服务系统的追踪方法及追踪系统

技术领域

本发明涉及在线服务领域，特别是涉及一种用于在线服务系统的追踪方法及追踪系统。

背景技术

随着分布式服务架构的流行，特别是微服务等设计理念在系统中的应用，服务系统的模块变得越来越多，业务的调用链也越来越复杂。以搜索系统为例，对于用户的一个搜索请求，会经过多个子系统的处理，而且这些处理可能是发生在不同的机器甚至是不同的集群上的。

由于缺乏日志统一收集与存储方案，在利用分布式服务架构实现在线服务时，一旦线上出现性能或者效果问题，需要登录到指定的机器上去拉取日志，实现起来极为麻烦且效率低下。并且，由于缺乏上下联动的调查机制，不同服务之间的日志非常难关联在一起，而且日志轮转有一定的周期，还存在潜在被删除风险。

由此，需要一种能够准确快速地对在线服务系统中实现服务请求所涉及的多个子系统(或服务节点)进行监控的方案。

发明内容

本发明的主要目的在于提供一种用于在线服务系统的追踪方法及追踪系统，其能够准确快速地对在线服务系统中实现服务请求所涉及的多个子系统进行实时监控。

根据本发明的一个方面，提供了一种用于在线服务系统的追踪方法，在线服务系统可以包括用于实现服务请求的多个服务节点，每次服务请求由唯一的服务请求ID标识，方法包括：实时获取在线服务系统中实现服务请求的关联消息，并将其存储至消息队列，其中每个服务请求的关联消息是涉及实现该特定服务请求的至少两个服务节点的服务请求关联消息；使用服务请求ID作为存储项标识，对消息队列中的关联消息进行分布式列式存储，其中按照服务节点划分某一存储项的各列。

由此，通过以服务请求ID为存储项标识，实时将对应于同一服务请求的涉及不同业务节点的关联消息以列存储的方式进行存储，可以实时得到在线服务系统中实现某一服务请求所涉及的业务节点的跟踪链，便于及时查询分析。

优选地，该追踪方法还可以包括：订阅需要实时获取的关联消息的服务节点和/或服务请求关联消息的类型。

由此，在执行本发明的追踪方法之前，还以预先获取需要跟踪的业务节点和/或特定类型的服务请求关联消息，以便于根据实际需求有针对性地获取相应的关联消息。

优选地，对消息队列中的服务关联消息进行分布式列式存储可以包括：根据规定的服务节点和/或服务请求关联消息的类型，从消息队列中选取要进行列式存储的服务请求。由此，还可以有针对性地从消息队列中读取符合需求的关联消息。

优选地，对消息队列中的服务关联消息进行分布式列式存储可以包括：对消息队列中存储的服务请求的关联消息进行负载均衡；以及分布式列式存储经负载均衡的关联消息。

由此，可以基于消息队列中的消息消费机制，实现负载均衡，避免个别位置上的拥塞而导致的处理速度下降。

优选地，在线服务系统是在线搜索系统，并且提供多种搜索业务。本发明的追踪方法还可以适用于任何数据流在线处理系统。

优选地，将关联消息存储至消息队列可以包括：将属于同种搜索业务的搜索请求关联消息存储至不同的消息队列，以提升随后消息消费的便利性。

优选地，对消息队列中的服务关联消息进行分布式列式存储可以包括：对消息队列中存储的服务请求的关联消息进行符合列式存储要求的格式和/或通信协议转换；以及分布式列式存储经转换的关联消息。

由此，可以通过转换消除列式存储系统和消息队列之间存在的跨语言访问障碍。

优选地，每个服务请求的关联消息是涉及实现该特定服务请求的所有服务节点的服务请求关联消息，分布式列式存储的是每个服务请求的完整跟踪链表。

由此，可以实时得到实现某一服务请求所涉及的全部业务节点的完整跟踪链。

优选地，该追踪方法以包括：按时间建立服务请求ID及其延时的索引表。索引表的建立能够有助于分散高并发写给列式存储系统带来的压力，也便于进行统计分析。

优选地，索引表是以时间戳和索引类型为标识的列式存储的索引表，其中按照服务请求ID和延时划分某一存储项的各列。由此，可以适用于批量扫描的访问场景。

根据本发明的另一个方面，还提供了一种用于在线服务系统的分布式服务追踪系统，在线服务系统包括用于实现服务请求的多个服务节点，每次服务请求由唯一的服务请求ID标识，追踪系统包括：多个消息队列，用于实时获取在线服务系统中实现服务请求的关联消息，并进行存储，其中每个服务请求的关联消息是涉及实现该特定服务请求的至少两个服务节点的服务请求关联消息；消息消费系统，用于从消息队列收集关联消息，并使用服务请求ID作为存储项标识，将消息队列中的关联消息进行分布式列式存储，其中按照服务节点划分某一存储项的各列；列式存储系统，用于进行分布式列式存储。

优选地，消息消费系统还可以包括：订阅服务器，用于订阅需要实时获取的关联消息的服务节点和/或服务请求关联消息的类型。

优选地，消息消费系统根据规定的服务节点和/或服务请求关联消息的类型，从消息队列中选取要进行列式存储的服务请求。

优选地，消息消费系统还可以包括：多个收集服务器，用于对消息队列中存储的服务请求的关联消息进行负载均衡。

优选地，在线服务系统是在线搜索系统，并且提供多种搜索业务。

优选地，属于同种搜索业务的搜索请求关联消息被存储至不同的消息队列。

优选地，列式存储系统还可以包括：转换服务器，用于对消息队列中存储的服务请求的关联消息进行符合列式存储要求的格式和/或通信协议转换。

优选地，每个服务请求的关联消息是涉及实现该特定服务请求的所有服务节点的服务请求关联消息，列式存储系统存储每个服务请求的完整跟踪链表。

优选地，列式存储系统还存储按时间建立服务请求ID及其延时的索引表。索引表优选地可以是以时间戳和索引类型为标识的列式存储的索引表，其中按照服务请求ID和延时划分某一存储项的各列。

本发明的用于在线服务系统的追踪方法及追踪系统，通过以服务请求ID为存储项标识，将对应于同一服务请求的涉及不同业务节点的关联消息以列存储的方式进行存储，可以得到实现某一服务请求所涉及的业务节点的跟踪链，便于后续查询分析。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。

图1是示出了根据本发明一实施例的追踪系统的结构的示意性方框图。

图2是示出了一个示例性追踪系统的整体架构的示意图。

图3是示出了根据本发明一实施例的列式存储系统的系统架构图。

图4是示出了收集服务器的设计类图。

图5是示出了收集服务器的消息处理状态转移图。

图6是示出了根据本发明一实施例的追踪方法的示意性流程图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本发明涉及消息的消费与订阅。“订阅”和“消费”，是消息队列中的两个行为。消息队列一般跟两种对象有联系：生产者和消费者，生产者写数据(即生产消息)，消费者读和处理数据(即订阅和消费数据)，生产者和消费者都是指计算机。“订阅”和“消费”都是消费者跟消息队列之间的联系和行为。消息队列接收多种数据，而某个消费者可能仅仅需要某类数据，因此，消费者在读数据之前需要事先告知消息队列其需要的数据，这一通知机制就是“订阅”。“消费”实际上就是消费者在拿到消息数据后的处理。消息生产者生产消息发送到消息队列中，然后消息消费者从消息队列中取出并且消费消息。消息被消费以后，消息队列中不再有存储，所以消息消费者不可能消费到已经被消费的消息。

本发明主要提出了一种用于在线服务系统的追踪方案。其中，本发明的追踪方案所针对的在线服务系统包括用于实现服务请求的多个服务节点，不同的服务节点可以部署在不同的服务器上，即在线服务系统可以是基于分布式服务架构实现的，例如可以是在线搜索系统、电商网站分布式系统等多种分布式数据流处理系统。在此，可以理解的是，每一次的服务请求根据其请求业务类型和系统当前状况，可能会涉及在线服务系统中不同的多个服务节点。

在线服务系统实现的每次服务请求可以由唯一的服务请求ID标识。对于每次独立的服务请求(例如，每次独立的查询)，系统都会为其赋予一个id，作为区分不同查询以及关联单次查询多个模块日志的唯一Key。服务请求ID可以由在线系统的第一个服务节点(例如对于搜索系统，可以是nginx模块)生成的，然后可以通过透传使得后续涉及该服务请求的其他服务节点也会收到该服务请求ID。此处关于透传的具体实现原理为本领域技术人员所公知，在此不再赘述。

本发明的追踪方案可以实现为一种追踪系统，图1是示出了根据本发明一实施例的追踪系统的结构示意图。

参见图1，追踪系统100包括一个或多个消息队列110、消息消费系统120以及列式存储系统130。

消息队列110可以用于实时获取在线服务系统中实现服务请求的关联消息，并进行存储。在这里，消息队列(Message Queue)是指在消息的传输过程中保存消息的容器，在本方案中，可以理解为将在线服务和离线追踪进行解耦的一个设计模块。

在线服务系统可以同时应答多个(通常是海量)服务请求，因此消息队列110可以实时获取在线服务系统中实现所有服务请求的关联消息，也可以实时获取在线服务系统中实现部分服务请求的关联消息。

每个服务请求的关联消息可以包括实现该服务请求所涉及的全部服务节点的服务请求关联消息，也可以包括实现该服务请求所涉及的部分服务节点(例如至少两个)的服务请求关联消息。

也就是说，对于某个服务请求，消息队列110可以获取在线服务系统中实现该服务请求用到的所有服务节点的服务请求关联消息，也可以有针对性地获取在线服务系统中实现该服务请求用到的服务节点中部分服务节点的服务请求关联消息。

本发明的追踪方案可以应用于任何用于处理大量数据流的在线系统，尤其可以是用于提供多种搜索业务的在线搜索系统。属于同种搜索业务的搜索请求关联消息可以例如通过分片方式存储至不同的消息队列，以方便后续的消息消费处理。

消息消费系统120用于从消息队列110收集关联消息，并使用服务请求ID作为存储项标识，将消息队列中的关联消息以分布式列式存储的方式存储在列式存储系统130中。

由此，通过对列式存储系统130中所存储的关联消息进行分析，就可以获取实现某服务请求所涉及的服务节点的状态信息，从而可以及时发现其中存在异常的服务节点。例如，可以根据对列式存储系统130中所存储的关联消息进行分析，精确地计量某个服务节点的耗时以及调用节点之间的网络开销等信息。

消息消费系统120可以向消息队列订阅消息。订阅可以在消息队列获取消息之前或是之后进行。当进行在前订阅时，消息队列110仅收集消费系统120订阅的关联消息，即，消息消费系统120收集消息队列110中存储的所有的关联消息，当进行在后订阅时，消息消费系统120可以有针对性地从消息队列110中收集部分关联消息。例如，消息消费系统120可以根据规定的服务节点和/或服务请求关联消息的类型，从消息队列110中选取要进行列式存储的服务请求。

消息消费系统120在收集得到关联消息后对其进行列式存储时，可以按照服务节点划分某一存储项的各列，然后按照列式存储的特点将收集的关联消息中属于同一列的服务请求关联消息存储在同一数据块。优选地，每一个服务节点存储一列，当然也不排除每一个服务节点存储多列的情况。

由此，与统一服务节点相关的服务请求关联消息存储在同一物理区域，在在线服务系统中某一服务节点出现故障时，可以从列式存储系统130中对应于该服务节点(列)的数据块中快速读取与该服务节点相关的全部服务请求关联消息进行分析，以准确全面地确定该服务节点的故障原因。

如上文所述，每个服务请求的关联消息可以是涉及实现该特定服务请求的所有服务节点的服务请求关联消息，此时列式存储系统130可以存储每个服务请求的完整跟踪链表。由此，可以针对特定的服务请求，查看该服务请求的完整跟踪链表，以实时发现不可用的服务节点。

需要说明的是，在利用本发明的追踪系统100对在线服务系统进行追踪时，可以对在线服务系统所实现的每次服务请求进行追踪，也可以以一定的采样率对在线服务系统实现的服务请求进行追踪。此处述及的采样率可以理解为以一定的比例对在线服务系统实现的服务请求进行追踪，例如，采样率可以设定为10％，即可以在线服务系统每实现10次不同的服务请求，利用追踪系统100对在线服务系统实现的当前服务请求进行一次追踪。另外，还可以使用其它指定的追踪机制灵活采样，例如还可以按照不同地域请求的采样、按照不同服务节点的采样等等，此处不再详述。

利用本发明的追踪系统100，还可以实时获取在线服务系统实现某次服务请求所涉及的各个服务节点的服务情况，并且还可以获知具体的服务结果信息。例如，以在线服务系统为在线搜索系统为例，可以获知某次查询请求下搜索结果及各搜索模块的服务情况，同时也可以根据关键词等信息，查找对应历史上某次请求的检索信息。

另外，在优选实施例中，在消息获取阶段可以不对消息具体属于哪个服务加以区分，而是由消息消费系统120对获取的每条消息进行反序列化处理，在通过例如参见图2的Thrift服务访问列式存储系统130时，由Thrift服务进行数据的序列化和反序列化，以供列式存储系统130进行后续存储处理。由此提升消息传输的便利性。

至此，结合图1简要说明了本发明的追踪系统100的结构示意图以及追踪原理。由上文描述可知，本发明提出的追踪系统100整体数据流为：消息队列110实时保存在线服务系统实现服务请求的关联消息，然后由消息消费系统120订阅这些消息，并最终写入列式存储系统130。由于整体数据流上每个服务和模块都是实时的，因此最终用户能够准实时的获取到某次查询的完整跟踪链，以便于发现和跟踪问题。

图1所示的追踪系统100主要包含三个模块：消息队列110、消息消费系统120以及列式存储系统130。下面结合图2中的具体实施例对其中涉及的细节做进一步详细说明。

应该理解的是，图2只是本申请追踪系统的一个具体实现，其中涉及的具体模块可以根据具体应用而有所取舍和替换。为了方便理解，首先对本实施例涉及的相关术语做以简要说明。

消费者：Consumer，消息消费的组成单元。

消费者组：ConsumerGroup，可扩展且具有容错性的消费者机制，一个消费者组对应一份消息数据源，一个消费者组包含多个消费者(Consumer)或消费者实例(Consumerinstance)，消费者之间通过负载均衡的方式消费消息，并且保证不会重复消费数据。

分片：Shard，一份消息数据源中的基本组成单位，通过类数据库sharding的方式，将同份消息源分到不同的Shard上，在本案中，可以优选地将来自同一服务业务的消息分到不同shard上。

列式存储结构：以表的形式存储数据，表有行(Row)和列(Column)组成，所有列可以按照存储特性被划分为若干个列族(Column Family)。

HBase：是一个分布式的、面向列的开源数据库。

收集器：Collector，在本发明中用于提供消息消费和存储访问服务。

Thrift：是一个软件框架，用来进行可扩展且跨语言的服务的开发。在本发明中，收集器(C++)和HBase数据库(JAVA)存在跨语言访问，可以使用Thrift作为网络访问的中间媒介。

行主键：RowKey，列式存储结构中单行数据的Key键值。

名字服务器：Name Service，负责管理上下游服务调用节点，并且提供局部调度、随机调度、优先权调度等调度策略和机制。

1、消息队列

消息队列110中可以存储对应于不同服务请求的关联消息，对应于同一服务请求的关联消息又可以包括涉及实现该服务请求的多个服务节点的服务请求关联消息，每个服务请求关联消息可以视为一个分片。

如图2所示，消息队列110可以从在线服务系统获取多个分片，消息队列110可以配置为支持多个消费者，每个消费者可以消费同一服务请求下的多个分片，不同服务请求下的分片由不同的消费者消费。

基于消息队列110中的消息消费机制，消息消费系统120可以实现消息订阅过程中的负载均衡和自动容错。

2、消息消费系统

如图2所示，消息消费系统120可以包括订阅服务器122。订阅服务器122可以用于订阅需要实时获取的关联消息的服务节点和/或服务请求关联消息的类型。

由此，消息消费系统120在从消息队列110收集关联消息之前，还可以由订阅服务器122预先确定需要跟踪的业务节点和/或特定类型的服务请求关联消息。

回到图2，消息消费系统120还可以包括多个收集服务器121。每个收集服务器121可以视为一个消费者，基于上文消息队列110中的消息消费机制可知，每个收集服务器121可以收集消息队列110中同一服务请求下的多个分片，不同的收集服务器121可以收集消息队列110中不同服务请求下的分片。由此，在消息队列110中的消息消费机制下，多个收集服务器121可以实现对消息队列110中存储的服务请求的关联消息进行负载均衡和自动容错。另外，收集服务器121还可以包括配置加载、解析等功能模块。

2.1收集服务器的系统设计

在线服务系统可以通过整合一个SDK，将信息上传至消息队列，消息队列可以作为在线服务系统和收集服务器的中间数据传递媒介。收集服务器主要完成两项功能：日志订阅和日志消费。具体地，1)、从消息队列里面订阅消息；2)、对消息进行解析、日志处理；3)、将日志写入HBase。

基于消息队列的消息消费机制，日志订阅能够自动完成负载均衡。一个收集服务器对应一个消费者，消息队列会按照收集服务器的数量均匀将日志分配给多个收集服务器消费。该机制保证了收集服务器的高可用，即使某几个收集服务宕掉，也能保证日志的正确消费。同时，这一特性也保证了收集服务器的高可扩展，能够在线完成收集服务器的横向扩展。另外，多个收集服务器及其对应的消费者能够实现自动容错功能。多个消息队列在某一收集服务器(或其对应消费者)故障时自动将其存储的关联消息分发给其他正常运行的收集服务器(或其对于的消费者)。收集服务器的详细设计类图如图4所示。

图4中，收集服务器作为为主线程，通过调用消费者组完成消息订阅和消息消费，具体内容是：加载配置、启动心跳(HeartBeat)线程、根据HeartBeat返回的分片(shard)信息，初始化/结束消费者。

心跳线程可以作为独立的线程存在，定期跟消息队列做交互，内容包括：心跳信息、分片列表。消费者跟分片一一对应，控制当前该分片的状态和执行逻辑，执行逻辑通过以状态转移图的形式实现，消费者流式执行各项任务，具体如图5所示。

收集服务器的消息处理状态主要包括初始化任务、消息订阅任务、消息处理任务，三者均作为线程池任务存在。对于消息处理任务，图4中为Hbase处理作为消息处理器接口的具体实现，本发明中即将信息流做预处理后存入HBase服务器。

另外，虽然图中示出了位于消息队列110的消费者组，但上述消费者组的功能也可以并入消息消费系统120，例如，一一对应的收集服务器和消费者中的每一对视为一个大的消费者模块，所述模块用于实现消息的调度、处理和消费，从而使得消息消费系统实现更为完整的消息订阅与消费功能。3、列式存储系统

3.1架构设计

列式存储系统130作为存储系统，可以视为一套完整的存储架构服务。一般而言，列式存储系统130和消息消费系统120之间存在跨语言访问，为了实现列式存储系统130和消息消费系统120之间的正常数据传输，如图2所示，列式存储系统130还可以包括转换服务器131。转换服务器131可以用于对消息队列110中存储的服务请求的关联消息进行符合列式存储要求的格式和/或通信协议转换。

例如，如图3所示，本发明述及的列式存储系统可以是Hbase存储系统，Java实现的Hbase存储系统与C++实现的收集服务器121之间存储跨语言访问，因此可以额外引入一层Thrift服务，Thrift可以提供两模块之间的通信协议以及数据的序列化和反序列化。由此，原本两层的服务变为三层服务，复杂性提高的同时，也引入跨机器、跨机房访问问题，可能存在实时性降低的可能性，为了解决该问题，可以通过使用名字服务器的自动化调度系统，优先保证本地化调度。

由此，可以将消息队列、收集服务器、HBase存储系统视为一套完整的流式数据处理链，最终数据存储到HBase存储系统中。

3.2存储结构设计

本发明述及的列式存储系统作为准实时存储模块，可以支持实时、高并发读和写。在真实数据使用场景中，为了支持批量的扫描操作，除了完整跟踪链表外，还可以额外建立索引表，用以应对不同扫描场景的数据访问。例如，列式存储系统可以是HBase存储系统，基于HBase的Column自动可扩展特性，通过无状态写入能够自动生成完整拓扑跟踪链。

1)表模式Schema的设计结构可以按照如下表格所示：

在本发明中，可以服务请求ID作为单行数据的键值(行主键)，用以唯一区分单次查询请求。而每个服务节点的请求跟踪数据作为一个列存储，每个服务节点均有不同的列名，如此就可以天然地将单次跟踪请求的完整请求数据作为单行数据存储，支持完整拓扑图的构建。其中，列值为列名所对应的服务节点下对应于服务请求ID的服务请求关联消息。

2)索引表的设计，如下表格所示：

索引表可以有多张表格，目的是为了高并发写的压力打散，可以以“索引类型+时间戳”的方式作为标识(行主键)，由此可以便于批量扫描的访问场景。而具体到列族存储中，索引表可以仅仅保存两项数据：对应的服务请求ID以及延时，前者是为了对应到上文述及的完整的跟踪链，后者是为了便于统计。

至此，结合图1至图5详细说明了本发明的追踪系统，另外，本发明还提出了一直用于在线服务系统的追踪方法，本发明的在线追踪方法可以由上文述及的追踪系统执行，下面就本发明的在线追踪方法可以具有的流程步骤做简要说明，对于其中涉及的细节可以参见上文相关描述，下文不再赘述。

图6是示出了根据本发明一实施例的用于在线服务系统的追踪方法200的示意性流程图。

参见图6，在步骤S210，实时获取在线服务系统中实现服务请求的关联消息，并将其存储至消息队列，其中每个服务请求的关联消息是涉及实现该特定服务请求的至少两个服务节点的服务请求关联消息。

在线服务系统可以同时实现一个或多个服务请求，因此可以实时获取在线服务系统中实现所有服务请求的关联消息，也可以实时获取在线服务系统中实现部分服务请求的关联消息。

由此，在执行步骤S210之前，还可以订阅需要实时获取的关联消息的服务节点和/或服务请求关联消息的类型。

作为本发明的一个优选实施例，在线服务系统可以是用于提供多种搜索业务的在线搜索系统。其中，属于同种搜索业务的搜索请求关联消息可以被存储至不同的消息队列。

在步骤S220，使用服务请求ID作为存储项标识，对消息队列中的关联消息进行分布式列式存储，其中按照服务节点划分某一存储项的各列。

在对消息队列中的关联消息进行分布式列式存储的过程中，可以根据规定的服务节点和/或服务请求关联消息的类型，从消息队列中选取要进行列式存储的服务请求。

在对消息队列中的关联消息进行分布式列式存储的过程中，可以对消息队列中存储的服务请求的关联消息进行负载均衡，然后分布式列式存储经负载均衡的关联消息。

在对消息队列中的关联消息进行分布式列式存储的过程中，可以对消息队列中存储的服务请求的关联消息进行符合列式存储要求的格式和/或通信协议转换，然后分布式列式存储经转换的关联消息。

每个服务请求的关联消息是涉及实现该特定服务请求的所有服务节点的服务请求关联消息，分布式列式存储的是每个服务请求的完整跟踪链表。

优选地，本申请的追踪方法还可以按时间建立服务请求ID及其延时的索引表。索引表可以是以时间戳和索引类型为标识的列式存储的索引表，其中按照服务请求ID和延时划分某一存储项的各列。

综上，本发明从在线服务系统出发，提炼出一套准实时、跨机房、高容错、高可用的分布式服务框架。对于线上服务实时的数据流，消息队列可以作为传递的中间媒介，通过订阅消息队列数据源，后端服务实时地将线上服务相关的访问日志写入列式存储系统系统，供查询分析之用。

而基于列式存储系统的列式可扩展存储特性，可以以服务请求与ID作为行主键，天然的将单次查询、不同服务模块的数据，通过以拓扑跟踪链的方式关联起来。

由此，本发明的用于在线服务系统的追踪方法及追踪系统，通过流式化的采集在线服务系统(例如，在线搜索系统。当然，也支持其它各类服务)的调用、处理、debug日志等信息流，并通过实时存储、实时索引的方式支持服务调用链的实时检索、实时展示，可以至少实现下述目的：

1.全链路服务调用跟踪：能够精确的计量某个服务节点的耗时，以及调用节点之间的网络开销；

2.问题的定位与发现：针对特定服务请求，能够完整查看该服务请求的服务调用链路，实时发现不可用节点；

3.在线服务实时拓扑及节点状态监控：通过实时的信息流统计，能做到秒级实时拓扑展示和服务节点状态监控；

4.全链路业务日志Debug：支持用户在服务节点插桩打印debug信息，并支持基于debug信息的检索和跟踪链展示。

此外，根据本发明的方法还可以实现为一种计算机程序，该计算机程序包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。或者，根据本发明的方法还可以实现为一种计算机程序产品，该计算机程序产品包括计算机可读介质，在该计算机可读介质上存储有用于执行本发明的上述方法中限定的上述功能的计算机程序。本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (21)

1.一种用于在线服务系统的追踪方法，所述在线服务系统包括用于实现服务请求的多个服务节点，每次服务请求由唯一的服务请求ID标识，所述方法包括：

实时获取所述在线服务系统中实现服务请求的关联消息，并将其存储至消息队列，其中每个服务请求的关联消息是涉及实现该特定服务请求的至少两个服务节点的服务请求关联消息；

使用服务请求ID作为存储项标识，对所述消息队列中的关联消息进行分布式列式存储，其中按照服务节点划分某一存储项的各列。

2.如权利要求1所述的方法，还包括：

订阅需要实时获取的关联消息的服务节点和/或服务请求关联消息的类型。

3.如权利要求1所述的方法，其中，对所述消息队列中的服务关联消息进行分布式列式存储包括：

根据规定的服务节点和/或服务请求关联消息的类型，从所述消息队列中选取要进行列式存储的服务请求。

4.如权利要求1所述的方法，其中，对所述消息队列中的服务关联消息进行分布式列式存储包括：

对消息队列中存储的服务请求的关联消息进行负载均衡；以及

分布式列式存储经负载均衡的所述关联消息。

5.如权利要求1所述的方法，其中，所述在线服务系统是在线搜索系统，并且提供多种搜索业务。

6.如权利要求5所述的方法，其中，将关联消息存储至消息队列包括：

将属于同种搜索业务的搜索请求关联消息存储至不同的消息队列。

7.如权利要求1所述的方法，其中，对所述消息队列中的服务关联消息进行分布式列式存储包括：

对消息队列中存储的服务请求的关联消息进行符合所述列式存储要求的格式和/或通信协议转换；以及

分布式列式存储经转换的所述关联消息。

8.如权利要求1所述的方法，其中，每个服务请求的关联消息是涉及实现该特定服务请求的所有服务节点的服务请求关联消息，

分布式列式存储的是每个服务请求的完整跟踪链表。

9.如权利要求1所述的方法，还包括：

按时间建立服务请求ID及其延时的索引表。

10.如权利要求9所述的方法，其中，所述索引表是以时间戳和索引类型为标识的列式存储的索引表，其中按照服务请求ID和延时划分某一存储项的各列。

11.一种用于在线服务系统的分布式服务追踪系统，所述在线服务系统包括用于实现服务请求的多个服务节点，每次服务请求由唯一的服务请求ID标识，所述追踪系统包括：

多个消息队列，用于实时获取所述在线服务系统中实现服务请求的关联消息，并进行存储，其中每个服务请求的关联消息是涉及实现该特定服务请求的至少两个服务节点的服务请求关联消息；

消息消费系统，用于从所述消息队列收集关联消息，并使用服务请求ID作为存储项标识，将所述消息队列中的关联消息进行分布式列式存储，其中按照服务节点划分某一存储项的各列；

列式存储系统，用于进行所述分布式列式存储。

12.如权利要求11所述的追踪系统，所述消息消费系统还包括：

订阅服务器，用于订阅需要实时获取的关联消息的服务节点和/或服务请求关联消息的类型。

13.如权利要求11所述的追踪系统，其中，所述消息消费系统根据规定的服务节点和/或服务请求关联消息的类型，从所述消息队列中选取要进行列式存储的服务请求。

14.如权利要求11所述的追踪系统，其中，所述消息消费系统还包括：

多个收集服务器，用于对消息队列中存储的服务请求的关联消息进行负载均衡。

15.如权利要求14所述的追踪系统，其中，所述多个消息队列在某一收集服务器故障时自动将其存储的关联消息分发给其他正常运行的收集服务器。

16.如权利要求11所述的追踪系统，其中，所述在线服务系统是在线搜索系统，并且提供多种搜索业务。

17.如权利要求16所述的追踪系统，其中，属于同种搜索业务的搜索请求关联消息被存储至不同的消息队列。

18.如权利要求11所述的追踪系统，其中，所述列式存储系统还包括：

转换服务器，用于对消息队列中存储的服务请求的关联消息进行符合所述列式存储要求的格式和/或通信协议转换。

19.如权利要求11所述的追踪系统，其中，每个服务请求的关联消息是涉及实现该特定服务请求的所有服务节点的服务请求关联消息，

所述列式存储系统存储每个服务请求的完整跟踪链表。

20.如权利要求11所述的追踪系统，所述列式存储系统还存储按时间建立服务请求ID及其延时的索引表。

21.如权利要求20所述的追踪系统，其中，所述索引表是以时间戳和索引类型为标识的列式存储的索引表，其中按照服务请求ID和延时划分某一存储项的各列。