背景说明：
目前我们的核心业务主要部署在 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 后端。
-
🎯 只适用于以下特定场景：
-
极度纯粹的 Serverless 架构： 如果你的代码跑在 Lambda 上，控制台一键开启即可，这方案是首选。
-
遗留的"历史包袱"系统： 团队早在几年前就已经在代码里硬编码 (Hardcode) 接入了 AWS X-Ray 专有 SDK，无力进行重构。
-
-
✨ 方案优势 (Pros)：
- 在纯 AWS 环境下，对 AWS 托管服务 (如 DynamoDB, SNS, SQS) 的 API 调用识别极其精准，几乎零配置。
-
⚠️ 避坑与风险 (Cons & Risks)：
-
代码侵入性高： 必须使用 AWS 私有的 SDK 埋点。
-
严重厂商锁定 (Vendor Lock-in)： 追踪数据格式不兼容开源标准。如果以后想把数据发给 Jaeger 或 Datadog，需要重写所有代码的埋点逻辑。不推荐现代化的新微服务架构采用此方案。
-