RPC全稱Remote Procedure Call，即遠(yuǎn)程過程調(diào)用。其本質(zhì)上其實(shí)就是主機(jī)A通過某種網(wǎng)絡(luò)協(xié)議向支持相同協(xié)議的主機(jī)B發(fā)送一個(gè)任務(wù)執(zhí)行命令，并且在某些情況下，還能支持任務(wù)執(zhí)行結(jié)果的返回。

幾乎每一個(gè)RPC都有著自己的網(wǎng)絡(luò)協(xié)議定義，如果要按照TCP/IP協(xié)議棧劃分，這些RPC協(xié)議通HTTP/HTTPS協(xié)議一樣屬于應(yīng)用層協(xié)議，不過相比較于HTTP/HTTPS協(xié)議來說，RPC協(xié)議在功能和性能之間更偏重與性能，即RPC框架是一種高性能的網(wǎng)絡(luò)通信框架。

RPC通信單獨(dú)來說只是一種高性能的網(wǎng)絡(luò)通信技術(shù)，和http相比除了快和簡單并沒有任何更為出采的地方，更不可能取代http在網(wǎng)絡(luò)通信中的地位。但是技術(shù)是要服務(wù)于架構(gòu)的，只有在特定的場景下才能發(fā)揮其長處，在實(shí)際開發(fā)中，RPC框架多用于微服務(wù)架構(gòu)中。

微服務(wù)是近些年才提出的概念，至于什么是微服務(wù)，在我查閱了許多資料之后也并沒有找到讓人豁然開朗的定義。要想了解什么是微服務(wù)，還是要看一下Java服務(wù)端開發(fā)的演變過程才能夠有一個(gè)淺顯的認(rèn)識(shí)。

Java服務(wù)端開發(fā)在早期多指B/S架構(gòu)下的JavaWeb應(yīng)用程序開發(fā)。開發(fā)者遵循Servlet規(guī)范將開發(fā)好的JavaWeb程序打包成war包運(yùn)行在支持http/https協(xié)議的Servlet容器中，比如tomcat，jetty等。而且當(dāng)時(shí)互聯(lián)網(wǎng)用戶還比較少，JavaWeb應(yīng)用程序還都比較簡單，一般就是一臺(tái)機(jī)器，如果掛了就人工重啟。

隨著時(shí)代的發(fā)展，互聯(lián)網(wǎng)用戶越來越多，網(wǎng)站的并發(fā)訪問量也越來越大，一臺(tái)機(jī)器已經(jīng)無法滿足我們的需求了，就產(chǎn)生了集群的概念。集群簡單來說就是一群運(yùn)行著相同程序的服務(wù)器，這群服務(wù)器對(duì)外提供的可能只是一個(gè)域名或者反向代理的機(jī)器地址，至于網(wǎng)站到底有多少服務(wù)器以及用戶到底訪問的是哪臺(tái)服務(wù)器，用戶是無感知的。

隨著用戶變得更多，集群愈發(fā)的龐大，我們每一次更新功能都需要將應(yīng)用重新發(fā)布在所有服務(wù)器上，哪怕我們僅僅是改了一個(gè)數(shù)據(jù)庫的地址。而且當(dāng)應(yīng)用越來越復(fù)雜時(shí)，代碼體積也會(huì)越來越龐大，每一次重新運(yùn)行都需要停機(jī)很長時(shí)間。對(duì)于一些用戶量特別多且與金錢密切相關(guān)的系統(tǒng)中，這是我們不能接受的，其中最典型的就是電商。

為了改善上面的痛點(diǎn)，架構(gòu)師根據(jù)業(yè)務(wù)自身的特性將整個(gè)系統(tǒng)拆分成一個(gè)個(gè)的小的系統(tǒng)，比如對(duì)于用戶身份驗(yàn)證有專門的登錄系統(tǒng)，購物車有專門的購物車系統(tǒng)，這些獨(dú)立的功能各自有各自的實(shí)現(xiàn)，但應(yīng)用最終組合起來依然滿足業(yè)務(wù)的需求，而且解決了上述痛點(diǎn)，這各階段應(yīng)該叫做應(yīng)用切分。

應(yīng)用切分雖然解決了應(yīng)用臃腫的問題，但由于應(yīng)用之間是互相獨(dú)立的，所以有些本來相同的業(yè)務(wù)代碼變得不可復(fù)用，比如在應(yīng)用切分中，購物車系統(tǒng)和支付系統(tǒng)都需要訂單系統(tǒng)的支持。但是由于代碼不是共用的，在購物車系統(tǒng)和支付系統(tǒng)中都有著一套和訂單系統(tǒng)進(jìn)行交互的業(yè)務(wù)代碼，比如http請求接口，數(shù)據(jù)轉(zhuǎn)換等。

