CN113905105B - 一种建立应用依赖关系的方法及装置 - Google Patents

Abstract

本申请公开了一种建立应用依赖关系的方法及装置，通过TCP网络调用五元组信息及进程信息，获取进程之间的关联关系；并基于建立的进程之间的关联关系以及进程所属的应用，确定存在依赖关系的应用。本申请提供与语言无关、与平台无关且对业务系统无侵入的构建应用之间的关联关系的方法，自动、简单地确定了应用依赖关系。进一步地，本申请实施例采用真实故障注入的方式，针对每一个依赖通过依次注入故障，通过验证业务稳态指标结果实现了具有依赖关系的应用之间的依赖程度的判定。

Description

一种建立应用依赖关系的方法及装置

技术领域

本申请涉及但不限于计算机技术，尤指一种建立应用依赖关系的方法及装置。

背景技术

计算机应用程序(下文简称为应用)通常具有一连串的依赖关系，这些依赖关系是成功部署并执行这些应用所必需的。这些依赖关系可以包括对诸如数据库、应用、硬件组件、网络连接等等的资源的访问。

云上大量不同技术栈客户进行架构升级、进行容器化以及微服务改造，伴随着业务持续迭代，业务及系统复杂度随之变高后，系统能否始终保证高可用，是业务系统研发面对的挑战。在系统高空治理中，业务链路梳理是首要保证的目标，但是，相关技术中对业务链路的梳理存在以下问题：技术栈不统一，链路追踪方法无法跨语言支持应用依赖关系自动梳理，且无法识别三方服务依赖；传统链路追踪方法无法针对采买系统进行应用依赖关系梳理。而且，对应用依赖强弱的识别繁琐，需要将下游依赖的元数据通过人工采集并配合故障注入工具的使用才能实现识别。

因此，亟需一种跨语言，且与平台无关、业务无侵入的依赖关系确定方法。

发明内容

本申请提供一种建立应用依赖关系的方法及装置，能够自动、简单地确定应用依赖关系。

本发明实施例提供了一种建立应用依赖关系的方法，包括：

根据传输控制协议TCP网络调用信息和进程信息，建立进程之间的关联关系；

根据建立的进程之间的关联关系和进程的归属信息确定应用之间的依赖关系。

在一种示例性实例中，所述TCP网络调用信息包括五元组信息；所述建立进程之间的关联关系，包括：

根据获得的与所述TCP网络调用相关的所述进程信息，建立五元组信息中的IP地址信息和端口号与当前运行的进程的映射关系；

根据所述TCP网络调用信息，以及五元组信息中的IP地址信息和端口号与当前运行的进程的映射关系，建立存在调用关系的进程间的关联关系。

在一种示例性实例中，还包括：

根据所述五元组信息中的状态信息，确定建立所述关联关系的进程间的调用关系。

在一种示例性实例中，所述确定应用之间的依赖关系，包括：

根据分别属于两个应用的一个或多个进程之间建立的关联关系，确定所述两个应用之间存在依赖关系。

在一种示例性实例中，还包括：

根据所述进程所在的容器、容器所在的主机、主机所在的数据中心，逐层确定出容器之间的依赖关系和/或主机之间的依赖关系和/或数据中心之间的依赖关系。

在一种示例性实例中，还包括：

通过对所述应用之间的所述依赖关系的下游不可用的模拟，确定所述应用之间的依赖关系的依赖程度。

在一种示例性实例中，所述确定应用之间的依赖关系的依赖程度，包括：

配置一个以上业务稳态指标信息；

向所述应用之间的依赖关系的下游应用进行故障注入，根据稳态指标结果确定所述应用之间的依赖关系的依赖程度。

在一种示例性实例中，所述根据稳态指标结果确定所述应用之间的依赖关系的依赖程度，包括：

所述稳态指标结果显示失败的比例高于预设阈值，确定出所述应用之间的依赖依赖程度强；所述稳态指标结果显示失败的比例低于预设阈值，确定出所述应用之间的依赖依赖程度弱。

本申请实施例还提供一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行上述任一项所述建立应用依赖关系的方法。

本申请实施例再提供了一种实现应用依赖关系建立的设备，包括存储器和处理器，其中，存储器中存储有以下可被处理器执行的指令：用于执行上述任一项所述的建立应用依赖关系的方法的步骤。

本申请实施例又提供了一种建立应用依赖关系的装置，包括：建立模块、第一确定模块；其中，

