RPC简介及框架选择，RPC与REST的区别

最新推荐文章于 2025-11-04 17:03:27 发布

原创最新推荐文章于 2025-11-04 17:03:27 发布 · 1.9k 阅读

7 ·

CC 4.0 BY-SA版权

架构设计同时被 2 个专栏收录

14 篇文章

订阅专栏

设计模式

4 篇文章

订阅专栏

一、基础概念

HTTP协议

http协议是基于tcp协议的，tcp协议是流式协议，包头部分可以通过多出的\r\n来分界，包体部分如何分界呢？这是协议本身要解决的问题。目前一般有两种方式，第一种方式就是在包头中有个content-Length字段，这个字段的值的大小标识了POST数据的长度，服务器收到一个数据包后，先从包头解析出这个字段的值，再根据这个值去读取相应长度的作为http协议的包体数据。
浏览器connect 80端口

RESTful API (http+json)

理解RESTful架构 - 阮一峰
 REST 架构该怎么生动地理解？ - 覃超的回答 - 知乎

网站即软件，而且是一种新型的软件，这种"互联网软件"采用客户端/服务器模式，建立在分布式体系上，通过互联网通信，具有高延时（high latency）、高并发等特点。
　　它首次出现在 2000 年 Roy Fielding 的博士论文中，他是 HTTP 规范的主要编写者之一。Representational State Transfer，翻译是”表现层状态转化”，通俗来讲就是：资源在网络中以某种表现形式进行状态转移。

总结一下什么是RESTful架构：
　　（1）每一个URI代表一种资源；
　　（2）客户端和服务器之间，传递这种资源的某种表现层，比如用JSON，XML，JPEG等；
　　（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。
用HTTP协议里的动词来实现资源的添加，修改，删除等操作。即通过HTTP动词来实现资源的状态扭转：
　　GET 用来获取资源，
　　POST 用来新建资源（也可以用于更新资源），
　　PUT 用来更新资源，
　　DELETE 用来删除资源。

RPC的核心并不在于使用什么协议。RPC的目的是让你在本地调用远程的方法，而对你来说这个调用是透明的，你并不知道这个调用的方法是部署哪里。通过RPC能解耦服务，这才是使用RPC的真正目的。RPC的原理主要用到了动态代理模式，至于http协议，只是传输协议而已。简单的实现可以参考spring remoting，复杂的实现可以参考dubbo。

简单的说，

RPC就是从一台机器（客户端）上通过参数传递的方式调用另一台机器（服务器）上的一个函数或方法（可以统称为服务）并得到返回的结果。
RPC 会隐藏底层的通讯细节（不需要直接处理Socket通讯或Http通讯） RPC 是一个请求响应模型。
客户端发起请求，服务器返回响应（类似于Http的工作方式） RPC 在使用形式上像调用本地函数（或方法）一样去调用远程的函数（或方法）。

RPC通信过程

RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式（TCP或者UDP）、序列化方式（XML/JSON/二进制）和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

RPC架构简单理解
 远程过程调用(RPC)详解

默认socket通信。本地机器的RPC框架反序列化出执行结果，函数return这个结果

RPC 工作原理

RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

任何 RPC 客户机-服务器程序的重要实体都包括 IDL 文件（接口定义文件）、客户机 stub、服务器 stub 以及由客户机和服务器程序共用的头文件。客户机和服务器 stub 使用 RPC 运行时库通信。RPC 运行时库提供一套标准的运行时例程来支持 RPC 应用程序。

使用 RPC 编程是在分布式环境中运行的客户机和服务器应用程序之间进行可靠通信的最强大、最高效的方法之一。

RPC通信过程

RPC 客户机-服务器交互方式

图 1 说明客户机和服务器通过网络完成 RPC 调用的方式。
图 1. 基本的 RPC 客户机-服务器交互

当客户机应用程序发出远程过程调用时，在两端的 RPC 运行时库的帮助下，客户机 stub 把与这个调用相关的信息通过网络传递给服务器 stub，见图 1。服务器 stub 把所需的信息提供给服务器应用程序。服务器应用程序执行远程过程调用，然后使用 RPC 运行时库通过服务器 stub 把结果传递给客户机 stub。最后，客户机 stub 把结果返回给客户机应用程序。stub 作为应用程序和 RPC 运行时之间的接口，以两者可以理解的格式交换信息。

