OpenTelemetry 插件如何实时绘制你的微服务架构图
译注：本文翻译自 JetBrains 官方博客，作者为 Nikita Dukin 与 Egor Klimov，原文发布于 2026 年 9 月 16 日。原文链接见文末。
接手一个新项目时，很多人第一件事就是找架构图。拿到手的图看起来很漂亮，但调试一周后你会发现，它已经过期半年了：服务 A 从春天起就不再调用服务 B，还多了一个没人记录的消息队列。
搞清楚一个复杂系统实际是如何拼装在一起的，是经典的工程难题。你可以手动梳理（前提是对自己有足够信心，且时间充裕），也可以用静态分析探索代码库（但往往无法反映服务在运行时的真实连接方式）。
还有第三条路：动态分析。如果我们直接观察系统运行，并根据实际发生的情况来绘制架构图，会怎样？
OpenTelemetry 插件已经在收集大量运行时数据——日志、指标和追踪。于是 JetBrains 意识到，可以借此自动生成架构图。本文深入介绍 Service Map 功能的实现内幕，它由 Rider 执行团队与软件工程研究团队合作完成。
关键要素：追踪
熟悉可观测性的人都知道“三大支柱”：日志、指标和追踪。
日志告诉你发生了什么，指标告诉你发生了多少，而追踪展示一个请求在系统中的完整旅程。追踪由称为 span 的独立工作单元组成。
由于 OpenTelemetry 对这些 span 做了标准化（例如明确定义了 HTTP Client 和 HTTP Server span），它们成了理解系统架构的终极捷径。依赖 OpenTelemetry 标准意味着，只要应用和库按照 OTel 预期的方式发出 span，插件就能完全独立于技术栈来可视化系统。
基于追踪构建架构图有一个巨大优势：它是运行时的事实来源。我们不是根据源代码或过时的规格去猜测，而是查看真实系统产生的数据。
工作原理
那么，这在 JetBrains IDE 内部是如何运作的？
启用 OpenTelemetry 插件启动 IDE 时，插件会启动一个轻量级的本地 OpenTelemetry 后端，用于处理应用的遥测数据。
当你在 IDE 中点击 Run 时：
- 插件向应用提供标准的 OTel 环境变量，使其知道数据应发送到本地后端。
- 应用（已配置为发出 span）开始向本地后端发送遥测数据。
- 后端异步处理这些传入的 span，持续构建并更新架构的内部模型。
- 当你点击 Service Map 标签页时，插件从后端获取最新的结构模型并渲染可视化图表。
遥测数据的混乱现实
架构图看起来静态而有序，但生成它的遥测数据流绝非如此。在编写算法连接这些点之前，团队必须解决几个隐藏的挑战：
传输中的混乱：span 完全独立地到达，顺序从不保证。父 span 可能在子 span 已被处理之后才到达。
没有终点线：追踪永远不会明确表示“我完成了”。在任何时刻，我们都不能 100% 确定不会再有迟到的 span 出现。
无类型负载：OpenTelemetry 不为每种 span 类型提供严格类型化的版本。每个 span 携带一个键值映射，其中的属性描述操作语义。团队必须纯粹通过检查属性来推断它们代表何种交互。
重建算法
为了处理这种异步、乱序的数据，团队将架构重建实现为流处理算法。与其等待一条完整的追踪（如前所述，这无法保证），不如在每个 span 到达时立即处理。
首先判断看到的是什么。提取 span 的基本元数据，然后检查其语义属性进行分类：http.request.method 和 http.response.status_code 等属性表明这是一次 HTTP 调用，其他属性则指向数据库查询、消息队列交互等。
接着判断是哪个服务发出的。没见过的服务？加入图中。已经存在？合并新数据并更新统计信息。
然后是最有趣的部分：跨服务边界连接各个点。一个完整插桩的 HTTP 调用有两端：调用方服务发出 CLIENT span，接收方服务发出 SERVER span。追踪上下文随请求传递，因此下游的 SERVER span 是作为上游 CLIENT span 的子节点创建的。
因此，当出现一个出站的 HTTP Client span 时，就去服务端寻找它的子节点；当出现一个入站的 HTTP Server span 时，就寻找调用它的父节点。如果配对 span 已在系统中，立即绘制（或更新）两个服务之间的连接；如果还没有，就把 span 暂存在内存中，等待另一半到达。
其他类型的依赖需要略微不同的规则。数据库调用通常由单个 CLIENT span 表示，因此直接从其语义属性推断数据库节点。消息传递则更加多样：生产者和消费者操作可能通过父子关系或 span link 连接，具体取决于消息系统和插桩方式。无论哪种情况，后端都会在 span 到达时进行处理，并随着更多证据的出现逐步丰富架构图。
最后这一步，正是插件即使在网络延迟、乱序的情况下，也能构建准确、实时架构图的原因。
该功能可以处理和展示 HTTP 请求、数据库请求以及消息队列的信息。由于架构图基于标准 OpenTelemetry span 构建，重建算法依赖语义约定而非特定框架的 API，因此该功能与语言和厂商无关。同一套逻辑适用于 JVM、.NET、Python、Go 以及其他 OpenTelemetry 插桩的应用，只要其插桩发出预期的 span 并正确传播上下文。这也意味着你可以在最适合自己技术栈的 JetBrains IDE 中使用该功能，包括 IntelliJ IDEA、GoLand、PyCharm、WebStorm 和 Rider。
查看你自己的架构
想实时看到自己的架构图吗？预期只有一次 HTTP 调用或数据库查询，图中却显示了好几次？在开发阶段发现这些问题，就能在发布前留出修复时间。
现在就可以安装 OpenTelemetry 插件，不再猜测服务之间如何通信。
原文链接
https://blog.jetbrains.com/platform/2026/09/how-to-service-map-with-opentelemetry/