开发工具微服务云原生CLI【免费下载链接】tyeTye is a tool that makes developing, testing, and deploying microservices and distributed applications easier. Project Tye includes a local orchestrator to make developing microservices easier and the ability to deploy microservices to Kubernetes with minimal configuration.项目地址https://gitcode.com/gh_mirrors/ty/tye点击查看免费下载导读本文讲解如何在 TyeProject Tye管理的 .NET 微服务应用中接入 Zipkin 分布式追踪系统你不需要向任何服务添加 SDK 或埋点库只需在.NET程序入口处开启 W3C 追踪格式并在tye.yaml中声明一个zipkin扩展即可在本地开发环境与 Kubernetes 部署环境获得完整的端到端调用链视图。读完本文你将掌握本地观察链路、部署到集群、清理环境以及理解底层 EventPipe 采集原理的完整实战能力。为什么需要分布式追踪在微服务架构中一次用户请求往往要横跨多个服务。当故障出现时仅靠每个服务各自的日志很难回答三个关键问题一次端到端操作到底涉及了哪些服务这次操作对应的 trace ID 是什么如何用它去关联各服务的日志每个服务在这次操作中分别消耗了多少时间Timings分布式追踪正是为此而生的诊断工具它能在宏观上一眼看透一次跨服务操作在整条链路上的完整经过。Zipkin 是广泛使用的开源分布式追踪存储与查询系统恰好能回答上述三个问题。而 Tye 的价值在于不用在你的服务里加任何 SDK 或库就能把分布式追踪跑起来——这正是它区别于传统埋点方案的体验优势。原理预览为什么 Tye 能做到零埋点在动手之前先建立一个大致的心理模型。.NET Core 3.0 引入了一套全新的运行时诊断机制Diagnostics improvements in .NET Core 3.0其中包含一项名为EventPipe的运行时功能另一个进程可以附加到你的服务进程上无需应用内任何代码即可采集日志、指标与追踪数据.NET 运行时、HTTP 客户端HttpClient、Web 服务器ASP.NET Core Hosting等底层组件本身已被埋点因此应用代码无需修改即可获得诊断能力。Tye 正是利用了这一点本地运行时由Tye Host 进程附加到每个 .NET 服务的 EventPipe 上监听追踪事件并转发给 Zipkin部署到 Kubernetes 时则由注入的诊断 sidecar 容器tye-diag-agent完成同样的工作。后文底层原理深挖一节会给出源码级证据。第一步启用 W3C 追踪格式强制要求要在 Tye 中看到 trace你的 .NET 应用必须先开启 W3C 追踪格式。这是硬性前提——文档中明确强调This is mandatory, you wont get traces without doing this!不这样做就不会有 trace。原因在于 Zipkin 基于 trace ID / span ID 关联调用链而 Tye 的追踪采集器只处理 W3C 格式的 Activity ID。从源码可以印证在 TracingSink.cs 的TryCreateActivity方法中如果检测到 Activity 的IdFormat是Hierarchical旧式层级格式采集器会直接返回false丢弃该事件源码注释直言We need W3C to make it work。你需要在程序早期推荐放在Program.cs的Main入口最前面加入如下语句Activity.DefaultIdFormat ActivityIdFormat.W3C;一个典型 ASP.NET Core 应用的Program.cs完整形态如下using System.Diagnostics; using Microsoft.AspNetCore.Hosting; using Microsoft.Extensions.Hosting; namespace Frontend { public class Program { public static void Main(string[] args) { Activity.DefaultIdFormat ActivityIdFormat.W3C; CreateHostBuilder(args).Build().Run(); } public static IHostBuilder CreateHostBuilder(string[] args) Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder { webBuilder.UseStartupStartup(); }); } }仓库中的官方示例 samples/frontend-backend 已经预先初始化了 W3C 格式前端 frontend/Program.cs 与后端 backend/Program.cs 都在Main中执行了Activity.DefaultIdFormat ActivityIdFormat.W3C;。如果你想直接跑通整套演示这个示例项目是最省事的选择其frontend服务会通过HttpClient调用backend服务天然构成一条跨服务调用链详见 frontend/Startup.cs。第二步在 tye.yaml 中添加 zipkin 扩展下一步是编辑应用的tye.yaml加入extensions节点并声明zipkin扩展。以官方示例为基础配置如下name: frontend-backend extensions: - name: zipkin services: - name: backend project: backend/backend.csproj - name: frontend project: frontend/frontend.csproj这段配置在原有 samples/frontend-backend/tye.yaml仅含name与两个services的基础上追加了extensions节点。Tye 的扩展机制由 Extension.cs 定义内置扩展注册表位于 WellKnownExtensions.cs其中zipkin对应的实现是 ZipkinExtension.cs。当你声明该扩展后Tye 会做如下事情注入一个名为zipkin的容器服务使用openzipkin/zipkin镜像绑定端口9411容器端口同为 9411协议为 HTTP。从源码看这是通过ContainerServiceBuilder(zipkin, openzipkin/zipkin, ServiceSource.Extension)注入的见 ZipkinExtension.cs把zipkin声明为所有其他服务的依赖Dependency保证服务间启动顺序正确若你的tye.yaml中已经手动定义了名为zipkin的服务扩展会跳过注入源码中先检查Application.Services.Any(s s.Name zipkin)。本地运行一条完整的链路观察流程完成以上配置后启动应用tye runTye 仪表盘Dashboard上应当出现一个名为zipkin的服务正在运行。接下来访问frontend服务如果你用的是自己的代码就向你的服务发送一些流量这会向 Zipkin 实例写入数据点击仪表盘上zipkin服务的链接打开 Zipkin 界面。Tye 固定使用http://localhost:9411Zipkin 的惯用默认端口——本地开发时该地址由扩展硬编码注入见 ZipkinExtension.cs 中的DistributedTraceProvider zipkinhttp://localhost:9411刚打开时页面是空的因为 Zipkin 需要先查询点击右侧的放大镜图标Find Traces执行搜索搜索到结果后点击任意一条 trace即可看到时间花在哪、访问了哪些 URI、HTTP 状态码、各 span 的耗时分布等细节。这一体验背后的本地链路是tye run启动时Program.RunCommand.cs 把--dtrace参数或扩展注入的默认值写入HostOptions.DistributedTraceProvider随后 TyeHost.cs 解析出zipkin追踪 Provider 并装配TracingSink当各服务进程启动后EventPipeDiagnosticsRunner.cs 订阅副本Replica事件为每个进程启动一个采集线程通过 DiagnosticsCollector.cs 创建 EventPipe 会话并实时把追踪事件交给TracingSink转发到 Zipkin。提示除了在tye.yaml中声明扩展tye run还提供--dtrace命令行选项帮助信息为Write distributed traces to the specified tracing provider. Supported providers are zipkin见 Program.RunCommand.cs。从源码看若扩展已注入默认值--dtrace不会被覆盖扩展仅在DistributedTraceProvider is null时赋值而如果不声明扩展、仅使用--dtrace zipkinhttp://host:port则 Tye 不会自动帮你拉起 Zipkin 容器你需要自行运行一个 Zipkin 实例。Kubernetes 部署让生产环境也能追踪要在已部署deployed的应用中使用 Zipkin 做分布式追踪首先需要把 Zipkin 部署到集群中。部署最小化 Zipkin运行以下命令部署一个最小化的 Zipkin 配置清单文件就在仓库中kubectl apply -f docs/recipes/zipkin.yaml警告这是 Zipkin 最基础的部署方式没有任何数据持久化适合验证链路与演示生产环境请自行补充持久化方案。该清单zipkin.yaml包含两部分一个zipkinDeploymentopenzipkin/zipkin镜像、1 个副本、暴露容器端口 9411和一个zipkinServiceClusterIP类型、9411端口映射到同名targetPort。它会创建在当前 kubectl 的 Kubernetes context 中。验证它已启动 kubectl get deployment zipkin NAME READY UP-TO-DATE AVAILABLE AGE zipkin 1/1 1 1 5m部署应用并指定 Zipkin 地址接下来部署你的应用tye deploy -iTye 会交互式地提示输入 Zipkin URI。按照上面的基础部署填入http://zipkin:9411提示你的 Zipkin 实例可以托管在任何位置——只要你能给出一个对 Pod 可达的 URI 即可。示例中http://zipkin:9411利用的是 Kubernetes 集群内的服务发现Service 名zipkin。部署时Tye 会在你的 Pod 中注入一个诊断 sidecar 容器详见下一节底层原理深挖sidecar 通过--provider:zipkinservice:zipkin参数获得 Zipkin 地址其中service:zipkin前缀由 tye-diag-agent/Program.cs 解析为服务发现地址。测试调用链用 kubectl 把某个服务的端口转发到本地。以下以官方 samples/frontend-backend 示例为准 kubectl port-forward svc/frontend 5000:80这会让frontend服务在本地5000端口可访问。在浏览器中确认可以正常访问http://localhost:5000。发起几次请求后用CtrlC取消这个端口转发。接着把 Zipkin 转发到本地 kubectl port-forward svc/zipkin 9411:9411提示这里的端口与上一条不同因为 Zipkin 通常监听 9411 端口。现在访问http://localhost:9411打开 Zipkin 界面与本地体验一致——点击放大镜图标搜索后应该能看到刚才请求产生的 trace 记录。清理部署测试完毕按如下顺序清理tye undeploy kubectl delete -f docs/recipes/zipkin.yaml第一条命令卸载 Tye 部署的应用及其注入的 sidecar第二条命令删除集群中的 Zipkin Deployment 与 Service。底层原理深挖从 EventPipe 到 Zipkin Span本地模式Tye Host 作为采集端本地运行时Tye Host 进程负责为所有.NET 服务监听追踪事件并统一发送给 Zipkin。这一架构避免了为每个服务单独部署采集代理。具体流程tye run解析出zipkin追踪 Provider 后在 TyeHost.cs 装配TracingSink并注册EventPipeDiagnosticsRunner作为应用处理器每个服务进程启动时触发ReplicaEventEventPipeDiagnosticsRunner.cs 为其创建独立线程执行DiagnosticsCollector.CollectDiagnosticsCollector.cs 通过DiagnosticsClient查找目标进程SelectProcess默认超时 5 秒、调试器附加时 1 分钟然后StartEventPipeSession建立 EventPipe 会话把事件流交给TracingSink.Attach。事件过滤采集哪些追踪事件WellKnownEventSources.cs 中的DiagnosticFilterString定义了需要监听的关键事件分为两类Activity1Start/Activity1StopASP.NET Core 的入站 HTTP 请求Microsoft.AspNetCore.Hosting.HttpRequestIn携带Request.Scheme、Request.Host、Request.PathBase、Request.QueryString、Request.Path、Request.Method、Response.StatusCode以及ActivityStartTime、ActivityTraceId、ActivitySpanId、ActivityParentSpanId、ActivityIdFormat等追踪字段Activity2Start/Activity2StopHttpClient的出站 HTTP 请求HttpHandlerDiagnosticListener携带Request.RequestUri、Request.Method等字段。这两类事件正好覆盖一条调用链的两个半程服务端收到请求Server Span与服务端发出下游请求Client Span从而把跨服务的 trace 串成完整的树状结构。对应的 EventPipe Provider 配置DiagnosticSourceEventSourceTplEventSource等见同一文件中的CreateDefaultProviders。Span 构建与导出TracingSink.cs 是核心处理逻辑收到Activity1Start时构造服务端 SpanSpanKind.Server从事件参数中提取Path、Method、Host、Scheme、QueryString等拼装为 OpenTelemetry 语义的http.url、http.method、http.path属性见 TracingSink.cs收到Activity1Stop时补充http.status_code并计算EndTime StartTime Duration组装成SpanData提交给处理器见 TracingSink.cs收到Activity2Start/Stop时构造客户端 SpanSpanKind.Client记录出站请求 URI 与方法见 TracingSink.cs最终通过ZipkinTraceExporter把 Span 批量发送到{Zipkin地址}/api/v2/spansZipkin 的 v2 APIServiceName 取服务名见 TracingSink.cs。TryCreateActivity中还包含对IdFormat的校验拒绝Hierarchical这正是第一步必须开启 W3C 的原因见 TracingSink.cs。部署模式诊断 sidecartye-diag-agent部署到 Kubernetes 时流程略有不同。在tye deploy过程中ZipkinExtension.cs 会对每个 .NET 项目服务调用DiagnosticAgent.GetOrAddSidecar并追加--provider:zipkinservice:zipkin参数。GetOrAddSidecar的实现DiagnosticAgent.cs会设置RelocateDiagnosticsDomainSockets true调整 Pod 定义使 sidecar 能访问主服务的 EventPipe 域套接字为每个项目注入名为tye-diag-agent的 sidecar 容器镜像为rynowak/tye-diag-agent:0.1启动参数包含--kubernetestrue、--service服务名、--assemblyName程序集名。所以当你在集群中查看 Pod 时会看到每个服务 Pod 都有2 个容器 kubectl get pods NAME READY STATUS RESTARTS AGE backend-68974b7bfd-r59bn 2/2 Running 0 5m frontend-7c94f75f98-zdqzf 2/2 Running 0 5m zipkin-85bcf65bb4-pfxwz 1/1 Running 0 5m注意服务类 Pod 的2/2表示 2 个容器中有 2 个就绪——一个是你的服务另一个就是诊断 sidecar。sidecar 本身是一个 .NET Worker实现见 DiagnosticsMonitor.cs它按AssemblyName在容器内定位目标进程通过ps命令匹配命令行中的{AssemblyName}.dll见 DiagnosticsMonitor.cs再走与本地相同的DiagnosticsCollector → TracingSink管线把 span 发给 Zipkin。像 Kubernetes 中的普通容器一样你可以查看 sidecar 的日志其输出大致如下info: Microsoft.Tye.DiagnosticsMonitor[0] dtrace: Using Zipkin at URL http://zipkin:9411/ info: Microsoft.Tye.DiagnosticsMonitor[0] Starting data collection info: Microsoft.Hosting.Lifetime[0] Application started. Press CtrlC to shut down. info: Microsoft.Hosting.Lifetime[0] Hosting environment: Production info: Microsoft.Hosting.Lifetime[0] Content root path: /app info: Microsoft.Tye.DiagnosticsMonitor[0] Selected process 7. info: Microsoft.Tye.DiagnosticsMonitor[0] Listening for event pipe events for frontend-7c94f75f98-zdqzf on process id 7这段日志展示了完整流程sidecar 启动 → 解析出 Zipkin 地址dtrace: Using Zipkin at URL http://zipkin:9411/→ 开始采集 → 定位到目标进程Selected process 7→ 为该进程建立 EventPipe 监听。其中service:zipkin会被 tye-diag-agent/Program.cs 通过服务发现解析为实际的http://zipkin:9411地址。局限与注意事项基于文档与源码使用本方案时有几点需要留意W3C 是硬性前提未设置Activity.DefaultIdFormat ActivityIdFormat.W3C的应用不会产生 trace采集器直接丢弃Hierarchical格式的 Activity无数据持久化zipkin.yaml 提供的是最简部署Zipkin 数据不会持久化重启即丢生产环境需自行接入存储采集对象是进程本地模式下EventPipeDiagnosticsRunner当前只对 Tye 直接启动的进程生效源码注释This temporarily only works for processes launched见 EventPipeDiagnosticsRunner.csDocker 容器运行模式下的追踪支持有限Zipkin 地址需可达部署模式下只要给出对 Pod 可达的 URI 即可无论集群内外仅 .NET 技术栈方案依赖 .NET Core 3.0 的 EventPipe 与运行时内建埋点非 .NET 服务无法被 Tye 自动采集追踪。小结分布式追踪是微服务排障工具箱中的关键一环。借助 Tye 的zipkin扩展你在本地开发与 Kubernetes 生产部署两个场景都能以近乎零成本的方式获得完整调用链只需要一行 W3C 格式初始化代码、一段extensions配置Tye 就会通过 EventPipe 自动采集 ASP.NET Core 服务端与HttpClient客户端两侧的 Span并由 Tye Host本地或tye-diag-agentsidecar集群统一转发到 Zipkin。理解 ZipkinExtension.cs、TracingSink.cs 与 WellKnownEventSources.cs 这三处核心实现你就能在遇到问题时快速定位配置与采集链路上的任何环节。赞分享开发工具微服务云原生CLI【免费下载链接】tyeTye is a tool that makes developing, testing, and deploying microservices and distributed applications easier. Project Tye includes a local orchestrator to make developing microservices easier and the ability to deploy microservices to Kubernetes with minimal configuration.项目地址https://gitcode.com/gh_mirrors/ty/tye点击查看免费下载相关推荐终极指南如何快速实现Dubbo集成Zipkin全链路追踪终极指南如何快速实现Dubbo集成Zipkin全链路追踪 在分布式微服务架构中全链路追踪是排查问题、优化性能的关键工具。Dubbo作为一款高性能、轻量级的分后端RPC框架微服务服务注册发现Hyperf 分布式链路追踪Tracer实战基于 OpenTracing 集成 Zipkin 与 JaegerHyperf 分布式链路追踪Tracer实战基于 OpenTracing 集成 Zipkin 与 Jaeger 在微服务架构中单个业务请求往往要横跨三四后端Web框架微服务RPC框架异步编程Zipkin 分布式链路追踪的 Pulsar 测试镜像 zipkin-pulsar构建、配置与集成实战Zipkin 分布式链路追踪的 Pulsar 测试镜像 zipkin pulsar构建、配置与集成实战 本文围绕 docker/test images/zip可观测性后端微服务上一篇数据丢失的终极救星TestDisk与PhotoRec开源恢复工具深度解析下一篇Miles CLI命令速查表9大参数组的核心标志位一网打尽创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考