【新品产上线啦】51CTO播客，随时随地，碎片化学习

RPC是一种方便的网络通讯编程模型，由于和编程言语的高度结合，大大增加了处置网络数据的复杂度，让代码可读性也有可观的提高。但是RPC本身的构成却比较复杂，由于遭到编程言语、网络模型、运用习气的约束，有少量的妥协和取舍之处。本文就是经过火析几种盛行的RPC完成案例，提供大家在设计RPC系统时的参考。

由于RPC底层的网络开发普通和详细运用环境有关，而编程完成手腕也十分多样化，但不影响运用者，因此本文基本触及如何完成一个RPC系统。

看法 RPC (远程调用)

我们在各种操作系统、编程言语生态圈中，多少都会接触过“远程调用”的概念。普通来说，他们指的是用复杂的一行代码，经过网络调用另外一个计算机上的某段顺序。比如：

RMI——Remote Method Invoke：调用远程的办法。“办法”普通是隶属于某个对象上的，所以通常RMI指对在远程的计算机上的某个对象，停止其办法函数的调用。

RPC——Remote Procedure Call：远程进程调用。指的是对网络上另外一个计算机上的，某段特定的函数代码的调用。

远程调用本身是网络通讯的一种概念，他的特点是把网络通讯封装成一个相似函数的调用。网络通讯在远程调用外，普通还有其他的几种概念：数据包处置、音讯队列、流过滤、资源拉取等候。下面比较一下他们差异：

方案编程方式信息封装传输模型典型运用

远程调用调用函数，输入参数，取得前往值。运用编程言语的变量、类型、函数收回央求，取得照应Java RMI

数据包处置调用Send()/Recv()，运用字节码数据，编解码，处置内容把通讯内容构形成二进制的协议包发送/接纳UDP编程

音讯队列调用Put()/Get()，运用“包”对象，处置其包含的内容音讯被封装成言语可用的对象或结构对某队列，存入一个音讯;取出一个音讯ActiveMQ

流过滤读取一个流，或写出一个流，对流中的单元包即刻处置单元长度很小的一致数据结构衔接;发送/接纳;处置网络视频

资源拉取输入一个资源ID，取得资源内容央求或照应都包含：头部+注释央求后等候照应WWW

针对远程调用的特点——调用函数。业界在各种言语下都开发过相似的方案，同时也有些方案是试图做到跨言语的。虽然远程调用在编程方式上，看起来似乎是最复杂易用的，但是也有清楚的缺陷。所以了解清楚远程调用的优势和缺陷，是决议能否要开发、或许运用远程调用这种模型的关键成绩。

远程调用的优势有：

屏蔽了网络层。因此在传输协议和编码协议上，我们可以选择不同的方案。比如WebService方案就是用的HTTP传输协议+SOAP编码协议;而REST的方案往往运用HTTP+JSON协议。Facebook的Thrift甚至可以定制任何不同的传输协议和编码协议，你可以用TCP+Google Protocol Buffer，也可以用UDP+JSON……。由于屏蔽了网络层，你可以依据实践需求来独立的优化网络部分，而无需触及业务逻辑的处置代码，这关于需求在各种网络环境下运转的顺序来说，十分有价值。

函数映射协议。你可以直接用编程言语来书写数据结构和函数定义，取代编写少量的编码协议格式和分包处置逻辑。关于那些业务逻辑十分复杂的系统，比如网络游戏，可以节省少量定义音讯格式的时间。而且函数调用模型十分容易学习，不需求学习通讯协议和流程，让阅历较浅的顺序员也能很容易的末尾运用网络编程。

远程调用的缺陷：

添加了功用消耗。由于把网络通讯包装成“函数”，需求少量额外的处置。比如需求预消费代码，或许运用反射机制。这些都是额外消耗CPU和内存的操作。而且为了表达复杂的数据类型，比如变长的类型string/map/list，这些都要数据包中添加更多的描画性信息，则会占用更多的网络包长度。

不必要的复杂化。假设你仅仅是为了某些特定的业务需求，比如传送一个固定的文件，那么你应该用HTTP/FTP协议模型。假设为了做监控或许IM软件，用复杂的音讯编码收发会更快速高效。假设是为了做代理效劳器，用流式的处置会很复杂。另外，假设你要做数据播送，那么音讯队列会很容易做到，而远程调用这简直无法完成。

因此，远程调用最适宜的场景是：业务需求多变，网络环境多变。

RPC方案的中心成绩

由于远程调用的运用接口是“函数”，所以要如何构建这个“函数”，就产生了三个方面需求决策的成绩：

1 . 如何表示“远程”的信息

所谓远程，就是指网络上另外一个位置，那么网络地址就是必需要输入的部分。在TCP/IP网络下，IP地址和端口号代表了运转中顺序的一个入口。所以指定IP地址和端口是发起远程调用所必需的。

但是，一个顺序能够会运转很多个功用，可以接纳多个不同含义的远程调用。这样如何去让用户指定这些不同含义的远程调用入口，就成为了另外一个成绩。当然最复杂的是每个端口一种调用，但是一个IP最多支持65535个端口，而且别的网络功用也能够需求端口，所以这种方案能够会不够用，同时一个数字代表一个功用也不太好了解，必需要查表才能明白。

所以我们必须想别的办法。在面向对象的思想下，有些方案提出了：以不同的对象来归结不同的功用组合，先指定对象，再指定办法。这个想法十分契合顺序员的了解方式，EJB就是这种方案的。一旦你确定了用对象这种模型来定义远程调用的地址，那么你就需求有一种指定远程对象的办法，为了指定对象，你必需要能把对象的一些信息，从被调用方(效劳器端)传输给调用方(客户端)。

最复杂的方案就是客户端输入一串字符串作为对象的“名字”，发给效劳器端，查找注册了这个“名字”的对象，假设找到了，效劳器端就会用某种技术“传输”这个对象给客户端，然后客户端就可以调用他的办法了。当然这种传输不能够是把整个效劳器上的对象数据拷贝给客户端，而是用一些符号或许标志的办法，来代表这个效劳器上的对象，然后发给客户端。

假设你不是运用面向对象的模型，那么远程的一个函数，也是必需要定位和传输的，由于你调用的函数必须先能找到，然后成为客户端侧的一个接口，才能调用。针对“远程对象”(这里说的对象包括面向对象的对象或许仅仅是 函数)如何表达才能在网络上定位;以及定位成功之后以什么方式供客户端调用，都是“远程调用”设计方案中第一个重要的成绩。

2 . 函数的接口方式应该如何表示

(责任编辑：admin)