RPC全稱Remote Procedure Call，即遠程過程調用。其本質上其實就是主機A通過某種網絡協議向支持相同協議的主機B發送一個任務執行命令，并且在某些情況下，還能支持任務執行結果的返回。

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

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

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

Java服務端開發在早期多指B/S架構下的JavaWeb應用程序開發。開發者遵循Servlet規范將開發好的JavaWeb程序打包成war包運行在支持http/https協議的Servlet容器中，比如tomcat，jetty等。而且當時互聯網用戶還比較少，JavaWeb應用程序還都比較簡單，一般就是一臺機器，如果掛了就人工重啟。

隨著時代的發展，互聯網用戶越來越多，網站的并發訪問量也越來越大，一臺機器已經無法滿足我們的需求了，就產生了集群的概念。集群簡單來說就是一群運行著相同程序的服務器，這群服務器對外提供的可能只是一個域名或者反向代理的機器地址，至于網站到底有多少服務器以及用戶到底訪問的是哪臺服務器，用戶是無感知的。

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

為了改善上面的痛點，架構師根據業務自身的特性將整個系統拆分成一個個的小的系統，比如對于用戶身份驗證有專門的登錄系統，購物車有專門的購物車系統，這些獨立的功能各自有各自的實現，但應用最終組合起來依然滿足業務的需求，而且解決了上述痛點，這各階段應該叫做應用切分。

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

為了解決在 應用切分鐘，系統間代碼冗余度過高的問題，服務化架構出現了。在服務化架構中，系統依然被拆分為多個應用，但與此同時， 應用與應用之間相互冗余的部分也被抽取出來了，作為一個服務單獨存在。比如上面講到的購物車系統和支付系統中查詢訂單的業務代碼，被提取出來作為一個訂單查詢服務而單獨存在。

而服務化又帶來了新的痛點。服務之間相互依賴，一個服務既可以作為Provider對外提供功能，又需要作為Consumer來依靠其他服務的實現，所以需要進行服務的治理。然而應用并不關心服務治理的細節，更不關心服務到底提供哪些功能。比如在APP上要實現一個下單成功的功能，總不能在APP客戶端既要調用訂單系統的服務去更新訂單，又要調用購物車系統提供的服務去更新購物車吧。而是只需要一個API，調用成功就表示用戶成功支付，訂單已完成。而這一的一個個應用層之間使用的API，也可以被應用層看做一個個的服務，這就是微服務架構。其中用來對這些微服務中的API進行統一管理的模塊通常被稱為網關。

在微服務和服務化架構中，不同的服務之間想要互相通信就只能通過網絡，而系統之所以被做成服務化，其中一條主要的原因就是因為訪問量巨大，所以不同的功能模塊之間的網絡通信是一個極其頻繁的事情。HTTP協議作為一個功能強大的網絡通信協議，隨之帶來的問題是開銷太大，用在微服務架構下過猶不及。因此，RPC通信協議產生了，協議簡單隨之而來的是性能優越。

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

RMI的使用起來也很簡單，只需要定義一個服務的提供者，服務的調用者以及服務的具體實現：

服務的調用者

整體結構很簡單，服務提供者通過LocateRegistry注冊實現了Remote接口的服務。服務的調用者通過Naming，根據服務的地址返回服務的實現類注冊的實例，然后服務調用方就可以在本地使用這個實例實現功能了。運行結果如下：

Rmi底層也是通過TCP協議實現的，我們可以在系統監控中看到Provider監聽了12345這個端口：

監聽

建立tcp連接

我們可以通過Wireshark抓包來看下Rmi協議交互的基本流程。因為Provider和Caller都在本地，由于底層優化，流量不會通過網卡，所以Wireshark是抓不到包的，可以裝一個npcap工具就行了：

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

之后在Wireshark中使用Npcap的網卡適配器就能抓到本地數據了

可以看到最長的一個數據包長達328個字節，即使數據看起來應該經過了特殊處理，還是能夠看到其返回的應該是服務實現類實例的一個代理：

不過由于RMI底層是通過BIO來實現的，必然無法應用在復雜場景下，所以一些基于NIO的RPC框架產生了，比較典型的有阿里巴巴的Dubbo、HSF，Spring的Spring Cloud等。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。