服务监控方法与装置与流程

本公开涉及互联网技术领域，具体而言，涉及用于监控依赖服务状态的服务监控方法与服务监控装置。

背景技术：

当系统要完成某些功能需要依赖于外部系统提供的服务来实现时，这些服务被称作依赖服务。例如超市售货依赖于物流公司提供的货物运输服务，那么物流公司提供的运输服务即所谓依赖服务。超市可看做服务依赖方，物流公司则为依赖服务的提供方。

如果提供依赖服务的外部系统产生故障而无法正常提供服务，依赖方系统将可能无法实现某些重要功能。同时，往往需要大量人力和时间来排查出是依赖服务出现故障导致依赖方系统出现故障。因此对于依赖方，监控依赖服务的实时状态显得尤为重要。同时由于某些原因，依赖服务的提供方可能不清楚有多少依赖方依赖本系统所提供的服务，因此依赖服务的提供方升级或下线某些对外提供的服务时会特别谨慎，甚至会因为不敢下线服务而保留一些无用的服务，造成了资源的浪费。

现有技术中，对于依赖服务的监控往往依靠纯人工监控，即由相关责任人在线下沟通确认依赖服务的状态。在纯人工监控下，信息的准确性难以得到保障。此外，依赖服务特别是存在时间较长的依赖服务的更新升级，下线停服等操作会耗费大量的精力，相关责任人很难在短时间内完全确认是否还有依赖方依赖本服务，冒然更新升级或下线停服很可能造成整条业务线的崩溃，风险巨大。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现要素：

本公开的目的在于提供用于监控依赖服务状态的两种服务监控方法与两种服务监控装置，用于至少在一定程度上克服由于相关技术的限制和缺陷而导致的依赖服务状态监控不及时、依赖服务转态不明确、线下沟通成本高等问题。

根据本公开的一个方面，提供一种服务监控方法，用于监控系统的依赖服务，所述服务监控方法包括：

获取所述系统的项目文件，提取所述依赖服务的地址链接；

检查所述依赖服务以判断所述依赖服务的状态是否异常；

当判断所述依赖服务异常时，提供反馈信息。

在本公开的一种示例性实施例中，所述项目文件包括源文件和/或配置文件。

在本公开的一种示例性实施例中，检查所述依赖服务包括采用定时任务检查所述依赖服务的地址链接。

在本公开的一种示例性实施例中，判断所述依赖服务异常包括：当单位时间内返回状态正常的次数低于预定次数，则判断所述依赖服务异常。

在本公开的一种示例性实施例中，所述反馈信息包括与所述系统关联的所述依赖服务的状态。

在本公开的一种示例性实施例中，还包括：

存储所述依赖服务的状态；和/或

获取所述反馈信息的处理结果，更新所述依赖服务的状态。

在本公开的一种示例性实施例中，还包括：记录所述系统与所述依赖服务的关联关系。

根据本公开的一个方面，提供一种服务监控方法，用于监控系统对外提供的依赖服务，服务监控方法包括：

获取利用所述依赖服务的外部系统的信息；

记录所述依赖服务与所述外部系统的对应关系。

在本公开的一种示例性实施例中，还包括：在所述依赖服务发生变动之前，根据所述对应关系通知所述外部系统或所述外部系统的相关主体。

在本公开的一种示例性实施例中，所述服务变动操作包括服务更新、服务升级、服务下线中的一个或多个。

在本公开的一种示例性实施例中，所述获取利用所述依赖服务的外部系统的信息包括：通过处理服务日志获取利用所述依赖服务的外部系统的信息。

根据本公开的一个方面，提供一种服务监控装置，用于监控系统的依赖服务，包括：

服务获取模块，用于获取所述系统的项目文件，提取所述依赖服务的地址链接；

服务监控模块，用于检查所述依赖服务以判断所述依赖服务的状态是否异常；

反馈提醒模块，用于当判断所述依赖服务异常时，提供反馈信息。

根据本公开的一个方面，提供一种服务监控装置，用于监控系统对外提供的依赖服务，包括：

服务获取模块，用于获取利用所述依赖服务的外部系统的信息；

服务记录模块，用于记录所述依赖服务与所述外部系统的对应关系。