建立模块，用于根据TCP网络调用信息和进程信息，建立进程之间的关联关系；

第一确定模块，用于根据建立的进程之间的关联关系和进程的归属信息确定应用之间的依赖关系。

在一种示例性实例中，还包括第二确定模块，用于：

通过对所述应用之间的依赖关系的下游不可用的模拟，确定所述应用之间的依赖关系的依赖程度。

通过本申请实施例提供的建立应用依赖关系的方法，通过TCP网络调用五元组信息及进程信息，获取进程之间的关联关系；并基于建立的进程之间的关联关系以及进程所属的应用，确定存在依赖关系的应用。本申请提供与语言无关、与平台无关且对业务系统无侵入的构建应用之间的关联关系的方法，自动、简单地确定了应用依赖关系。

进一步地，本申请实施例采用真实故障注入的方式，针对每一个依赖通过依次注入故障，通过验证业务稳态指标结果实现了具有依赖关系的应用之间的依赖程度的判定。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本申请技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请的技术方案，并不构成对本申请技术方案的限制。

图1为本申请实施例中建立应用依赖关系的方法的流程示意图；

图2为本申请实施例中建立进程之间的关联关系第一实施例的示意图；

图3为本申请实施例中建立进程之间的关联关系第二实施例的示意图；

图4为本申请实施例中建立应用依赖关系的装置的组成结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下文中将结合附图对本申请的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

在本申请一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

应用是一组运维实体的抽象，可以理解为是架构拓扑中的聚合实体，比如buy应用，在K8s下由一组Pod列表组成，每一个Pod又可能由一组进程组成，实际发生网络调用关系的是最内部的进程之间的关联关系，上层均为聚合实体(如Pod以及应用)。因此，本申请发明人巧妙地通过进程之间的关联关系来推导出应用之间的依赖关系，提供了一种与语言无关、与平台无关且对业务系统无侵入的构建应用之间的关联关系的方法。

其中，K8s是Kubernetes的简称，是一种可自动实施Linux容器操作的开源平台。Pod是Kubernetes集群中最小的单元。Pod是对一个容器或(某些情况下)一组容器的抽象，集群中的每个Pod均分配有一个唯一的内部可用IP地址。

图1为本申请实施例中应用依赖关系确定方法的流程示意图，如图1所示，包括：

步骤100：根据TCP网络调用信息和进程信息，建立进程之间的关联关系。

在一种示例性实例中，传输控制协议(TCP，Transmission Control Protocol)网络调用信息可以包括如网络五元组信息。网络五元组信息包括：本地IP地址(sourceIp)、本地端口号(sourcePort)、远端IP地址(destinationIp)、远端端口号(destinationPort)和状态(state)。

在一种示例性实例中，步骤100还可以包括：获取网络五元组信息。在一种实施例中，在Linux环境中，可以通过查看网络调用请求cat/proc/net/tcp，对原始数据模型进行抽象，抽取出核心字段来获得网络五元组信息。

在一种实施例中，原始数据模型可以包括如下所示：

sl local_address rem_address st tx_queue rx_queue tr tm->whenretrnsmt uid timeout inode

序号本地IP:本地端口远端IP:远端端口状态队列长度定时器类型超时时间超时重传次数用户ID-----Inode

38:7D59C00B:1F90 4331C10B:CB28 06 00000000:0000000003:000010D9000000000 0 0 3ffff880036083900

在一种示例性实例中，步骤100还可以包括：获取进程信息。在一种实施例中，可以根据原始数据模型中的inode字段获取与TCP网络调用相关(如正在运行)的进程的进程信息。更具体地，可以根据inode字段，通过/proc/{pid}/fd中的socket:[{inode}]反查出inode对应的进程信息。

在一种示例性实例中，步骤100可以包括：

根据获得的与TCP网络调用相关的进程信息，建立IP地址信息和端口号与运行的进程的映射关系；

根据TCP网络调用信息，以及IP地址信息和端口号与运行的进程的映射关系，建立存在调用关系的进程间的关联关系。

容易理解，当通过inode字段反查出与TCP网络调用相关的进程的进程信息后，也就建立了sourceIp和sourcePort与反查出的进程之间的映射关系；同理，对于TCP网络调用信息中的远端，同样可以根据inode字段反查出与TCP网络调用相关的进程的进程信息，这样，也就可以建立destinationIp和destinationPort与远端机器上与TCP网络调用相关的进程的映射关系。

