Jaeger项目中的采样策略模块重构分析

在分布式追踪系统Jaeger的开发过程中，团队发现OTEL/contrib扩展模块对Jaeger核心采样策略模块存在依赖关系，这不利于代码的模块化和维护。本文详细分析了这一技术重构的背景、方案设计和实施过程。

背景与问题

Jaeger的采样策略系统是核心功能之一，负责决定哪些请求需要被追踪。该系统原先分布在多个包中，包括cmd/collector/app/sampling和plugin/sampling/strategyprovider等位置。随着项目发展，这种分散的结构导致OTEL/contrib扩展模块对核心采样策略产生了不必要的依赖，增加了维护难度。

重构方案设计

经过深入讨论，团队确定了以下重构原则：

1. 依赖解耦：将OTEL/contrib扩展模块所需的采样策略代码复制到contrib目录下，打破对核心模块的依赖
2. 代码重组：将采样策略相关代码集中到新的internal/sampling包中
3. 接口优化：重新设计接口以减少循环依赖

重构后的包结构设计如下：

internal/
├── leaderelection/
└── sampling/
    ├── grpc/        # gRPC处理程序
    ├── http/        # HTTP处理程序
    └── strategyprovider/
        ├── file/    # 文件策略(原static)
        ├── adaptive/ # 自适应策略
        ├── metafactory/ # 策略工厂
        ├── provider.go # 提供者接口
        └── aggregator.go # 聚合器接口

关键技术点

1. 模型迁移：将原先分散在各处的采样模型集中到storage/samplingstore包中，使结构更清晰

2. 接口重构：

   • 将Provider和Aggregator接口定义在顶层
   • 具体实现放在子包中
   • 使用返回结构体指针而非接口的方式避免循环依赖

3. 命名规范化：

   • 将static策略重命名为file策略，与Jaeger v2的命名规范保持一致
   • 使用更具描述性的文件名如provider.go替代通用的interface.go

实施策略

团队采用渐进式重构方法，将大规模改动分解为多个小步骤：

1. 首先迁移模型定义
2. 然后移动gRPC和HTTP处理程序
3. 接着重构领导选举模块
4. 最后重组策略提供者实现

这种分阶段方法降低了重构风险，使每个变更都保持可控范围。

技术收益

通过此次重构，Jaeger项目获得了以下改进：

1. 模块解耦：OTEL/contrib扩展不再依赖Jaeger核心采样模块
2. 结构清晰：采样相关代码集中到统一位置
3. 可维护性提升：通过接口优化减少了循环依赖
4. 命名规范：统一了策略实现的命名方式

这一重构为Jaeger后续的功能演进和架构优化奠定了更好的基础，体现了项目团队对代码质量的持续追求。