Go 并发任务编排：从基础模式到工程级优雅实现

任务编排的核心，在于对一组并发执行单元的生命周期、数据流和错误流进行有组织的管理。它追求的不是并发本身，而是并发下的可控性、可观测性和健壮性。

基础构建块：同步、通信与取消

在讨论具体模式前，需要先厘清 Go 提供的几个核心原语及其在编排中的角色。

1. 使用 WaitGroup 进行生命周期同步

sync.WaitGroup 是等待一组 Goroutine 完成的经典工具。它的模式很固定，但关键在于确保 Add 在启动 Goroutine 前调用，且 Done 一定会被调用。

func processTasks(tasks []string) error {
    var wg sync.WaitGroup
    var errMu sync.Mutex
    var errs []error

    for _, task := range tasks {
        wg.Add(1)
        go func(t string) {
            defer wg.Done()
            if err := doTask(t); err != nil {
                errMu.Lock()
                errs = append(errs, err)
                errMu.Unlock()
            }
        }(task)
    }
    wg.Wait()
    // 处理收集到的错误
    return combineErrors(errs)
}

这个模式适用于“发射后不管”的场景，但缺点也很明显：没有超时控制，一个卡住的任务会阻塞整个等待；错误处理需要额外同步（如使用互斥锁保护切片）。

2. 利用 Channel 进行任务分发与结果收集

Channel 是 Go CSP 模型的灵魂，天然适合构建生产者-消费者模式的任务管道。一个更结构化的做法是使用两个 Channel：一个用于发送任务，一个用于接收结果。

func runWorkerPool(taskChan <-chan Task, resultChan chan<- Result, workerCount int) {
    var wg sync.WaitGroup
    for i := 0; i < workerCount; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            for task := range taskChan { // 自动从关闭的channel退出
                resultChan <- process(task)
            }
        }(i)
    }
    // 所有worker完成后，关闭结果channel
    go func() {
        wg.Wait()
        close(resultChan)
    }()
}

主控程序负责向 taskChan 发送任务，然后关闭它，并通过 for range 从 resultChan 读取所有结果。这种模式清晰地将任务分发、并发执行和结果收集解耦。

3. 引入 Context 实现超时与取消

生产环境中的任务编排必须考虑边界情况。context.Context 提供了在任务树中传播取消信号和超时截止期的标准方式。

一个常见的场景是：你发起一个 HTTP 请求，该请求需要并行调用三个微服务获取数据。如果其中任何一个调用超时或失败，你希望立即取消其他仍在进行的调用，而不是空等。

func gatherData(ctx context.Context) (*CombinedData, error) {
    ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
    defer cancel()

    dataChan := make(chan *ServiceData, 3) // 缓冲通道避免goroutine泄漏
    var wg sync.WaitGroup

    services := []string{"svcA", "svcB", "svcC"}
    for _, svc := range services {
        wg.Add(1)
        go func(s string) {
            defer wg.Done()
            select {
            case dataChan <- fetchFromService(ctx, s):
                // 成功发送结果
            case <-ctx.Done():
                // 超时或被取消，直接退出，避免向已关闭的channel发送
                log.Printf("Fetch for %s cancelled: %v", s, ctx.Err())
            }
        }(svc)
    }

    // 等待所有worker完成，然后关闭channel
    go func() {
        wg.Wait()
        close(dataChan)
    }()

    var combinedData CombinedData
    for data := range dataChan {
        combinedData.Merge(data)
    }

    // 检查是否因超时导致数据不全
    if ctx.Err() == context.DeadlineExceeded {
        return &combinedData, fmt.Errorf("partial data due to timeout")
    }
    return &combinedData, nil
}

这里的关键是，每个工作 Goroutine 都监听 ctx.Done()。当主函数中的超时发生，cancel() 被调用（defer 确保），所有子 Goroutine 都会收到信号并尝试退出。使用缓冲的结果通道可以防止工作 Goroutine 在尝试发送结果时被阻塞，从而造成 Goroutine 泄漏。

高级模式：扇入、扇出与错误处理

当任务流变得更加复杂时，基础模式需要组合使用。

扇出（Fan-out）：一份输入，多份并发处理

扇出模式通常用于提高吞吐量，例如用一个任务 Channel 喂养多个 worker Goroutine。上面的 worker pool 就是一个扇出的例子。需要注意的点是：

• 并发度控制：worker 数量并非越多越好，需考虑下游承受能力和自身资源。
• 任务顺序：多个 worker 并发消费，任务完成顺序与发送顺序不一致。如果要求严格顺序，则不能使用此模式。

扇入（Fan-in）：多份输入，一份结果汇总

扇入模式用于将多个来源的数据合并到一个流中。例如，监听多个消息队列，或者像上面的 gatherData 函数一样合并多个微服务的结果。实现扇入时，常用 select 语句来同时监听多个输入 Channel。

func fanIn(ctx context.Context, inputs ...<-chan Result) <-chan Result {
    out := make(chan Result)
    var wg sync.WaitGroup
    multiplex := func(in <-chan Result) {
        defer wg.Done()
        for {
            select {
            case r, ok := <-in:
                if !ok {
                    return // 输入channel关闭
                }
                select {
                case out <- r:
                case <-ctx.Done():
                    return // 整体被取消
                }
            case <-ctx.Done():
                return // 整体被取消
            }
        }
    }
    wg.Add(len(inputs))
    for _, in := range inputs {
        go multiplex(in)
    }
    go func() {
        wg.Wait()
        close(out)
    }()
    return out
}

统一的错误传播与聚合

在并发编排中，错误处理策略至关重要。一种优雅的做法是定义一个包含结果和错误的结构体，通过统一的 Channel 传递。

type JobResult struct {
    Output interface{}
    Err    error
    JobID  string
}

func executeJobs(ctx context.Context, jobs []Job) ([]JobResult, error) {
    resultChan := make(chan JobResult, len(jobs))
    // ... 启动goroutine处理jobs，将JobResult发送到resultChan
    // ... 使用Context控制超时
    // 收集结果
    var results []JobResult
    for res := range resultChan {
        results = append(results, res)
    }
    // 事后分析：是否有失败？是否超时？
    return results, analyzeResults(results, ctx.Err())
}

模式选型与实战建议

没有一种模式是万能的。选择哪种编排方式，取决于你的具体需求。下表对比了几种常见场景的适用模式：

给工程实践的建议

1. 始终考虑超时：为任何可能阻塞的操作设置超时，使用 context.WithTimeout 或 context.WithDeadline。
2. 避免 Goroutine 泄漏：确保 Goroutine 在不再需要时能够退出。Channel 关闭、Context 取消是两种主要的信号机制。
3. 度量并发度：使用 Prometheus 等工具监控活跃 Goroutine 数量、Channel 长度等，了解系统实际并发压力。
4. 从简单开始：如果 WaitGroup 能满足需求，就不要引入复杂的 Channel 管道。复杂性会随着模式升级而指数级增长。
5. 编写可测试的代码：将并发逻辑封装在函数内，通过注入 mock 的 Channel 或 Context 来方便测试超时、取消等行为。

总结

Go 语言为并发任务编排提供了强大的底层原语，但“优雅实现”的关键在于根据问题域选择合适的模式并进行恰当的组合。从简单的同步等待，到基于 Channel 的通信，再到利用 Context 进行生命周期管理，每一层都解决了更高阶的协调问题。真正的优雅不在于代码使用了多少种炫酷的模式，而在于它是否清晰地表达了并发意图，是否健壮地处理了边界情况，是否便于团队理解和维护。在并发世界里，可控往往比纯粹的“快”更重要。