在开发客户机-服务器应用程序时，客户机和服务器首先应该就要交换的过程的声明和定义达成一致。这就是接口起的作用，接口维护客户机和服务器都认可的所有过程声明和数据类型。

我们把所有共用的声明和数据类型放在接口定义语言 (IDL) 文件中，客户机和服务器将共享这个文件。我们在 IDL 文件中使用 UUID，以使之在网络上所有其他接口中保持惟一。UUID 是一个惟一的随机数，是由 uuidgen 实用程序使用网络地址信息和系统时间生成的。

开发 RPC 客户机-服务器应用程序

图 2 说明在开发简单的客户机-服务器分布式应用程序时涉及的步骤。
图 2. 开发 RPC 客户机-服务器应用程序

开发RPC应用程序涉及的步骤

用 IDL 编译器编译 IDL 文件，生成客户机和服务器 stub 对象文件以及头文件。
这个头文件包含共用的定义和过程。
stub 文件在远程过程调用期间作为应用程序和 RPC 运行时库之间的接口。
头文件包含在客户机和服务器源代码文件中。
用 C 编译器分别编译客户机和服务器文件，生成对象文件。
客户机对象文件和客户机 stub 文件与 RPC 运行时库链接，生成客户机可执行程序。
以相似的方式生成服务器可执行程序，见图 2。

简单的RPC代码实现

package Server;

public interface EchoService {
    String echo(String ping);

}


package Server;

public class EchoServiceImpl implements EchoService{

    @Override
    public String echo(String ping) {
        // TODO Auto-generated method stub
        return ping !=null?ping+"--> I am ok.":"I am bad.";
    } 

}



package Exporter;

import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.lang.reflect.Method;
import java.net.InetSocketAddress;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.concurrent.Executor;
import java.util.concurrent.Executors;

/**
 * RPC服务端发布者
 * 作为服务端，监听客户端的TCP连接，接收到新的客户端连接之后，将其封装成Task，由线程池执行
 * 将客户端发送的码流反序列化成对象，反射调用服务实现者，获取执行结果
 * 将执行结果对象发序列化，通过Socket发送给客户端
 * 远程调用完成之后，释放Socket等连接资源，防止句柄泄露
 * @author Administrator
 *
 */
public class RpcExporter {
    //创建一个可重用固定线程数的线程池
    //Runtime.getRuntime().availableProcessors()返回虚拟机可用的处理器数量
    static Executor executor=Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
    
    public static void exporter(String hostname,int port) throws IOException {
        //创建一个监听特定端口的Serversocket,负责接收客户连接请求
        ServerSocket server = new ServerSocket();
        //绑定主机名端口号
        server.bind(new InetSocketAddress(hostname,port));
        try{
        while(true)
        {
            executor.execute(new ExporterTask(server.accept()));
        }
        }finally
        {
            server.close();
        }
    }
    
    private static class ExporterTask implements Runnable{

        Socket client=null;
        public ExporterTask(Socket client){
            this.client=client;
        }
        @Override
        public void run() {
            // TODO Auto-generated method stub
            ObjectInputStream input=null;
            ObjectOutputStream output=null;
            try{
                //获取输入流
                input=new ObjectInputStream(client.getInputStream());
                //获取调用的接口名
                String interfaceName = input.readUTF();
                //加载接口
                Class<?> service = Class.forName(interfaceName);
                //获取调用的方法名
                String methodName = input.readUTF();
                //获取方法返回类型
                Class<?>[] ParameterTypes = (Class<?>[]) input.readObject();
                //获取参数
                Object[] arguments = (Object[]) input.readObject();
                //通过反射获取方法
                Method method = service.getMethod(methodName, ParameterTypes);
                //通过反射调用方法
                Object result = method.invoke(service.newInstance(), arguments);
                output = new ObjectOutputStream(client.getOutputStream());
                output.writeObject(result);
            }catch(Exception e){
                e.printStackTrace();
            }
            finally{
                if(output != null)
                try{
                    output.close();
                }catch ( IOException e){
                    e.printStackTrace();
                }
                
                if(input !=null)
                try{
                    input.close();
                }catch(IOException e){
                    e.printStackTrace();
                }
                
                if(client != null)
                    try{
                        client.close();
                    }catch (IOException e){
                        e.printStackTrace();
                    }
        }
        
    }

}
}