本公开提供的服务监控方法通过对系统的依赖服务进行监控，实时获取依赖服务状态，并在依赖服务出现异常时进行提醒，实现了依赖服务线上可视化监控，降低了在检查系统异常时的人工成本，节省了大量人力以及时间，极大提高了工作效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出本公开示例性实施例中一种服务监控方法的流程图。

图2示意性示出本公开示例性实施例中另一种服务监控方法的流程图。

图3示意性示出本公开示例实施方式中提及的抓取系统文件中依赖服务地址链接的流程图。

图4示意性示出本公开示例实施方式中信息池的工作原理示意图。

图5示意性示出本公开示例实施方式中判断依赖服务是否异常的流程图。

图6示意性示出本公开示例性实施例中一种服务监控装置的方框图。

图7示意性示出本公开示例性实施例中另一种服务监控装置的方框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

下面结合附图对本公开提供的服务监控方法进行详细说明。

图1是本公开示例性实施例中一种服务监控方法的流程图。

参考图1，服务监控方法100可以用于监控系统的依赖服务，其可以包括：

步骤102，获取所述系统的项目文件，提取所述依赖服务的地址链接。

可以在接入系统上线前扫描所述系统的项目文件，上述的系统文件可以包括配置文件、源码文件等，将依赖服务的地址链接进行抓取分类。在本公开的一种示例性实施例中，步骤102还可以包括记录所述系统与所述依赖服务的关联关系，将所述关联关系存储到信息池中。上述地址链接可以包括http、ftp、https等地址链接类型。

本示例实施方式中所述的信息池可以采用mysql数据库完成数据持久化，通过redis缓存达到实时查询更新的目的，并依据数据优先级在mysql数据库与redis缓存之间的数据同步，定时清理redis缓存中无效数据。上述的redis缓存是一个高性能的key-value数据库，mysql数据库是一种常用的关系型数据库管理系统。

根据一些示例实施例，在抓取依赖服务的地址链接过程中，可以通过规则匹配方式检出文件中的地址链接，记录检出的文件的路径，并依据该路径获取该文件所属文件夹的路径，根据所属文件夹的路径，检测与该文件夹同级的文件，以此类推，逐层向上检测，直至遍历所有项目源码文件。举例而言，若检测到源码文件中文件路径a下存储了文件b以及文件夹c，则继续检测文件夹c，找到文件夹c下的文件d和文件夹e，继续检测文件夹e，找到文件夹e下存储有文件f和文件g。可以先对文件f和文件g进行正则校验，判断其是否记录有依赖服务地址链接，然后依次向上级检测文件d与文件b判断其是否记录有依赖服务地址链接，直至文件路径a下的文件被遍历检测完成。这种由下至上的检测方法可以准确地记录每一层文件夹与文件夹下内容之间的对应关系，有助于提高遍历整个项目的源码文件的效率。

在本示例性实施方式中规则匹配可以采用正则表达式技术，即判断对象是否符合一定规则，是则对对象进行抓取与记录，不是则接着判断下一个对象。

根据一些实施例，通过java程序实现上述过程。例如，可以使用java中通用的文件处理方式filereader(java语言中的文件读取工具)按照文件路径层次逐层读取源码文件,目标文件类型可包括.java文件、.xml文件以及.properties文件。

可以采用多线程(thread)方式按照文件路径分层，并行读取文件，同时匹配正则表达式进行对依赖服务链接的抓取，并建立本系统域名与抓取到的依赖服务的关联关系。

步骤104，检查所述依赖服务以判断所述依赖服务的状态是否异常。

检查所述依赖服务包括采用定时任务检查所述依赖服务的地址链接。定时任务是指，在设定时间执行预先设计好的任务。本示例实施方式中可以采用spring中的quartz技术实现。

根据一些实施例，步骤104还可以包括存储所述依赖服务的状态，存储状态的位置可以为上述的信息池，以利于实现实时查询更新的目的。

步骤106，当判断所述依赖服务异常时，提供反馈信息。

