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 . 函数的接口办法应该怎么表明
长途调用因为遭到网络通讯的束缚，所以往往不能彻底的支撑编程言语的一切特性。比方C言语函数中的指针类型参数，就无法经过网络传递出去。因而长途调用的函数界说，能用言语中的什么特性，不能用什么特性，是需求在规划计划是规则下来的。
这种规则假如太严厉，会影响运用者的易用性；假如太广泛，则可能导致长途调用的功用低下。怎么去规划一种办法，把编程言语中的函数，描绘成一个长途调用的函数，也是需求考虑的问题。许多计划选用了配置文件这种通用的办法，而其他一些计划能够直接在源代码中里边加特别的注释。
一般来说，编译型言语如C/C++只能选用源代码依据配置文件生成的计划，虚拟机型言语如C#/JAVA能够选用反射机制结合配置文件（设置是在源代码顶用特别注释来替代配置文件）的计划，假如是脚本言语就更简略，有时候连配置文件都不需求，因为脚本自己就能够充任。总归长途调用的接口要满意怎样的束缚，也是一个需求细心考虑的问题。
3. 用什么办法来完结网络通讯
长途调用最重要的完结细节，就是关于网络通讯。用何种通讯办法来承载长途调用的问题，细化下来就是两个子问题：用什么样的效劳程序供给网络功用？用什么样的通讯协议？
长途调用体系能够自己直接对TCP/IP编程来完结通讯，也能够托付一些其他软件，比方Web效劳器、音讯行列效劳器等等……也能够运用不同的网络通讯结构，如Netty/Mina这些开源结构。通讯协议则一般有两层：一个是传输协议，比方TCP/UDP或许高层一点的HTTP，或许自己界说的传输协议；其他一个是编码协议，就是怎么把一个编程言语中的目标，序列化和反序列化成为二进制字节省的计划，盛行的计划有JSON、Google Protocol Buffer等等，许多开发言语也有自己的序列化计划，如JAVA/C#都自带。以上这些技能细节，应该挑选运用哪些，直接关系到长途调用体系的功用和环境兼容性。
以上三个问题，就是长途调用体系有必要考虑的中心选型。依据每个计划所面临的束缚不同，他们都会在这三个问题上做出取舍，然后习惯其束缚。可是现在并不存在一个“全能”或许“通用”的计划，其原因就是：在如此杂乱的一个体系中，假如要照料的特性越多，需求支付的本钱（易用性价值、功用开支）也会越多。
下面，咱们能够研讨下业界现存的各种长途调用计划，看他们是怎么在这三个方面做平衡和挑选的。
业界计划举例
1. CORBA
CORBA是一个“陈旧”的，雄心壮志的计划，他企图在完结长途调用的一起，还完结跨言语的通讯的使命，因而其杂乱程度是最高的，可是它的规划思维，也被后来更多的其他计划所学习。在通讯目标的定位上，它运用URL来界说一个长途目标，这是在互联网年代十分简略接受的。其目标的内容则约束在C言语类型上，并且只能传递值，这也是十分简略了解的。为了能让不同言语的程序通讯，所以就必需求在各种编程言语之外独立规划一种仅仅用于描绘长途接口的言语，这就是所谓的IDL：Interface Description Language 接口描绘言语。
用这个办法，你就能够先用一种超然于一切言语之外的言语来界说接口，然后运用东西主动生成各种编程言语的代码。这种计划关于编译型言语简直是仅有挑选。CORBA并没有对通讯问题有任何约好，而是留给详细言语的完结者去处理，这也许是他没有广泛盛行的原因之一。
实际上CORBA有一个十分闻名的承继者，他就是Facebook公司的Thrift结构。Thrift也是运用一种IDL编译生成多种言语的长途调用计划，并且用C++/JAVA等多种言语完好的完结了通讯承载，所以在开源结构中是特别有号召力的一个。Thrfit的通讯承载还有个特色，就是能组合运用各种不同的传输协议和编码协议，比方TCP/UDP/HTTP合作JSON/BIN/PB……这让它简直能够挑选任何的网络环境。
Thrift的模型相似下图，这儿有的stub表明“桩代码”，就是客户端直接运用的函数办法程序；skeleton表明“骨架代码”，是需求程序员编写详细供给长途效劳功用的模板代码，一般对模版做填空或许承继（扩展）即可。这个stub-skeleton模型简直是一切长途调用计划的标配。
2. JAVA RMI
JAVA RMI是JAVA虚拟机自带的一个长途调用计划。它也是能够运用URL来定位长途目标，运用JAVA自带的序列化编码协议传递参数值。在接口描绘上，因为这是一个仅限于JAVA环境下的计划，所以直接用JAVA言语的Interface类型作为界说言语。用户经过完结这个接口类型来供给长途效劳，一起JAVA会依据这个接口文件主动生成客户端的调用代码供调用者运用。他的底层通讯完结，仍是用TCP协议完结的。在这儿，Interface文件就是JAVA言语的IDL，一起也是skeleton模板，供开发者来填写长途效劳内容。而stub代码则因为JAVA的反射功用，由虚拟机直接包办了。
这个计划因为JAVA虚拟机的支撑，运用起来十分简略，彻底依照标志的JAVA编程办法就能够轻松解决问题，可是这也仅仅能在JAVA环境下运转，约束了其适用的规模。鱼与熊掌不可兼得，易用性和适用性往往是相互冲突的。这和CORBA/Thrift寻求最大规模的适用性有很大的不同，也导致了两者在易用性上的不同。
3. Windows RPC
Windows中对RPC支撑是比较早和比较完善的。首要它经过GUID来查询目标，然后运用C言语类型作为参数值的传递。因为Windows的API主要是C言语的，所以关于RPC功用来说，仍是要用一种IDL来描绘接口，最终生成.h和.c文件来出产RPC的stub和skeleton代码。而通讯机制，因为是操作体系自带的，所以运用内核LPC机制承载，这一点仍是对运用者来说比较便利的。可是也约束了只能用于Windows程序之间做调用。
4. WebService & REST
在互联网年代，程序需求经过互联网来相互调用。而互联网上最盛行的协议是HTTP协议和WWW效劳，因而运用HTTP协议的Web Service就水到渠成的成为跨体系调用的最盛行计划。因为能够运用大多数互联网的根底设施，所以Web Service的开发和完结简直是毫无难度的。一般来说，它都会运用URL来定位长途目标，而参数则经过一系列预界说的类型（主要是C言语根底类型），以及目标序列化办法来传递。接口生成方面，你能够自己直接对HTTP做解析，也能够运用比如WSDL或许SOAP这样的规范。在REST的计划中，则约束了只要PUT/GET/DELETE/POST四种操作函数，其他都是参数。
总结一下上面的这些RPC计划，咱们发现，针对长途调用的三个中心问题，一般业界有以下几个挑选：
长途目标定位：运用URL；或许运用姓名效劳来查找
长途调用参数传递：运用C的根本类型界说；或许运用某种预定的序列化（反序列化）计划
接口界说：运用某种特定格局的技能，直接按预先约好一种接口界说文件；或许运用某种描绘协议IDL来生成这些接口文件
通讯承载：有运用特定TCP/UDP之类的效劳器，也有能够让用户自己开发定制的通讯模型；还有运用HTTP或许音讯行列这一类愈加高档的传输协议
计划选型
在咱们断定了长途调用体系计划几个可行挑选后，天然就要清晰一下各个计划的优缺陷，这样才干挑选真实适宜需求的规划：
1. 关于长途目标的描绘：运用URL是互联网通行的规范，比较便运用户了解，也简略增加日后需求扩展到内容，因为URL自身是一个由多个部分组合的字符串；而姓名效劳则旧式一些，可是仍然有他的优点，就是姓名效劳能够顺便负载均衡、容灾扩容、自界说路由等一系列特性，关于需求杂乱的定位比较简略完结。
2. 长途调用的接口描绘：假如只约束于某个言语、操作体系、平台上，直接运用“隐喻”办法的接口描绘，或许以“注解”类型注释手法来标示源代码，完结长途调用接口的界说，是最便利不过的。可是，假如需求兼容编译型言语，如C/C++，就必定要用某种IDL来生成这些编译言语的源代码了。
3.通讯承载：给用户自己定制通讯模块，能供给最好的适用性，可是也让用户增加了运用的杂乱程度。而HTTP/音讯行列这种承载办法，在体系的布置、运维、编程上都会比较简略，缺陷就是关于功用、传输特性的定制空间就比较小。
剖析完中心问题，咱们还需求考虑一些适用性场景：
1. 面向目标仍是面向进程：假如咱们仅仅考虑做面向进程的长途调用，只需求定位到“函数”即可。而假如是面向目标的，则需求定位到“目标”。因为函数是无状况的，所以其定位进程能够简略到一个姓名即可，而目标则需求动态的查找到其ID或句柄。
2.跨言语仍是单一言语：单一言语的计划中，头文件或接口界说彻底用一种言语处理即可，假如是跨言语的，就少难免要IDL
3. 混合式通讯承载仍是运用HTTP效劳器承载：混合式承载可能能够用到TCP/UDP/同享内存等底层技能，能够供给最优的功用，可是运用起来必定十分费事。运用HTTP效劳器的话，则十分简略，因为WWW效劳的开源软件、库很多，并且客户端运用浏览器或许一些JS页面即可调试，缺陷是其功用较低。
假定咱们现在要为某种事务逻辑十分多变的范畴，如企业事务运用范畴，或游戏效劳器端范畴，去规划一个长途调用体系，咱们可能应该如下挑选：
1. 运用姓名效劳定位长途目标：因为企业效劳是需求高可用性的，运用姓名效劳能在查询姓名时辨认和挑选可用性效劳目标。J2EE计划中的EJB（企业JavaBean）就是用姓名效劳的。
2. 运用IDL来生成接口界说：因为企业效劳或游戏效劳，其开发言语可能不是一致的，又或许需求高功用的编程言语如C/C++，所以只能运用IDL。
3.运用混合式通讯承载：尽管企业效劳看起来无需在很杂乱的网络下运转，可是不同的企业的网络环境又可能是千差万其他，所以要做一个通用的体系，最好仍是不怕费事供给混合式的通讯承载，这样能够在TCP/UDP等各种协议中挑选。
