11、分布式追踪：开发、测试与规划指南

分布式追踪：开发、测试与规划指南

1. 追踪成本与平衡

追踪过程中最大的资源成本并非创建和发送跨度（span）的服务级成本。从大小上看，单个跨度很可能只是任何给定远程过程调用（RPC）中处理数据的一小部分。为了在性能和从追踪中获取价值所需的信息之间找到合适的平衡，你应该对创建的跨度、添加到跨度的数据量以及创建跨度的速率进行试验。

2. 追踪驱动的开发

2.1 开发中使用追踪

• 开发起点 ：无论使用何种语言、平台或服务风格，开发通常都始于白板。在白板上创建服务功能模型，并绘制表示与其他服务连接的线条，这在开发的早期原型阶段非常有用。
• 模型与代码的转换问题 ：将模型转化为代码时会遇到问题。传统上建议使用测试函数，但单元测试的目标太小，只能验证非常小的功能单元，如单个方法调用。编写更大的单元测试来验证函数的其他假设，最终可能会为了不合理的原因遍历每个代码路径。
• 集成测试的问题 ：当测试服务与前置和依赖服务的关系时，情况会更加复杂。集成测试通常用于验证模型，但存在两个问题。一是模拟服务时，测试的不是实际服务，而是遵循预定命令的模拟替代物；二是集成测试通常局限于测试环境，并且在跨进程边界通信方面支持不佳。
• 追踪的优势 ：追踪可以提供一种验证应用程序心理模型的方法。它能确保内部方法和外部服务以正确的顺序、使用正确的参数被调用，并且合理处理错误。例如，在AWS S3存储桶长时间不可用导致的服务中断事件中，追踪数据可以帮助快速比较系统的