為了解決在 應(yīng)用切分鐘，系統(tǒng)間代碼冗余度過高的問題，服務(wù)化架構(gòu)出現(xiàn)了。在服務(wù)化架構(gòu)中，系統(tǒng)依然被拆分為多個(gè)應(yīng)用，但與此同時(shí)， 應(yīng)用與應(yīng)用之間相互冗余的部分也被抽取出來了，作為一個(gè)服務(wù)單獨(dú)存在。比如上面講到的購物車系統(tǒng)和支付系統(tǒng)中查詢訂單的業(yè)務(wù)代碼，被提取出來作為一個(gè)訂單查詢服務(wù)而單獨(dú)存在。

而服務(wù)化又帶來了新的痛點(diǎn)。服務(wù)之間相互依賴，一個(gè)服務(wù)既可以作為Provider對(duì)外提供功能，又需要作為Consumer來依靠其他服務(wù)的實(shí)現(xiàn)，所以需要進(jìn)行服務(wù)的治理。然而應(yīng)用并不關(guān)心服務(wù)治理的細(xì)節(jié)，更不關(guān)心服務(wù)到底提供哪些功能。比如在APP上要實(shí)現(xiàn)一個(gè)下單成功的功能，總不能在APP客戶端既要調(diào)用訂單系統(tǒng)的服務(wù)去更新訂單，又要調(diào)用購物車系統(tǒng)提供的服務(wù)去更新購物車吧。而是只需要一個(gè)API，調(diào)用成功就表示用戶成功支付，訂單已完成。而這一的一個(gè)個(gè)應(yīng)用層之間使用的API，也可以被應(yīng)用層看做一個(gè)個(gè)的服務(wù)，這就是微服務(wù)架構(gòu)。其中用來對(duì)這些微服務(wù)中的API進(jìn)行統(tǒng)一管理的模塊通常被稱為網(wǎng)關(guān)。

在微服務(wù)和服務(wù)化架構(gòu)中，不同的服務(wù)之間想要互相通信就只能通過網(wǎng)絡(luò)，而系統(tǒng)之所以被做成服務(wù)化，其中一條主要的原因就是因?yàn)樵L問量巨大，所以不同的功能模塊之間的網(wǎng)絡(luò)通信是一個(gè)極其頻繁的事情。HTTP協(xié)議作為一個(gè)功能強(qiáng)大的網(wǎng)絡(luò)通信協(xié)議，隨之帶來的問題是開銷太大，用在微服務(wù)架構(gòu)下過猶不及。因此，RPC通信協(xié)議產(chǎn)生了，協(xié)議簡單隨之而來的是性能優(yōu)越。

早在Java1.2的時(shí)候，JDK就提供了RPC功能——RMI

RMI的使用起來也很簡單，只需要定義一個(gè)服務(wù)的提供者，服務(wù)的調(diào)用者以及服務(wù)的具體實(shí)現(xiàn)：

服務(wù)的調(diào)用者

整體結(jié)構(gòu)很簡單，服務(wù)提供者通過LocateRegistry注冊實(shí)現(xiàn)了Remote接口的服務(wù)。服務(wù)的調(diào)用者通過Naming，根據(jù)服務(wù)的地址返回服務(wù)的實(shí)現(xiàn)類注冊的實(shí)例，然后服務(wù)調(diào)用方就可以在本地使用這個(gè)實(shí)例實(shí)現(xiàn)功能了。運(yùn)行結(jié)果如下：

Rmi底層也是通過TCP協(xié)議實(shí)現(xiàn)的，我們可以在系統(tǒng)監(jiān)控中看到Provider監(jiān)聽了12345這個(gè)端口：

監(jiān)聽

建立tcp連接

我們可以通過Wireshark抓包來看下Rmi協(xié)議交互的基本流程。因?yàn)镻rovider和Caller都在本地，由于底層優(yōu)化，流量不會(huì)通過網(wǎng)卡，所以Wireshark是抓不到包的，可以裝一個(gè)npcap工具就行了：

wireshark如何抓取本機(jī)包 - Avatarx - 博客園?www.cnblogs.com

之后在Wireshark中使用Npcap的網(wǎng)卡適配器就能抓到本地?cái)?shù)據(jù)了

可以看到最長的一個(gè)數(shù)據(jù)包長達(dá)328個(gè)字節(jié)，即使數(shù)據(jù)看起來應(yīng)該經(jīng)過了特殊處理，還是能夠看到其返回的應(yīng)該是服務(wù)實(shí)現(xiàn)類實(shí)例的一個(gè)代理：

不過由于RMI底層是通過BIO來實(shí)現(xiàn)的，必然無法應(yīng)用在復(fù)雜場景下，所以一些基于NIO的RPC框架產(chǎn)生了，比較典型的有阿里巴巴的Dubbo、HSF，Spring的Spring Cloud等。

總結(jié)

以上是生活随笔為你收集整理的rpc 服务器不可用_RPC和微服务的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。