package Client;

import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.net.InetSocketAddress;
import java.net.Socket;
/**
 *本地服务代理
 *将本地的接口调用转换成JDK的动态代理，在动态代理中实现接口的远程调用
 *创建Socket客户端，根据指定地址连接远程服务提供者
 *将远程服务调用所需要的接口类，方法名，参数列表等编码参数发送给服务提供者
 *同步阻塞等待服务端返回应答，获取应答之后返回
 * @author Administrator
 *
 * @param <S>
 */
public class RpcImporter<S> {
    @SuppressWarnings("unchecked")
    public S importer(final Class<?> serviceClass,final InetSocketAddress addr)
    {
        return (S) Proxy.newProxyInstance(serviceClass.getClassLoader(), new  Class<?>[] {serviceClass.getInterfaces()[0]}, new InvocationHandler() {
            
            @Override
            public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                // TODO Auto-generated method stub
                Socket socket =null;
                ObjectOutputStream output = null;
                ObjectInputStream input = null;
                try{
                    socket = new Socket();
                    socket.connect(addr);
                    //将远程服务调用所需要的接口类，方法名，参数列表等编码参数发送给服务提供者
                    output = new ObjectOutputStream(socket.getOutputStream());
                    output.writeUTF(serviceClass.getName());
                    output.writeUTF(method.getName());
                    output.writeObject(method.getParameterTypes());
                    output.writeObject(args);
                    //同步阻塞等待服务端返回应答，获取应答之后返回
                    input= new ObjectInputStream(socket.getInputStream());
                
                return input.readObject();
                }
                finally{
                    if(socket != null)
                        socket.close();
                    
                    if(output != null)
                        output.close();
                    if(input != null)
                        input.close();
                }
            }
        });
    }
}



package test;

import java.net.InetSocketAddress;

import Client.RpcImporter;
import Exporter.RpcExporter;
import Server.EchoService;
import Server.EchoServiceImpl;

public class run {

    public static void main(String[] args) {
        // TODO Auto-generated method stub

        //创建异步发布服务端的线程并启动，用于接受PRC客户端的请求，根据请求参数调用服务实现类，返回结果给客户端
        new Thread(new Runnable() {
            
            @Override
            public void run() {
                // TODO Auto-generated method stub
                try{
                    RpcExporter.exporter("localhost", 8088);
                }catch (Exception e){
                    e.printStackTrace();
                }
            }
        }).start();
        //创建客户端服务代理类，构造RPC求情参数，发起RPC调用
        RpcImporter<EchoService> importer=new RpcImporter<EchoService>();
        EchoService echo = importer.importer(EchoServiceImpl.class, new InetSocketAddress("localhost",8088));
        System.out.println(echo.echo("Are u ok?"));
    }

}

RPC和restful api对比

* REST vs JSON-RPC? - stackoverflow
既然有http 请求，为什么还要用rpc调用？ - 手不要乱摸的回答 - 知乎
 为什么需要RPC，而不是简单的HTTP接口

REST是一种设计风格，它的很多思维方式与RPC是完全冲突的。 RPC的思想是把本地函数映射到API，也就是说一个API对应的是一个function，我本地有一个getAllUsers，远程也能通过某种约定的协议来调用这个getAllUsers。至于这个协议是Socket、是HTTP还是别的什么并不重要； RPC中的主体都是动作，是个动词，表示我要做什么。而REST则不然，它的URL主体是资源，是个名词。而且也仅支持HTTP协议，规定了使用HTTP Method表达本次要做的动作，类型一般也不超过那四五种。这些动作表达了对资源仅有的几种转化方式。
RPC的根本问题是耦合。RPC客户端以多种方式与服务实现紧密耦合，并且很难在不中断客户端的情况下更改服务实现。RPC更偏向内部调用，REST更偏向外部调用。

Web 服务应该算是 RPC 的一个子集，理论上 RPC 能实现的功能，用 Web 服务也能实现，甚至很多 RPC 框架选用 HTTP 协议作为传输层。
现在很多网站的 API 都是以 HTTP 服务的形式提供的，这也算是 RPC 的一种形式。

区别主要在这 2 个东西设计的出发点不太一样：

