前言RPC 框架如 gRPC、Thrift、Dubbo、RESTful HTTP 调用虽非严格 RPC但属远程调用的一种、RMIJava 专属远程对象调用的异同是社么这是一个很经典的后端技术问题。简单来说它们的共同目标是“让调用远程服务像调用本地函数一样”但实现方式、协议、序列化、跨语言能力以及生态支持上差异很大。下面为你详细对比它们的相同点和核心不同点。一、共同点屏蔽网络通信复杂性开发者不需要手动编写Socket连接、处理数据包拆包粘包、管理连接池等底层细节。基于请求-响应模型调用方发送请求服务方处理并返回结果RESTful中也可以是资源操作但本质上还是请求-响应。解决分布式通信问题都用于微服务、SOA架构下不同进程甚至不同机器间的交互。二、核心不同点为了清晰对比我们先简单区分一下这几个概念RPC远程过程调用是一种思想/协议目标是直接调用远程函数。gRPC、Thrift、Dubbo是其具体实现框架。RESTful HTTP是一种架构风格基于HTTP协议操作资源GET/POST/PUT/DELETE不是严格意义上的RPC。RMI是Java原生的RPC实现。下面从几个关键维度对比它们维度gRPCThriftDubboRESTful HTTPRMI协议HTTP/2二进制TCP可定制TCP默认或HTTPHTTP/1.1或HTTP/2文本二进制JRMPJava Remote Method Protocol基于TCP序列化Protobuf强类型、高性能Thrift IDL可插拔默认Binary/CompactHessian2默认Java友好JSON/XML/Text文本型自描述Java原生序列化效率低且不安全IDL接口定义语言必须.proto文件必须.thrift文件可选可Java接口直接定义无标准IDL常用OpenAPI/Swagger文档纯Java接口不需要单独IDL跨语言能力优秀主流语言全支持优秀支持语言极多一般主要Java生态对Go/Python等有支持但非一等公民完美HTTPJSON任何语言都能调差仅Java且依赖JVM调用风格面向远程函数/方法面向远程函数/服务面向远程接口/服务面向资源URI 动词面向远程Java对象方法典型场景微服务间高性能调用、多语言混合、流式数据大规模跨语言RPC、需要极致性能和紧凑编码阿里巴巴生态、Java为主的高性能内部调用、服务治理对外API、浏览器/移动端调用、简单系统集成遗留Java系统、全Java环境的内网调用基本已被淘汰流式支持原生支持单/双/客户端/服务端流支持但不如gRPC自然有限支持可通过Streaming方式不支持原生流式可用WebSocket或分块传输不支持服务治理需配合治理系统如Istio基本需自建或配合服务发现内置负载均衡、熔断、限流、注册中心Zookeeper/Nacos需额外网关/中间件如Spring Cloud Gateway几乎无三、详细解读与选型建议1. gRPC谷歌出品高性能微服务标杆原理基于HTTP/2多路复用 Protobuf序列化。客户端生成Stub像本地调用一样发起请求。优势性能极高Protobuf二进制编码体积小、速度快。全双工流式支持服务器推送、聊天类场景。强类型契约.proto文件就是跨团队的API合同。劣势.proto文件管理有版本维护成本。HTTP/2排查问题不如普通HTTP直观例如抓包需要理解帧。浏览器原生支持差需gRPC-Web代理。适用内部高性能微服务、多语言混合团队、IoT设备通信。2. ThriftApache顶级项目极致灵活原理代码生成器 多种传输层/协议层组合可插拔。优势支持语言最多超过gRPC。序列化效率极高可选Compact比Protobuf更小。传输层可选TCP、HTTP、甚至内存通道。劣势框架较重学习曲线陡峭。社区活跃度低于gRPC文档偏老。服务治理需自建。适用需要极高吞吐、极小编码如搜索引擎内部调用、已经深度使用Thrift的老项目。3. Dubbo阿里巴巴Java生态首选原理基于NettyNIO的TCP长连接 Hessian2序列化 SPI扩展机制。优势开箱即用的服务治理注册中心、负载均衡、集群容错、路由规则比gRPC成熟。对Java开发者友好纯注解/XML配置无需IDL也能用Protobuf。性能优异接近gRPC。劣势跨语言能力弱非Java语言客户端成熟度低。协议相对封闭Hessian2跨语言兼容性一般。适用全栈Java微服务、需要强大服务治理能力如阿里、携程内部。4. RESTful HTTP万金油简单但不够“RPC”原理HTTP 资源语义GET /users/123 而不是 UserService.getUser(123)。优势极简浏览器、curl随意调用。统一接口标准HTTP方法、状态码、缓存语义。无状态、可缓存适合CDN和网关层。劣势低效JSON文本序列化慢HTTP/1.1头部冗余。无强类型约束全靠文档或JSON Schema约定。无法原生表达“方法调用”需开发者人为映射如POST /orders/123/cancel 表示取消订单。适用对外API开放平台、前端-后端交互、简单系统集成。5. RMIJava历史的遗迹原理Java原生远程对象代理通过JRMP协议传输序列化对象。优势无需任何框架Java标准库自带真正的对象引用传递。劣势Java序列化慢、不安全、版本不兼容。无法跨语言。防火墙困难动态端口。维护复杂几乎没有现代项目使用已被各种RPC框架替代。适用仅供学习理解Java远程调用原理不推荐用于生产。四、一句话总结要跨语言 高性能 流式→gRPC要极高性能 极度紧凑编码 语言极其多样→Thrift纯Java 要服务治理注册中心/熔断→Dubbo对外API、浏览器/移动端、简单性优先→RESTful HTTP除非维护20年前的Java系统否则忘掉RMI最后提醒RESTful不是RPC它走的是资源化设计而RPC强调直接调用远程函数。两者在微服务中经常并存内部用gRPC/Dubbo高性能通信边缘网关转成REST给前端调用。
远程调用是什么
发布时间：2026/6/1 17:25:28
前言RPC 框架如 gRPC、Thrift、Dubbo、RESTful HTTP 调用虽非严格 RPC但属远程调用的一种、RMIJava 专属远程对象调用的异同是社么这是一个很经典的后端技术问题。简单来说它们的共同目标是“让调用远程服务像调用本地函数一样”但实现方式、协议、序列化、跨语言能力以及生态支持上差异很大。下面为你详细对比它们的相同点和核心不同点。一、共同点屏蔽网络通信复杂性开发者不需要手动编写Socket连接、处理数据包拆包粘包、管理连接池等底层细节。基于请求-响应模型调用方发送请求服务方处理并返回结果RESTful中也可以是资源操作但本质上还是请求-响应。解决分布式通信问题都用于微服务、SOA架构下不同进程甚至不同机器间的交互。二、核心不同点为了清晰对比我们先简单区分一下这几个概念RPC远程过程调用是一种思想/协议目标是直接调用远程函数。gRPC、Thrift、Dubbo是其具体实现框架。RESTful HTTP是一种架构风格基于HTTP协议操作资源GET/POST/PUT/DELETE不是严格意义上的RPC。RMI是Java原生的RPC实现。下面从几个关键维度对比它们维度gRPCThriftDubboRESTful HTTPRMI协议HTTP/2二进制TCP可定制TCP默认或HTTPHTTP/1.1或HTTP/2文本二进制JRMPJava Remote Method Protocol基于TCP序列化Protobuf强类型、高性能Thrift IDL可插拔默认Binary/CompactHessian2默认Java友好JSON/XML/Text文本型自描述Java原生序列化效率低且不安全IDL接口定义语言必须.proto文件必须.thrift文件可选可Java接口直接定义无标准IDL常用OpenAPI/Swagger文档纯Java接口不需要单独IDL跨语言能力优秀主流语言全支持优秀支持语言极多一般主要Java生态对Go/Python等有支持但非一等公民完美HTTPJSON任何语言都能调差仅Java且依赖JVM调用风格面向远程函数/方法面向远程函数/服务面向远程接口/服务面向资源URI 动词面向远程Java对象方法典型场景微服务间高性能调用、多语言混合、流式数据大规模跨语言RPC、需要极致性能和紧凑编码阿里巴巴生态、Java为主的高性能内部调用、服务治理对外API、浏览器/移动端调用、简单系统集成遗留Java系统、全Java环境的内网调用基本已被淘汰流式支持原生支持单/双/客户端/服务端流支持但不如gRPC自然有限支持可通过Streaming方式不支持原生流式可用WebSocket或分块传输不支持服务治理需配合治理系统如Istio基本需自建或配合服务发现内置负载均衡、熔断、限流、注册中心Zookeeper/Nacos需额外网关/中间件如Spring Cloud Gateway几乎无三、详细解读与选型建议1. gRPC谷歌出品高性能微服务标杆原理基于HTTP/2多路复用 Protobuf序列化。客户端生成Stub像本地调用一样发起请求。优势性能极高Protobuf二进制编码体积小、速度快。全双工流式支持服务器推送、聊天类场景。强类型契约.proto文件就是跨团队的API合同。劣势.proto文件管理有版本维护成本。HTTP/2排查问题不如普通HTTP直观例如抓包需要理解帧。浏览器原生支持差需gRPC-Web代理。适用内部高性能微服务、多语言混合团队、IoT设备通信。2. ThriftApache顶级项目极致灵活原理代码生成器 多种传输层/协议层组合可插拔。优势支持语言最多超过gRPC。序列化效率极高可选Compact比Protobuf更小。传输层可选TCP、HTTP、甚至内存通道。劣势框架较重学习曲线陡峭。社区活跃度低于gRPC文档偏老。服务治理需自建。适用需要极高吞吐、极小编码如搜索引擎内部调用、已经深度使用Thrift的老项目。3. Dubbo阿里巴巴Java生态首选原理基于NettyNIO的TCP长连接 Hessian2序列化 SPI扩展机制。优势开箱即用的服务治理注册中心、负载均衡、集群容错、路由规则比gRPC成熟。对Java开发者友好纯注解/XML配置无需IDL也能用Protobuf。性能优异接近gRPC。劣势跨语言能力弱非Java语言客户端成熟度低。协议相对封闭Hessian2跨语言兼容性一般。适用全栈Java微服务、需要强大服务治理能力如阿里、携程内部。4. RESTful HTTP万金油简单但不够“RPC”原理HTTP 资源语义GET /users/123 而不是 UserService.getUser(123)。优势极简浏览器、curl随意调用。统一接口标准HTTP方法、状态码、缓存语义。无状态、可缓存适合CDN和网关层。劣势低效JSON文本序列化慢HTTP/1.1头部冗余。无强类型约束全靠文档或JSON Schema约定。无法原生表达“方法调用”需开发者人为映射如POST /orders/123/cancel 表示取消订单。适用对外API开放平台、前端-后端交互、简单系统集成。5. RMIJava历史的遗迹原理Java原生远程对象代理通过JRMP协议传输序列化对象。优势无需任何框架Java标准库自带真正的对象引用传递。劣势Java序列化慢、不安全、版本不兼容。无法跨语言。防火墙困难动态端口。维护复杂几乎没有现代项目使用已被各种RPC框架替代。适用仅供学习理解Java远程调用原理不推荐用于生产。四、一句话总结要跨语言 高性能 流式→gRPC要极高性能 极度紧凑编码 语言极其多样→Thrift纯Java 要服务治理注册中心/熔断→Dubbo对外API、浏览器/移动端、简单性优先→RESTful HTTP除非维护20年前的Java系统否则忘掉RMI最后提醒RESTful不是RPC它走的是资源化设计而RPC强调直接调用远程函数。两者在微服务中经常并存内部用gRPC/Dubbo高性能通信边缘网关转成REST给前端调用。
)
