一种微服务环境中服务依赖关系构建方法与流程

本发明涉及计算机技术领域，更具体地，涉及一种微服务环境中服务依赖关系构建方法。

背景技术：

在新兴商业模式（如电子商务）和it技术（例如devops和云计算）的驱动下，软件架构正在迅速从单一体系转变为微服务体系结构。利用微服务架构，应用程序可以根据业务功能将复杂的交互解耦成许多松耦合度的细粒度服务。通常这些微服务通过一些轻量级网络协议（如http和rpc协议）进行连接。每个微服务都遵循单一职责原则，具有简单和独立的功能。微服务架构使软件系统具有新的特性，例如强大的可扩展性，适用于敏捷开发，快速交付等等。尽管如此，由于外部（例如，配置变化）和内部（例如软件缺陷）的损坏，微服务系统中的异常问题并不少见，这对企业收入带来重大影响。研究表明，亚马逊的每个请求的响应时间延迟100毫秒会导致销售额下降1％，而google曾报告由于响应时间延迟500毫秒而导致流量下降20％。

为了让微服务持续可靠地运行，有必要检测不良的性能问题并找出产生异常的根本原因。然而，由于以下挑战，在微服务环境中实现这一点是非常困难的：

复杂的网络依赖性。通过微服务体系结构，应用程序可以分解为许多细节复杂的网络拓扑。另外，为了连接包装在容器中的不同微服务，总是采用诸如flannel之类的覆盖网络，这进一步增加了性能诊断的复杂性。

持续集成和交付。微服务系统随着持续集成和交付技术而不断发展。这意味着异常检测和根本原因诊断程序应该适应这些变化以获得更好的结果。

动态运行时环境。微服务系统总是运行在状态经常变化的容器环境中，高度动态的环境加剧了性能诊断的难度。

大量的监控指标。由于微服务系统中存在如此多的服务，因此这些服务的监控指标（例如响应时间）的数量非常大。如何从这些数据中找出根源是一个具有挑战性的问题。

构建微服务系统中服务之间的网络依赖拓扑图是解决微服务系统中的异常诊断问题的关键一步，目前的方法要么需要修改应用程序或平台的源代码以获得服务依赖性，或者需要应用程序的领域知识进行构建，或者通过捕捉应用层数据包进行解析和构建，或者利用一些监控指标进行服务依赖的关联分析，这些方法要么基于侵入式的方法获得服务依赖关系，要么基于统计分析方法，这使得这些方法的应用场景有限或者最终得到的依赖关系是概率上而非真实的依赖关系。

技术实现要素：

本发明为克服上述现有技术所述的至少一种缺陷，提供一种微服务环境中服务依赖关系构建方法。

本发明旨在至少在一定程度上解决上述技术问题。

本发明的目的是提供一种微服务环境中服务依赖关系构建方法，本发明不需要应用程序领域知识、对应用程序或者平台进行源代码更改，并且最终得到的是真实的服务依赖关系。

为解决上述技术问题，本发明的技术方案如下：一种微服务关系中服务依赖关系构建方法，包括如下步骤：

s1：socket系统调用监控，所述socket系统调用包括以下函数：创建套接字函数，套接字绑定函数，套接字监听函数，连接函数，获取接收请求函数。

s2：socket调用拦截，采用跟踪工具对socket系统调用的函数进行拦截,并将拦截的结果保存为文件；

s3：socket数据解析，将步骤s2拦截保存的文件解析得到客户端ip和服务器ip之间原始的网络连接方向和依赖关系；

s4：分别构建客户端ip和服务器ip到服务实例的映射，根据所获得的客户端ip和服务器ip，从微服务架构的基础设施中获取ip到服务名的映射关系，所述映射关系结合步骤s3中的客户端ip和服务器ip之间的原始网络依赖关系得到当前应用程序的网络依赖关系，当前应用程序的网络依赖关系表示为：（服务名称，服务实例）->（服务名称，服务实例）；

s5：构建服务依赖关系图,根据步骤s4得到的应用程序的网络依赖关系构建服务依赖关系图。

进一步地，步骤s2中采用的跟踪工具为strace跟踪器。

进一步地，步骤s4中所述微服务架构的基础设施包括开源应用引擎docker和开源的容器集群管理系统kubernetes。

进一步地，步骤s5所述构建服务依赖关系图，具体步骤包括：

s5.1：初始化依赖关系图，根据基础设施中获取的数据，将每一个服务实例初始化为依赖关系图上的节点，节点的结构为（服务名称，服务实例）；

s5.2：填充依赖关系，对于ip到服务实例映射之后的每一行数据，所述数据形式表示为（服务名称，服务实例）—>（服务名称，服务实例），将箭头左侧的节点作为起点，箭头右侧的节点作为终点，在步骤s5.1所述的依赖关系图上将对应的节点按照起点到终点的方向连接一条有向线段。

进一步地，所述服务依赖关系图代表着当前应用程序的服务之间的依赖关系，服务依赖关系图是一个有向无环图，每一个节点代表该应用的一个服务实例，每一条有向线段代表着一个服务实例依赖于另外一个服务实例，其中有向线段的指向表示依赖方向。