在一种示例性实例中，本步骤还可以包括：

根据五元组信息中的状态信息，确定建立关联关系的进程间的调用关系。

在一种示例性实例中，TCP网络请求为双工通信，仅基于五元组信息<sourceIp,sourcePort,destinationIp,destinationPort>无法识别请求的来源与目标，source侧可能是请求的发起方，也可能是被调用方，因此，本申请实施例中，还包括：基于网络调用中的state信息来区分进程之间的调用关系。在一种实施例中，如果source侧state信息为“LISTEN”状态，那么，由被调用方判断不在被调用方端口列表中的其它端口为主动请求端口。可以引入Bound概念，Bound包括InBound和OutBound，其中，InBound表示TCP网络调用的调用关系为dest->source方向的调用(即远端是调用方，本地是被调用方)，OutBound表示TCP网络调用的调用关系为source->dest方向的调用(即本地是调用方，是远端被调用方)。

在一种示例性实例中，步骤100可以在预设周期执行。

步骤101：根据建立的进程之间的关联关系和进程的归属信息确定应用之间的依赖关系。

应用程序是由一个或多个进程组成的一个整体。在一种示例性实例中，步骤101可以包括：根据分别属于两个应用的一个或多个进程之间建立的关联关系，确定这两个应用之间存在依赖关系。也就是说，两个应用之间的依赖关系可以通过分别属于两个应用的进程之间的关联关系聚合而成。

在一种示例性实例中，还可以包括：

根据进程所在的容器、容器所在的主机、主机所在的数据中心等，可以逐层确定出实体之间的依赖关系，比如容器之间的依赖关系，和/或主机之间的依赖关系，和/或数据中心之间的依赖关系。

本申请实施例中，通过识别哪些实体正在彼此通信，正在通信的实体正在与哪些TCP端口进行通信以及哪些进程正在这些实体上运行，可以在相互依赖的应用之间构建上游和下游的依赖关系即确定应用之间的依赖关系。也就是说，基于网络调用关系信息如五元组信息，通过网络调用数据构建通信双方的实体关系，并可以根据通信实体关系推导出上层实体关系。比如：根据两台主机上的两个进程之间已建立的调用关系，推导出建立调用关系的两个进程分别归属的两台主机之间存在依赖关系。

本申请实施例提供的建立应用依赖关系的方法，通过TCP网络调用五元组信息及进程信息，获取进程之间的关联关系；并基于建立的进程之间的关联关系以及进程所属的应用，确定存在依赖关系的应用。本申请提供与语言无关、与平台无关且对业务系统无侵入的构建应用之间的关联关系的方法，自动、简单地确定了应用依赖关系。

实体依赖关系映射(EDM)通过识别哪些设备正在彼此通信，这些正在彼此通信的设备正在与哪些TCP端口进行通信以及哪些进程正在这些设备上运行，从而在相互依赖的应用程序之间构建上游和下游的依赖关系。

图2为本申请实施例中建立进程之间的关联关系第一实施例的示意图，如图2所示，可以分别在两台主机上安装代理(Agent)模块，Agent模块用于采集进程和网络数据，在服务端通过网络数据模型中的sourceIp:sourcePort建立套接字(socket)与进程的关系，并将建立好的关系保存在分布式缓存中。图2中，设备A上的容器通信时，假设抓取到sourceIp:sourcePort(170.1.1.1:8081)与tomcat进程的关系，写入缓存(cache)中，设备B上的容器通信时，假设抓取到sourceIp:sourcePort(170.1.2.1:6379)与redis进程的关系，写入cache中；当在任何一台设备上分析destinationIp:destinationPort时，都能找到对应的映射关系。在一种实施例中，cache的生命周期时长需要设置为略大于采集频率，因为，如果过小会导致查询不到存储的映射关系，而过大会导致可能查到脏数据。

对于设备A开启了Agent模块并开始采集分析，而设备B未安装Agent模块的情况，是无法获取设备A上的进程与设备B上的进程之间的关系的。不过，可以基于目标IP与设备元数据的比对，分析出设备A与设备B的关系。

