Istio 调用链埋点原理剖析—是否真的“零修改”？.docxVIP

Istio 调用链埋点原理剖析—能否真的“零修改”？ 在 Istio 的实践中最近经常被问到一个问题，使用 Istio 做调用链用户的业务代码是不是完全 0 侵入，到底要不要修改业务代码？ 看官方引见： 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. 是不用修改任何代码即可做各种管理。实际使用中应用程序不做任何修改，使用 Istio 的调用链输出总是断开的，这到底是什么缘由呢？ 对以上问题关注的人比较多，但是貌似说的都不是特殊清楚，在最近的 K8S 技术社区的 Meetup 上笔者特地做了主题共享，通过解析 Istio 的架构机制与 Istio 中调用链的工作原理来回答以上问题。在本文中将节选里面的重点内容，基于 Istio 官方典型的示例来开放其中的每个细节和原理。 Istio 本身的内容在这里不多引见，作为 Google 继 Kubernetes 之后的又一重要项目，Istio 供应了 Service Mesh 方式服务管理的完整的处理方案。正如其首页引见，通过非侵入的方式供应了服务的连接、把握、爱护和观测力量。包括智能把握服务间的流量和 API 调用；供应授权、认证和通信加密机制自动爱护服务平安；通过开放策略来把握调用者对服务的访问；另外供应了可扩展丰富的调用链、监控、日志等手段来对服务与功能进行观测。即用户不用修改代码，就可以实现各种服务管理力量。 较之其他系统和平台，Istio 比较明显的一个特点是服务运转的监控数据都可以动态猎取和输出，供应了强大的调用链、监控和调用日志收集输出的力量。协作可视化工具，运维人员可以便利的看到系统的运转情况，并发觉问题进而处理问题。而我们基本上不用在本人的代码里做任何修改来生成数据并对接各种监控、日志、调用链等后端。格外奇特的是只需我们的程序被部署 run 起来，其运转数据就自动收集并在一个面板上呈现出来。 调用链概述 对于分布式系统的运维管理和毛病定位来说，调用链当然是第一利器。 正如 Service Mesh 的诞生是为了处理大规模分布式服务访问的管理问题，调用链的消灭也是为了对应于大规模的简单的分布式系统运转中遇到的毛病定位定界问题。大量的服务调用、跨进程、跨服务器，可能还会跨多个物理机房。无论是服务本身问题还是网络环境的问题导致调用上链路上消灭问题都比较简单，如何定位就比单进程的一个服务打印一个特别栈来找出某个方法要困难的多。需要有一个类似的调用链路的跟踪，经一次恳求的规律法规完整的表达出来，可以观看到每个阶段的调用关系，并能看到每个阶段的耗时和调用具体情况。 Dapper, a Large-Scale Distributed Systems Tracing Infrastructure?描述了其中的原理和一般性的机制。模型中包含的术语也很多，理解最次要的两个即可： Trace：一次完整的分布式调用跟踪链路。 Span：跨服务的一次调用； 多个 Span 组合成一次 Trace 追踪记录。 上图是 Dapper 论文中的经典图示，左表示一个分布式调用关系。前端（A），两个两头层（B 和 C），以及两个后端（D 和 E）。用户发起一个恳求时，先到达前端，再发送两个服务 B 和 C。B 直接应答，C 服务调用后端 D 和 E 交互之后给 A 应答，A 进而前往最终应答。要使用调用链跟踪，就是给每次调用添加 TraceId、SpanId 这样的跟踪标识和时间戳。 右表示对应 Span 的管理关系。每个节点是一个 Span，表示一个调用。至少包含 Span 的名、父 SpanId 和 SpanId。节点间的连线下表示 Span 和父 Span 的关系。全部的 Span 属于一个跟踪，共用一个 TraceId。从图上可以看到对前端 A 的调用 Span 的两个子 Span 分别是对 B 和 C 调用的 Span，D 和 E 两个后端服务调用的 Span 则都是 C 的子 Span。 调用链系统有很多实现，用的比较多的如zipkin，还有已经加入 CNCF 基金会并且的用的越来越多的Jaeger，满足 Opentracing 语义标准的就有这么多。 一个完整的调用链跟踪系统，包括调用链埋点，调用链数据收集，调用链数据存储和处理，调用链数据检索（除了供应检索的 APIServer，一般还要包含一个格外酷炫的调用链前端）等若干重要组件。如图是 Jaeger 的一个完整实现。 这里我们仅关注与应用