与现有技术相比，本发明技术方案的有益效果是：

本发明提供的基于非侵入式的一种微服务关系中服务依赖关系构建方法，不需要应用程序领域知识、不需要对应用程序或者平台进行源代码更改，通过系统调用监控，socket调用拦截，socket数据解析，ip到服务实例映射，依赖关系图构建这五个步骤，最终得到真实的服务依赖关系。

附图说明

图1为本发明实施例以一种微服务环境中服务依赖关系构建方法流程图。

具体实施方式

下面结合附图和实施例对本发明的技术方案做进一步的说明。

实施例1

参见图1为本发明实施例示出的服务依赖关系构建方法流程图。

一种微服务关系中服务依赖关系构建方法，包括如下步骤：

socket系统调用监控，在计算机中，系统调用是程序从操作系统内核请求服务的方式。其中包括与硬件相关的服务（例如，访问硬盘）、创建和执行新的进程，以及与内核集成的服务（如调度）通信。系统调用提供了进程和操作系统之间的基本接口，所述socket系统调用包括以下函数：

创建套接字函数intsocket(intsocket,inttype,intprotocol)；

连接函数intconnect(intsockfd,conststructsockaddr*servaddr,socklen_taddrlen)；

套接字绑定函数intbind(intsockfd,conststructsockaddr*myaddr,socklen_taddrlen)；

套接字监听函数intlisten(intsockfd,intbacklog)；

获取接收请求函数intaccept(intsockfd,structsockaddr*cliaddr,socklen_t*addrlen)。

调用拦截，采用strace跟踪器对socket系统调用进行拦截,并将拦截的结果保存为文件；

socket数据解析，在微服务系统中，网络数据是表示真实服务依赖关系的重要信息。网络数据包的流动方向某种程度上代表着两个服务之间的依赖关系，如当数据包从服务a流向服务b时，我们可以认为服务a依赖于服务b。但是，同一个网络请求会包含request和response数据包，因此在客户端和服务器之间会存在双向的网络数据包，使得当我们在不同的主机上观察时，我们会得到一个相反的连接方向。例如，当我们在发送请求网络包的主机（192.168.1.2）中观察时，我们得到连接（192.168.1.2）->（192.168.1.3）。但在发送响应网络数据包的主机（192.168.1.3）中，我们将获得（192.168.1.3）->（192.168.1.2）。所以我们不能直接在主机中捕获数据包流动方向来构建服务之间的依赖关系。

为此引入了一种监控和拦截与系统网络套接字(socket)相关的系统调用的方法，例如socket()，connect()。网络套接字用于在计算机网络内在两个程序之间实现发送或接收数据的端点。由于每个套接字函数都与某个具体的套接字变量相关。当拦截一个套接字系统调用时，根据所拦截的系统调用函数名进行语义解析以及该函数的参数来获取客户端ip和服务器ip。例如，如果拦截了connect()函数，则套接字的本地地址将被解析为客户端ip，对端地址将被解析为服务器ip。另一种情况是，如果拦截了accept()函数，则本地地址将被解析为服务器ip，对等地址将被解析为服务器ip。因此能够得到网络连接的方向和两个服务之间的真正依赖关系。

ip到服务实例映射，在套接字解析之后，得到的是原始的网络ip连接关系(172.20.1.123->172.20.2.20)，而非服务名之间对应的依赖关系(user->user-db)。由于在微服务环境中，微服务的ip地址有可能是人为设定的或者是基础设施(如kubernetes)分配的，需要知道每一个ip对应的服务是什么，这些ip到服务名的映射关系可以从微服务架构的基础设施（如开源应用引擎docker和开源的容器集群管理系统kubernetes）中提取的得到。结合这些信息，可以将原始ip网络依赖关系（ip->ip）映射到当前应用程序的网络依赖关系表示为：（服务名称，服务实例）->（服务名称，服务实例）。

服务依赖关系图构建

所述服务依赖关系图代表着当前应用程序的服务之间的依赖关系，服务依赖关系图是一个有向无环图，每一个结点代表该应用的一个服务实例，每一条有向边代表着一个服务实例依赖于另外一个服务实例，其中有向边的指向代表着依赖方向；根据服务实例之间的依赖关系构造服务依赖关系图。

初始化依赖关系图，从基础设施中获取的数据，我们将每一个服务实例初始化为依赖关系图上的节点，节点的结构为（服务名称，服务实例），此依赖关系图上节点之间没有连接；

填充依赖关系，对于ip到服务实例映射之后的每一行数据，所述数据形式为（服务名称，服务实例）—>（服务名称，服务实例），将箭头左边的节点作为起点，箭头右边的节点作为终点，在依赖关系图上将对应的节点按照起点到终点的方向增加一条有向线段。

显然，本发明的上述实施例仅仅是为清楚地说明本发明所作的举例，而并非是对本发明的实施方式的限定。对于所属领域的普通技术人员来说，在上述说明的基础上还可以做出其它不同形式的变化或变动。这里无需也无法对所有的实施方式予以穷举。凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明权利要求的保护范围之内。