什么是RPCRPC 全称 Remote Procedure Call即远程过程调用。它的核心目标非常简单让开发者调用远程机器上的函数/方法就像调用本地函数一样简单无需关注底层的网络连接、数据传输、序列化与反序列化等繁琐细节[1]。举个通俗的例子你在自己的电脑客户端上写了一段代码想调用另一台服务器服务端上的“计算两数之和”的方法RPC 框架会帮你屏蔽所有网络交互细节你只需要像写add(1,2)这样的本地调用代码就能拿到远程方法的执行结果[5]。这里要明确一个关键RPC 不是一种具体的技术而是一种通信协议/调用规范。不同的 RPC 框架如 Dubbo、gRPC都是基于这个规范实现的具体工具底层可能采用不同的传输协议TCP、HTTP/2和序列化方式Protobuf、JSON[1]。RPC 核心原理RPC 的本质是“跨网络的函数调用”其工作流程看似复杂但拆解后只有11个核心步骤核心是通过“存根Stub”实现远程通信的透明化[1]。我们以“客户端调用服务端 add 方法”为例一步步拆解客户端Client以本地调用的方式调用远程服务的接口比如rpc_add(1,2)客户端存根Client Stub/Proxy接收调用请求负责将调用信息方法名、参数、请求ID等打包成可网络传输的消息体并将消息体序列化为二进制数据[5]客户端通过底层网络传输基于 TCP、HTTP/2 等协议将二进制消息发送到服务端[4]服务端Server接收网络消息将消息传递给服务端存根Server Stub/Skeleton[1]服务端存根对接收的二进制消息进行反序列化解析出方法名、参数等核心信息[5]服务端存根根据解析结果调用服务端本地的真实方法比如add(1,2)[1]服务端本地方法执行完成得到结果比如 3服务端存根将执行结果序列化打包成二进制消息[5]服务端通过网络将二进制响应消息发送回客户端[1]客户端存根接收响应消息对其进行反序列化解析出最终结果[5]客户端存根将结果返回给客户端业务代码一次远程调用完成[1]。总结RPC 框架的核心价值就是将上述步骤中“序列化、网络传输、反序列化”等底层操作全部封装让开发者完全感知不到“远程”的存在专注于业务逻辑开发[4]。RPC 核心组件一个完整的 RPC 系统无论采用哪种框架都离不开以下5个核心组件它们协同工作实现远程调用的透明化和高效性[2]1. 客户端Client发起远程调用的应用程序也就是“调用方”。客户端只需要调用远程服务的接口无需关心底层通信细节就像调用本地方法一样[5]。2. 客户端存根Client StubRPC 框架在客户端生成的动态代理或自动生成的代码相当于客户端的“通信助手”[1]。它的核心职责是接收客户端的调用请求、序列化请求数据、发起网络请求、接收服务端响应、反序列化响应数据并将结果返回给客户端[5]。3. 服务端Server提供真实业务逻辑实现的服务提供者也就是“被调用方”。服务端启动后会暴露自己的服务接口并等待客户端的调用请求[5]。4. 服务端存根Server StubRPC 框架在服务端生成的动态代理相当于服务端的“通信助手”[1]。它的核心职责是接收客户端的网络请求、反序列化请求数据、调用本地业务方法、序列化方法执行结果并将响应消息发送回客户端[5]。5. 注册中心Registry可选但几乎必备的组件核心作用是“服务注册与发现”[2]。服务端启动时会向注册中心注册自己的元数据服务名、IP地址、端口、健康状态等客户端启动时会从注册中心订阅所需的服务获取服务端的地址列表从而实现动态寻址[1]。常见的注册中心有 Nacos、Zookeeper、Consul 等[2]。RPC 和 HTTP到底该选哪个很多新手都会有这个疑问HTTP 也是跨网络通信为什么还要用 RPC其实两者没有绝对的优劣核心区别在于“适用场景”我们从3个核心维度对比一看就懂[2][3]对比维度RPCHTTPRESTful核心范式动作/过程调用远程函数资源操作资源的状态性能高采用二进制序列化、TCP协议开销小、延迟低中等采用文本序列化、HTTP协议开销大、延迟较高易用性需集成框架如 Dubbo、gRPC有一定学习成本无门槛基于 HTTP 协议可直接通过 Postman、curl 调用服务治理内置完善负载均衡、容错、限流、监控等需自行实现或集成第三方组件适用场景分布式系统内部服务调用微服务、分布式计算跨系统、跨语言的外部接口调用如前后端交互、第三方接口简单总结内部服务通信优先选 RPC追求高性能、强服务治理外部接口暴露优先选 HTTP追求通用性、无门槛。比如电商系统中订单服务调用支付服务用 RPC支付服务暴露接口给第三方平台用 HTTP。主流 RPC 框架对比目前主流的 RPC 框架各有侧重选择时需结合自身技术栈、业务需求性能、跨语言、服务治理来决定。以下是4款最常用框架的核心对比帮你快速选型[2]Dubbo阿里开源的 RPC 框架核心定位是“高性能、强服务治理”专为 Java 技术栈的大规模分布式系统设计[2]。核心优势服务治理生态完善内置监控、链路追踪、限流熔断等性能优异默认 Dubbo 协议 Hessian2 序列化国产化适配友好集成 Nacos、Sentinel 等国产中间件国内企业落地案例极多阿里、京东、美团[2]。局限性跨语言支持较弱3.x 版本通过 Triple 协议优化但核心生态仍围绕 Java[2]。适用场景纯 Java 技术栈的微服务架构、对服务治理要求高的大规模分布式系统[2]。gRPC谷歌开源的跨语言 RPC 框架基于 HTTP/2 和 Protobuf 协议核心定位是“跨语言互通、云原生友好”[2]。核心优势跨语言能力极强原生支持 Java、Go、C、Python 等多语言基于 HTTP/2 实现多路复用、头部压缩性能优异契约优先通过 Protobuf 定义接口确保多语言接口一致性[2]。局限性服务治理能力较弱需依赖第三方组件实现负载均衡、容错等功能[2]。适用场景跨语言通信、云原生场景、需要高吞吐量的分布式系统[2]。Spring Cloud OpenFeignSpring 生态专属的 RPC 框架本质是基于 HTTP 的声明式调用依托 Spring Boot 实现“零侵入”开发[2]。核心优势易用性极高注解驱动无需复杂配置与 Spring Cloud 生态无缝集成支持负载均衡、容错等功能[2]。局限性仅支持 Java 语言基于 HTTP/1.1 协议性能中等[2]。适用场景Spring Cloud 微服务架构、追求快速开发的 Java 项目[2]。ThriftFacebook 开源的跨语言 RPC 框架核心定位是“高性能、轻量级”[2]。核心优势性能极高采用自定义二进制协议序列化开销极小跨语言支持完善轻量级、无过多依赖[2]。局限性服务治理能力薄弱需自行实现负载均衡、容错等功能易用性中等[2]。适用场景高性能跨语言通信、内部系统调用对性能要求极高对服务治理要求低[2]。RPC 进阶特性除了基础的远程调用主流 RPC 框架还提供了一些进阶特性用于应对复杂的分布式场景[1][6]异步调用客户端发起调用后不阻塞等待结果而是立即返回一个 Future/Promise 对象或注册一个回调函数。当结果准备好时通过回调函数通知客户端可大幅提高资源利用率和系统吞吐量[1]。流式 RPC允许在单个连接上建立双向的、持续的数据流。客户端可以发送请求流服务端可以返回响应流或建立双向流非常适合文件上传/下载、实时消息推送、聊天等场景[1]。HTTP/2 的多路复用特性是实现流式 RPC 的关键如 gRPC Stream[1]。传输加密使用 TLS/SSL 对网络传输的数据进行加密防止数据被窃听和篡改保障通信安全[1]。负载均衡与容错客户端从注册中心获取服务端地址列表后通过随机、轮询、一致性哈希等策略选择一个服务端发起调用当某个服务端故障时自动切换到其他健康节点确保调用可靠性[2]。RPC 到底能解决什么问题看到这里相信你已经对 RPC 有了完整的认知。我们再回到核心RPC 不是“花里胡哨”的技术而是为了解决分布式系统中“服务间高效通信”的痛点而生[3]。它的核心价值的是透明化远程调用屏蔽底层细节、高性能通信适配分布式场景、完善的服务治理降低分布式系统复杂度[2]。