调用链原理（转载）

声明：本文转载自其他作者的文章，供自己学习之用。

调用链的兴起
1，分布式遇到的问题：随着微服务设计理念在系统中的应用，业务的调用链越来越复杂。一个请求可能会涉及到几十个服务的协同操作，涉及到多个团队的业务系统。当遇到问题需要定位时候，也会产生一系列的麻烦。
2，解决方案：通过调用连，把一次请求调用过程完整的串联起来，实现了对请求调用路径的监控，便于故障快速定位。
3，调用链显示内容：各个调用环节的性能分析(如各个API使用时间、使用堆栈情况)、在调用连各个环节依赖关系还原、SQL语句打印、IP显示等。

调用链原理
1，请求到来生成一个全局TraceID，通过TraceID可以串联起整个调用链，一个TraceID代表一次请求。
2，除了TraceID外，还需要SpanID用于记录调用父子关系。每个服务会记录下Parent id和Span id，通过他们可以组织一次完整调用链的父子关系。
3，一个没有Parent id的span成为root span，可以看成调用链入口。
4，所有这些ID可用全局唯一的64位整数表示；
5，整个调用过程中每个请求都要透传TraceID和SpanID。
6，每个服务将该次请求附带的TraceID和附带的SpanID作为Parent id记录下，并且将自己生成的SpanID也记录下。
7，要查看某次完整的调用则只要根据TraceID查出所有调用记录，然后通过Parent id和Span id组织起整个调用父子关系。
分布式系统的远程调用过程

典型的分布式系统的调用关系如下图所示，在用户的一个请求到达组合的前端服务后，前端服务会分发请求到内部的各个服务，每次调用都设计跨系统的一次请求和一次响应。

在有大规模、高并发请求量的系统中，我们如何标识这些请求及存储这些调用信息，并形成一个调用链呢？

如果系统的某两个服务之间出了问题，我们又如何提供可视化的方式展现调用链，并在调用链上标注产生问题的那条边呢？

从上图可知，服务于一个请求的内部服务调用结构是一个树形结构，树节点是整个架构的基本单元，每个节点对应一个服务。
在谷歌的Dapper论文中，每个节点对应一个Span，节点之间的连线标识为Span与其Parent Span之间的关系（请求和响应的调用关系），并将请求调用和响应组成的数据称为调用信息。

现在，我们重点关注两个服务之间的通信，两个服务之间也许会有成千上万次通信，每一次都有成对的一次请求和响应，但是它们的顺序是不能保证的（发送请求1、2得到响应2、1）。所以，需要一种手段来标识请求和响应是一对。

谷歌的Dapper论文通过增加应用层的标记来对服务化中的请求和响应建立联系。例如，它通过HTTP协议头来携带标记信息，标记信息包括标识调用链的唯一流水ID（TraceID），以及标识调用层次和顺序的SpanID和ParentSpanID。

一次远程调用分为4个阶段，每个阶段对应一种远程调用信息的类型：

调用端发送请求的调用信息 RPCPhase.P1
被调用端接收请求的调用信息 RPCPhase.P2
被调用端发送响应的调用信息 RPCPhase.P3/E3
调用端接收响应的调用信息 RPCPhase.P4/E4
由于响应又被分为成功响应和异常响应。所以第三第四阶段的调用类型分为P/E。另外主线程与子线程之间的调用信息称为 RPCPhase.SIB。
上面每种调用信息都包含：调用端/被调用端的IP、系统ID;本次请求的TraceID、SpanID、ParentSpanID；时间戳、调用的方法名称及远程调用信息的类型等等。

TraceID
如下图所示，前端接收用户请求后，会为用户分配一个TraceID，然后在内部服务调用时，会依次传递。所以通过TraceID可以追踪到这个唯一ID所有的请求和响应，并定位问题发生的节点。