本文将结合一个具体例子中的细节详细描述Istio调用链的原理和使用方式。并基于Istio中埋点的原理解释来说明：为了输出一个质量良好的调用链，业务程序需根据自身特点做适当的修改，即并非官方一直在说的完全无侵入的做各种治理。另外还会描述Istio当前版本中收集调用链数据可以通过Envoy和Mixer两种不同的方式。
Istio一直强调其无侵入的服务治理，服务运行可观察性。即用户完全无需修改代码，就可以通过和业务容器一起部署的proxy来执行服务治理和与性能数据的收集。原文是这样描述的： Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, then configure and manage Istio using its control plane functionality。
调用链的埋点是一个比起来记录日志，报个metric或者告警要复杂的多，根本原因是要能将在多个点上收集的关于一次调用的多个中间请求过程关联起来形成一个链。Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 描述了其中的原理和一般性的机制，还是挺复杂的。也有很多实现，用的比较多的如zipkin，和已经在CNCF基金会的用的越来越多的Jaeger，满足Opentracing语义标准的就有这么多。在Istio中大段的埋点逻辑在Sidecar中已经提供，业务代码不用调用以上这些埋点方式来创建trace，维护span等这些复杂逻辑，但是为了能真正连接成一个完整的链路，业务代码还是需要做适当修改。我们来分析下细节为什么号称不用修改代码就能搞定治理、监控等高级功能的Sidecar为什么在调用链埋点的时候需要改应用代码。
调用详细
服务调用关系 简单期间，我们以Istio最经典的Bookinfo为例来说明。Bookinfo的4个为服务的调用关系是这样：
调用链输出 从前端入口gateway那个envoy上进行一次调用，到四个不同语言开发的服务间完成调用，一次调用输出的调用链是这样：
简单看下bookinfo 中的代码，能看到并没有任何创建维护span这种埋点的逻辑，想也是，对于python、java、ruby、nodejs四种不同的语言采用不同的埋点的库在来实现类似的埋点逻辑也是非常头痛的一件事情。那我们看到这个调用链信息是怎么输出的？答案当然是应用边上的sidecar Envoy，Envoy对于调用链相关设计参照这里。sidecar拦截应用程序所有的进和出的网络流量，跟踪到所有的网络请求，像Service mesh的设计理念中其他的路由策略、负载均衡等治理一样，只要拦截到流量Sidecar也可以实现埋点的逻辑。
埋点逻辑 对于经过sidecar流入应用程序的流量，如例子中流入roductpage， details、reviews和ratings的流量，如果经过Sidecar时header中没有任何跟踪相关的信息，则会在创建一个span，Traceid就是这个spanId，然后在将请求传递给通pod的业务服务；如果请求中包含trace相关的信息，则sidecar从走回归提取trace的上下文信息并发给应用程序。
对于经过sidecar流出的流量，如例子中gateway调用productpage，或者productpage调用链details和reviews的请求。如果经过sidecar时header中没有任何跟踪相关的信息，则会创建根span，并将该跟span相关上下文信息放在请求头中传递给下一个调用的服务，当然调用前会被目标服务的sidecar拦截掉执行上面流入的逻辑；当存在trace信息时，sidecar从header中提取span相关信息，并基于这个span创建子span，并将新的span信息加在请求头中传递。
以上是bookinfo一个实际的调用中在proxy上生成的span主要信息。可以看到，对于每个app访问都经过Sidecar代理，inbound的流量和outbound的流量都通过Sidecar。图上为了清楚表达每个将对Sidecar的每个处理都分开表示，如productpage，接收外部请求是一个处理，给details发出请求是一个处理，给reviews发出请求是另外一个处理，因此围绕Productpage这个app有三个黑色的处理块，其实是一个Sidecar。为了不使的图上太凌乱，最终的Response都没有表示。其实图上每个请求的箭头都有一个反方向的response，在服务发起方的Sidecar会收到response时，会记录一个CR(client received)表示收到响应的时间并计算整个span的持续时间。
解析下具体数据，结合实际调用中生成的数据来看下前面proxy埋点的逻辑会更清楚些。 1.从gateway开始，gateway作为一个独立部署在一个pod中的envoy进程，当有请求过来时，它会将请求转给入口的微服务productpage。Gateway这个Envoy在发出请求时里面没有trace信息，会生成一个根span：spanid和traceid都是f79a31352fe7cae9，parentid为空，并记录CS时间，即Client Send；
2.请求从入口gateway这个envoy进入productpage前先讲过productpage pod内的envoy，envoy处理请求头中带着trace信息，则记录SR,Server received，并将请求发送给Productpage业务容器处理，productpage在处理请求的业务方法中需要接收这些header中的trace信息,然后再调用Details和Reviews的微服务。 Python写的 productpage在服务端处理请求时，先从request中提取接收到的header。然后再调用details获取details服务时，将header转发出去。