谁能用通俗的语言解释一下什么是 RPC 框架？
了解到最近 Java 的 Netty 很火，只知道它是这样类型的一种框架。想了解一下它主要用于解决了什么问题？适用于什么样的场景？
1 条评论分享 默认排序 按时间排序
20 个回答
用心阁软件工程师 486人赞同关于RPC你的题目是RPC框架，首先了解什么叫RPC，为什么要RPC，RPC是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。
比如说，一个方法可能是这样定义的：
Employee getEmployeeByName(String fullName)
那么：
首先，要解决通讯的问题，主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。第二，要解决寻址的问题，也就是说，A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。
第三，当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。第四，B服务器收到请求后，需要对参数进行反序列化（序列化的逆操作），恢复为内存中的表达方式，然后找到对应的方法（寻址的一部分）进行本地调用，然后得到返回值。第五，返回值还要发送回服务器A上的应用，也要经过序列化的方式发送，服务器A接到后，再反序列化，恢复为内存中的表达方式，交给A服务器上的应用
（图片来源： https://www.cs.rutgers.edu/~pxk/417/notes/03-rpc.html）
为什么RPC呢？就是无法在一个进程内，甚至一个计算机内通过本地调用的方式完成的需求，比如比如不同的系统间的通讯，甚至不同的组织间的通讯。由于计算能力需要横向扩展，需要在多台机器组成的集群上部署应用，
RPC的协议有很多，比如最早的CORBA，Java RMI，Web Service的RPC风格，Hessian，Thrift，甚至Rest API。
关于Netty
而Netty框架不局限于RPC，更多的是作为一种网络协议的实现框架，比如HTTP，由于RPC需要高效的网络通信，就可能选择以Netty作为基础。除了网络通信，RPC还需要有比较高效的序列化框架，以及一种寻址方式。如果是带会话（状态）的RPC调用，还需要有会话和状态保持的功能。
大体上来说，Netty就是提供一种事件驱动的，责任链式（也可以说是流水线）的网络协议实现方式。网络协议包含很多层次，很多部分组成，如传输层协议，编码解码，压缩解压，身份认证，加密解密，请求的处理逻辑，怎么能够更好的复用，扩展，业界通用的方法就是责任链，
一个请求应答网络交互通常包含两条链，一条链（Upstream）是从传输层，经过一系列步骤，如身份认证，解密，日志，流控，最后到达业务层，一条链（DownStream）是业务层返回后，又经过一系列步骤，如加密等，又回到传输层。
（图片来源： ChannelPipeline (The Netty Project API Reference (3.2.6.Final))）
这样每一层都有一个处理接口，都可以进行不同的操作，比如身份认证，加解密，日志，流控，将不同的处理实现像拼积木那样插接起来就可以实现一个网络协议了（快速开发）。每一层都有自己的实现，上层不需要关注面向网络的操作（可维护）。Netty已经提供了很多实现。
（图片来源： /netty/3.1/guide/html/architecture.html）
当然Netty还有许多好处，比如对非阻塞IO（NIO）的支持，比如在链上传递时最大程度的减少buffer的copy（高性能）。编辑于 -09-06 14 条评论 感谢分享收藏 • 没有帮助 • 举报 • 申请转载知乎用户IT-风水师 45人赞同 Netty只是网络通信框架，把Java Socket的API又封装了一次，使得你可以用最少的代码来完成网络通信这一任务。
回到RPC 上，我的看法和 @肖继潮略有不同。
根据字面意思来推断，RPC 的确是为了进程间通信而准备的，但构造成函数调用这一形式，是因为这是在抽象上最合理的。
我们可以推断演进一下
====
1. A B 两个进程之间需要进行数据交换。
2.于是我们想出来在某个内存区域划出一个空间，然后向该空间中写入和读取数据。（共享文件也可以）(常见的socket就是这一共享内存的抽象，只是现在大多指网络通路)
3.A B 通信完成。
====
4.A B需要完成更复杂的交互
5.于是我们指定一个协议,A B 根据该协议对数据的进行编码解码，根据协议内容做出决策。
====
6.发现协议过于复杂(比如 编号1代表调用 a函数，编号2代表b函数)
7.试图优化协议，将函数参数和调用的函数名称作为协议的一部分，函数返回值类似
8.RPC达成
=====
9.表现出来的特性就是，object invok(parameter)，就代表了，序列化 parameter 对象到中间格式，利用远程服务器的 invok 函数进行处理 ，同时将返回的数据解码生成 object对象。
======总结=====
RPC 在整个过程中，体现了逐层抽象，将复杂的协议编解码和数据传输封装到了一个函数中。
======缺点=====
单一 RPC 无法实现 push,即推送服务。
理由是，RPC 是client 调用 server获取数据，是一个完整的过程，实现不了server调用client。
解决方案：让client 既可以调用server上的RPC服务，反之client本身也成为一个RPC服务让Server来调用。
=====回到题主的问题====
1. Netty只是网络通信框架,目的是让你用最少的代码构建出足够支撑网络通信的功能。
2.完成RPC 需要两个协议： 对象序列化协议 和 调用控制协议
常见例子举例：
1.zeroC ICE，拥有自己的网络通信框架 + ICE 调用控制协议和对象序列化协议,同时也涵盖了服务组件的抽象部署等功能。
2.thrift，有自己的网络通信框架+thrift 对象序列化协议+thrift 调用控制协议
3.probuff，只是 对象序列化协议
4.XMLRPC ，jsonRPC，常见的语境是利用HTTP协议作为调用控制协议,XML 和 JSON 作为对象序列化之后的格式。
5.其他的大概也差不多了。发布于 -12-31 8 条评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利知乎用户IT培训师 100人赞同 泻药。
早期单机时代，一台电脑上运行多个进程，大家各干各的，老死不相往来。假如A进程需要一个画图的功能，B进程也需要一个画图的功能，程序员就必须为两个进程都写一个画图的功能。这不是整人么？于是就出现了IPC（Inter-process communication，单机中运行的进程之间的相互通信）。OK，现在A既然有了画图的功能，B就调用A进程上的画图功能好了，程序员终于可以偷下懒了。
到了网络时代，大家的电脑都连起来了。以前程序只能调用自己电脑上的进程，能不能调用其他机器上的进程呢？于是就程序员就把IPC扩展到网络上，这就是RPC（远程过程调用）了。现在不仅单机上的进程可以相互通信，多机器中的进程也可以相互通信了。
要知道实现RPC很麻烦呀，什么多线程、什么Socket、什么I/O，都是让咱们普通程序员很头疼的事情。于是就有牛人开发出RPC框架（比如，CORBA、RMI、Web Services、RESTful Web Services等等）。
OK，现在可以定义RPC框架的概念了。简单点讲，RPC框架就是可以让程序员来调用远程进程上的代码一套工具。有了RPC框架，咱程序员就轻松很多了，终于可以逃离多线程、Socket、I/O的苦海了。
至于最近Java中流行的Netty，没玩过。但是大致了解过，Netty、Mina是游戏行业做服务器开发的Java程序员用的比较多的PRC框架（我们学生主要是Java方向的，有不少人毕业后从事游戏开发）。据说互联网公司用的也比较多。这两行业都有高并发量的、长连接、分布式、异步通讯、大数据量等特点。Netty这种RPC框架封装和优化了Java NIO和异步网络编程的一些繁琐的细节，一方面可以让开发者专注于业务逻辑的实现，一方面只需要调用Netty封装的API就可以很快编写出高性能的服务器。
抱歉，知识有限，只能答到这里了。发布于 -09-26 18 条评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利知乎用户 29人赞同 RPC, 远程过程调用直观说法就是A通过网络调用B的过程方法。
通信中的协议是你自己规定的，比如你可以规定说当A向B发送数字1, B就打印hello world, 并返回数字1给A, 如果发送数字2，B就打印hello, guy.并发送数字2给A.
这就是一个简单的RPC示例，实际上natty就是干这个的，只不过它提供一套框架给你，让你可以定义自己的规则，实现B里面的函数。
我们来想一想，当A要把数字1发送给B要怎么办呢，你需要用socket，B是server, A是client， B执行完以后再把1通过socket写回即可。你可以用AUPE书中的例子很容易就构建出来。
问题到这里，应该就结束了，事实上就是这么简单，那为什么需要RPC框架呢？
当你给B发送1或者2就可以区分函数方法，但是你不可能写100个函数打印100个字符，你需要在发送1的时候，再接着发送一个字符串，这样B只要实现一个通用的print函数就够了。
我们继续思考，当你想发送一个数字比如65534给B的时候，我们知道socket是按照字节接受数据的，一个字节最大为255也就是0xff, 如果要发送65534你有两种方法，第一把65534当作5个字符6,5,5,3,4然后让socket接受5个字符。第二，你可以把65534变成二进制0xfffe, 这样你可以先发送一个0xff再发送一个0xfe,也就是先发一个255再发一个254再拼装。
另外在拼装这255和254的时候，我们知道不同体系结构的CPU字节序是不一样的，因此，你需要解决大端小端字节序的问题。否则对于一个32位机器上，65534作为一个int型可能会是0xfffe0000,或者0x0000feff，这取决于你如何发送和打包它。
对于相对复杂的RPC, 我们发送的一个数据包往往既包含字符串又包含数字，这样我们就需要把他们切割开来然后分别解码编码。
这个部分就叫做序列化反序列化，在高级一点的RPC框架中，甚至可以做到把
一个类从A扔给B.用到的还是这个方法，只是把类这个类型也放进去了。
对于脚本语言比如Lua，你甚至可以把编译过后的字节码发给远程，然后在B用Lua虚拟机执行。
所以对于一个完整的RPC框架底层往往是socket搭配序列化反序列化的工作。
问题到这里，一个RPC分析应该也结束了, 实际上要想把一个RPC做稳定了，还有几个问题。
首先，要想让一个RPC能够更高效，往往做到让A可以连续向B发送请求，这就要求在协议解析的时候区分两个包，在TCP分包的时候这里有个问题叫做半包和粘包。
另外B也无需在返回完函数1以后再返回函数2，这就要求在返回的时候，A能够区分开来，这就要求在协议里面加入session.
高效的写法不但在编解码和协议设计理念，还需要在编写socket server时候，尽可能降低阻塞调用，用异步来做，这有一大推开源方案，比如libev.
netty就是一个这样异步的RPC通信框架。
当然，在实际项目中，我们只是需要解决实际问题，完全没必要从头构建，你可以选一个通信协议比如protobuf/JSON/msgpack/thrift等等再找他相关的RPC库使用即可。
当然完全可以自己定制。
一个好的框架不只是解决最基本的问题，它更像是一个生态系统，比如我看到netty还有SSL的部分，DNS部分。
Have Fun.编辑于 -07-07 5 条评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利赵老师你沉默着倾听着那一首歌 1人赞同 你调用一个函数，可是这个函数的实现体（代码）是另一台机器上的，这就是RPC
Remote procedure call 远程过程（就是函数）调用。
为什么能做到呢？
因为他写了socket的代码，这样你就不用写了。
所以RPC就是一个比直接socket编程模型更方便的模型。发布于 -09-20 添加评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利iseeyou 3人赞同 RPC是系统间的一种通信方式，系统间常用的通信方式还有http,webservice，rpc等，一般来讲rpc比http和webservice性能高一些，常见的RPC框架有：thrift，Finagle，dubbo，grpc，json-rpc等。
一个通用的网络RPC框架，它应该包括如下功能：
1.具有服务的分层设计，借鉴Future/Service/Filter概念
2.具有网络的分层设计，区分协议层、数据层、传输层、连接层
3.独立的可适配的codec层，可以灵活增加HTTP，Memcache，Redis，MySQL/JDBC，Thrift等协议的支持。
4.将多年各种远程调用High availability的经验融入在实现中，如负载均衡，failover，多副本策略，开关降级等。
5.通用的远程调用实现，采用async方式来减少业务服务的开销，并通过future分离远程调用与数据流程的关注。
6.具有状态查看及统计功能
7.当然，最终要的是，具备以下通用的远程容错处理能力，超时、重试、负载均衡、failover……
QiuRPC是一个采用JAVA实现的小巧的RPC框架，一共3K多行代码，已在github开源出来，项目地址为： GitHub - i1see1you/QiuRPC: 一个简单的RPC框架，实现了RPC的基本功能，开发者也可以自定义扩展，可以供大家学习探讨或者在小项目中使用，目前QiuRPC具有如下特点：
1. 服务端基于注解，启动时自动扫描所有RPC实现，基本零配置
2. 客户端实现Filter机制，可以自定义Filter
3. 基于netty的Reactor IO多路复用网络模型
4. 数据层提供protobuff和hessian的实现，可以扩展ISerializer接口自定义实现其他
5. 负载均衡算法采用最少活跃调用数算法，可以扩展ILoadBlance接口自定义实现其他
6. 客户端支持服务的同步或异步调用编辑于 -07-27 添加评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利林毅文码农 1人赞同 Netty 不是RPC框架。netty是一个web服务器原型。理解netty为一个弱化的tomcat就是了。当然你用netty写一个rpc框架也是可以的o(╯□╰)o
RPC这东西字面意思是远过程调用。操作系统层面的RPC和架构层面的RPC是不太一样的。
架构层面的RPC我理解为对SOA的协调。比如说原来简单粗暴的一对一访问， 我委托RPC框架处理，有了RPC框架，可以方便比如说监控，流量控制，灰度发布等。
操作系统的RPC就让专门的童鞋补充吧~我就不乱说了。发布于 -03-22 3 条评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利马秉尧自由软件开发者，pecl 成员 7人赞同RPC(远程过程调用)是什么
简单的说，RPC就是从一台机器（客户端）上通过参数传递的方式调用另一台机器（服务器）上的一个函数或方法（可以统称为服务）并得到返回的结果。
RPC 会隐藏底层的通讯细节（不需要直接处理Socket通讯或Http通讯）
RPC 是一个请求响应模型。客户端发起请求，服务器返回响应（类似于Http的工作方式）
RPC 在使用形式上像调用本地函数（或方法）一样去调用远程的函数（或方法）。
远程过程调用发展历程
ONC RPC （开放网络计算的远程过程调用），OSF RPC（开放软件基金会的远程过程调用）
CORBA（Common Object Request Broker Architecture公共对象请求代理体系结构）
DCOM（分布式组件对象模型），COM+
Java RMI
.NET Remoting
XML-RPC，SOAP，Web Service
PHPRPC，Hessian，JSON-RPC
Microsoft WCF，WebAPI
ZeroC Ice，Thrift，GRPC
Hprose
早期的 RPC
第一代 RPC（ONC RPC，OSF RPC）不支持对象的传递。
CORBA 太复杂，各种不同实现不兼容，一般程序员也玩不转。
DCOM，COM+ 逃不出 Windows 的手掌心。
RMI 只能在 Java 里面玩。
.NET Remoting 只能在 .NET 平台上玩。
XML-RPC，SOAP，WebService
冗余数据太多，处理速度太慢。
RPC 风格的 Web Service 跨语言性不佳，而 Document 风格的 Web Service 又太过难用。
Web Service 没有解决用户的真正问题，只是把一个问题变成了另一个问题。
Web Service 的规范太过复杂，以至于在 .NET 和 Java 平台以外没有真正好用的实现，甚至没有可用的实现。
跨语言跨平台只是 Web Service 的一个口号，虽然很多人迷信这一点，但事实上它并没有真正实现。
PHPRPC
基于 PHP 内置的序列化格式，在跨语言的类型映射上存在硬伤。
通讯上依赖于 HTTP 协议，没有其它底层通讯方式的选择。
内置的加密传输既是特点，也是缺点。
虽然比基于 XML 的 RPC 速度快，但还不是足够快。
Hessian
二进制的数据格式完全不具有可读性。
官方只提供了两个半语言的实现（Java，ActionScript 和不怎么完美的 Python 实现），其它语言的第三方实现良莠不齐。
支持的语言不够多，对 Web 前端的 JavaScript 完全无视。
虽然是动态 RPC，但动态性仍然欠佳。
虽然比基于 XML 的 RPC 速度快，但还不是足够快。
JSON-RPC
JSON 具有文本可读性，且比 XML 更简洁。
JSON 受 JavaScript 语言子集的限制，可表示的数据类型不够多。
JSON 格式无法表示数据内的自引用，互引用和循环引用。
某些语言具有多种版本的实现，但在类型影射上没有统一标准，存在兼容性问题。
JSON-RPC 虽然有规范，但是却没有统一的实现。在不同语言中的各自实现存在兼容性问题，无法真正互通。
Microsoft WCF，WebAPI
它们是微软对已有技术的一个 .NET 平台上的统一封装，是对 .NET Remoting、WebService 和基于 JSON 、XML 等数据格式的 REST 风格的服务等技术的一个整合。
虽然号称可以在 .NET 平台以外来调用它的这些服务，但实际上跟在 .NET 平台内调用完全是两码事。它没有提供任何在其他平台的语言中可以使用的任何工具。
ZeroC Ice，Thrift，GRPC
初代 RPC 技术的跨语言面向对象的回归。
仍然需要通过中间语言来编写类型和接口定义。
仍然需要用代码生成器来将中间语言编写的类型和接口定义翻译成你所使用的编程语言的客户端和服务器端的占位程序（stub）。
你必须要基于生成的服务器代码来单独编写服务，而不能将已有代码直接作为服务发布。
你必须要用生成的客户端代码来调用服务，而没有其它更灵活的方式。
如果你的中间代码做了修改，以上所有步骤你都要至少重复一遍。
Hprose
无侵入式设计，不需要单独定义类型，不需要单独编写服务，已有代码可以直接发布为服务。
具有丰富的数据类型和完美的跨语言类型映射，支持自引用，互引用和循环引用数据。
支持众多传输方式，如 HTTP、TCP、Websocket 等。
客户端具有更灵活的调用方式，支持同步调用，异步调用，动态参数，可变参数，引用参数传递，多结果返回（Golang）等语言特征，Hprose 2.0 甚至支持推送。
具有良好的可扩展性，可以通过过滤器和中间件实现加密、压缩、缓存、代理等各种功能性扩展。
兼容的无差别跨语言调用
支持更多的常用语言和平台
支持浏览器端的跨域调用
没有中间语言，无需学习成本
性能卓越，使用简单编辑于 -07-08 2 条评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利知乎用户Shoot on the face 9人赞同 远程调用。没啥高深的，都是些概念和范式。我感觉你访问个网页也算。。。发布于 -07-06 1 条评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利@kazaff幼儿园架构师为了一些理由（遗留系统挟持，架构设计等），需要面对多系统之间的通信问题而引入了RPC技术。
RPC框架则是打包提供了完备的核心功能和增值服务，更好的辅助开发人员实现RPC调用~~
我解释的够粗俗吧？发布于 -09-26 添加评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利员外读书的村夫 6人赞同 就推荐一个infoq的视频吧，比较新，4月6日的，国内netty方面研究的最深的几个人之一，李林峰的演讲视频。 Netty架构剖析和行业应用
高并发、大吞吐，还有就是一些长连接的应用，netty目前好像是必不可少的框架，而且现在很多和互联网应用搭边的应用，也都开始在自己的项目中加一层netty来管理链路接收和分发。发布于 -04-14 1 条评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利Way Lau码农 3人赞同 见 《 远程过程调用(RPC)详解》发布于 -07-10 添加评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利厨房仔http://wire- 3人赞同 本质是tcp网络通信。
概念上讲是你调用远程函数返回结果，最简单的例子是调用add 1,2 远程计算得出结果3返回给你。
工程角度讲由于定义了很多规范，会方便很多。发布于 -08-15 3 条评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利匿名用户 2人赞同 各位都把简单的事情复杂化了。。。
其实就是我把参数传给你，你处理完之后把返回值回传给我。
只不过双方不在同一台机，这就是所谓的“远程过程调用”，简称RPC。
简单的例子，我在Google输入 ，然后Google把搜索结果回传给我。
没错，就是这么回事。发布于 -08-22 2 条评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利北冥有鱼生也有涯。 1人赞同 不用想的太复杂，rpc框架做的最重要的一件事就是封装了，调用者和被调用者的通信细节。客户端代理负责将调用方法的方法名，参数返回值包等信息根据通信协议组织成报文发送给服务端，服务端解析报文，根据客户端传递的信息执行对应的方法，然后将返回值按照协议组织成报文发送给客户端，客户端再解析出来。发布于 -08-22 添加评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利王小明半路出家的程序员 1人赞同 写了个简单的RPC 代码见： GitHub - wenbo/fox: fox is a lightweight RPC framework that supports distributed deployment
这个代码能够很好的对初学者理解RPC整个过程。主要参考了大众点评pigeon和阿里巴巴dubbo。编辑于 -08-29 添加评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利张振将装逼进行到底~~~~RPC:Remote Procedure Call Protocol，远程过程调用
使用场景：不在同一个进程中的程序之间的调用（不同服务器，或同一个服务器都可以涉及），说白了就是想办法实现不通进程间都通信，可以通过网络请求，或者共享资源的方式都可以发布于 -08-23 添加评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利匿名用户最近在看ice slice rcp hprose这些 感觉要学的不是一星半点呀发布于 -03-17 添加评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利wxpit啊简单回答下，比方说你的网站想获取天气信息，你数据哪里来？肯定是气象中心啦！那你怎么获取？这就需要远程调用、从气象部门的服务器获取信息到你的网站。netty底层是nio写的。nio是非阻塞的，简单来说是不需要等。cpu在处理完后直接交给硬盘读取。举个栗子，你去饭店吃饭，传统的模式是你点菜，然后点完去炒，直到炒完给你再下一个，这个过程下一位可能等的不耐烦了。而非阻塞则是这样，你去前台点菜，前台叫厨师炒，炒完叫你，然后前台点菜员继续服务下一位客户。这样是不是效率大大提高了。发布于 -08-22 添加评论 感谢分享收藏 • 没有帮助 • 举报 • 作者保留权利求索在gis的世界里找到自己的价值！各位介绍的都很好，最近我也开始学习使用RPC相关的框架，google的GRPC，还有facebook开源的ThriftRPC，哪个在实践中使用起来更方面，我目前用的是centos6的系统，请大家给出比较，谢谢！
