{"id":22885021,"url":"https://github.com/mark8s/opentracing-tutorial","last_synced_at":"2025-03-31T17:55:39.818Z","repository":{"id":189125572,"uuid":"679579166","full_name":"mark8s/opentracing-tutorial","owner":"mark8s","description":null,"archived":false,"fork":false,"pushed_at":"2023-08-22T09:45:42.000Z","size":497,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-02-06T22:42:24.632Z","etag":null,"topics":["istio","jaeger","opentracing"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/mark8s.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-08-17T06:47:28.000Z","updated_at":"2023-08-23T06:12:22.000Z","dependencies_parsed_at":"2024-12-13T19:31:09.546Z","dependency_job_id":"c6c39b10-6a09-41a7-b815-dda48f2005b7","html_url":"https://github.com/mark8s/opentracing-tutorial","commit_stats":null,"previous_names":["mark8s/opentracing-tutorial"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mark8s%2Fopentracing-tutorial","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mark8s%2Fopentracing-tutorial/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mark8s%2Fopentracing-tutorial/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mark8s%2Fopentracing-tutorial/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/mark8s","download_url":"https://codeload.github.com/mark8s/opentracing-tutorial/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246514287,"owners_count":20790016,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["istio","jaeger","opentracing"],"created_at":"2024-12-13T19:30:44.128Z","updated_at":"2025-03-31T17:55:39.786Z","avatar_url":"https://github.com/mark8s.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# 分布式链路追踪\n\n## 背景\n\n随着互联网产品的快速发展，不断变化的商业环境和用户诉求带来了纷繁复杂的业务需求。业务系统需要支撑的业务场景越来越广、涵盖的业务逻辑越来越多，系统的复杂度也跟着快速提升。\n与此同时，由于微服务架构的演进，业务逻辑的实现往往需要依赖多个服务间的共同协作。总而言之，业务系统的日益复杂已经成为一种常态。\n\n业务系统往往面临着多样的日常客诉和突发问题，“业务追踪”就成为了关键的应对手段。业务追踪可以看做一次业务执行的现场还原过程，通过执行中的各种记录还原出原始现场，\n可用于业务逻辑执行情况的分析和问题的定位，是整个系统建设中重要的一环。\n\n## 基础概念\n\n1. 分布式链路跟踪中的traceid和spanid代表什么？\n\n在分布式链路跟踪中有两个重要的概念：跟踪（trace）和 跨度（ span）。从客户端发起请求抵达系统的边界开始，记录请求流经的每一个服务，直到向客户端返回响应为止，这整个过程就叫做一次Trace。\n由于每次 Trace 都可能会调用数量不定、坐标不定的多个服务，那么为了能够记录具体调用了哪些服务，以及调用的顺序、开始时点、执行时长等信息，每次开始调用服务前，系统都要先埋入一个调用记录，这个记录就叫做一个Span。\n\n- 在整个请求的调用链中，请求会一直携带 traceid（由客户端或网关生成） 往下游服务传递，每个服务内部也会生成自己的 spanid 用于生成自己的内部调用视图，并和traceid一起传递给下游服务。\n  traceid 在请求的整个调用链中始终保持不变，所以在日志中可以通过 traceid 查询到整个请求期间系统记录下来的所有日志。\n\n- 请求到达每个服务后，服务都会为请求生成spanid，而随请求一起从上游传过来的上游服务的 spanid 会被记录成parent-spanid或者叫 pspanid。当前服务生成的 spanid 随着请求一起再传到下游服务时，这个spanid 又会被下游服务当做 pspanid 记录。\n\n在 A-\u003eB-\u003eC-\u003eD 的情况下，在整个调用链中，正常情况下会产生 3 个 Span，分别是 Span1（A-\u003eB）、Span2（B-\u003eC）、Span3（C-\u003eD），这时 Span3 的父 Span 就是 Span2，而 Span2 的父 Span 就是 Span1。\n\n2. 分布式追踪的特征\n\n从目标来看，链路追踪的目的是为排查故障和分析性能提供数据支持，系统在对外提供服务的过程中，持续地接受请求并处理响应，同时持续地生成 Trace，按次序整理好 Trace 中每一个 Span 所记录的调用关系，就能绘制出一幅系统的服务调用拓扑图了。这样，根据拓扑图中 Span 记录的时间信息和响应结果（正常或异常返回），我们就可以定位到缓慢或者出错的服务；然后，将 Trace 与历史记录进行对比统计，就可以从系统整体层面分析服务性能，定位性能优化的目标。\n\n- 功能上的挑战。功能上的挑战来源于服务的异构性，各个服务可能会采用不同的程序语言，服务间的交互也可能会采用不同的网络协议，每兼容一种场景，都会增加功能实现方面的工作量。\n- 非功能性的挑战。\n    - 1.低性能损耗：分布式追踪不能对服务本身产生明显的性能负担。\n    - 2.对应用透明：追踪系统通常是运维期才事后加入的系统，所以应该尽量以非侵入或者少侵入的方式来实现追踪，对开发人员做到透明化。\n    - 3.随应用扩缩：现代的分布式服务集群都有根据流量压力自动扩缩的能力，这就要求当业务系统扩缩时，追踪系统也能自动跟随，不需要运维人员人工参与。\n    - 4.持续的监控：即要求追踪系统必须能够 7x24 小时工作，否则就难以定位到系统偶尔抖动的行为。\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmark8s%2Fopentracing-tutorial","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmark8s%2Fopentracing-tutorial","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmark8s%2Fopentracing-tutorial/lists"}