Go 驱动 工程化 后端服务：并发不是越多越好
一、AI 后端的瓶颈常在等待和排队
Go 很适合写 AI 应用后端：并发模型清晰，网络服务成熟，部署成本低。但一接入模型推理、向量检索、对象存储和外部 API，就会发现瓶颈不只在代码执行。更多时间消耗在等待下游、排队、重试和序列化上。若只是开更多 goroutine，很容易把下游打爆。
AI 后端要关心的是端到端延迟。用户的一次请求可能经历鉴权、Prompt 构造、检索、推理、内容审核、结果存储。每一步都可能失败。Go 服务的价值，是把这些步骤编排得清楚、可取消、可超时、可观测，而不是简单堆并发。
二、请求链路：每一步都要有超时
sequenceDiagram participant U as User participant API as Go API participant R as Retriever participant M as Model participant S as Storage U->>API: Submit request API->>R: Search context R-->>API: Chunks API->>M: Infer with timeout M-->>API: Stream tokens API->>S: Save result API-->>U: Response这个链路里，context 是第一等公民。用户取消请求后，后端不应该继续占用推理资源；检索超时后，可以降级为无上下文回答或直接返回可重试提示；存储失败时，要明确结果是否已返回给用户。没有超时和取消，AI 后端会在流量高峰时积累大量无意义工作。
三、并发控制：用信号量保护下游
下面是一个简化的并发限制示例。它不是为了限制 Go 的能力，而是保护模型服务。
package main import ( "context" "errors" "time" ) var inferSlots = make(chan struct{}, 32) func CallModel(ctx context.Context, prompt string) (string, error) { select { case inferSlots <- struct{}{}: defer func() { <-inferSlots }() case <-ctx.Done(): return "", ctx.Err() default: return "", errors.New("inference queue is full") } child, cancel := context.WithTimeout(ctx, 20*time.Second) defer cancel() return doInfer(child, prompt) } func doInfer(ctx context.Context, prompt string) (string, error) { return "result", nil }这个模式很朴素，但生产价值很高。满载时明确拒绝，比让请求无限排队更诚实。排队过长会让用户等待，也会让系统指标变得难以解释。后端服务要把容量限制显式化，才能做告警、扩容和降级。
四、工程边界：重试要有预算
AI 后端的重试尤其危险。模型推理成本高，外部 API 可能按 token 计费，盲目重试会放大成本和延迟。建议为每个请求设置 retry budget：哪些错误可重试，最多重试几次，是否允许跨模型降级，是否需要返回部分结果。重试不是补救一切的胶带，而是有限预算内的恢复策略。
可观测性也要跟上。至少记录 request_id、user_tier、model_name、prompt_tokens、completion_tokens、retrieval_latency、infer_latency、error_type。日志不能泄露用户隐私，但需要足够支持排障。指标层面可以关注 P50/P95/P99、队列长度、拒绝数、超时数和下游错误率。没有这些数据，所谓性能优化只能靠猜。
取舍方面，严格限流会带来更多“请稍后再试”，但能保护整体服务；无限排队看似提高成功率，实际会拖垮延迟并造成雪崩。务实的 AI 后端应该在容量边界处清楚地说不，再用扩容和缓存解决真实需求。
生产落地补充：从能跑到可维护
从生产落地角度看，这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通，真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束，读者很难判断它能否放进真实系统。
评估时建议先定义三类指标：正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信，稳定性指标回答失败时是否可控，成本指标回答持续运行是否划算。三类指标要同时进入验收清单，不能只用平均耗时或单次成功率证明方案有效。
实现层面还需要把观测数据留出来。日志至少包含请求标识、关键参数摘要、耗时、状态和错误类型；指标至少覆盖成功率、超时率、重试次数和队列长度；必要时再补 Trace 关联上下游调用。这样排查问题时不用靠猜，也能区分是代码逻辑、外部依赖还是容量配置导致的故障。
五、总结
Go 写 AI 后端，关键不是开更多 goroutine，而是把并发、超时、取消、限流、重试和观测做扎实。模型能力很重要，但稳定链路才是用户真正能感知到的服务质量。