通过调度定时任务访问依赖服务链接，依据返回状态判断依赖服务的运行状态，可以实现对依赖服务的实时监控，当所述依赖服务异常时，例如当单位时间内返回状态正常的次数低于预定次数，则可以认为该依赖服务可用率过低，判断所述依赖服务异常，并触发预警通知，对外提供状态监控预警等反馈信息。在一些实施例中，上述步骤可以包括同步更新信息池中的数据，所述数据包括依赖服务的状态。为保证实时性及高效率，上述监控依赖服务状态以及提供反馈信息可以采用多线程技术。

触发预警并提供反馈信息时，可以通过读取反馈信息接收人及反馈方式确定提供反馈方式的途径。上述反馈信息接收人及反馈方式可根据需要灵活配置。例如，可以通过邮件服务和短信服务，双渠道通知本系统或本系统的相关主体与外部系统或外部系统的相关主体，达到预警目的。上述反馈信息可以包括与所述系统关联的所述依赖服务的状态。根据一些实施例，可以获取所述反馈信息的处理结果，例如判断所述反馈信息已经由外部系统或外部系统的相关主体手动处理后，更新所述依赖服务的状态，在一些实施例中，更新所述依赖服务的状态包括更新信息池中的依赖服务的状态。

除了上述用于监控系统的依赖服务的服务监控方法，本公开还提供一种用于监控系统对外提供的依赖服务的服务监控方法。

图2是本公开示例性实施例中另一种服务监控方法的流程图。参考图2，服务监控方法200可以包括：

步骤s202，获取利用所述依赖服务的外部系统的信息。

可以在接入系统上线前扫描所述系统的项目文件，上述的系统文件可以包括配置文件、源码文件等，将利用所述依赖服务的外部系统地址链接进行抓取分类。

根据一些示例实施例，在抓取依赖服务的地址链接过程中，可以通过规则匹配方式检出文件中的地址链接，记录检出的文件的路径，并依据该路径获取该文件所属文件夹的路径，根据所属文件夹的路径，检测与该文件夹同级的文件，以此类推，逐层向上检测，直至遍历所有项目源码文件。举例而言，若检测到源码文件中文件路径a下存储了文件b以及文件夹c，则继续检测文件夹c，找到文件夹c下的文件d和文件夹e，继续检测文件夹e，找到文件夹e下存储有文件f和文件g。可以先对文件f和文件g进行正则校验，判断其是否记录有依赖服务地址链接，然后依次向上级检测文件d与文件b判断其是否记录有依赖服务地址链接，直至文件路径a下的文件被遍历检测完成。这种由下至上的检测方法可以准确地记录每一层文件夹与文件夹下内容之间的对应关系，有助于提高遍历整个项目的源码文件的效率。

在本示例性实施方式中规则匹配可以采用正则表达式技术，即判断对象是否符合一定规则，是则对对象进行抓取与记录，不是则接着判断下一个对象。如果通过java程序实现上述过程，可以使用java中通用的文件处理方式filereader(java语言中的文件读取工具)按照文件路径层次逐层读取源码文件,目标文件类型可包括.java文件、.xml文件以及.properties文件。可以采用多线程(thread)方式按照文件路径分层，并行读取文件，同时匹配正则表达式进行对外部系统地址链接的抓取，并建立该依赖服务与抓取到的外部系统地址链接的关联关系。

在一些实施例中，所述获取利用所述依赖服务的外部系统的信息也可以包括通过处理服务日志获取利用所述依赖服务的外部系统的信息。当然，也可以是通过其他方式抓取外部系统地址链接，本示例实施方式对此不做限定。

步骤s204，记录所述依赖服务与所述外部系统的对应关系。

在一些实施例中，还可以包括记录所述依赖服务与所述多个外部系统的关联关系，将所述关联关系存储到信息池中并在自定义时间对关联关系进行更新，以供依赖服务提供者查询、监控还有多少外部系统使用本依赖服务。

本示例实施方式中所述的信息池可以采用mysql数据库完成数据持久化，通过redis缓存达到实时查询更新的目的，并依据数据优先级在mysql数据库与redis缓存之间的数据同步，定时清理redis缓存中无效数据。上述的redis缓存是一个高性能的key-value数据库，mysql数据库是指关系型数据库管理系统。

