技术领域
[0001] 本
发明涉及云服务技术领域，尤其涉及一种基于服务起源的云服务监控方法和装置。
背景技术
[0002] 现有的服务监控，主要关注的是服务本身的运行状态，很少关注服务之间的依赖关系。
专利“一种WEB服务监控参数的调整装置和方法 - 200910094000.1”主要关注特定的web服务监控方法，专利“一种分布式应用系统的服务监控方法及装置201310625603.6”关注应用系统的服务调用次数，发现调用异常。专利“云计算服务
监控系统及方法201310625603.6”和“服务监控方法及系统201210009234.3”主要关注服务监控系统的体系结构和通讯，没有关注服务状态和依赖的监控。
[0003] 在服务监控中，以Google，Twitter为代表的互联网公司处于自身需要开发了相应的服务追踪平台。Google在2010年发布了Dapper[Benjamin H. Sigelman, Luiz Andre Barroso, Mike Burrows, Pat Stephenson,Manoj Plakal, Donald Beaver, Saul Jaspan, Chandan Shanbhag Dapper, “a Large-Scale Distributed Systems Tracing Infrastructure”, Google Technical Report dapper-2010-1, April 2010]，通过
修改服务调用底层库结构，实现自动获取服务动态行为，服务之间的依赖关系通过栅格和
树形结构进行表达，起源信息存储在bigtable。Dapper本身建立在Google的
基础平台上，高性能要求和同构特性使得其不支持其他异构平台。
发明内容
[0004] 本发明要解决的技术问题在于针对
现有技术中的
缺陷，提供一种基于服务起源的云服务监控方法。
[0005] 本发明解决其技术问题所采用的技术方案是：
[0006] 1）捕获服务起源数据；其中服务起源的定义为，描述了服务的动态执行历史和过程，体现了服务运行的状态（耗时、
频率等）和动态依赖关系；
[0007] 2）应用服务起源数据规范根据服务起源数据生成起源日志文件；
[0008] 3）使用非关系
数据库存储起源日志文件；所述非关系数据库包括文档型数据库和图数据库；
[0009] 采用图数据库进行存储，该存储模式包括
节点及节点属性，关系和关系属性，具体如下：
[0010] (3.1)所有的服务作为节点存储在节点集合中;
[0011] (3.2)服务之间的依赖作为关系（边）存储;
[0012] (3.3)节点属性，主要存储服务起源规范中的location信息，以Key-Value的形式在属性结合存储;
[0013] (3.4)关系属性存储在属性集合中，主要存储服务起源规范中的(token, elapsed time, timestamp, input, output, status)信息，以Key-Value的形式在属性结合存储;
[0014] (3.5)当服务Si多次调用Sj，调用关系只存储一次，每次调用的信息存储在关系属性集合中。
[0015] 4）生成服务起源图；服务起源图的生成过程包括：
[0016] 4.1）读取捕获的服务起源日志记录；
[0017] 4.2）从上述描述的服务起源数据结构（9元组），获得InvokingService, ServiceInvoked，在现有的服务列表中通过查找确定是否已经记录了这两个服务，如果没有，则加入服务节点, 并从9元组中读取location信息，存入到服务节点属性；
[0018] 4.3）根据表示的两个服务之间的依赖关系，把该关系存储为图数据库的一条边；
[0019] 4.4）获取某次服务调用的
属性信息，包括(token, elapsed time, timestamp, input, output, status)存储在边的属性对中，该属性对以Key-Value的形式存储。
[0020] 4.5）通过服务节点和服务依赖，构造服务起源图；
[0021] 5）若发现某个服务Si异常，
定位查找导致服务Si异常的服务；
[0022] 5.1）在服务起源图中查找该服务是否有依赖服务，如果没有依赖服务，则该故障发生在该服务本身；
[0023] 5.2）查询该服务所有的直接依赖服务，并搜索时间最新的调用属性记录，提取token值，形成Si调用异常的服务节点集合M；
[0024] 5.3）采用图的深度遍历
算法，以M集合中的服务节点为起点，查询具有同样token值的依赖服务；
[0025] 5.4）反复
迭代，重复步骤5.2）和5.3），直到找到没有服务依赖的服务，终止搜索；
[0026] 5.5）综合返回的路径，构造给定服务Si的实时调用起源图，在进行故障诊断的时候采用如下方法：
[0027] A）在Si的调用图中，查找status为0的调用路径P，则该路径上的服务节点可能是故障点；（Status为1表示服务调用正常，status为0表示服务调用异常）
[0028] B）对路径P上的所有节点进行故障排查，如果某个节点服务调用其他服务正常，则该节点正常，并从P中删除；
[0029] C）P中的服务节点即可能为故障节点；
[0030] 6）监测所有服务的执行耗时，统计某段时间范围内耗时较多的服务；
[0031] 具体步骤为：
[0032] 6.1）通过聚合运算统计具有直接依赖关系的服务调用平均耗时，即Si调用Sj的平均耗时
[0033] 6.2）通过聚合运算统计具有直接依赖关系的服务调用次数，即Si调用Sj的次数[0034] 6.3）基于上述的起源图存储模式，统计两个直接依赖关系的服务，其每次调用信息存储在关系属性集合中，所以只需要对这两个服务之间的记录按照要求进行聚合运算；
[0035] 6.4）对统计的服务调用平均耗时数据和服务调用次数排序，进行服务起源的服务性能分析。
[0036] 按上述方案，步骤1）中捕获服务起源数据采取以下方法：
[0037] 1.1）根据服务
框架和调用协议设计服务调用拦截器；
[0038] 1.2）将服务调用拦截器内置在服务调用协议中；
[0039] 1.3）当服务调用发生时，服务调用拦截器拦截服务调用
请求，获得服务动态调用依赖关系，并标识每个任务的
服务组合；
[0040] 服务调用拦截器的设计方法包括以下步骤：
[0041] 1.11）创建用于存储服务起源信息的文件；
[0042] 1.12）服务调用者产生一个唯一的token值，作为识别服务动态依赖的标志；
[0043] 1.13）创建用于读取并存储服务调用开始时间的参量；
[0044] 1.14）创建用于读取和存储当前的IP地址的参量；
[0045] 1.15) 创建用于存储所调用的服务名称的参量；
[0046] 1.16）创建用于存储所调用的服务的入口参数的参量；
[0047] 1.17）上述参量、文件和token值共同构成服务调用拦截器。
[0048] 按上述方案，步骤2）中捕获服务起源数据采取以下方法：
[0049] 服务调用拦截器按照服务起源数据规范，根据获得的服务动态调用依赖关系和经过标识的每个任务的服务组合生成并输出起源日志文件；
[0050] 将起源日志文件进行
数据处理后，存储在云数据库中；
[0051] 所述服务起源数据规范为一个9元组：
[0052] BasicProv(token,InvokingService,ServiceInvoked,location, elapsed time, timestamp, input, output, status)；
[0053] 其中Token为一个32位的字符串，用于标识一个动态的组合任务；
[0054] InvokingService为服务调用者，也称为服务消费者，其数据格式为一个32位的字符串；
[0055] ServiceInvoked为服务被调用者，也称为服务提供者，其数据格式为一个32位的字符串；
[0056] Location为服务调用发生的
位置，在云服务环境，为IP地址。
[0057] Elapsed time为服务调用的耗时，该耗时为从服务调用者的视
角看，完成一次服务调用所需要的时间，包含了被调用服务的嵌套执行时间，其数据格式为一个8位的整型；
[0058] Timestamp为服务调用事件发生的时间戳；
[0059] Input为服务调用的输入参数，数据存储格式为32位的字符串；
[0060] Output为服务调用的输出数据文件，为一个XML对象，或者一个json数据对象；
[0061] Status为服务执行的状态，数据格式为一个布尔值，1表示成功，0表示失败。
[0062] 按上述方案，所述唯一token值根据时间和网卡产生。
[0063] 本发明产生的有益效果是：
[0064] 1.本发明方法有效解决云计算环境下，分布式服务的故障追踪、服务性能分析难题。现有的技术方案主要监控标准的服务，如数据库服务、web容器（IIS,tomcat），基础
硬件服务（CPU,内存等），本发明主要针对业务系统监控，能够细粒度的监控业务系统的服务运行状态，当发生性能
瓶颈的时候，能够分析和发现是由哪一个具体的业务服务导致的；如果发现某个服务异常，能够根据捕获的服务起源，定位异常的源头，进行故障诊断。
附图说明
[0065] 下面将结合附图及
实施例对本发明作进一步说明，附图中：
[0067] 图2是本发明实施例的服务起源图；
[0068] 图3是本发明实施例中关系存储和图存储模式下聚合运算的时间代价示意图；
[0069] 图4是本发明实施例中关系模式和图模式插入操作耗时对比示意图。
具体实施方式
[0070] 为了使本发明的目的、技术方案及优点更加清楚明白，以下结合实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。
[0071] 一种基于服务起源的云服务监控方法，包括以下步骤：
[0072] 1）根据服务框架和调用协议设计服务调用拦截器；
[0073] 服务调用拦截器的设计方法包括以下步骤：
[0074] 1.1）创建用于存储服务起源信息的文件；
[0075] 1.2）服务调用者产生一个唯一的token值，作为识别服务动态依赖的标志；
[0076] 1.3）创建用于读取并存储服务调用开始时间的参量；
[0077] 1.4）创建用于读取和存储当前的IP地址的参量；
[0078] 1.5) 创建用于存储所调用的服务名称的参量；
[0079] 1.6）创建用于存储所调用的服务的入口参数的参量；
[0080] 1.7）上述参量、文件和token值共同构成服务调用拦截器。
[0081] 服务调用者在生成全局唯一的token值，作为识别服务动态依赖的标志，该token值和IP地址、时间等服务起源信息植入调用协议消息的头部。
[0082] 2）将服务调用拦截器内置在服务调用协议中；
[0083] 透明性和自动化捕获程度取决于拦截器的部署位置，一种形式是：Dapper方法把拦截器部署在库函数，所有的通过核心库函数的调用将自动被拦截，具有高透明性，但由于不同平台的库函数差异很大，且不易修改，所以难以支持异构平台。另一种形式是使用基于应用程序标记方法，拦截器部署在应用程序，具有很好的灵活性，但是不支持自动捕获。
[0084] 3）当服务调用发生时，服务调用拦截器拦截服务调用请求，获得服务动态调用依赖关系，并标识每个任务的服务组合；
[0085] 3.1）解析SOAP消息头部信息；
[0086] 3.2）获取消息头部信息中的token值，并存储到本地线程变量中；
[0087] 3.3）根据token值获得服务动态调用依赖关系；
[0088] 3.4）选取具有相同数值的token的服务，该服务组合共同完成某个任务；
[0089] 3.5) 根据任务形成的动态服务组合过程，可以通过token进行查询后，进行迭代运算得到每个任务的服务组合。
[0090] 在收集拦截器的信息过程中，为了提供对异构系统的支持，采用拦截器和拦截器管理分离的方式，管理模
块负责所有拦截的注册、日志收集和处理，拦截器负责捕获服务起源并按照规范输出日志，可以根据不同的服务协议设计不同的拦截器，拦截器和管理模块是松耦合关系，拦截器运行的策略和方式通过读取一个XML配置文件实现，该文件由管理模块进行管理和维护，通过更新和修改该文件，拦截器实施不同的抽样策略和执行方式。所有拦截器采用公共标准的数据规范和传输协议。
[0091] 服务调用拦截器拦截服务调用请求时，根据不同的服务调用频率，确定服务调用拦截器的拦截频率。
[0092] 在云平台中，热
门的服务往往调用的频率很高，在很短的时间内容，往往会被调用成千上万次，如果拦截每一次的调用，即使单次拦截的时间很短，例如，单次拦截耗时2ms，但是如果在1秒拦截100次服务调用，则需要耗时2ms*100=200ms=0.2s，这将给系统带来较大的开销。所以需要设计合适的抽样策略，降低服务起源捕获代价。
[0093] 另外一个问题是，服务之间的调用频率差异巨大，有些非常用服务调用频率很低，如果采用统一的调用抽样策略，要么将丢掉服务调用模式特征，要么将带来较高的拦截代价。
[0094] 本实施例中采用了一种分层的抽样策略，具体为
[0095] 调用频率大于100次/秒，抽样频率为：向下取整（调用频率/100） 每秒；
[0096] 调用频率小于100次/秒，且大于1次/秒，抽样频率为：1次 每秒；
[0097] 调用频率小于1次/秒，抽样频率为：根据调用次数抽样
[0098] 我们可以根据服务调用频率的实际情况，修改抽样策略，使之在降低采集代价的同时，保持服务起源的模式特征。
[0099] 4）服务调用拦截器按照服务起源数据规范，根据获得的服务动态调用依赖关系和经过标识的每个任务的服务组合生成并输出起源日志文件；其中服务起源数据规范为一个9元组：
[0100] BasicProv(token,InvokingService,ServiceInvoked,location, elapsed time, timestamp, input, output, status)；服务起源的数据规范参数含义如下：
[0101] Token：一个32位的字符串，用于标识一个动态的组合任务
[0102] InvokingService：服务调用者，也可以称为服务消费者。数据格式为一个32位的字符串
[0103] ServiceInvoked：服务被调用者，也可以称为服务提供者。数据格式为一个32位的字符串。
[0104] Location:服务调用发生的位置，在云服务环境，主要是IP地址。
[0105] Elapsed time：服务调用的耗时，该耗时为从服务调用者的视角看，完成一次服务调用所需要的时间，包含了被调用服务的嵌套执行时间。数据格式为一个8位的整型，单位为毫秒。
[0106] Timestamp：服务调用事件发生的时间戳，格式为年/月/日 小时/分钟/秒/毫秒[0107] Input：服务调用的输入参数，数据存储格式为32位的字符串。
[0108] Output：服务调用的输出数据文件，一般为一个XML对象，或者一个json数据对象。
[0109] Status：服务执行的状态，数据格式为一个布尔值，1表示成功，0表示失败。
[0110] 5）将起源日志文件进行数据处理后，存储在云数据库中。
[0111] 读取服务起源日志记录，检查是否符合当前的服务起源数据规范，用户可以根据需要设置服务起源数据的规范要求，例如，当不需要分布式debug的时候，可以不拦截服务的输入和输出，在进行格式检查的时候不检查相关信息。
[0112] 对于不符合要求的数据（包括信息不完整、超出位数长度等）进行丢弃，不插入远端数据库;
[0113] 对于符合要求的数据，调用插入数据库模块，把信息插入到远程数据库中；
[0114] 对系统支持异构的服务起源数据，如果当前数据标签和名称不符合数据规范，则采用数据映射的方式实现语义转换，具体的方式为，建立待转化数据信息字段名称和服务起源数据格式字段名称的映射关系，在插入数据之前，进行映射，然后根据匹配的信息插入到数据库中；
[0115] 将服务起源日志存储到服务所在的本地
服务器上，通过日志采集工具，实现数据的读取、传输和插入数据库。
[0116] 6）使用非关系数据库存储起源日志文件；所述非关系数据库包括文档型数据库和图数据库；
[0117] 采用图数据库进行存储，该存储模式包括节点及节点属性，关系和关系属性，具体如下：
[0118] (6.1)所有的服务作为节点存储在节点集合中
[0119] (6.2)服务之间的依赖作为关系（边）存储
[0120] (6.3)节点属性，主要存储服务起源规范中的location信息，以Key-Value的形式在属性结合存储。
[0121] (6.4)关系属性存储在属性集合中，主要存储服务起源规范中的(token, elapsed time, timestamp, input, output, status)信息，以Key-Value的形式在属性结合存储。
[0122] (6.5)当服务Si多次调用Sj，调用关系只存储一次，每次调用的信息存储在关系属性集合中。
[0123] 7）生成服务起源图；服务起源图如图2所示，服务起源图的生成过程包括：
[0124] 7.1）读取捕获的服务起源日志记录；
[0125] 7.2）从上述描述的服务起源数据结构（9元组），获得InvokingService, ServiceInvoked，在现有的服务列表中通过哈希查找确定是否已经记录了这两个服务，如果没有，则加入服务节点, 并从9元组中读取location信息，存入到服务节点属性；
[0126] 7.3）根据表示的两个服务之间的依赖关系，把该关系存储为图数据库的一条边；
[0127] 7.4）获取某次服务调用的属性信息，包括(token, elapsed time, timestamp, input, output, status)存储在边的属性对中，该属性对以Key-Value的形式存储。
[0128] 7.5）通过服务节点和服务依赖，构造服务起源图；
[0129] 8）若发现某个服务Si异常，定位查找导致服务Si异常的服务；适用图数据库；
[0130] 8.1）在服务起源图中查找该服务是否有依赖服务，如果没有依赖服务，则该故障发生在该服务本身；
[0131] 8.2）查询该服务所有的直接依赖服务，并搜索时间最新的调用属性记录，提取token值，形成Si调用异常的服务节点集合M；
[0132] 8.3）采用图的深度遍历算法，以M集合中的服务节点为起点，查询具有同样token值的依赖服务；
[0133] 5.4）反复迭代，重复步骤5.2）和5.3），直到找到没有服务依赖的服务，终止搜索；
[0134] 5.5）综合返回的路径，构造给定服务Si的实时调用起源图，在进行故障诊断的时候采用如下方法：
[0135] A）在Si的调用图中，查找status为0的调用路径P，则该路径上的服务节点可能是故障点；（Status为1表示服务调用正常，status为0表示服务调用异常）
[0136] B）对路径P上的所有节点进行故障排查，如果某个节点服务调用其他服务正常，则该节点正常，并从P中删除；
[0137] C）P中的服务节点即可能为故障节点；
[0138] 这样，当发现某个服务Si异常，可以快速定位该异常在此服务本身，还是由于所依赖的其他服务所引起的。极大的减少了维护成本。
[0139] 9）监测所有服务的执行耗时，统计某段时间范围内耗时较多的服务；适用图数据库和文档型数据库；
[0140] 具体步骤为：
[0141] 9.1）通过聚合运算统计具有直接依赖关系的服务调用平均耗时，即Si调用Sj的平均耗时
[0142] 9.2）通过聚合运算统计具有直接依赖关系的服务调用次数，即Si调用Sj的次数[0143] 9.3）基于上述的起源图存储模式，统计两个直接依赖关系的服务，其每次调用信息存储在关系属性集合中，所以只需要对这两个服务之间的记录按照要求进行聚合运算；
[0144] 9.4）对统计的服务调用平均耗时数据和服务调用次数排序，进行服务起源的服务性能分析。
[0145] 不同于关系模式，在起源图模式下，调用信息记录是按照直接依赖服务进行存储的，不需要遍历所有的调用记录，实际上具有切片功能，该方法将有效的提供统计分析的效率。
[0146] 图3显示了关系存储和图存储模式下聚合运算的时间代价，设计了1万到500万条服务起源数据，分别存储在关系数据库MySQL和图数据库Neo4j，其中Mysql的运算代价随数据集增加快速增长，Neo4j保持相对稳定。图4显示了关系模式和图模式插入操作耗时对比，设计了10万到200万条服务起源数据，可见Mysql中插入操作耗时随数据集增加快速增长，Neo4j保持相对稳定。
[0147] 应当理解的是，对本领域普通技术人员来说，可以根据上述说明加以改进或变换，而所有这些改进和变换都应属于本发明所附
权利要求的保护范围。
