📚 课程目录第1章微服务并发模型基础

1. 微服务并发模型基础：Go goroutine 与 GMP 调度原理、并发与并行的区别、微服务中常见的并发模式

1.1 并发与并行的本质区别

在微服务架构中，理解并发与并行的区别是设计高性能系统的前提。Go 语言的设计哲学强调“并发不是并行”，但并发是构建并行系统的基石。

维度	并发（Concurrency）	并行（Parallelism）
定义	逻辑上同时处理多个任务（交替执行）	物理上同时执行多个任务（真正同时）
硬件依赖	单核 CPU 即可实现	必须多核 CPU 或多处理器
执行方式	时间片轮转、任务切换	多核并行、指令级并行
关注点	任务结构、分解、组合	吞吐量、加速比
Go 实现	goroutine + channel	GOMAXPROCS > 1
典型场景	微服务请求处理、IO 密集型	计算密集型、数据并行处理

关键认知： 并发是程序设计的结构属性，并行是程序执行的运行时属性。Go 通过 goroutine 让并发编程变得简单，而 GMP 调度器负责将并发任务高效映射到并行执行。

1.2 Go goroutine 与 GMP 调度原理

goroutine 是 Go 语言轻量级线程的抽象，初始栈仅 2KB，可动态增长。GMP 调度器是 Go 运行时实现高并发能力的核心引擎。

GMP 核心组件

组件	全称	职责	数量关系
G	Goroutine	用户态协程，包含栈、上下文、状态	可创建数百万个
M	Machine（线程）	操作系统线程，负责执行 G	通常等于 GOMAXPROCS
P	Processor（逻辑处理器）	本地运行队列、调度上下文	由 GOMAXPROCS 决定

GMP 调度流程

P 从本地队列或全局队列获取可运行的 G。
P 将 G 绑定到 M 上执行。
G 执行中发生阻塞（系统调用、channel 操作、time.Sleep），M 与 P 解绑，P 寻找空闲 M 或新建 M。
阻塞的 G 和 M 进入等待状态，阻塞结束后 G 重新入队。
P 定期检查全局队列和网络轮询器，防止饥饿。
当 M 执行完 G，P 继续获取下一个 G，形成循环。

微服务启示： GMP 调度器使得每个请求可以独立使用一个 goroutine 处理，而不会产生传统线程模型中的高内存开销和频繁上下文切换。这是 Go 微服务能够支撑高并发请求的底层保障。

1.3 微服务中常见的并发模式

在 Go 微服务开发中，以下四种并发模式被广泛使用，每种模式对应不同的业务场景和性能特征。

模式一：请求-响应（Request-Response）

每个请求启动一个 goroutine 处理，处理完成后返回响应。这是微服务中最基础的并发模式，适用于无状态、独立处理的 API 端点。

// 请求-响应模式示例
func handleRequest(w http.ResponseWriter, r *http.Request) {
    // 每个请求自动运行在独立的 goroutine 中
    result := process(r)
    w.Write(result)
}

模式二：扇出（Fan-Out）

一个请求需要同时调用多个下游服务，然后聚合结果。适用于仪表盘、推荐系统等需要多数据源的场景。

// 扇出模式示例
func fanOutHandler(ctx context.Context, ids []string) []Result {
    ch := make(chan Result, len(ids))
    for _, id := range ids {
        go func(id string) {
            ch <- callService(ctx, id)
        }(id)
    }
    var results []Result
    for i := 0; i < len(ids); i++ {
        results = append(results, <-ch)
    }
    return results
}

模式三：管道（Pipeline）

多个处理阶段通过 channel 连接，每个阶段由一组 goroutine 处理。适用于数据流处理、日志处理、ETL 等场景。

// 管道模式示例
func pipeline(input <-chan Data) <-chan Result {
    stage1 := func(in <-chan Data) <-chan Data {
        out := make(chan Data)
        go func() {
            for d := range in {
                out <- transform(d)
            }
            close(out)
        }()
        return out
    }
    stage2 := func(in <-chan Data) <-chan Result {
        out := make(chan Result)
        go func() {
            for d := range in {
                out <- aggregate(d)
            }
            close(out)
        }()
        return out
    }
    return stage2(stage1(input))
}

模式四：工作池（Worker Pool）

固定数量的 worker goroutine 从任务队列中获取任务并执行。适用于控制并发度、保护下游服务不被突发流量打垮的场景。

// 工作池模式示例
func workerPool(tasks []Task, workerCount int) {
    taskCh := make(chan Task, len(tasks))
    var wg sync.WaitGroup
    for i := 0; i < workerCount; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for task := range taskCh {
                execute(task)
            }
        }()
    }
    for _, t := range tasks {
        taskCh <- t
    }
    close(taskCh)
    wg.Wait()
}

并发陷阱： 扇出模式中未限制并发数可能导致下游服务被压垮；管道模式中未处理 channel 关闭可能导致 goroutine 泄漏；工作池中 worker 数量设置不当（过多或过少）都会影响系统吞吐量。这些都是在微服务性能调优中需要重点关注的瓶颈点。

1.4 并发模型选择矩阵

在实际微服务架构设计中，需要根据业务特征选择合适的并发模式。下表总结了各模式的适用场景和性能特征：

并发模式	适用场景	并发度控制	goroutine 数量	典型瓶颈
请求-响应	REST API、gRPC 端点	无（依赖 GMP）	与请求数成正比	内存占用、GC 压力
扇出	仪表盘、推荐、搜索聚合	需手动限制	请求数 × 下游服务数	下游服务过载
管道	日志处理、ETL、数据清洗	每阶段可独立控制	阶段数 × 每阶段 goroutine	channel 阻塞、背压
工作池	任务队列、消息消费、批量处理	固定 worker 数	固定（worker 数）	worker 数量调优

性能调优要点：
请求-响应模式：关注 GOMAXPROCS 设置，通常设置为 CPU 核心数。
扇出模式：使用 errgroup 或 semaphore 控制并发数，避免打垮下游。
管道模式：使用 buffered channel 减少阻塞，注意 channel 关闭顺序。
工作池模式：worker 数通常设置为 CPU 核心数的 2~4 倍（IO 密集型）或等于核心数（CPU 密集型）。

1.5 本章小结

本章建立了微服务并发模型的理论基础：

并发 vs 并行： 并发是结构，并行是执行；Go 通过 goroutine 实现并发，通过 GMP 调度实现并行。
GMP 调度： G（协程）→ P（逻辑处理器）→ M（线程）的三层架构，是 Go 高并发的底层保障。
四种并发模式： 请求-响应、扇出、管道、工作池，每种模式都有明确的适用场景和调优方向。