HTTP 是面向浏览器设计的应用层协议，操作的核心在资源。我们更多的用 Web 服务在做网站。
RPC 是为了在像在本地调用一个函数那样调用远程的代码而设计的，所以更关注减少本地调用和远程调用的差异，像 SOAP(简单对象访问协议) 这种东西是可以把对象当参数传的。

我们讨论 RPC 和 Web 的区别，其实是在谈论 2 个东西：序列化协议和传输协议。序列化协议比如常见的 XML，JSON 和比较现代的 Protocol Buffers、Thrift。传输协议比如 TCP、UDP 以及更高层的 HTTP 1.1、HTTP 2.0。

一般我们考虑用 RPC 而不是 HTTP 构建自己的服务，通常是考虑到下面的因素：

接口是否需要 Schema 约束
是否需要更高效的传输协议（TCP，HTTP 2.0）
是否对数据包的大小非常敏感

比如 HTTP 是基于文本的协议，头部有非常多冗余（对于 RPC 服务而言）。HTTP 中我们用的最多就是 RESTful ，而 RESTful 是个弱 Schema 约束，大家通过文档沟通，但是如果我就是不在实现的时候对接口文档约定的参数做检查，你也不能把我怎么样。这个时候 Thrift 这种序列化协议的优势就体现出来了，由于 Schema 的存在，可以保证服务端接受的参数和 Schema 保持一致。

RPC框架

谁能用通俗的语言解释一下什么是 RPC 框架？ - 洪春涛的回答 - 知乎
 常用的跨语言通信方案
 深入浅出 RPC - 深入篇

Call ID映射。我们怎么告诉远程机器我们要调用Multiply，而不是Add或者FooBar呢？在本地调用中，函数体是直接通过函数指针来指定的，我们调用Multiply，编译器就自动帮我们调用它相应的函数指针。但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。所以，在RPC中，所有的函数都必须有自己的一个ID。这个ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，必须附上这个ID。然后我们还需要在客户端和服务端分别维护一个 {函数 <--> Call ID} 的对应表。两者的表不一定需要完全相同，但相同的函数对应的Call ID必须相同。当客户端需要进行远程调用时，它就查一下这个表，找出相应的Call ID，然后把它传给服务端，服务端也通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
序列化和反序列化。客户端怎么把参数值传给远程的函数呢？在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。甚至有时候客户端和服务端使用的都不是同一种语言（比如服务端用C++，客户端用Java或者Python）。这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。这个过程叫序列化和反序列化。同理，从服务端返回的值也需要序列化反序列化的过程。
网络传输。远程调用往往用在网络上，客户端和服务端是通过网络连接的。所有的数据都需要通过网络传输，因此就需要有一个网络传输层。网络传输层需要把Call ID和序列化后的参数字节流传给服务端，然后再把序列化后的调用结果传回客户端。只要能完成这两者的，都可以作为传输层使用。因此，它所使用的协议其实是不限的，能完成传输就行。尽管大部分RPC框架都使用TCP协议，但其实UDP也可以，而gRPC干脆就用了HTTP2。Java的Netty也属于这层的东西。

目前有很多Java的RPC框架，有基于Json的，有基于XML，也有基于二进制对象的。

论复杂度，RPC框架肯定是高于简单的HTTP接口的。但毋庸置疑，HTTP接口由于受限于HTTP协议，需要带HTTP请求头，导致传输起来效率或者说安全性不如RPC

RPC框架封装

常用RPC框架

支持Java最多，golang

