架构决策记录 (ADR):全链路追踪方案选型对比评估

背景说明:

目前我们的核心业务主要部署在 AWS 的 9 个 VPC 内的 EC2 实例上,应用大多为 Java 架构。为实现跨 VPC、跨微服务的性能监控及排障,现对三种链路追踪方案进行技术验证与ROI(投资回报率)对比。


💡 执行摘要 (Executive Summary)

为快速了解全貌,以下是三种方案的核心差异对比表:

评估维度 方案 A:自建 Jaeger 方案 B:ADOT + X-Ray 方案 C:原生 X-Ray Daemon
标准协议 OpenTelemetry OpenTelemetry AWS X-Ray 专有协议
架构耦合度 锁定自建存储生态 零锁定 (随时可切回 Jaeger) 深度绑定 AWS 生态
后端运维成本 极高 (需维护 EKS 与 ES 存储) (全托管) (全托管)
AWS 资源拓扑图 较弱 极强 (自动识别 VPC、TGW) 极强
核心花销 跨 VPC 流量费 + 存储计算资源费 按需扫描/存储费 (前 10万条免费) 按需扫描/存储费

🛠️ 方案深度拆解

方案 A:自建 Jaeger 路线 (目前团队已在 EKS 搭建的方案)

此方案依托开源生态,将数据集中汇聚到 EKS 集群中的中间件进行处理。

  • 架构流向: EC2 Java 应用 (挂载 OTel Agent) \\rightarrow 跨 VPC 网络传输 \\rightarrow EKS Jaeger Collector \\rightarrow Elasticsearch (ES) 存储库。

  • ✨ 方案优势 (Pros):

    • 无额外 AWS 服务订阅费: 不需要向 AWS 支付 X-Ray 的按量计费账单。

    • 复用现有资产: 团队同事已完成 EKS 端 Jaeger 环境的初步搭建,有一定技术沉淀。

  • ⚠️ 避坑与风险 (Cons & Risks):

    • 运维黑洞: 随着 9 个 VPC 的流量接入,Elasticsearch 的索引管理、磁盘扩容和内存调优将成为沉重的运维负担。

    • 网络成本隐患: 大规模跨 VPC (Cross-AZ/VPC) 传输遥测数据,会产生意想不到的 AWS 数据传输费用。

    • 高可用风险: 如果 EKS 集群或 ES 数据库因压力过大宕机,整个链路追踪系统将丢失监控数据。


方案 B:AWS 的 ADOT 路线 (AWS 推荐的现代化标准实践)

此方案兼顾了开源标准 (OpenTelemetry) 与云端全托管免运维的优势,是目前最具"杠杆效应"的选择。

  • 架构流向: EC2 Java 应用 (挂载 OTel Agent) \\rightarrow 本地 EC2 ADOT Collector 独立进程 \\rightarrow 批量且安全地发往 AWS X-Ray 后端。

  • ✨ 方案优势 (Pros):

    • 终极的"进可攻退可守": 完全基于 OpenTelemetry 行业标准。业务代码零侵入,哪天不想用 X-Ray 了,只需修改 ADOT 配置文件,流量就能立刻导回方案 A 的 Jaeger,不被 AWS 锁定

    • 后端零运维: 彻底告别维护 Elasticsearch 的噩梦。AWS X-Ray 后端提供无限扩展的存储和毫秒级检索。

    • 原生云拓扑: 能自动结合 AWS 元数据,精准画出流量跨越 TGW (Transit Gateway) 和不同 VPC 时的节点与延迟耗时。

  • ⚠️ 避坑与风险 (Cons & Risks):

    • Agent 部署管理: 需要在所有的 EC2 实例上统一部署 ADOT Collector 进程(建议使用 AWS Systems Manager 自动化完成)。

    • 需要管控采样率: 必须在控制台严格配置采样率 (Sampling Rate,建议 5%),否则全量收集会产生较高的 X-Ray 账单。


方案 C:原生 X-Ray Daemon 路线 (受限的传统方案)

此方案是 AWS 早期的原生链路追踪做法。

  • 架构流向: 代码集成 AWS X-Ray SDK \\rightarrow EC2 上的 X-Ray Daemon \\rightarrow AWS X-Ray 后端。

  • 🎯 只适用于以下特定场景:

    1. 极度纯粹的 Serverless 架构: 如果你的代码跑在 Lambda 上,控制台一键开启即可,这方案是首选。

    2. 遗留的"历史包袱"系统: 团队早在几年前就已经在代码里硬编码 (Hardcode) 接入了 AWS X-Ray 专有 SDK,无力进行重构。

  • ✨ 方案优势 (Pros):

    • 在纯 AWS 环境下,对 AWS 托管服务 (如 DynamoDB, SNS, SQS) 的 API 调用识别极其精准,几乎零配置。
  • ⚠️ 避坑与风险 (Cons & Risks):

    • 代码侵入性高: 必须使用 AWS 私有的 SDK 埋点。

    • 严重厂商锁定 (Vendor Lock-in): 追踪数据格式不兼容开源标准。如果以后想把数据发给 Jaeger 或 Datadog,需要重写所有代码的埋点逻辑。不推荐现代化的新微服务架构采用此方案。

相关推荐
张忠琳13 分钟前
【kubernetes v1.21】(kubelet 1)Kubelet 核心架构与启动流程
云原生·架构·kubernetes·kubelet
用户9874092388727 分钟前
超算中心 高性能计算 htc命令module use的作用
架构
AI科技星1 小时前
基于**v=c(空间光速螺旋运动)唯一第一性原理**重新完整求导证明
人工智能·线性代数·算法·机器学习·架构·概率论·学习方法
__log1 小时前
如何优雅地“借鉴”任何网站的设计系统
人工智能·架构·知识图谱
她的男孩2 小时前
从自然语言到数据大屏:Forge Report Studio 的 AI 生成链路
人工智能·后端·架构
她的男孩2 小时前
大屏动态数据接入:从静态 Mock 到真实业务 API
后端·架构
吴佳浩2 小时前
Vibe Coding 时代,研发经理为何越来越值钱?
算法·架构
canonical_entropy3 小时前
为什么 Attractor Guided Engineering 不能被降级为 AI Agent Skill
架构·agent·ai编程
Upsy-Daisy3 小时前
IOTA 学习笔记(四):当前 IOTA 架构总览
笔记·学习·架构
TangKengzai_王者归来4 小时前
行情 WebSocket 从握手到断线重连:symbol 格式不一致才是真正让你对不齐数据的元凶
架构