資訊專欄INFORMATION COLUMN
摘要：知乎的點(diǎn)贊，應(yīng)該還是可以參考的。除了網(wǎng)絡(luò)通信，還需要有高效的序列化框架，以及一種尋址方式，如果是帶會話狀態(tài)的調(diào)用，還需要有會話的狀態(tài)保持的功能。一般來說，框架實(shí)現(xiàn)的架構(gòu)原理都是類似的。服務(wù)端響應(yīng)主要是服務(wù)端業(yè)務(wù)邏輯實(shí)現(xiàn)。
本博客 貓叔的博客，轉(zhuǎn)載請申明出處
在我剛剛了解分布式的時候，經(jīng)常對RPC和分布式有些混淆，甚至一直以為兩者對等，所以我們先看看他們有什么區(qū)別？
RPC實(shí)現(xiàn)了服務(wù)消費(fèi)調(diào)用方Client與服務(wù)提供實(shí)現(xiàn)方Server之間的點(diǎn)對點(diǎn)調(diào)用流程，即包括了stub、通信、數(shù)據(jù)的序列化/反序列化。且Client與Server一般采用直連的調(diào)用方式。
而分布式服務(wù)框架，除了包括RPC的特性，還包括多臺Server提供服務(wù)的負(fù)載均衡、策略及實(shí)現(xiàn)，服務(wù)的注冊、發(fā)布與引入，以及服務(wù)的高可用策略、服務(wù)治理等等。
那么RPC是什么呢？
百度百科是這樣表示的：
RPC（Remote Procedure Call）—遠(yuǎn)程過程調(diào)用，它是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計算機(jī)程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中，RPC跨越了傳輸層和應(yīng)用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。
它甚至給出了工作原理，這一點(diǎn)很驚喜。
1.調(diào)用客戶端句柄；執(zhí)行傳送參數(shù)
2.調(diào)用本地系統(tǒng)內(nèi)核發(fā)送網(wǎng)絡(luò)消息
3.消息傳送到遠(yuǎn)程主機(jī)
4.服務(wù)器句柄得到消息并取得參數(shù)
5.執(zhí)行遠(yuǎn)程過程
6.執(zhí)行的過程將結(jié)果返回服務(wù)器句柄
7.服務(wù)器句柄返回結(jié)果，調(diào)用遠(yuǎn)程系統(tǒng)內(nèi)核
8.消息傳回本地主機(jī)
9.客戶句柄由內(nèi)核接收消息
10.客戶接收句柄返回的數(shù)據(jù)
我喜歡搜查更多的信息資料，所以我又找到了知乎上的回答。
知乎1.7k的點(diǎn)贊，應(yīng)該還是可以參考的。
恰如回答提到的，RPC是指遠(yuǎn)程過程調(diào)用，也就是說兩臺服務(wù)器A，B，一個應(yīng)用部署在A服務(wù)器上，想要調(diào)用B服務(wù)器上應(yīng)用提供的函數(shù)/方法，由于不在一個內(nèi)存空間，不能直接調(diào)用，需要通過網(wǎng)絡(luò)來表達(dá)調(diào)用的語義和傳達(dá)調(diào)用的數(shù)據(jù)。
至于為什么使用RPC？答主也提到，無法在一個進(jìn)程內(nèi)，甚至一個計算機(jī)內(nèi)通過本地調(diào)用的方式完成的需求，比如不同系統(tǒng)間的通訊，甚至不同組織間的通訊。
這里再說一下關(guān)于Netty，Netty框架不局限于RPC，更多的是作為一種網(wǎng)絡(luò)協(xié)議的實(shí)現(xiàn)框架，比如HTTP，由于RPC需要高效的網(wǎng)絡(luò)通信，就可以選擇Netty作為基礎(chǔ)。除了網(wǎng)絡(luò)通信，RPC還需要有高效的序列化框架，以及一種尋址方式，如果是帶會話（狀態(tài)）的RPC調(diào)用，還需要有會話的狀態(tài)保持的功能。
好了，讓我們再來整理一下，什么是RPC？
RPC（遠(yuǎn)程過程調(diào)用）一般用來實(shí)現(xiàn)部署在不同機(jī)器上的系統(tǒng)之間的方法調(diào)用，使得程序能夠像訪問本地系統(tǒng)資源一樣，通過網(wǎng)絡(luò)傳輸去訪問遠(yuǎn)端系統(tǒng)資源。一般來說，RPC框架實(shí)現(xiàn)的架構(gòu)原理都是類似的。
可以這樣說，
客戶端調(diào)用：負(fù)責(zé)發(fā)起RPC調(diào)用，為調(diào)用方用戶提供使用API。
服務(wù)端響應(yīng)：主要是服務(wù)端業(yè)務(wù)邏輯實(shí)現(xiàn)。
序列化/反序列化：負(fù)責(zé)對RPC調(diào)用通過網(wǎng)絡(luò)傳輸?shù)膬?nèi)容進(jìn)行序列化與反序列化，不同的RPC框架有不同的實(shí)現(xiàn)機(jī)制。一般分為文本（XML、JSON）與二進(jìn)制（Java原生的、Hessian、protobuf、Thrift、Avro、Kryo、MessagePack），需要注意的是，不同的序列化方式在可讀性、碼流大小、支持的數(shù)據(jù)類型及性能等方面都存在較大差異，我們可以根據(jù)需要自行選擇。
Stub：我們看成代理對象，它會屏蔽RPC調(diào)用過程中的復(fù)雜的網(wǎng)絡(luò)處理邏輯，使其透明簡單，且能夠保持與本地調(diào)用一樣的代碼風(fēng)格。
通信傳輸：即RPC的底層通信傳輸模塊，一般通過Socket在客戶端與服務(wù)端之間傳遞請求與應(yīng)答消息。
公眾號：Java貓說學(xué)習(xí)交流群：728698035
現(xiàn)架構(gòu)設(shè)計（碼農(nóng)）兼創(chuàng)業(yè)技術(shù)顧問，不羈平庸，熱愛開源，雜談程序人生與不定期干貨。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/12005.html
摘要：支持相關(guān)規(guī)范和標(biāo)準(zhǔn)，包括同上。支持多種傳輸協(xié)議和協(xié)議綁定數(shù)據(jù)綁定。構(gòu)建端還有其服務(wù)實(shí)現(xiàn)，接口使用注解，標(biāo)明是一個遠(yuǎn)程服務(wù)接口。然后編寫一個的啟動程序，并運(yùn)行，我想你會成功的因?yàn)槲铱吹搅讼聢D是一種跨平臺的技術(shù)協(xié)議。 本博客 貓叔的博客，轉(zhuǎn)載請申明出處 學(xué)習(xí)系列 RPC框架是啥？ RPC框架是啥之Java自帶RPC實(shí)現(xiàn)，RMI框架入門 Apache CXF一款WebService RP...
摘要：知乎的點(diǎn)贊，應(yīng)該還是可以參考的。除了網(wǎng)絡(luò)通信，還需要有高效的序列化框架，以及一種尋址方式，如果是帶會話狀態(tài)的調(diào)用，還需要有會話的狀態(tài)保持的功能。一般來說，框架實(shí)現(xiàn)的架構(gòu)原理都是類似的。服務(wù)端響應(yīng)主要是服務(wù)端業(yè)務(wù)邏輯實(shí)現(xiàn)。 本博客 貓叔的博客，轉(zhuǎn)載請申明出處 在我剛剛了解分布式的時候，經(jīng)常對RPC和分布式有些混淆，甚至一直以為兩者對等，所以我們先看看他們有什么區(qū)別？ RPC實(shí)現(xiàn)了服務(wù)消費(fèi)...
摘要：讓我們優(yōu)先來實(shí)現(xiàn)一個的案例吧。為了防止被防火墻攔截，需要強(qiáng)制制定的通信端口，一般通過自定義一個類來實(shí)現(xiàn)。完美支持語言所獨(dú)有的特性，不支持其他語言。使用了原生序列化，所有序列化對象必須實(shí)現(xiàn)接口。 本博客 貓叔的博客，轉(zhuǎn)載請申明出處 學(xué)習(xí)系列 RPC框架是啥？ Java自帶RPC實(shí)現(xiàn)，RMI框架入門 首先RMI（Remote Method Invocation）是Java特有的一種RPC實(shí)...
摘要：服務(wù)發(fā)現(xiàn)問題對于來講，我們已經(jīng)解決了傳輸協(xié)議的問題基于，協(xié)議約定問題基于，最后要解決的是服務(wù)發(fā)現(xiàn)問題。另外一方是服務(wù)消費(fèi)方，向獲取服務(wù)提供方的注冊信息。 ????上一節(jié)我們了解了基于 XML 的 SOAP 協(xié)議，SOAP 的 S 是啥意思來著？是 Simple，但是好像一點(diǎn)兒都不簡單??！ 傳輸協(xié)議問題 ????對于 SOAP 來講，比如我創(chuàng)建一個訂單，用 POST，在 XML 里面寫明...
摘要：服務(wù)發(fā)現(xiàn)問題對于來講，我們已經(jīng)解決了傳輸協(xié)議的問題基于，協(xié)議約定問題基于，最后要解決的是服務(wù)發(fā)現(xiàn)問題。另外一方是服務(wù)消費(fèi)方，向獲取服務(wù)提供方的注冊信息。 ????上一節(jié)我們了解了基于 XML 的 SOAP 協(xié)議，SOAP 的 S 是啥意思來著？是 Simple，但是好像一點(diǎn)兒都不簡單??！ 傳輸協(xié)議問題 ????對于 SOAP 來講，比如我創(chuàng)建一個訂單，用 POST，在 XML 里面寫明...
閱讀 1626·2021-11-22 14:45
閱讀 1076·2021-11-17 09:33
閱讀 3329·2021-09-02 09:48
閱讀 976·2019-08-30 15:54
閱讀 2774·2019-08-30 15:53
閱讀 2561·2019-08-30 12:54
閱讀 2250·2019-08-29 12:37
閱讀 2429·2019-08-26 13:58
