📚 课程目录第2章 Go项目结构设计

2. Go 项目结构设计：标准布局与模块化

在压测闭环方案中，项目结构决定了测试代码的可维护性、可扩展性以及接口调用的稳定性。一个清晰的分层结构能让压测脚本与业务代码解耦，同时复用核心逻辑。本节围绕标准 Go 项目布局、模块化设计、接口抽象层和依赖注入四个核心维度展开。

2.1 标准 Go 项目布局（cmd / internal / pkg）

Go 社区推荐的项目布局遵循 cmd、internal、pkg 三大顶层目录，这种结构天然适合压测闭环方案：

目录	职责	压测场景下的作用
`cmd/`	存放可执行入口文件，每个子目录对应一个 main 包	压测启动器、CLI 工具入口
`internal/`	私有应用逻辑，外部包无法导入	压测编排器、数据收集器、断言引擎
`pkg/`	可被外部项目引用的公共库	HTTP 客户端封装、报告生成器、通用工具函数

  关键原则：压测代码与业务代码共享同一仓库时，internal/ 目录能有效防止外部依赖意外侵入压测核心逻辑；pkg/ 中的客户端封装可被压测脚本和业务代码共同引用，避免重复实现。

2.2 模块化设计：按功能域拆分

模块化不是简单的目录分层，而是按功能域（Domain）将代码组织为高内聚、低耦合的模块。在压测闭环中，推荐以下模块划分：

runner：压测执行引擎，负责并发控制、请求调度、超时管理。
assert：断言模块，支持状态码、响应体、响应时间等维度的校验。
reporter：报告模块，聚合压测结果并输出为 JSON / HTML / 控制台表格。
client：HTTP/gRPC 客户端封装，内置重试、连接池、指标采集。
config：配置模块，统一管理压测参数、目标地址、并发数等。

模块化收益：当需要新增一种协议（如 WebSocket）或一种报告格式（如 Prometheus）时，只需扩展对应模块，不影响其他模块的测试与压测流程。

2.3 接口抽象层：面向接口编程

接口抽象层是压测闭环方案的核心设计之一。通过定义清晰的接口，压测脚本可以脱离具体实现，实现“测试逻辑”与“底层通信”的解耦。

// client.go — 定义 HTTP 客户端接口
type HTTPClient interface {
    Do(req *http.Request) (*http.Response, error)
    DoWithMetrics(req *http.Request) (*http.Response, Metrics, error)
}

// assert.go — 定义断言接口
type Asserter interface {
    Assert(resp *http.Response, duration time.Duration) error
    Name() string
}

// reporter.go — 定义报告接口
type Reporter interface {
    Record(result *Result)
    Flush() error
    Summary() *ReportSummary
}

常见误区：接口定义过早或过细会导致抽象泄漏。建议从压测闭环的实际调用链路出发，先写调用方代码，再反向提炼接口，确保每个接口都有至少两个实现（如真实客户端 + Mock 客户端）后再定型。

2.4 依赖注入：构建可测试的压测引擎

依赖注入（DI）让压测引擎的各个组件可以在运行时组装，便于在单元测试中替换为 Mock 实现，也便于在压测时切换不同的客户端或报告器。

// engine.go — 压测引擎构造函数
type Engine struct {
    client   HTTPClient
    asserter Asserter
    reporter Reporter
    config   *Config
}

func NewEngine(client HTTPClient, asserter Asserter, reporter Reporter, config *Config) *Engine {
    return &Engine{
        client:   client,
        asserter: asserter,
        reporter: reporter,
        config:   config,
    }
}

// 使用示例：压测时注入真实客户端
func main() {
    client := client.NewRealClient(5 * time.Second)
    asserter := assert.NewCompositeAsserter(
        assert.StatusOK(),
        assert.BodyContains("success"),
    )
    reporter := reporter.NewConsoleReporter()
    cfg := config.LoadFromFile("benchmark.yaml")

    engine := NewEngine(client, asserter, reporter, cfg)
    engine.Run(context.Background())
}

  DI 在压测中的优势：单元测试时只需注入 mockClient 和 mockReporter，即可验证引擎的调度逻辑、超时处理、错误重试等核心行为，无需启动真实服务。

2.5 整体结构图：压测闭环的项目骨架

下图展示了标准 Go 项目布局与压测闭环模块之间的映射关系，以及接口抽象层和依赖注入如何串联各模块：

2.6 模块间调用关系：压测执行流程

为了更清晰地展示模块在压测运行时的协作顺序，下图以一次完整的压测请求为例，展示各模块的调用链路：

流程要点：Engine 先加载配置，然后循环执行 HTTP 请求 → 断言校验 → 记录结果，最后统一 Flush 报告。每个步骤都通过接口调用，替换实现时无需修改 Engine 代码。

2.7 本章小结

标准布局：cmd/ 放入口，internal/ 放私有压测逻辑，pkg/ 放可复用客户端与工具。
模块化：按 runner / assert / reporter / client / config 五个功能域拆分，每个模块职责单一。
接口抽象：定义 HTTPClient、Asserter、Reporter 等接口，压测脚本与具体实现解耦。
依赖注入：通过构造函数注入依赖，单元测试可轻松替换为 Mock，压测时切换真实组件。