架构决策记录 (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,需要重写所有代码的埋点逻辑。不推荐现代化的新微服务架构采用此方案。

相关推荐
梦梦代码精3 分钟前
电商系统的核心难点:订单与营销系统如何设计?——LikeShop 架构深度拆解(规则计算与状态一致性)
java·开发语言·低代码·架构·开源·github
SZLSDH4 分钟前
专项治理场景下,数字孪生IOC的架构适配逻辑:以智慧河湖监管为例
java·大数据·架构·数据可视化
beeboobeeboo9 分钟前
重塑计算基点:AI 操作系统的架构革命与应用、安全、开发范式重构
人工智能·安全·架构
敲敲千反田11 分钟前
微服务基础
java·微服务·架构
笨蛋不要掉眼泪10 小时前
Mysql架构揭秘:update语句的执行流程
数据库·mysql·架构
东方小月10 小时前
5分钟搞懂Harness Engineering(驾驭工程):从提示词到AI Agent的进化之路
前端·后端·架构
飞Link14 小时前
深度变革:Cloudflare 裁员背后的信号——“智能体优先”将重塑企业组织架构
架构
飞Link14 小时前
智能体时代的“紧箍咒”:深度解析 Agent 治理架构与 AI 杀伤开关
人工智能·架构
WangLanguager14 小时前
Unix架构详细介绍
arm开发·架构·unix
zhengzizhe16 小时前
ReBAC 与 Google Zanzibar:权限系统的未来
后端·架构