RPC 核心概念 01：什么是 RPC？为什么需要 RPC？

RPC 核心概念 01什么是 RPC为什么需要 RPC一、从函数调用说起我们写代码的最基本动作就是调用函数result:add(1,2)这种调用发生在同一个进程内CPU 直接跳转到函数地址执行。但当业务越来越大单个进程容纳不下所有功能我们就要把不同模块拆到不同进程、不同机器上。问题来了A 机器上的代码如何调用 B 机器上的函数这就是 RPCRemote Procedure Call远程过程调用要解决的核心问题——让远程函数调用看起来像本地函数调用一样简单。二、RPC 的定义RPC一种让程序透明地调用另一个地址空间通常是远程服务器函数的协议与技术。调用方Client的代码长这样result,err:userClient.GetUser(ctx,GetUserReq{ID:1})被调方Server的代码长这样func(s*UserService)GetUser(ctx context.Context,req*GetUserReq)(*GetUserResp,error){returnGetUserResp{Name:Tom},nil}中间发生的网络通信、序列化、连接管理等细节全部被框架隐藏。三、为什么需要 RPC3.1 微服务架构的必然需求随着业务复杂度提升单体应用面临编译部署慢任意模块出 bug 影响全局团队协作冲突难以按模块独立扩缩容。拆分成多个微服务后服务间通信就是头等大事。HTTPJSON 当然可以但有诸多缺点后述RPC 框架是更合适的方案。3.2 性能与开发效率的平衡维度HTTP/JSONRPC协议开销较大HTTP 头、JSON 文本小二进制协议序列化效率慢文本快Protobuf 等接口契约弱依赖文档强IDL 强约束开发体验手写客户端代码自动生成服务治理自行实现框架内置四、RPC 的本质本地调用 网络通信一次 RPC 调用的完整流程Client Server │ │ │ 1. 调用 stub (生成的客户端代码) │ │ │ │ 2. 参数序列化 (Marshal) │ │ │ │ 3. 通过网络发送 (TCP / HTTP/2 / QUIC) │ ├─────────────────────────────────────────────────────►│ │ │ 4. 接收并反序列化 │ │ │ │ 5. 路由到具体方法 │ │ │ │ 6. 执行业务逻辑 │ │ │ │ 7. 序列化结果 │◄─────────────────────────────────────────────────────┤ │ 8. 反序列化得到返回值 │可以发现 RPC 框架要解决的核心问题接口约定IDL序列化协议如 Protobuf传输协议TCP、HTTP/2 等服务发现与负载均衡错误处理与超时可观测性日志、监控、链路追踪五、RPC 的发展历程年代代表技术特点1980sSun RPC、CORBA早期跨平台尝试复杂笨重2000sXML-RPC、SOAP文本协议性能差但跨语言好2010sThriftFacebook、Dubbo阿里二进制协议性能跃升2015gRPCGoogleHTTP/2 Protobuf事实标准国内tRPC腾讯、Kitex字节业务定制 多协议互通六、与其他通信方式的对比6.1 RPC vs RESTREST 是资源导向的设计风格基于 HTTP 语义RPC 是动作导向的远程调用。对外暴露的开放 API建议 REST生态、调试方便内部微服务通信建议 RPC性能、强契约。6.2 RPC vs 消息队列MQRPC同步、点对点MQ异步、解耦、广播。复杂业务往往两者结合核心链路同步 RPC旁路通知用 MQ。6.3 RPC vs GraphQLRPC客户端直接调用具体方法GraphQL客户端按需查询字段。GraphQL 适合面向多端 BFF 场景RPC 适合内部微服务。七、一个最小 RPC 示例伪代码服务端typeCalculatorstruct{}func(c*Calculator)Add(req AddReq)AddResp{returnAddResp{Sum:req.Areq.B}}server:rpc.NewServer()server.Register(Calculator{})server.Listen(:8000)客户端client:rpc.Dial(127.0.0.1:8000)deferclient.Close()resp,err:client.Call(Calculator.Add,AddReq{A:1,B:2})fmt.Println(resp.Sum)// 3看起来就像本地调用但底层经历了序列化、网络、反序列化等一系列步骤。八、RPC 不是银弹引入 RPC 的代价网络不可靠超时、抖动、断连必须处理延迟变大本地调用 ns 级RPC 至少 ms 级可观测性复杂跨进程调用要做链路追踪版本兼容服务升级要考虑客户端旧版本。经典理论Fallacies of Distributed Computing分布式计算谬误告诫我们网络不是 100% 可靠。九、什么时候不该用 RPC单进程内直接函数调用极高吞吐 异步处理用 MQ数据流式传输考虑 gRPC streaming 或专用协议与浏览器直连用 REST/WebSocket 更兼容。十、小结RPC 让远程调用像本地调用一样简单RPC 框架解决IDL、序列化、传输、治理、观测内部微服务首选 RPC对外开放接口可用 REST享受便利的同时要尊重网络不可靠的事实。下一篇我们将深入 RPC 的骨架IDL 与 Protobuf。