在实际应用中，一些容器会主动配置将自身所在设备上的端口映射到容器内的另外一个端口，对于这种存在端口映射的TCP网络请求的情况，在构建进程之间的关联关系时，需要使用端口转换功能。图3为本申请实施例中建立进程之间的关联关系第二而实施例的示意图，如图3所示，本实施例中，假设在设备B上的容器进行注册时，主动注册容器与设备的端口映射，当获取到设备B上Redis容器的网络调用时，查询注册的容器与设备的端口映射，如果存在，那么，如图3中的加粗斜黑体所示，同步向cache写入设备B和映射端口与redis进程的映射关系。这样，当遇到<170.1.1.1:8081，10.1.1.2:6378>网络数据请求时，进程之间的关系也可以建立起来。

本申请实施例中，网络数据请求是基于进程实体的，建立的是进程之间的关联关系，进一步地，可以根据进程所在的容器、或容器所在的主机、或主机所在的数据中心等，逐层确定出容器之间、主机之间、数据中心之间的关联关系。

在一种示例性实例中，K8s应用为Pod，但是在实际架构中，采用非业务容器SideCar部署形态的较多，SideCar容器、业务容器及Pod并不具备等价的强弱依赖属性，因此，可以通过相比于Pod更加细化的运维实体来实现依赖关系的建立即依赖治理。针对业务本身，更关注业务容器，因此，本申请实施例中，在K8s架构下，可以按照Pod下的容器维度作为应用的分组维度进行依赖治理即可以通过Pod下的容器之间的关联关系建立应用之间的依赖关系。

在一种示例性实例中，对于短链接，创建TCP连接需要执行的系统调用，由于客户端不执行bind函数，系统会随机分配端口，但是，客户端一定会执行socket函数和connect函数(尤其是connect函数)，因此，本申请一种实施例中，可以通过监听这两个系统调用来抓取TCP短链接。一种实施例中，auditd能够根据规则在触发系统调用或系统调用返回时生成相应的日志记录，比如创建一条audit规则为：auditctl-a exit,always-F arch＝b64-Sconnect-k TEST_CONN，上述规则的意思是，64位系统，在系统调用connect函数返回时，创建一条key为TEST_CONN的记录。日志默认保存在/var/log/audit/audit.log文件中。对每个connect函数调用，会生成两条记录，分别是TYPE＝syscall和TYPE＝SOCKADDR，第一条记录中包括调用进程的pid、ppid、命令等；第二条记录中包括IP地址、端口号等。

对于短链接，由于采用audit抓取，不会得到本地IP地址与端口号，也不会有TCP状态信息，取而代之的是连接的发起方与接收方。比如：一条记录:＝TIMESTAMP@#进程1记录@！进程2记录@！……@！进程n记录@！；进程x记录:＝<pid>＝连接1记录@*连接2记录@*……@*连接n记录@*；连接x记录:＝REMOTE_IP|REMOTE_PORT|STATE|HAS_DNS；STATE:＝A(表示accept，服务端)or C(表示connect，客户端)；HAS_DNS:＝0(无记录)or 1(有对应记录)等等。对于短链接，只抓取connect函数与accept函数(以及accept4函数)调用容易导致现存长连接信息的缺失，使用读取/proc/net/tcp文件进行补充，读取频率可以更低(如3分钟一次)，且只需要established和listen状态；该采集相比audit会占用更低的系统资源。对于缓存设置，要避免内存占用过大。由于长连接不一定有connect函数与accept函数调用，因此是不能准确统计长连接的频次信息的。

在一种示例性实例中，本申请还可以包括：

通过对应用之间的依赖关系的下游不可用的模拟，确定应用之间的依赖关系的依赖程度。

在一种实施例中，确定应用之间的依赖关系的依赖程度可以包括：

配置一个以上业务稳态指标信息；

向应用之间的依赖关系的下游应用进行故障注入，根据稳态指标结果确定应用之间的依赖关系的依赖程度。

本申请实施例中，采用贴合真实故障场景下的下游不可用的表象来验证应用之间依赖的强弱属性，具体可以使用故障注入方法。本申请实施例中，是对应用维度的依赖强弱的分析，因此，只需要评估依赖关系中下游依赖服务的调用IP与端口即可完成下游不可用的故障场景模拟。

在一种实施例中，业务稳态指标可以包括如：HTTP网页响应的字符串中是否包括404、响应时间(RT)、每秒钟的请求量(QPS)、业务成功率、错误日志数等。比如：稳态指标结果显示失败的比例高于预设阈值，确定出应用之间的依赖依赖程度强；稳态指标结果显示失败的比例低于预设阈值，确定出应用之间的依赖依赖程度弱。在另一种实施例中，阈值也可以从小到大设置多个，这样，可以将依赖程度强弱分出多个等级。

