本文将结合一个具体例子中的细节详细描述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转发出去。
app.route(‘/productpage‘)
def front():
product_id = 0 # TODO: replacedefault value
headers = getForwardHeaders(request)
…
detailsStatus, details = getProductDetails(product_id, headers)
reviewsStatus, reviews = getProductReviews(product_id, headers)
return…
可以看到就是提取几个trace相关的header kv
def getForwardHeaders(request):
headers = {}
incoming_headers = [ ‘x-request-id‘,
‘x-b3-traceid‘,
‘x-b3-spanid‘,
‘x-b3-parentspanid‘,
‘x-b3-sampled‘,
‘x-b3-flags‘,
‘x-ot-span-context‘
]
for ihdr in incoming_headers:
val = request.headers.get(ihdr)
if val is not None:
headers[ihdr] = val
return headers
其实就是重新构造一个请求发出去，可以看到请求中包含收到的header。
def getProductReviews(product_id, headers):
url = reviews[‘name‘] + "/" + reviews[‘endpoint‘] + "/" + str(product_id)
res = requests.get(url, headers=headers, timeout=3.0)
3.从ProductPage出的请求去请求Reviews服务前，又一次通过同Pod的envoy，envoy埋点逻辑检查header中包含了trace相关信息，在将请求发出前会做客户端的调用链埋点，即以当前span为parent span，生成一个子span：即traceid：保持一致9a31352fe7cae9， spanid重新生成cb4c86fb667f3114，parentid就是上个span： f79a31352fe7cae9。
4.请求在到达Review业务容器前，先经过Review的Envoy，从Header中解析出trace信息存在，则发送Trace信息给Reviews。Reviews处理请求的服务端代码中需要解析出这些包含trace的Header信息。
reviews服务中java的rest代码如下：
@GETbr/>@Path("/reviews/{productId}")
public Response bookReviewsById(@PathParam("productId") int productId,
@HeaderParam("end-user") String user,
@HeaderParam("x-request-id") String xreq,
@HeaderParam("x-b3-traceid") String xtraceid,
@HeaderParam("x-b3-spanid") String xspanid,
@HeaderParam("x-b3-parentspanid") String xparentspanid,
@HeaderParam("x-b3-sampled") String xsampled,
@HeaderParam("x-b3-flags") String xflags,
@HeaderParam("x-ot-span-context") String xotspan)
即在服务端接收请求的时候也同样会提取header。调用Ratings服务时再传递下去。其他的productpage调用Details，Reviews调用Ratings逻辑类似。不再复述。
以一实际调用的例子了解以上调用过程的细节，可以看到Envoy在处理inbound和outbound时的埋点逻辑，更重要的是看到了在这个过程中应用程序需要配合做的事情。即需要接收trace相关的header并在请求时发送出去，这样在出流量的proxy向下一跳服务发起请求前才能判断并生成子span并和原span进行关联，进而形成一个完整的调用链。否则，如果在应用容器未处理Header中的trace，则Sidecar在处理outbound的请求时会创建根span，最终会形成若干个割裂的span，并不能被关联到一个trace上。
即虽然Istio一直是讲服务治理和服务的可观察性对业务代码0侵入。但是要获得一个质量良好的调用链，应用程序还是要配合做些事情。在官方的distributed-tracing 中这部分有描述：“尽管proxy可以自动生成span，但是应用程序需要在类似HTTP Header的地方传递这些span的信息，这样这些span才能被正确的链接成一个trace。因此要求应用程序必须要收集和传递这些trace相关的header并传递出去”
? x-request-id
? x-b3-traceid
? x-b3-spanid
? x-b3-parentspanid
? x-b3-sampled
? x-b3-flags
? x-ot-span-context
调用链阶段span解析：
前端gateway访问productpage的proxy的这个span大致是这样：
"traceId": "f79a31352fe7cae9",
"id": "f79a31352fe7cae9",
"name": "productpage-route",
"timestamp": 1536132571838202,
"duration": 77474,
"annotations": [
{
"timestamp": 1536132571838202,
"value": "cs",
"endpoint": {
"serviceName": "istio-ingressgateway",
"ipv4": "172.16.0.28"
}
},
{
"timestamp": 1536132571839226,
"value": "sr",
"endpoint": {
"serviceName": "productpage",
"ipv4": "172.16.0.33"
}
},
{
"timestamp": 1536132571914652,
"value": "ss",
"endpoint": {
"serviceName": "productpage",
"ipv4": "172.16.0.33"
}
},
{
"timestamp": 1536132571915676,
"value": "cr",
"endpoint": {
"serviceName": "istio-ingressgateway",
"ipv4": "172.16.0.28"
}
}
],
gateway上报了个cs，cr, productpage的那个proxy上报了个ss，sr。
分别表示gateway作为client什么时候发出请求，什么时候最终受到请求，productpage的proxy什么时候收到了客户端的请求，什么时候发出了response。
Reviews的span如下：
"traceId": "f79a31352fe7cae9",
"id": "cb4c86fb667f3114",
"name": "reviews-route",
"parentId": "f79a31352fe7cae9",
"timestamp": 1536132571847838,
"duration": 64849,
Details的span如下：
"traceId": "f79a31352fe7cae9",
"id": "951a4487642c0966",
"name": "details-route",
"parentId": "f79a31352fe7cae9",
"timestamp": 1536132571842677,
"duration": 2944,
可以看到productpage这个微服务和detail和reviews这两个服务的调用。
一个细节就是traceid就是第一个productpage span的id，所以第一个span也称为根span，而后面两个review和details的span的parentid是前一个productpage的span的id。
Ratings 服务的span信息如下：可以看到traceid保持一样，parentid就是reviews的spanid。
"traceId": "f79a31352fe7cae9",
"id": "5aac176b61ec8d84",
"name": "ratings-route",
"parentId": "cb4c86fb667f3114",
"timestamp": 1536132571889086,
"duration": 1449,
当然在Jaeger里上报会是这个样子：
根据一个实际的例子理解原理后会发现，应用程序要修改代码根本原因就是调用发起方，在Isito里其实就是Sidecar在处理outbound的时生成span的逻辑，而这个埋点的代码和业务代码不在一个进程里，没法使用进程内的一些类似ThreadLocal的方式（threadlocal在golang中也已经不支持了，推荐显式的通过Context传递），只能显式的在进程间传递这些信息。这也能理解为什么Istio的官方文档中告诉我们为了能把每个阶段的调用，即span，串成一个串，即完整的调用链，你需要修你的代码来传递点东西。
当然实例中只是对代码侵入最少的方式，就是只在协议头上机械的forward这几个trace相关的header，如果需要更多的控制，如在在span上加特定的tag，或者在应用代码中代码中根据需要构造一个span，可以使用opentracing的StartSpanFromContext 或者SetTag等方法。
调用链数据上报
Envoy上报
一个完整的埋点过程，除了inject、extract这种处理span信息，创建span外，还要将span report到一个调用链的服务端，进行存储并支持检索。在Isito中这些都是在Envoy这个sidecar中处理，业务程序不用关心。在proxy自动注入到业务pod时，会自动刷这个后端地址。如：
即envoy会连接zipkin的服务端上报调用链数据，这些业务容器完全不用关心。当然这个调用链收集的后端地址配置成jaeger也是ok的，因为Jaeger在接收数据是兼容zipkin格式的。
Mixers上报
除了直接从Envoy上报调用链到zipkin后端外，和其他的Metric等遥测数据一样通过Mixer这个统一面板来收集也是可行的。
即如tracespan中描述，创建一个tracespan的模板，来描述从mixer的一次访问中提取哪些数据，可以看到trace相关的几个ID从请求的header中提取，而访问的很多元数据有些从访问中提取，有些根据需要从pod中提取（背后去访问了kubeapiserver的pod资源）
apiVersion: "config.istio.io/v1alpha2"
kind: tracespan
metadata:
name: default
namespace: istio-system
spec:
traceId: request.headers["x-b3-traceid"]
spanId: request.headers["x-b3-spanid"] | ""
parentSpanId: request.headers["x-b3-parentspanid"] | ""
spanName: request.path | "/"
startTime: request.time
endTime: response.time
clientSpan: (context.reporter.local | true) == false
rewriteClientSpanId: false
spanTags:
http.method: request.method | ""
http.status_code: response.code | 200
http.url: request.path | ""
request.size: request.size | 0
response.size: response.size | 0
source.ip: source.ip | ip("0.0.0.0")
source.service: source.service | ""
source.user: source.user | ""
source.version: source.labels["version"] | ""
最后
在这个文章发出前，一直在和社区沟通，督促在更明晰的位置告诉大家用Istio的调用链需要修改些代码，而不是只在一个旮旯的位置一小段描述。得到回应是1.1中社区首页第一页what-is-istio/已经修改了这部分说明，不再是1.0中说without any changes in service code，而是改为with few or no code changes in service code。提示大家在使用Isito进行调用链埋点时，应用程序需要进行适当的修改。当然了解了其中原理，做起来也不会太麻烦。
参照
https://thenewstack.io/distributed-tracing-istio-and-your-applications/
https://github.com/istio/old_mixer_repo/issues/797
http://www.idouba.net/opentracing-serverside-tracing/
原文地址：http://blog.51cto.com/14051317/2345885