教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载在将单体应用拆分为微服务之后服务可能分布在上千台服务器、不同的数据中心和可用区中服务之间的调用关系错综复杂。本文以 kubernetes-handbook 仓库中 分布式追踪 一文为主线系统讲解分布式追踪Distributed Tracing的核心概念、OpenTracing 标准与基本术语、业界主流实现Jaeger、Zipkin、SkyWalking并结合作者仓库中的 Istio 教程与 OpenTracing 文档给出从本地启动 Jaeger、在 Spring Boot 中接入 OpenTracing 客户端、到 Kubernetes 集群中查看调用链的完整实战方案。读完本文你将能够理解 Trace/Span 等追踪模型掌握分布式追踪系统的三类硬性要求并能在自己的微服务与 Kubernetes 环境中独立部署和接入一套可用的追踪系统。为什么微服务架构需要分布式追踪当单体应用被拆分成多个微服务后一次用户请求往往需要穿越多个服务、多台主机甚至多个数据中心。此时传统单机日志与监控手段会失效因为难以定位故障环节请求在哪一个服务环节失败、哪一次调用耗时最长无法从单点日志中判断难以评估优化点服务之间的依赖关系不透明哪些调用链存在瓶颈、哪些服务可以拆分或合并缺乏数据支撑跨进程上下文丢失单个服务内部的指标无法还原一次完整请求的端到端行为。分布式追踪Distributed Tracing正是为解决上述问题而生。它通过为每次请求生成全局唯一的 Trace ID并在请求流经的每个服务节点上记录 Span从而还原出一次请求从入口到出口的完整调用链、每段调用的耗时与依赖关系。在 kubernetes-handbook 的 可观察性 一文中将可观察性定义为使用指标、日志和追踪这些外部输出来理解系统的能力并明确指出追踪让你能够看到一个请求从开始到结束的过程它是对事件行为的实时捕捉可以帮助确定故障发生的位置或确定引起当前示例性能问题的原因。在微服务环境中会产生大量事件事件被定义为从请求到达网络外围的那一刻起发生的一切。分布式追踪正是还原这些事件的时空脉络的关键技术。分布式追踪标准与主流实现OpenTracing厂商中立的追踪 API 标准CNCF 提出了分布式追踪的标准OpenTracing它提供厂商中立的 API并提供了Go、Java、JavaScript、Python、Ruby、PHP、Objective-C、C 和 C#这九种语言的库。这意味着应用代码只需面向 OpenTracing API 编程底层 Tracer 可以随时在 Zipkin、SkyWalking、Jaeger 等实现之间切换从而避免被单一厂商绑定。从仓库中的 OpenTracing 文档可知目前支持 OpenTracing 的 Tracer 包括Zipkin、SkyWalking、Jaeger等支持的框架包括gRPC、MOTAN、django、Flask、Sharding-JDBC等。在开发应用时需要使用兼容 OpenTracing API 的 Tracing 实现库例如 Jaeger来实现自动的分布式追踪。主流追踪系统Jaeger、Zipkin 与 SkyWalking大部分分布式追踪系统都是根据 Google 的Dapper 论文《Dapper大规模分布式系统的跟踪系统》实现的。Dapper 论文提出了以 Trace 和 Span 为核心的数据模型、低消耗的埋点采样策略以及对应用透明的追踪设计理念成为后续所有主流追踪系统的理论基础。业界常见的分布式追踪系统包括JaegerCNCF 旗下的端到端分布式追踪项目完整支持 OpenTracing API提供查询 UI、依赖分析图与多后端存储如 Elasticsearch、Cassandra能力ZipkinTwitter 开源、由 Apache 基金会维护的分布式追踪系统是 Istio 早期版本默认集成的追踪后端Apache SkyWalkingApache 基金会旗下的中国开源应用性能监控工具不仅支持分布式追踪还集成了应用性能管理APM与服务性能管理SPM能力。在 kubernetes-handbook 的 Istio 教程 中作者采用了使用 Zipkin 做分布式追踪而不是 Jaeger的方案同时也在教程的本地运行环节演示了 Jaeger 的部署说明这两个系统在实践中可以按需选用。OpenTracing 核心术语Trace、Span 与 SpanContext要在实践中用好追踪系统必须先理解 OpenTracing 定义的基本数据模型。以下是仓库 OpenTracing 文档中的核心术语。Trace一次完整的调用链Trace通常指一次完整的调用链。例如在 Istio 官方提供的 Bookinfo 示例中对productpage服务的一次访问会在追踪系统中形成一条贯穿productpage → details等服务的完整调用链这就是一个 Trace。SpanTrace 中的一段调用每个 Trace 都由一系列Span组成。一个 Span 可以理解为两个微服务之间的一次调用如同 Chrome 开发者工具中查看网络访问瀑布图一样每个请求占据一段横条按时间顺序展开。根据 OpenTracing 的规格约定每个 Span 都要包含以下状态状态字段说明必填性示例操作名称可以是访问的一个 URL必填localhost:8808/起/止时间戳也可以使用起始时间和持续时间表示必填1540273832696773Tags一组键值对集合OpenTracing 的 Semantic Conventions 有一些常用约定必填http.protocolLogs一组键值对集合用于记录调用日志可选填—SpanContext在进程间通信时携带的 span 信息指整个 trace——其中SpanContext是整个追踪传播机制的关键它随请求在进程间传递通常通过 HTTP Header 或消息队列消息头下游服务据此将自己产生的 Span 挂接到同一个 Trace 上从而形成完整的调用链。真实追踪数据示例下面是仓库文档中记录的、由 Jaeger 收集的来自 Bookinfo 示例中productpage的调用链追踪数据{ data: [ { traceID: aaccbe962478cf93, spans: [ { traceID: aaccbe962478cf93, spanID: fa36a9cbd60b4ae5, operationName: details.default.svc.cluster.local:9080/*, references: [ { refType: CHILD_OF, traceID: aaccbe962478cf93, spanID: 2 } ], startTime: 1540273832696773, duration: 8171, tags: [ { key: component, type: string, value: proxy }, { key: node_id, type: string, value: sidecar~172.33.5.11~productpage-v1-8584c875d8-4jgwg.default~default.svc.cluster.local } ], logs: [], processID: p1, warnings: null } ], processes: { p1: { serviceName: productpage, tags: [ { key: ip, type: string, value: 172.33.5.11 } ] } }, warnings: null } ], total: 0, limit: 0, offset: 0, errors: null }这份真实数据揭示了几点实现事实每条 Trace 有全局唯一的traceID每个 Span 有本 Trace 内唯一的spanIDSpan 通过references中的refType: CHILD_OF声明父子关系即 Spanfa36a9cbd60b4ae5是 Span2的子调用operationName直接反映了被调用的服务与接口details.default.svc.cluster.local:9080/*说明该调用链来自 Istio/Envoy 注入的 sidecar 代理component: proxystartTime单位为微秒duration为该 Span 的耗时8171 微秒可用于定位耗时瓶颈processes记录了每个 Span 归属的服务进程serviceName: productpage及其 IP 地址。分布式追踪系统的设计要求在对分布式追踪系统选型或自研评估时kubernetes-handbook 的 分布式追踪 文档给出了三类硬性要求。1. 对应用程序的消耗足够低消耗低包含两层含义占用的系统资源要足够低埋点、采样、上报过程不应显著增加服务的 CPU 与内存开销造成的延迟要足够低追踪数据的产生与传播不能拖慢业务请求本身的响应时间。这也是 Dapper 论文中强调的设计原则——埋点代码运行在请求的关键路径上任何额外开销都会被放大因此必须保证极低的性能损耗。2. 对应用程序透明为了做到 7x24 小时无所不在的部署在向应用程序中集成分布式追踪系统时要让程序员对程序的改动尽可能的小这样才便于大范围、低成本地接入。对透明性的追求催生了两类实现路径通过服务网格实现零侵入追踪在 Kubernetes 中由 Istio/Envoy sidecar 代理自动完成 Span 的创建、传播与上报应用代码完全无感知上文 JSON 数据中component: proxy即为 sidecar 产生的 Span通过 SDK 自动埋点实现低侵入接入应用只需引入 OpenTracing 兼容的客户端库并配置 Tracer即可自动捕获 HTTP/RPC 调用的追踪信息下文 Istio 教程即采用此方式。3. 可扩展为了将所有服务接入分布式追踪系统该系统必须能够承载大规模服务。这要求追踪后端具备横向扩展能力包括支持分布式采集与多后端存储如 Elasticsearch、Cassandra能够应对高并发的 Span 写入查询与可视化组件与存储解耦可按需扩容。其他要求除了以上三点分布式追踪系统还应对产生的追踪数据处理得尽可能快并且可以方便地对追踪结果进行查询和可视化。这体现在 Jaeger 的 Query UI、Zipkin 的依赖关系图、SkyWalking 的拓扑图等可视化能力上。实战一本地启动 Jaeger 并接入 Spring Boot 微服务kubernetes-handbook 的 Istio 教程 提供了一个完整的分布式追踪实战案例三个服务customer → preference → recommendation组成的 Java 微服务调用链其中customer和preference基于 Spring Boot 构建recommendation基于 vert.x 构建。引入 OpenTracing 与 Jaeger 依赖customer和preference微服务的pom.xml中都引入了 OpenTracing 和 Jaeger 的依赖dependency groupIdio.opentracing.contrib/groupId artifactIdopentracing-spring-cloud-starter/artifactId version0.1.7/version /dependency dependency groupIdcom.uber.jaeger/groupId artifactIdjaeger-tracerresolver/artifactId version0.25.0/version /dependency其中opentracing-spring-cloud-starter提供 Spring Cloud 环境下基于 OpenTracing API 的自动埋点能力jaeger-tracerresolver则负责将 Jaeger 实现注册为 OpenTracing 的全局 Tracer。二者配合即可做到对应用程序透明业务代码无需改动框架自动捕获服务间 HTTP 调用并生成 Span。用 Docker 启动 Jaeger all-in-one在本地使用 Docker 运行 Jaeger 的单机一体化镜像docker run -d \ --rm \ -p5775:5775/udp \ -p6831:6831/udp \ -p6832:6832/udp \ -p16686:16686 \ -p14268:14268 \ jaegertracing/all-in-one:1.3端口说明5775/udp兼容 Zipkin thrift 协议的 UDP 接收端口6831/udp、6832/udpJaeger 原生 thrift compact/binary 协议的 UDP 接收端口16686Jaeger Query UI 的 HTTP 访问端口14268jaeger-collector 的 HTTP 接收端口。启动后访问 http://localhost:16686 即可看到 Jaeger query UI。启动微服务并查看调用链在本地依次启动三个服务并为 Jaeger 指定服务名cd customer/java/springboot JAEGER_SERVICE_NAMEcustomer mvn \ spring-boot:run \ -Drun.arguments--spring.config.locationsrc/main/resources/application-local.propertiescd preference/java/springboot JAEGER_SERVICE_NAMEpreference mvn \ spring-boot:run \ -Drun.arguments--spring.config.locationsrc/main/resources/application-local.propertiescd recommendation/java/vertx mvn vertx:run三个服务分别监听 8280、8180、8080 端口。访问 http://localhost:8280 后将看到输出customer preference recommendation v1 from unknown: 1此时访问 http://localhost:16686即可在 Jaeger UI 中搜索customer和preference服务的 Trace查看每次请求的完整追踪信息。实战二将追踪系统部署到 Kubernetes在 Istio 服务网格中集成 Zipkin在 Istio 教程 的集群部署环节作者使用 Zipkin 作为分布式追踪后端。仓库中的 manifests/istio/zipkin.yaml 提供了 Zipkin 在 Kubernetes 中的 Deployment 与 Service 定义--- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: zipkin spec: replicas: 1 template: metadata: annotations: alpha.istio.io/sidecar: ignore labels: app: zipkin spec: containers: - name: zipkin image: harbor-001.jimmysong.io/library/zipkin:latest ports: - containerPort: 9411 env: - name: POD_NAMESPACE valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.namespace --- apiVersion: v1 kind: Service metadata: name: zipkin spec: #type: NodePort ports: - name: http port: 9411 #nodePort: 30411 selector: app: zipkin这个配置文件的实现细节值得注意Deployment 的 Pod 注解alpha.istio.io/sidecar: ignore表明追踪系统自身不注入 sidecar避免追踪后端成为被追踪对象Zipkin 的 HTTP 端口为9411这也是 Istio/Envoy 默认上报追踪数据的端口Service 暴露9411端口通过 selectorapp: zipkin关联 Pod配置中预留了 NodePort 与 nodePort 的注释项说明可以按需改为type: NodePort以便在集群外部访问。部署应用并查看分布式追踪与依赖关系将三个微服务部署到 Kubernetes使用istioctl kube-inject注入 sidecarkubectl create ns istio-tutorial kubectl apply -f (istioctl kube-inject -f recommendation/kubernetes/Deployment.yml) -n istio-tutorial kubectl apply -f recommendation/kubernetes/Service.yml kubectl apply -f (istioctl kube-inject -f preference/kubernetes/Deployment.yml) -n istio-tutorial kubectl apply -f preference/kubernetes/Service.yml kubectl apply -f (istioctl kube-inject -f customer/kubernetes/Deployment.yml) -n istio-tutorial kubectl apply -f customer/kubernetes/Service.yml批量访问 customer 服务产生流量后即可在追踪系统中查看调用链。下面两张图分别展示了服务间调用的分布式追踪视图与服务依赖关系图——这正是追踪系统快速处理、方便查询与可视化要求的直接体现。从追踪数据反推流量分布该教程还演示了如何利用追踪之外的信息辅助验证流量控制为recommendation构建 v2 版本并扩容到 2 个实例后持续访问 customer 服务观察输出中 v1/v2 版本被访问的频次变化。结合追踪系统开发者可以进一步确认每次请求实际命中哪个版本的服务、经过哪些节点实现从调用链可观测到流量行为可验证的闭环。小结分布式追踪是微服务与 Kubernetes 环境下不可或缺的可观测性支柱。以 kubernetes-handbook 中的相关文档为骨架可以梳理出完整的技术脉络为什么需要微服务拆分后跨主机、跨数据中心的调用链无法用单机日志还原需要分布式追踪定位故障环节与优化点标准与模型CNCF 的 OpenTracing 标准提供九种语言的厂商中立 API以 Trace、Span、SpanContext、Tags、Logs 为核心数据模型大部分实现源于 Google Dapper 论文主流实现JaegerCNCF 项目完整支持 OpenTracing、ZipkinIstio 早期默认后端、Apache SkyWalking集成 APM/SPM 能力设计要求消耗足够低资源 延迟、对应用透明低侵入接入、可扩展支撑大规模服务并需支持快速处理、查询与可视化落地路径本地可用jaegertracing/all-in-one镜像快速启动 Jaeger通过opentracing-spring-cloud-starter与jaeger-tracerresolver实现 Spring Boot 低侵入接入在 Kubernetes 中可部署 Zipkin参考 manifests/istio/zipkin.yaml由 Istio sidecar 自动上报 Span零侵入实现调用链还原与服务依赖可视化。读者可继续深入仓库阅读 OpenTracing术语与数据模型详解、可观察性指标、日志、追踪三支柱定位以及 Istio 教程完整 Java 微服务追踪实战获取更多细节。赞分享教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载相关推荐分布式追踪标准 OpenTracing 与 Jaeger 实践从 Trace/Span 语义到 Kubernetes 微服务调用链分析分布式追踪标准 OpenTracing 与 Jaeger 实践从 Trace/Span 语义到 Kubernetes 微服务调用链分析 OpenTracing教程云原生容器编排如何使用SwiftGodot快速构建跨平台游戏iOS、Linux、macOS全指南如何使用SwiftGodot快速构建跨平台游戏iOS、Linux、macOS全指南 SwiftGodot是一套为Swift开发者设计的全新Godot绑定库让Bitnami Containers追踪系统JaegerZipkin分布式追踪Bitnami Containers追踪系统JaegerZipkin分布式追踪 还在为微服务架构中的性能问题头疼吗分布式系统调用链复杂问题定位困难一文云原生供应链安全应用安全创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考