在一些实施例中，上述方法200还可以包括步骤s206，在所述依赖服务发生变动之前，根据所述对应关系通知所述外部系统或所述外部系统的相关主体。当服务提供方对外提供依赖服务的系统服务变动操作时，可以由外部系统或外部系统的相关主体手动触发所述服务操作指令。所述服务变动操作可以包括服务更新、服务升级、服务下线中的一个或多个。

值得一提的是，在本示例实施方式的一些实施例中，可以同时使用方法100和方法200，实现既监控系统的依赖服务，也监控系统对外提供的依赖服务。

图3是本公开示例实施方式中提及的抓取系统文件中依赖服务地址链接的流程图。参考图3，抓取依赖服务地址可以包括：

步骤s302，可以使用filereader按文件路径进行文件读取后缀名为.java；.xml；.properties的文件。

步骤s304，判断单个文件读取完成后可以进行正则校验。

具体的正则校验过程可以为判断所述单个文件的内容是否匹配正则校验规则，如果匹配，则可以进入步骤s308将目标路径与本系统映射关系存入信息池；如果不匹配，则可以返回到步骤s302，继续读取其他文件，重复上述流程。

在一些实施例中，将映射关系存入信息池后，也可以继续读取其他文件，重复上述流程。

图4是本公开示例实施方式中信息池的工作原理示意图。参考图4，数据同步处理器可以依据数据热度定时将mysql数据同步到redis缓存中，并定时清除redis缓存中无效数据。

图5是本公开示例实施方式中判断依赖服务是否异常的流程图。

参考图5，在步骤s502，当获取到依赖服务地址链接后，可以采用http通信的方式(或ftp、https等通信方式)访问依赖服务链接地址。

在步骤s504，判断上述访问是否返回成功状态码。如果该访问动作没有返回成功状态码，则可以将该链接访问失败次数failcount加1，并启动线程，在5秒(或其他预设时间)之后继续访问该地址。当每分钟内访问失败超过3次(或其他访问失败阈值)，可以将该连接状态更新为可用率低，并提供反馈信息。

在步骤s506，如果该访问动作返回成功状态码，则可以计算访问过程用时。

在步骤s508，判断访问用时是否超过20ms。当该访问用时超过20ms时，可以将该链接访问超时次数timeoutcounts加1，并启动线程，于5秒(或其他预设时间)之后继续访问该地址。当每分钟访问超时次数达到5次(或其他访问超时阈值)，可以更新该链接状态为可用率低，并提供反馈信息。

在步骤s510，如果上述访问过程用时并未超时，可以访问下一个依赖服务的链接地址，并循环上述判断过程。

对应于上述方法实施例，本公开还提供两种服务监控装置，可以分别用于执行上述服务监控方法100和服务监控方法200。

图6是本公开示例性实施方式中的服务监控装置。参考图6，服务监控装置600可以包括服务获取模块602、服务监控模块604以及反馈提醒模块606。

服务获取模块602可以用于获取所述系统的项目文件，提取所述依赖服务的地址链接。

服务监控模块604可以用于检查所述依赖服务以判断所述依赖服务的状态是否异常。

反馈提醒模块606可以用于当判断所述依赖服务异常时，提供反馈信息。

图7是本公开示例性实施方式中的服务监控装置。参考图7，服务监控装置700可以包括服务获取模块702、服务记录模块704以及操作提醒模块706。

服务获取模块702可以用于获取利用所述依赖服务的外部系统的信息。

服务记录模块704可以用于记录所述依赖服务与所述外部系统的对应关系。

在其他实施例中，装置700还可以包括操作提醒模块706，用于在所述依赖服务发生变动之前，根据所述对应关系通知所述外部系统或所述外部系统的相关主体。由于上述装置的工作过程已在对应的方法实施例中进行详细描述，本公开于此不再赘述。

综上所述，本公开提供的服务监控方法与装置通过对系统的依赖服务进行监控，实时获取依赖服务状态，并在依赖服务出现异常时进行提醒，实现了依赖服务线上可视化监控，降低了在检查系统异常时的人工成本，节省了大量人力以及时间，极大提高了工作效率。同时，通过对使用本系统提供的依赖服务的外部系统进行监控，可以为依赖服务提供方节省大量核实依赖服务被使用状态的时间，避免了无人使用的依赖服务因为不敢下线而继续活动，节省了依赖服务提供方的资源。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。