Go 实现嵌套中间件的轻量 RPC 框架

本文深入探讨了如何在 Go 中设计一个轻量级、支持嵌套中间件的 RPC 框架，核心在于不侵入标准 net/rpc 实现，而是通过统一的中间件签名（接收 context、请求、响应指针和 next 函数）实现可链式透传上下文与错误的灵活拦截；服务端借助自定义 ServerCodec 在请求生命周期关键节点注入前置/后置逻辑，客户端则通过封装 Do 方法支持 Before/After 回调，全程强调 context 显式传递、error 精准归因与资源安全——既保持了 Go 原生 RPC 的简洁性，又赋予其媲美成熟框架的可观测性、可扩展性与运维友好性。

Go 里实现支持中间件嵌套调用的轻量级 RPC 框架，核心不在于重写 net/rpc，而在于把中间件逻辑注入到请求生命周期的关键钩子点——服务端用 Handler 包裹，客户端用 Call 前后拦截，且中间件必须能链式传递上下文和错误。

用 func(context.Context, *rpc.Request, interface{}, func() error) error 统一中间件签名

中间件必须可嵌套，就不能依赖固定参数列表。统一用函数类型接收 context.Context、*rpc.Request、响应值指针、以及一个“继续向下执行”的 next 函数。这样每层中间件决定是否调用 next()，还能在前后做日志、鉴权、超时控制等。

常见错误是把中间件写成 func(*rpc.Request) error，导致无法透传 context 或提前终止调用链。

• 所有中间件必须返回 error，以便上层统一处理失败（比如直接返回 rpc.ErrShutdown）
• 响应值用 interface{} 指针接收，避免中间件内部对具体结构体强依赖
• next() 不应暴露底层连接或 codec，只负责触发后续 handler 或实际 RPC 调用

服务端：用 rpc.Server.RegisterCodec + 自定义 ServerCodec 插入中间件链

标准 rpc.Server 不提供 handler 注册钩子，但允许替换 Codec。你可以包装原始 ServerCodec，在 ReadRequestHeader 后、ReadRequestBody 前启动中间件链，在 WriteResponse 前注入后置逻辑。

典型场景是统一加 trace ID、校验 token、限流——这些都得在反序列化请求体前完成，否则可能浪费解析开销。

• 不要在 Register 阶段注册中间件，那只是绑定方法名，不参与执行流
• 自定义 ServerCodec 必须完整代理原始 codec 的所有方法，漏掉 Close 会导致连接泄漏
• 中间件链执行顺序 = 注册顺序，前置中间件先执行；若某层返回非 nil error，应跳过 next() 并直接 WriteResponse 错误

客户端：封装 rpc.Client.Call 为 Do 方法并支持 Before/After 回调

客户端没法改 rpc.Client 内部逻辑，所以最轻量做法是包装一层结构体，暴露 Do(ctx context.Context, serviceMethod string, args interface{}, reply interface{}) error，并在其中按序执行 Before 列表（如注入 header）、调用原 Call、再执行 After（如记录耗时）。

容易踩的坑是把中间件写成同步阻塞式重试——这会卡死整个调用，正确做法是在 Before 中设置 ctx 超时，让 Call 自身承担重试语义（或由单独的 retry middleware 处理）。

• Before 可修改 args（比如加签名字段），但不能改 reply 指针本身
• After 接收 error 参数，用于判断是否成功，避免重复解包 response
• 不要在中间件里直接操作 rpc.Client 的 conn 字段——它是未导出字段，且 Go 1.22+ 已标记为 internal

中间件嵌套时 context 传递必须显式透传，不能依赖闭包捕获

多个中间件嵌套时，如果用闭包捕获外层 ctx，会导致超时/取消信号无法向下传递。必须把更新后的 ctx 作为参数传给下一层 next，并在每层中间件开头用 ctx = ctx 显式接收。

例如鉴权中间件生成新 ctx 带 user info，日志中间件就得从这个 ctx 里取，而不是读原始传入的 ctx。

• 每次调用 next(ctx, req, reply, ...) 前，确保 ctx 已被当前中间件增强（如 context.WithValue 或 context.WithTimeout）
• 避免在中间件中用 context.Background() 创建子 context，会切断取消链
• 调试时打印 ctx.Err() 是排查“调用没响应却也不报错”的最快方式

真正难的不是写通中间件链，而是保证每个环节的 error 被正确归因——是 codec 解析失败？还是中间件主动拒绝？还是下游服务无响应？这些 error 类型必须区分清楚，否则运维时根本没法定位是框架问题还是业务逻辑问题。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Go 实现嵌套中间件的轻量 RPC 框架》文章吧，也可关注golang学习网公众号了解相关技术文章。