本文介绍如何在 Go SDK 中设计支持异步执行、结果通过 HTTP 回调返回的 RPC 接口，解决跨语言调用下无法使用 Go 原生 channel 的限制，并对比标准库 net/rpc 的异步能力与 HTTP 层适配方案。
本文介绍如何在 go sdk 中设计支持异步执行、结果通过 http 回调返回的 rpc 接口，解决跨语言调用下无法使用 go 原生 channel 的限制，并对比标准库 `net/rpc` 的异步能力与 http 层适配方案。
在构建面向多语言客户端的 SDK 时，常需提供“发起即返回、结果异步送达”的 RPC 接口——尤其当后端操作耗时较长（如文件处理、模型推理、第三方服务集成），阻塞式 HTTP 请求不仅易触发超时，还会浪费连接资源并降低系统吞吐。虽然 Go 标准库 net/rpc 提供了 Client.Go() 方法支持基于 channel 的异步调用，但该机制仅适用于 Go 客户端内部通信，无法直接用于跨语言 HTTP 场景（如 Python/Java 客户端调用）。
因此，真正的异步 RPC over HTTP 必须脱离“单请求-单响应”范式，转而采用 “请求-确认-回调”三段式流程：
- 客户端发起异步请求：POST /api/v1/process，携带业务参数及 callback_url（如 https://client.example.com/notify）；
- 服务端立即返回 202 Accepted，附带唯一 request_id；
- 服务端后台执行任务完成后，主动向 callback_url 发起 POST 请求，传送结果（JSON 格式）。
示例服务端逻辑（Go）：
type AsyncRequest struct {
Data interface{} `json:"data"`
CallbackURL string `json:"callback_url"`
}
func handleAsyncProcess(w http.ResponseWriter, r *http.Request) {
var req AsyncRequest
if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
http.Error(w, "Invalid JSON", http.StatusBadRequest)
return
}
reqID := uuid.New().String()
// 异步启动任务（如 goroutine 或任务队列）
go func() {
result := doHeavyWork(req.Data)
callbackPayload := map[string]interface{}{
"request_id": reqID,
"status": "success",
"result": result,
}
// 使用 http.Client 向 callback_url 发送结果
payloadBytes, _ := json.Marshal(callbackPayload)
http.Post(req.CallbackURL, "application/json", bytes.NewReader(payloadBytes))
}()
json.NewEncoder(w).Encode(map[string]string{
"request_id": reqID,
"status": "accepted",
})
}⚠️ 注意事项：
- 回调可靠性：生产环境应引入重试机制（指数退避）、签名验证（防止伪造回调）、幂等性设计（如 idempotency-key 头）；
- 超时与状态查询：建议配套提供 /api/v1/status/{request_id} 接口，供客户端轮询或兜底；
- Gorilla RPC 不适用此场景：其设计基于 TCP 连接复用，不原生支持 HTTP 回调语义；net/rpc 的 Go() 方法虽为异步，但本质仍是同步网络调用 + channel 解耦，不解决跨语言回调问题；
- 替代方案参考：对高可靠要求场景，可接入消息队列（如 RabbitMQ/Kafka）解耦执行与通知，由独立服务负责回调投递。
总结：HTTP 协议本身无内置回调机制，所谓“异步 RPC 回调”实为服务端主动反向 HTTP 调用。设计时应明确分离请求入口、任务调度、结果分发三层职责，避免阻塞主线程，同时兼顾安全性、可观测性与错误恢复能力。
