Golang微服务文件上传不能直接用round-robin负载均衡，因multipart请求长连接、不可中断、易被代理截断；必须解耦接入与处理，统一入口+异步分发至幂等worker，依赖对象存储保障一致性。
直接说结论：Golang微服务做文件上传时，**不能把负载均衡逻辑放在上传路径本身**，而必须把“接收上传”和“处理上传”解耦——否则必然出现文件分片丢失、重复写入、元数据不一致等问题。
为什么不能用 round_robin 直接转发 multipart/form-data 请求
常见错误是给 http.Client 配一个轮询地址池，然后对每个 POST /upload 请求手动选节点发过去。这会立刻暴露三个硬伤：
- HTTP 上传请求（尤其是大文件）耗时长、连接生命周期不可控，
round_robin的连接复用机制完全失效，每个请求都新建 TCP 连接 - 客户端一旦开始上传，就无法中途切换后端；若目标实例宕机或超时，整个上传失败，没有 fallback 能力
- multipart boundary 和 body 流式读取依赖底层连接状态，跨代理转发时容易被中间件截断或重写（比如某些反向代理会 buffer 整个 body）
正确做法：上传入口统一 + 后端异步分发
核心思路是让所有上传请求先打到一个无状态的“接入层”，再由它决定后续动作。这个接入层可以极轻量，甚至只是 Nginx 或 Traefik 的简单路由，不需要 Go 写：
- 前端
POST /api/v1/upload固定发往一个 VIP 或域名（如upload-gateway.example.com） - 接入层不做业务处理，只做两件事：校验 token / 签名、生成唯一
upload_id（如uuid.NewString()）并返回给前端 - 前端拿到
upload_id后，发起真正的文件上传请求（可带预签名 URL 或直传 OSS），或由接入层用http.Post异步推送给下游 worker 实例
这样就把“负载问题”从 HTTP 协议层移到了消息/任务分发层，天然适配各种策略。
立即学习“go语言免费学习笔记（深入）”；
worker 层如何做真正的负载均衡
真正需要 LB 的是处理上传完成后的业务逻辑（例如转码、OCR、校验、入库）——这部分才是微服务间调用，可以用标准方案：
- 用 Consul 注册所有
file-processor实例，客户端通过go-micro/v2的service.Client().Call()发起调用，自动走轮询 - 如果是 gRPC，直接
grpc.Dial("dns:///file-processor", grpc.WithBalancerName("round_robin"))，前提是 Kubernetes 中配置了 Headless Service - 避免用
http.Get硬编码地址；改用go-kit/sd+lb.Balancer封装，失败时自动 fallback 到下一个健康节点（lb.NewOpportunist） - 所有 worker 必须幂等：同一
upload_id的处理请求可能因重试多次到达，需靠 DB 唯一索引或 Redis setnx 拦截
绕不开的细节：临时文件与存储一致性
最容易被忽略的是“上传中文件存哪”。如果接入层把文件暂存本地磁盘再转发，就引入了单点故障和路径不一致风险：
- 不要用本地
/tmp—— 多实例部署时路径不可共享，且重启即丢 - 推荐用对象存储（MinIO / S3）作中转：接入层收到文件后立即
PutObject，生成 presigned URL 给 worker 拉取；worker 处理完再写结果回同一 bucket - 若必须用本地存储，至少挂载共享 NFS 或用
etcd协调临时目录锁，但性能和可靠性远不如对象存储
上传不是单纯的网络分发问题，而是涉及协议语义、状态持久化、失败恢复的完整链路。把“谁收”和“谁干”分开，比在 HTTP 层硬塞 LB 可靠十倍。
