RPC(remote procedure call)即遠(yuǎn)程過(guò)程調(diào)用淹朋，在分布式越來(lái)越普及的現(xiàn)在啥繁，許多系統(tǒng)都用到了RPC服務(wù)，他們有的基于thrift碧磅，有的基于dubbo，有的基于webservice遵馆，那么到底什么是RPC呢鲸郊？不同的RPC框架又有什么區(qū)別呢？
什么是RPC?
首先我們要有分布式的概念货邓，用到RPC的系統(tǒng)通常不是單機(jī)的秆撮，比如你做的是一個(gè)電商平臺(tái)系統(tǒng)，你可能會(huì)有一個(gè)訂單服務(wù)的集群换况，一個(gè)商品服務(wù)的集群职辨。訂單服務(wù)提供訂單查詢接口盗蟆，訂單明細(xì)接口等，而訂單明細(xì)需要展示商品的數(shù)據(jù)拨匆，顯然姆涩，訂單服務(wù)里是查詢不到商品的數(shù)據(jù)，這個(gè)時(shí)候訂單服務(wù)就需要調(diào)用商品服務(wù)的接口惭每，而訂單服務(wù)調(diào)用商品服務(wù)的接口這個(gè)過(guò)程即是遠(yuǎn)程過(guò)程過(guò)程調(diào)用骨饿。將一個(gè)遠(yuǎn)程的方法像本地方法一樣調(diào)用，即遠(yuǎn)程過(guò)程調(diào)用台腥。
RPC的流程
如圖所示宏赘，一個(gè)RPC服務(wù)有客戶端，和服務(wù)端之分黎侈，客戶端調(diào)用服務(wù)端暴露的RPC服務(wù)察署，發(fā)起請(qǐng)求，而服務(wù)端則負(fù)責(zé)提供服務(wù)峻汉，接受客戶端傳入的參數(shù)贴汪，將結(jié)果返回給客戶端。
client發(fā)起一個(gè)請(qǐng)求休吠，首先會(huì)委托給代理Proxy扳埂，將調(diào)用的信息封裝好交給Invoker去執(zhí)行，Invoker通過(guò)Connector與服務(wù)端進(jìn)行通信瘤礁，當(dāng)然通信前阳懂，會(huì)將要傳輸?shù)膶?duì)象信息根據(jù)協(xié)議進(jìn)行序列化。服務(wù)端接收器Acceptor收到客戶端發(fā)來(lái)的請(qǐng)求后柜思，首先根據(jù)協(xié)議進(jìn)行解碼岩调，然后將客戶端的調(diào)用信息傳給processor進(jìn)行處理，最后調(diào)用invoke執(zhí)行調(diào)用的方法赡盘，并且返回相應(yīng)的結(jié)果給客戶端号枕。
幾個(gè)值得思考的問(wèn)題
了解了流程之后，我們可能對(duì)RPC的大致流程有了一定了解陨享，但是整個(gè)流程中還有一些問(wèn)題值得我們深入思考葱淳。
1.序列化的方法
我們?cè)诔绦蚶镎{(diào)用本地方法的時(shí)候，是將相應(yīng)參數(shù)壓到棧底霉咨，然后讓讓函數(shù)自己讀取蛙紫，但是我們使用RPC服務(wù)調(diào)用遠(yuǎn)程方法的時(shí)候拍屑，則一定要有一個(gè)序列化的過(guò)程途戒，因?yàn)榭蛻舳伺c服務(wù)端是用流進(jìn)行通信，甚至客戶端和服務(wù)端可能是基于不同語(yǔ)言實(shí)現(xiàn)的（例如僵驰，客戶端使用的java喷斋，服務(wù)端使用的python）唁毒，我們需要先將客戶端所需傳遞的參數(shù)序列化成字節(jié)流，然后傳給服務(wù)端星爪，服務(wù)端再進(jìn)行反序列化浆西，進(jìn)行讀取。
常見(jiàn)的序列化方式有
（1）json／xml:可讀性顽腾，擴(kuò)展性較強(qiáng)近零，但是壓縮效率及解析效率低。對(duì)性能要求高時(shí)不適用抄肖。
（2）thrift:支持二進(jìn)制傳輸久信，支持json序列化，支持多種語(yǔ)言漓摩。二進(jìn)制相對(duì)json／xml效率較高裙士，但同時(shí)也帶來(lái)了可讀性較差的缺點(diǎn)。
（3）protobuf:序列化層面上和thrift一樣管毙，支持二進(jìn)制腿椎，支持json等多種數(shù)據(jù)格式，以及多種語(yǔ)言夭咬，不過(guò)protobuf的底層通信需要自己實(shí)現(xiàn)啃炸，而沒(méi)有thrift的支持更全面。
2.異常處理
調(diào)用RPC服務(wù)的時(shí)候和本地對(duì)異常處理的方式可能會(huì)更加復(fù)雜皱埠，因?yàn)楫惓５脑蚩赡軙?huì)更多肮帐。既有可能是業(yè)務(wù)層面的異常，也有可能是網(wǎng)絡(luò)原因?qū)е碌耐ㄐ女惓１咂鳎詫?duì)于不同類型的異常训枢，我們應(yīng)該定義為不同的異常類，做好區(qū)分忘巧。
假設(shè)恒界，我們定義業(yè)務(wù)異常為BizException，網(wǎng)絡(luò)異常為TException砚嘴，由于RPC服務(wù)可能設(shè)計(jì)比較長(zhǎng)的調(diào)用鏈十酣，我們可能因?yàn)橐淮尾僮鳎瑨伋隽薚Exception际长，但無(wú)法定位具體是哪個(gè)服務(wù)拋出了異常耸采。所以針對(duì)不同的業(yè)務(wù)邏輯，對(duì)RPC調(diào)用可能的異常工育，做好更詳細(xì)的說(shuō)明虾宇，能在異常被拋出的時(shí)候讓我們更快地定位異常原因。
基于thrift的RPC服務(wù)代碼demo
首先我們基于IDL定義thrift文件
thrift數(shù)據(jù)結(jié)構(gòu)比較簡(jiǎn)單如绸，有其他語(yǔ)言基礎(chǔ)的話嘱朽，稍微了解旭贬，即可以根據(jù)接口定義出對(duì)應(yīng)的thrift文件ThriftDemo.thrift
定義好了thrift文件之后，我們可以使用thrift命令生成對(duì)應(yīng)的java文件（需要先安裝thrift-0.9.2.exe）
thrift-0.9.2.exe -r -gen java ThriftDemo.thrift
接下來(lái)我們即可以根據(jù)thrift接口搪泳，寫出我們自定義接口的具體實(shí)現(xiàn)稀轨，我們需要實(shí)現(xiàn)DemoTest.Iface接口
最后，我們可以在本地寫個(gè)server和client進(jìn)行測(cè)試岸军。
server端：
為了測(cè)試簡(jiǎn)單奋刽，采用的nio，二進(jìn)制協(xié)議書寫的一個(gè)簡(jiǎn)單的server的demo
client端的實(shí)現(xiàn)
包括我們平時(shí)在服務(wù)端開(kāi)發(fā)時(shí)艰赞，也可以自己寫一個(gè)client端杨名，來(lái)對(duì)自己的thrift服務(wù)進(jìn)行一個(gè)簡(jiǎn)單的測(cè)試。
總結(jié)?
最后猖毫，RPC服務(wù)為我們?cè)诜植际椒?wù)中互相調(diào)用提供了很多便利台谍，但是我們?cè)谑褂肦PC的同時(shí)，也會(huì)遇到他給我們帶來(lái)的很多問(wèn)題吁断，我們必須根據(jù)自己服務(wù)特點(diǎn)趁蕊，探索我們開(kāi)發(fā)過(guò)程中選用哪種框架，需要注意哪些問(wèn)題仔役，讓我們的服務(wù)更穩(wěn)定掷伙。
