高并发服务部署前的配置核对
Go 服务能在本地压测中跑出高吞吐，不代表放进容器后仍有相同行为。CPU 配额、内存上限、连接池、CGO 原生库和 Pod 终止流程，都会改变调度与延迟。部署前的配置核对，重点是确认代码看到的资源与 Kubernetes 实际提供的资源一致，并为过载和退出准备清楚路径。
示例值不能直接复制到生产。先用目标镜像、目标节点和代表性请求做容量测试，再确定并发、队列、资源 requests、limits 和关闭窗口。
先确认 Go 运行时看到多少 CPU
容器的 CPU limit 表示可使用的 CPU 时间配额，不一定等同于独占固定核心。Go 运行时对容器配额的感知行为与具体 Go 版本、平台和配置有关。部署时应记录工具链版本，并在启动日志里输出runtime.GOMAXPROCS(0)，不要根据宿主机核心数或 Deployment 清单猜测。
如果当前工具链不能按预期适配配额，可以显式设置GOMAXPROCS，或在确认兼容性后使用现有的容器适配库。引入额外包不是固定答案；升级 Go 后要重新验证，避免一个旧补丁与运行时的新行为叠加。
CPU limit 过紧会让容器被节流，表现为长尾上升；完全不设边界又可能与同节点工作负载争抢。观察时把应用 CPU、Cgroup throttling、请求排队和延迟放在一起。只看到 CPU 未跑满，不能判断服务仍有余量，瓶颈也可能在 CGO、网络或下游。
HTTP 并发必须有入口边界
Goroutine 很轻量，但它持有的请求体、模型输入和下游连接并不轻。入口要限制请求体、排队数量与单任务时限，不能为每个到达请求无限创建后台工作。超过容量时尽快返回可识别的繁忙状态，比让请求一直等到网关超时更容易恢复。
下面的服务入口区分存活与就绪状态，并在收到终止信号后先标记为不就绪，再关闭 HTTP 服务。具体超时应根据接口类型设置；若提供长时间流式响应，不要沿用适合普通 JSON 接口的统一WriteTimeout。
package main import ( "context" "log" "net/http" "os/signal" "runtime" "sync/atomic" "syscall" "time" ) func main() { var draining atomic.Bool mux := http.NewServeMux() mux.HandleFunc("/livez", func(w http.ResponseWriter, _ *http.Request) { w.WriteHeader(http.StatusOK) }) mux.HandleFunc("/readyz", func(w http.ResponseWriter, _ *http.Request) { if draining.Load() { http.Error(w, "draining", http.StatusServiceUnavailable) return } w.WriteHeader(http.StatusOK) }) mux.HandleFunc("/predict", handlePredict) server := &http.Server{ Addr: ":8080", Handler: http.MaxBytesHandler(mux, 1<<20), ReadHeaderTimeout: 5 * time.Second, IdleTimeout: 60 * time.Second, } ctx, stop := signal.NotifyContext( context.Background(), syscall.SIGINT, syscall.SIGTERM, ) defer stop() go func() { log.Printf("GOMAXPROCS=%d", runtime.GOMAXPROCS(0)) if err := server.ListenAndServe(); err != nil && err != http.ErrServerClosed { log.Fatalf("listen: %v", err) } }() <-ctx.Done() draining.Store(true) shutdownCtx, cancel := context.WithTimeout(context.Background(), 20*time.Second) defer cancel() if err := server.Shutdown(shutdownCtx); err != nil { log.Printf("graceful shutdown incomplete: %v", err) } }示例还缺少业务级并发限制和模型资源关闭，应由实际实现补充。http.Server.Shutdown等待 HTTP 连接，不会自动关闭自建 worker、原生运行时或消息订阅。主程序需要按依赖顺序逐项关闭，并在超过窗口时记录仍未完成的任务。
CGO 调用要写清内存与线程契约
调用 ONNX Runtime、TensorRT 或其他 C/C++ 库时，先从该库的正式 API 确认三件事：函数是否线程安全，返回内存由谁分配和释放，调用能否取消。不同库的约定不同，不能看到char*就一律在 Go 侧C.free。
C 分配的内存通常不在 Go 堆统计中，Go GC 无法替你释放。包装层应把创建与销毁放在同一类型中，使用方通过Close明确结束。并发数根据原生库实例、内部线程池和设备容量限制，不要让每个 HTTP 请求直接进入 CGO。
下面的信号量只展示拒绝与释放结构，nativeRun和nativeFree必须严格遵守所用库的真实契约。
type Predictor struct { sem chan struct{} } func NewPredictor(maxConcurrency int) (*Predictor, error) { if maxConcurrency < 1 { return nil, errors.New("maxConcurrency must be positive") } return &Predictor{sem: make(chan struct{}, maxConcurrency)}, nil } func (p *Predictor) Predict(ctx context.Context, input []byte) ([]byte, error) { select { case p.sem <- struct{}{}: defer func() { <-p.sem }() case <-ctx.Done(): return nil, ctx.Err() default: return nil, ErrPredictorBusy } // nativeRun must document ownership of the returned buffer. output, err := nativeRun(input) if err != nil { return nil, fmt.Errorf("native inference: %w", err) } return output, nil }上下文取消只能让等待信号量的请求退出。已经进入不可取消的 C 函数后，Go 无法凭空终止它。若原生库提供取消句柄，应接入；否则部署时要把最坏调用时间计入终止窗口，并防止新任务继续进入。
镜像与原生依赖要在同一环境构建
启用 CGO 后，编译产物依赖目标系统的 C 库和动态链接器。构建阶段与运行阶段应使用兼容的发行版，并把所需.so、模型文件和许可证一并纳入清单。不要在 Alpine 构建后默认它能在任意 glibc 镜像运行，也不要把开发机上的动态库手工复制进容器。
FROM golang:1.24-bookworm AS build WORKDIR /src COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=1 go build -trimpath -o /out/predictor ./cmd/predictor FROM debian:bookworm-slim RUN useradd --system --uid 10001 --no-create-home app WORKDIR /app COPY --from=build --chown=app:app /out/predictor ./predictor USER app ENTRYPOINT ["./predictor"]真实项目还需要安装对应原生运行库，并验证动态链接结果。是否改用 jemalloc，要根据内存剖析和原生库支持决定。默认预加载另一种分配器可能与库冲突，也可能让排查更困难，不应作为所有 CGO 服务的通用优化。
探针分别回答不同问题
Startup Probe 用来容纳模型加载等较长启动过程；Readiness 决定是否接收新流量；Liveness 只判断进程是否无法自行恢复。三者共用一个“端口可访问”接口，会让未加载完成的实例过早接流，也可能在过载时反复重启。
Deployment 还要有必需的selector，并让标签与模板一致。下面只表达结构，资源值与探针时间需要通过目标模型的启动和容量测试确定。
apiVersion: apps/v1 kind: Deployment metadata: name: go-predictor spec: replicas: 3 selector: matchLabels: app: go-predictor template: metadata: labels: app: go-predictor spec: terminationGracePeriodSeconds: 30 containers: - name: predictor image: registry.example.com/team/go-predictor:VERSION ports: - containerPort: 8080 resources: requests: cpu: "1" memory: 1Gi limits: cpu: "2" memory: 2Gi startupProbe: httpGet: { path: /livez, port: 8080 } failureThreshold: 30 periodSeconds: 2 readinessProbe: httpGet: { path: /readyz, port: 8080 } periodSeconds: 5 livenessProbe: httpGet: { path: /livez, port: 8080 } periodSeconds: 10示例里的资源只是占位，不能用于真实容量规划。模型文件、原生库内存和 Go 堆都要计入容器上限。发生 OOM 时，先分清增长来自 Go 堆还是进程外内存，再决定调整 GC、修复释放或增加容量。
在目标环境做一次缩容演练
发布前先用固定请求确认并发边界、超时和繁忙返回，再主动终止一个 Pod。观察它何时变为不就绪，已有请求是否在宽限期内结束，原生资源是否关闭，上游有没有不受控重试。随后执行滚动更新和回滚，确认旧版本仍能读取当前配置与模型文件。
最终记录 Go 版本、GOMAXPROCS、镜像与原生库版本、资源配置、探针行为、并发上限和关闭结果。高并发能力来自受控队列与清楚的资源契约，不是 Goroutine 数量。部署配置能准确反映这些边界，服务在压力和变更时才不会突然换一种运行方式。