在一种示例性实例中，为了避免因环境或者其他不稳定因素带来的干扰，可以预先设置判断次数阈值(比如3次)，自动进行多次判断，最后根据稳态指标结果进行依赖关系强弱的判定。

本申请实施例中，采用真实流量(线上或者灰度环境)，针对每一个依赖通过依次注入异常，通过验证业务稳态指标结果实现了具有依赖关系的应用之间的依赖程度的判定。

本申请实施例中，通过上述依赖程度的确定过程，会基于依赖关系自动生成依赖治理列表，每一条治理对象中的故障注入靶点与参数均来自依赖分析，用户无需填写复杂的故障信息。

在一种实施例中，一些服务之间的调用是通过K8s的服务(Service)进行调用的，比如Service A调用Service B暴露出来的Service，那么，调用关系为：A->ServiceEndpoint->B。其中，Service是将运行在一组Pods上的应用程序公开为网络服务的抽象方法；Endpoint是K8s集群中的一个资源对象，用来记录一个Service对应的所有Pod的访问地址。由于基于网络TCP五元组是无法识别Service的Endpoint的，因此，也就无法构建Service A到Service B的关联关系。架构感知构建关系的一个原则是同一层次原则，也就是说，只会在同一层次构建如Pod与Pod之间的关系、Service与Service之间的关系，不会跨层构建关联关系，因为在应用强弱依赖治理中构建的层次是容器层，因此，是不能构建容器container到Service之间的关联关系的。那么，本申请实施例中，在Service B侧的网络调用中，获取到的远端的IP为Service A，那么，站在Service B的视角可以构建Service B<-Service A的关联关系，基于此，可以在应用和应用分组关系注册时，进行关系构建即可构建应用下游依赖关系。对于这种情况，依赖关系建立后，在模拟下游不可用时上游的应用表现中，在使用ServiceB<-ServiceA的反向关系时，故障注入的IP为下游实际提供服务的Service B的IP，但是，Service A调用Service B是通过Service B暴露的Service，所以实际网络调用并不会直连Service B，因此阻断Service B是无法达到阻断调用的目标的，因此，本申请实施例中，需要在Service A侧阻断Service B暴露出来的Service的Endpoint来进行依赖关系强弱的分析，也就是说，故障参数中会引入Service的Endpoint。

本申请还提供一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行上述任一项所述的建立应用依赖关系的方法。

本申请再提供一种实现应用依赖关系建立的设备，包括存储器和处理器，其中，存储器中存储有以下可被处理器执行的指令：用于执行上述任一项所述的建立应用依赖关系的方法的步骤。

图4为本申请实施例中建立应用依赖关系的装置的组成结构示意图，如图4所示，包括：建立模块、第一确定模块；其中，

建立模块，用于根据TCP网络调用信息和进程信息，建立进程之间的关联关系；

第一确定模块，用于根据建立的进程之间的关联关系和进程的归属信息确定应用之间的依赖关系。

在一种示例性实例中，建立模块具体可以用于：

根据获得的与TCP网络调用相关的进程信息，建立IP地址信息和端口号与运行的进程的映射关系；

根据TCP网络调用信息，以及IP地址信息和端口号与运行的进程的映射关系，建立存在调用关系的进程间的映射关系。

在一种示例性实例中，第一确定模块具体可以用于：

根据分别属于两个应用的一个或多个建立关联关系的进程之间建立的关联关系，确定这两个应用之间存在依赖关系。

在一种示例性实例中，建立模块还用于：

根据五元组信息中的状态信息，确定建立映射关系的进程间的调用关系。

在一种示例性实例中，第一确定模块还用于：

根据进程所在的容器、容器所在的主机、主机所在的数据中心，逐层确定出实体之间的依赖关系。

本申请实施例提供的建立应用依赖关系的装置，通过TCP网络调用五元组信息及进程信息，获取进程之间的关联关系；并基于建立的进程之间的关联关系以及进程所属的应用，确定存在依赖关系的应用。本申请提供与语言无关、与平台无关且对业务系统无侵入的构建应用之间的关联关系的方法，自动、简单地确定了应用依赖关系。