Netty - Netty框架不局限于RPC，更多的是作为一种网络协议的实现框架，比如HTTP，由于RPC需要高效的网络通信，就可能选择以Netty作为基础。
brpc是一个基于protobuf接口的RPC框架，在百度内部称为“baidu-rpc”，它囊括了百度内部所有RPC协议，并支持多种第三方协议，从目前的性能测试数据来看，brpc的性能领跑于其他同类RPC产品。
Dubbo是Alibaba开发的一个RPC框架，远程接口基于Java Interface, 依托于Spring框架。
gRPC的Java实现的底层网络库是基于Netty开发而来，其Go实现是基于net库。
Thrift是Apache的一个项目(http://thrift.apache.org)，前身是Facebook开发的一个RPC框架，采用thrift作为IDL (Interface description language)。
jsonrpc

JSON-RPC

python web接口实现（restful方式、jsonrpc方式）
区块链项目中用的较多？资料不是很多
JSON-RPC是一种序列化协议。JSON 是 JS 对象的字符串表示法，它使用文本表示一个 JS 对象的信息，本质是一个字符串。
非常简单，方便，速度慢
相关Python 包(直接集成到flask和django)
Flask-JSONRPC,django-json-rpc；jsonrpcserver,jsonrpcclient

thrift

Python RPC 之 Thrift
Facebook开源的跨语言RPC框架。

gRPC

gRPC 官方文档中文版
 深入了解gRPC协议-知乎

tensorflow分布式与tensorflow serving底层通信都是是用的grpc
序列化用protobuf，通信使用http2
latest Google APIs will have gRPC versions of their interfaces, letting you easily build Google functionality into your applications.
支持 C, C++, Node.js, Python, Ruby, Objective-C,PHP and C#

HTTP2

一文读懂 HTTP2 特性 - 又拍云的文章 - 知乎
 HTTP/2 和 HTTP/1 速度对比
 http://www.http2demo.io/
HTTP/2
HTTP/2 是 HTTP 协议自 1999 年 HTTP 1.1 发布后的首个更新，主要基于 SPDY 协议。
HTTP/2的主要目标是通过启用完整请求和响应复用来减少延迟，通过有效压缩HTTP头字段来最大限度地降低协议开销，并添加对请求优先级和服务器推送的支持;多路复用(同一tcp,多个流)，头部压缩，服务推送。

Protobuf

常用的跨语言通信方案
 Google Protocol Buffer 的使用和原理
 Protobuf 语法指南
Protocol Buffers 是一种轻便高效的结构化数据存储格式，可以用于结构化数据串行化，或者说序列化。它很适合做数据存储或 RPC 数据交换格式。可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。目前提供了 C++、Java、Python 三种语言的 API。
同 XML 相比， Protobuf 的主要优点在于性能高。它以高效的二进制方式存储，比 XML 小 3 到 10 倍，快 20 到 100 倍。

框架选择

gRPC vs Thrift
RPC框架性能基本比较测试
 怎么看待谷歌的开源 RPC 框架 gRPC？ - 知乎
 微服务的服务间通信与服务治理
 最佳实践 | 7大维度看国外企业为啥选择gRPC打造高性能微服务？

如何选择

什么时候应该选择gRPC而不是Thrift
　　需要良好的文档、示例
　　喜欢、习惯HTTP/2、ProtoBuf
　　对网络传输带宽敏感
什么时候应该选择Thrift而不是gRPC
　　需要在非常多的语言间进行数据交换
　　对CPU敏感
　　协议层、传输层有多种控制要求
　　需要稳定的版本
　　不需要良好的文档和示例

总的来说，Python rpc框架选择较少，thrift性能最好，grpc性能比thrift稍差，原因是多了http2，而thrift直接基于tcp，但grpc序列化方案更通用(protobuf)优秀，文档较好；
jsonrpc 本身基于http/1进行通信，速度最慢，相对于之前速度无提升，只是接口和数据格式更为统一；

gRPC不足

1）GRPC尚未提供连接池
2）尚未提供“服务发现”、“负载均衡”机制
3）因为基于HTTP2，绝大部多数HTTP Server、Nginx都尚不支持，即Nginx不能将GRPC请求作为HTTP请求来负载均衡，而是作为普通的TCP请求。（nginx将会在1.9版本支持）

为什么需要RPC，而不是简单的HTTP接口

http接口是在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议进行传输。但是如果是一个大型的网站，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了，

首先就是长链接，不必每次通信都要像http一样去3次握手什么的，减少了网络开销；

其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。

第三个来说就是安全性。最后就是最近流行的服务化架构、服务化治理，RPC框架是一个强力的支撑

RPC=Remote Produce Call 是一种技术的概念名词. HTTP是一种协议,RPC可以通过HTTP来实现,也可以通过Socket自己实现一套协议来实现.所以楼主可以换一个问法,为何RPC还有除HTTP之外的实现法,有何必要.毕竟除了HTTP实现外,私有协议不具备通用性.那么我想唯一的答案就在于HTTP不能满足其业务场景的地方,所以这个就要具体案例具体分析了.

一个朋友新做的公众号，帮忙宣传一下，会不定时推送一些开发中碰到的问题的解决方法，以及会分享一些开发视频。资料等。请大家关注一下谢谢：