掃二維碼與項(xiàng)目經(jīng)理溝通
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
RPC系列的文章是我去年寫的，當(dāng)時(shí)寫的比較散，現(xiàn)在重新進(jìn)行整理。對(duì)于想學(xué)習(xí)RPC框架的同學(xué)，通過這篇文章，讓你知其然并知其所以然，便于以后技術(shù)選型，下面是文章內(nèi)容目錄：
成都創(chuàng)新互聯(lián)公司專注于渾南網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供渾南營銷型網(wǎng)站建設(shè)，渾南網(wǎng)站制作、渾南網(wǎng)頁設(shè)計(jì)、渾南網(wǎng)站官網(wǎng)定制、微信小程序定制開發(fā)服務(wù)，打造渾南網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供渾南網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
RPC(Remote Procedure Call Protocol)遠(yuǎn)程過程調(diào)用協(xié)議。一個(gè)通俗的描述是：客戶端在不知道調(diào)用細(xì)節(jié)的情況下，調(diào)用存在于遠(yuǎn)程計(jì)算機(jī)上的某個(gè)對(duì)象，就像調(diào)用本地應(yīng)用程序中的對(duì)象一樣。
比較正式的描述是：一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請(qǐng)求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。
那么我們至少從這樣的描述中挖掘出幾個(gè)要點(diǎn)：
其實(shí)這是應(yīng)用開發(fā)到一定的階段的強(qiáng)烈需求驅(qū)動(dòng)的。如果我們開發(fā)簡(jiǎn)單的單一應(yīng)用，邏輯簡(jiǎn)單、用戶不多、流量不大，那我們用不著。當(dāng)我們的系統(tǒng)訪問量增大、業(yè)務(wù)增多時(shí)，我們會(huì)發(fā)現(xiàn)一臺(tái)單機(jī)運(yùn)行此系統(tǒng)已經(jīng)無法承受。此時(shí)，我們可以將業(yè)務(wù)拆分成幾個(gè)互不關(guān)聯(lián)的應(yīng)用，分別部署在各自機(jī)器上，以劃清邏輯并減小壓力。此時(shí)，我們也可以不需要RPC，因?yàn)閼?yīng)用之間是互不關(guān)聯(lián)的。
當(dāng)我們的業(yè)務(wù)越來越多、應(yīng)用也越來越多時(shí)，自然的，我們會(huì)發(fā)現(xiàn)有些功能已經(jīng)不能簡(jiǎn)單劃分開來或者劃分不出來。此時(shí)，可以將公共業(yè)務(wù)邏輯抽離出來，將之組成獨(dú)立的服務(wù)Service應(yīng)用 。而原有的、新增的應(yīng)用都可以與那些獨(dú)立的Service應(yīng)用 交互，以此來完成完整的業(yè)務(wù)功能。
所以此時(shí)，我們急需一種高效的應(yīng)用程序之間的通訊手段來完成這種需求，所以你看，RPC大顯身手的時(shí)候來了!
其實(shí)描述的場(chǎng)景也是服務(wù)化 、微服務(wù)和分布式系統(tǒng)架構(gòu)的基礎(chǔ)場(chǎng)景。即RPC框架就是實(shí)現(xiàn)以上結(jié)構(gòu)的有力方式。
要讓網(wǎng)絡(luò)通信細(xì)節(jié)對(duì)使用者透明，我們需要對(duì)通信細(xì)節(jié)進(jìn)行封裝，我們先看下一個(gè)RPC調(diào)用的流程涉及到哪些通信細(xì)節(jié)：
RPC的目標(biāo)就是要2~8這些步驟都封裝起來，讓用戶對(duì)這些細(xì)節(jié)透明。
下面是網(wǎng)上的另外一幅圖，感覺一目了然：
怎么封裝通信細(xì)節(jié)才能讓用戶像以本地調(diào)用方式調(diào)用遠(yuǎn)程服務(wù)呢?對(duì)java來說就是使用代理!java代理有兩種方式：1) jdk 動(dòng)態(tài)代理;2)字節(jié)碼生成。盡管字節(jié)碼生成方式實(shí)現(xiàn)的代理更為強(qiáng)大和高效，但代碼維護(hù)不易，大部分公司實(shí)現(xiàn)RPC框架時(shí)還是選擇動(dòng)態(tài)代理方式。
下面簡(jiǎn)單介紹下動(dòng)態(tài)代理怎么實(shí)現(xiàn)我們的需求。我們需要實(shí)現(xiàn)RPCProxyClient代理類，代理類的invoke方法中封裝了與遠(yuǎn)端服務(wù)通信的細(xì)節(jié)，消費(fèi)方首先從RPCProxyClient獲得服務(wù)提供方的接口，當(dāng)執(zhí)行helloWorldService.sayHello("test")方法時(shí)就會(huì)調(diào)用invoke方法。
public class RPCProxyClient implements java.lang.reflect.InvocationHandler{
private Object obj;
public RPCProxyClient(Object obj){
this.obj=obj;
}
/**
* 得到被代理對(duì)象;
*/
public static Object getProxy(Object obj){
return java.lang.reflect.Proxy.newProxyInstance(obj.getClass().getClassLoader(),
obj.getClass().getInterfaces(), new RPCProxyClient(obj));
}
/**
* 調(diào)用此方法執(zhí)行
*/
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
//結(jié)果參數(shù);
Object result = new Object();
// ...執(zhí)行通信相關(guān)邏輯
// ...
return result;
}
}
public class Test {
public static void main(String[] args) {
HelloWorldService helloWorldService = (HelloWorldService)RPCProxyClient.getProxy(HelloWorldService.class);
helloWorldService.sayHello("test");
}
}
其實(shí)就是通過動(dòng)態(tài)代理模式，在執(zhí)行該方法的前后對(duì)數(shù)據(jù)進(jìn)行封裝和解碼等，讓用于感覺就像是直接調(diào)用該方法一樣，殊不知，我們對(duì)方法前后都經(jīng)過了復(fù)雜的處理。
客戶端的請(qǐng)求消息結(jié)構(gòu)一般需要包括以下內(nèi)容：
服務(wù)端返回的消息結(jié)構(gòu)一般包括以下內(nèi)容：
一旦確定了消息的數(shù)據(jù)結(jié)構(gòu)后，下一步就是要考慮序列化與反序列化了。
什么是序列化?序列化就是將數(shù)據(jù)結(jié)構(gòu)或?qū)ο筠D(zhuǎn)換成二進(jìn)制串的過程，也就是編碼的過程。
什么是反序列化?將在序列化過程中所生成的二進(jìn)制串轉(zhuǎn)換成數(shù)據(jù)結(jié)構(gòu)或者對(duì)象的過程。
為什么需要序列化?轉(zhuǎn)換為二進(jìn)制串后才好進(jìn)行網(wǎng)絡(luò)傳輸嘛!
為什么需要反序列化?將二進(jìn)制轉(zhuǎn)換為對(duì)象才好進(jìn)行后續(xù)處理!
現(xiàn)如今序列化的方案越來越多，每種序列化方案都有優(yōu)點(diǎn)和缺點(diǎn)，它們?cè)谠O(shè)計(jì)之初有自己獨(dú)特的應(yīng)用場(chǎng)景，那到底選擇哪種呢?從RPC的角度上看，主要看三點(diǎn)：
目前互聯(lián)網(wǎng)公司廣泛使用Protobuf、Thrift、Avro等成熟的序列化解決方案來搭建RPC框架，這些都是久經(jīng)考驗(yàn)的解決方案。
消息里為什么要有requestID?這個(gè)問題很簡(jiǎn)單，就不說明了，你能回答出來么?
這個(gè)我前面的很多文章都提到過，Java常用zookeeper，Go常用ETCD，服務(wù)端進(jìn)行注冊(cè)和心跳，客戶端獲取機(jī)器列表，沒啥高深的，比如zookeeper：
gRPC是一個(gè)高性能、通用的開源RPC框架，其由Google 2015年主要面向移動(dòng)應(yīng)用開發(fā)并基于HTTP/2協(xié)議標(biāo)準(zhǔn)而設(shè)計(jì)，基于ProtoBuf序列化協(xié)議開發(fā)，且支持眾多開發(fā)語言。
由于是開源框架，通信的雙方可以進(jìn)行二次開發(fā)，所以客戶端和服務(wù)器端之間的通信會(huì)更加專注于業(yè)務(wù)層面的內(nèi)容，減少了對(duì)由gRPC框架實(shí)現(xiàn)的底層通信的關(guān)注。
如下圖，DATA部分即業(yè)務(wù)層面內(nèi)容，下面所有的信息都由gRPC進(jìn)行封裝。
簡(jiǎn)單地說，gRPC就是在客戶端和服務(wù)器端開啟gRPC功能后建立連接，將設(shè)備上配置的訂閱數(shù)據(jù)推送給服務(wù)器端。我們可以看到整個(gè)過程是需要用到Protocol Buffers將所需要處理數(shù)據(jù)的結(jié)構(gòu)化數(shù)據(jù)在proto文件中進(jìn)行定義。
你可以理解ProtoBuf是一種更加靈活、高效的數(shù)據(jù)格式，與XML、JSON類似，在一些高性能且對(duì)響應(yīng)速度有要求的數(shù)據(jù)傳輸場(chǎng)景非常適用。ProtoBuf在gRPC的框架中主要有三個(gè)作用：
為什么ProtoBuf會(huì)提高傳輸效率呢?
我們知道使用XML、JSON進(jìn)行數(shù)據(jù)編譯時(shí)，數(shù)據(jù)文本格式更容易閱讀，但進(jìn)行數(shù)據(jù)交換時(shí)，設(shè)備就需要耗費(fèi)大量的CPU在I/O動(dòng)作上，自然會(huì)影響整個(gè)傳輸速率。Protocol Buffers不像前者，它會(huì)將字符串進(jìn)行序列化后再進(jìn)行傳輸，即二進(jìn)制數(shù)據(jù)。
可以看到其實(shí)兩者內(nèi)容相差不大，并且內(nèi)容非常直觀，但是Protocol Buffers編碼的內(nèi)容只是提供給操作者閱讀的，實(shí)際上傳輸?shù)牟⒉粫?huì)以這種文本形式，而是序列化后的二進(jìn)制數(shù)據(jù)。字節(jié)數(shù)會(huì)比JSON、XML的字節(jié)數(shù)少很多，速率更快。
如何支撐跨平臺(tái)，多語言呢?
Protocol Buffers自帶一個(gè)編譯器也是一個(gè)優(yōu)勢(shì)點(diǎn)。前面提到的proto文件就是通過編譯器進(jìn)行編譯的，proto文件需要編譯生成一個(gè)類似庫文件，基于庫文件才能真正開發(fā)數(shù)據(jù)應(yīng)用。具體用什么編程語言編譯生成這個(gè)庫文件呢?由于現(xiàn)網(wǎng)中負(fù)責(zé)網(wǎng)絡(luò)設(shè)備和服務(wù)器設(shè)備的運(yùn)維人員往往不是同一組人，運(yùn)維人員可能會(huì)習(xí)慣使用不同的編程語言進(jìn)行運(yùn)維開發(fā)，那么Protocol Buffers其中一個(gè)優(yōu)勢(shì)就能發(fā)揮出來——跨語言。
從上面的介紹，我們得出在編碼方面Protocol Buffers對(duì)比JSON、XML的優(yōu)點(diǎn)：
除了Protocol Buffers之外，從交互圖中和分層框架可以看到， gRPC還有另外一個(gè)優(yōu)勢(shì)——它是基于HTTP 2.0協(xié)議的。
由于gRPC基于HTTP 2.0標(biāo)準(zhǔn)設(shè)計(jì)，帶來了更多強(qiáng)大功能，如多路復(fù)用、二進(jìn)制幀、頭部壓縮、推送機(jī)制。這些功能給設(shè)備帶來重大益處，如節(jié)省帶寬、降低TCP連接次數(shù)、節(jié)省CPU使用等。gRPC既能夠在客戶端應(yīng)用，也能夠在服務(wù)器端應(yīng)用，從而以透明的方式實(shí)現(xiàn)兩端的通信和簡(jiǎn)化通信系統(tǒng)的構(gòu)建。
HTTP 版本分為HTTP 1.X、 HTTP 2.0，其中HTTP 1.X是當(dāng)前使用最廣泛的HTTP協(xié)議，HTTP 2.0稱為超文本傳輸協(xié)議第二代。HTTP 1.X定義了四種與服務(wù)器交互的方式，分別為：GET、POST、PUT、DELETE，這些在HTTP 2.0中均保留。HTTP 2.0的新特性：
thrift是一種可伸縮的跨語言服務(wù)的RPC軟件框架。它結(jié)合了功能強(qiáng)大的軟件堆棧的代碼生成引擎，以建設(shè)服務(wù)，高效、無縫地在多種語言間結(jié)合使用。2007年由facebook貢獻(xiàn)到apache基金，是apache下的頂級(jí)項(xiàng)目，具備如下特點(diǎn)：
Thrift是一套包含序列化功能和支持服務(wù)通信的RPC(遠(yuǎn)程服務(wù)調(diào)用)框架，也是一種微服務(wù)框架。其主要特點(diǎn)是可以跨語言使用，這也是這個(gè)框架最吸引人的地方。
圖中code是用戶實(shí)現(xiàn)的業(yè)務(wù)邏輯，接下來的 Service.Client和 write()/read()是thrift根據(jù)IDL生成的客戶端和服務(wù)端的代碼，對(duì)應(yīng)于RPC中Client stub和Server stub。TProtocol 用來對(duì)數(shù)據(jù)進(jìn)行序列化與反序列化，具體方法包括二進(jìn)制，JSON 或者 Apache Thrift 定義的格式。TTransport 提供數(shù)據(jù)傳輸功能，使用 Apache Thrift 可以方便地定義一個(gè)服務(wù)并選擇不同的傳輸協(xié)議。
thirft使用socket進(jìn)行數(shù)據(jù)傳輸，數(shù)據(jù)以特定的格式發(fā)送，接收方進(jìn)行解析。我們定義好thrift的IDL文件后，就可以使用thrift的編譯器來生成雙方語言的接口、model，在生成的model以及接口代碼中會(huì)有解碼編碼的代碼。thrift網(wǎng)絡(luò)棧結(jié)構(gòu)如下：
代表Thrift的數(shù)據(jù)傳輸方式，Thrift定義了如下幾種常用數(shù)據(jù)傳輸方式：
代表thrift客戶端和服務(wù)端之間傳輸數(shù)據(jù)的協(xié)議，通俗來講就是客戶端和服務(wù)端之間傳輸數(shù)據(jù)的格式(例如json等)，thrift定義了如下幾種常見的格式：
直接貼上網(wǎng)上的兩幅截圖：
也是基于網(wǎng)上測(cè)試的結(jié)果，僅供參考：
什么時(shí)候應(yīng)該選擇gRPC而不是Thrift：
什么時(shí)候應(yīng)該選擇Thrift而不是gRPC：
上面詳細(xì)介紹gRPC和Thrift的特點(diǎn)和區(qū)別，小節(jié)如下：
除了理論，我們還需注重實(shí)踐，gPRC的使用姿勢(shì)看這篇文章 ??【RPC基礎(chǔ)系列3】gRPC簡(jiǎn)單示例??
Dubbo 是一個(gè)分布式服務(wù)框架，致力于提供高性能和透明化的 RPC 遠(yuǎn)程服務(wù)調(diào)用方案，以及 SOA 服務(wù)治理方案。簡(jiǎn)單的說，Dubbo 就是個(gè)服務(wù)框架，說白了就是個(gè)遠(yuǎn)程服務(wù)調(diào)用的分布式框架。
Dubbo 總體架構(gòu)：
Spring Cloud 基于 Spring Boot，為微服務(wù)體系開發(fā)中的架構(gòu)問題，提供了一整套的解決方案——服務(wù)注冊(cè)與發(fā)現(xiàn)，服務(wù)消費(fèi)，服務(wù)保護(hù)與熔斷，網(wǎng)關(guān)，分布式調(diào)用追蹤，分布式配置管理等。
使用 Dubbo 構(gòu)建的微服務(wù)架構(gòu)就像組裝電腦，各環(huán)節(jié)我們的選擇自由度很高，但是最終結(jié)果很有可能因?yàn)橐粭l內(nèi)存質(zhì)量不行就點(diǎn)不亮了，總是讓人不怎么放心，但是如果你是一名高手，那這些都不是問題;而 Spring Cloud 就像品牌機(jī)，在 Spring Source 的整合下，做了大量的兼容性測(cè)試，保證了機(jī)器擁有更高的穩(wěn)定性，但是如果要在使用非原裝組件外的東西，就需要對(duì)其基礎(chǔ)有足夠的了解。
關(guān)于 Dubbo 和 Spring Cloud 的相關(guān)概念和對(duì)比，我個(gè)人比較傾向于 Spring Cloud，原因就是真正的微服務(wù)框架、提供整套的組件支持、使用簡(jiǎn)單方便、強(qiáng)大的社區(qū)支持等等，另外，因?yàn)榭紤]到 .NET/.NET Core 的兼容處理，RPC 并不能很好的實(shí)現(xiàn)跨語言(需要借助跨語言庫，比如 gRPC、Thrift，但因?yàn)?Dubbo 本身就是“gRPC”，在 Dubbo 之上再包一層 gRPC，有點(diǎn)重復(fù)封裝了)，而 HTTP REST 本身就是支持跨語言實(shí)現(xiàn)，所以，Spring Cloud 這一點(diǎn)還是非常好的(Dubbox 也支持，但性能相比要差一些)。
但凡事無絕對(duì)，每件事物有好的地方也有不好的地方，總的來說，Dubbo 和 Spring Cloud 的主要不同體現(xiàn)在兩個(gè)方面：服務(wù)調(diào)用方式不同和專注點(diǎn)不同(生態(tài)不同)。
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
微信二維碼
微信二維碼
移動(dòng)版官網(wǎng)