在一种示例性实例中，本申请建立应用依赖关系的装置还可以包括：第二确定模块，用于：

通过对应用之间的依赖关系的下游不可用的模拟，确定应用之间的依赖关系的依赖程度。

在一种示例性实例中，第二确定模块具体可以用于：

配置一个以上业务稳态指标信息；

向应用之间的依赖关系的下游应用进行故障注入，根据稳态指标结果确定应用之间的依赖关系的依赖程度。

本申请实施例提供的建立应用依赖关系的装置，采用真实故障注入的方式，针对每一个依赖通过依次注入故障，通过验证业务稳态指标结果实现了具有依赖关系的应用之间的依赖程度的判定。

虽然本申请所揭露的实施方式如上，但所述的内容仅为便于理解本申请而采用的实施方式，并非用以限定本申请。任何本申请所属领域内的技术人员，在不脱离本申请所揭露的精神和范围的前提下，可以在实施的形式及细节上进行任何的修改与变化，但本申请的专利保护范围，仍须以所附的权利要求书所界定的范围为准。

Claims (10)

1.一种建立应用依赖关系的方法，包括：

根据传输控制协议TCP网络调用信息和进程信息，建立进程之间的关联关系；其中，所述TCP网络调用信息包括五元组信息；所述建立进程之间的关联关系，包括：根据获得的与所述TCP网络调用相关的所述进程信息，建立五元组信息中的IP地址信息和端口号与当前运行的进程的映射关系；根据所述TCP网络调用信息，以及五元组信息中的IP地址信息和端口号与当前运行的进程的映射关系，建立存在调用关系的进程间的关联关系；根据所述五元组信息中的状态信息，确定建立所述关联关系的进程间的调用关系；

根据建立的进程之间的关联关系和进程的归属信息确定应用之间的依赖关系。

2.根据权利要求1所述的方法，其中，所述确定应用之间的依赖关系，包括：

根据分别属于两个应用的一个或多个进程之间建立的关联关系，确定所述两个应用之间存在依赖关系。

3.根据权利要求1或2所述的方法，还包括：

根据所述进程所在的容器、容器所在的主机、主机所在的数据中心，逐层确定出容器之间的依赖关系和/或主机之间的依赖关系和/或数据中心之间的依赖关系。

4.根据权利要求1所述的方法，还包括：

通过对所述应用之间的所述依赖关系的下游不可用的模拟，确定所述应用之间的依赖关系的依赖程度。

5.根据权利要求4所述的方法，其中，所述确定应用之间的依赖关系的依赖程度，包括：

配置一个以上业务稳态指标信息；

向所述应用之间的依赖关系的下游应用进行故障注入，根据稳态指标结果确定所述应用之间的依赖关系的依赖程度。

6.根据权利要求5所述的方法，其中，所述根据稳态指标结果确定所述应用之间的依赖关系的依赖程度，包括：

所述稳态指标结果显示失败的比例高于预设阈值，确定出所述应用之间的依赖依赖程度强；所述稳态指标结果显示失败的比例低于预设阈值，确定出所述应用之间的依赖依赖程度弱。

7.一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行权利要求1~权利要求6任一项所述建立应用依赖关系的方法。

8.一种实现应用依赖关系建立的设备，包括存储器和处理器，其中，存储器中存储有以下可被处理器执行的指令：用于执行权利要求1~权利要求6任一项所述的建立应用依赖关系的方法的步骤。

9.一种建立应用依赖关系的装置，包括：建立模块、第一确定模块；其中，

建立模块，用于根据TCP网络调用信息和进程信息，建立进程之间的关联关系；其中，所述TCP网络调用信息包括五元组信息；所述建立进程之间的关联关系，包括：根据获得的与所述TCP网络调用相关的所述进程信息，建立五元组信息中的IP地址信息和端口号与当前运行的进程的映射关系；根据所述TCP网络调用信息，以及五元组信息中的IP地址信息和端口号与当前运行的进程的映射关系，建立存在调用关系的进程间的关联关系；根据所述五元组信息中的状态信息，确定建立所述关联关系的进程间的调用关系；

第一确定模块，用于根据建立的进程之间的关联关系和进程的归属信息确定应用之间的依赖关系。

10.根据权利要求9所述的装置，还包括第二确定模块，用于：

通过对所述应用之间的依赖关系的下游不可用的模拟，确定所述应用之间的依赖关系的依赖程度。