如果让你来？：自己实现一个 RPC 框架，你会考虑哪些方面？

“让你像调用本地方法一样调用远程服务。”

那如果，不让你用这些现成框架，而是——

“如果让你来自己实现一个 RPC 框架，你会考虑哪些方面？”

01、你会怎么做？

最基础的想法可能是这样的：

• 通过 Socket 建立客户端和服务端通信；
• 客户端把请求方法、参数发过去；
• 服务端收到后反射执行；
• 把结果返回给客户端。

看起来似乎能跑，但这只是 冰山一角。

02、怎么考虑呢？

1、通信协议

• 选 TCP、HTTP 还是 HTTP/2？
• 如何定义请求头、响应头？
• 序列化方式（JSON、Protobuf、Kryo）怎么选？

2、服务发现

• 服务注册中心：Zookeeper / Nacos / Etcd？
• 如何负载均衡（随机、轮询、一致性哈希）？

3、动态代理

• 客户端调用时如何生成代理类？
• 服务端如何根据方法名反射调用？

4、容错机制

• 超时重试怎么做？
• 失败是否重试？
• 断路器和限流策略如何集成？

5、性能优化

• 连接池、NIO（Netty）、批量发送；
• 异步调用 vs 同步阻塞；
• 压缩、请求合并、心跳检测。

6、可观测性

• 调用日志、Tracing（TraceId）；
• Metrics 监控；
• 重试统计与报警。

03、延伸思考参考

• gRPC 用 HTTP/2 + Protobuf；
• Dubbo 用 Netty + 自定义协议；
• 都通过 SPI 实现可插拔扩展机制。

你实现的不一定要复杂，但要 结构清晰、可扩展性强。

📌 一句话总结

💡 会写代码的是工程师，会设计框架的是架构师。

你还有哪些考虑呢？欢迎留言交流～～