其實計算機里面的很多概念都是來源於現實世界的，通過現實里面具體的例子來理解RPC。A：代表一棟大樓（相當於一個大的服務端內網集群），B：代表大樓內的一個個房間（每個房間相當於一個應用框架)，C：代表人員管理機構（相當於樓管處或者各級人口管理部門）。首先，在項目架構比較簡單的時候，可能一個項目就一個統一的框架，一種語言，這時候我們程序里面的一個方法里面可能會調用N個其他的方法，但因為都是在同一個框架內，都屬於框架級的內部調用，這個時候自然用不到RPC，RESTful足以滿足當前場景。 但是當你的項目架構越來越復雜，訪問量越來越多的時候，可能上了N多框架，N個語言，當你在業務里面調用其他框架的方法或者調用其他獨立部署的服務的時候，自然沒法像最初那樣直接在框架/容器的內部去調用，當這種框架和容器間的這種調用量不是很大的時候依然可以選擇用RESTful方式去調用，但是當這種調用量很大，服務很多的時候，RESTful顯然是無法滿足需求的。
打個比方，最初的內部調用相當於你要找的人和你在同一個房間內，直接就可以找到。但當要找的人分散在大樓的各個房間的時候，你怎么找他呢？你可以去區里人口部門查，查不到去市里 - 省里 - 國家人口管理部門查，最終肯定總能找到他，但這樣的方式是不是效率很低，路徑很長？所以這個時候就來了RPC解決了這個問題，我們在該大樓一樓建立了統一的樓管處（服務注冊中心），該出記錄了大樓里面每個人的詳細信息，每個人要先去登記（服務注冊），要查的時候直接去樓管處查（服務發現）就可以了。當然你可以直接走路（HTTP協議）去查，也可以直接打電話（TCP協議）去樓管處查，也可以微信群（自定義協議）去查。 首先該樓管處記錄的信息量非常小（只記錄你們大樓的人），非常垂直和精確，所以你去查的速度會非常快，路徑會非常短。 如果你還用傳統RESTful的方式，首先查找范圍會非常大，因為你根本不知道這個人到底在哪里，他可能在你們大樓內，也可能在本市某個角落的大樓里面，還可能在幾千公里外的另一個城市，你查找的目標范圍會非常大，路徑會非常長，不確定性非常大。所以最終的效率肯定是非常低的。
RPC和RESTful的區別
RPC的優勢：
- 是查找的精確性，快速性，短路徑，和確定性，因為屬於內網查詢，獨立的注冊中心，所以查找的速度更快。
- 而且由於做了精簡和優化，刪去了RESTful方式里面很多多余的信息，比如Header，而且做了壓縮和序列化，通過二進制方式傳輸，傳輸的內容更少，傳輸的速度也更快。
- 環節和流程更少，因為RESTful需要經過路由，負載均衡，網關，防火牆和一系列的身份識別和校驗，就像大樓內來了個不認識的人，樓管大叔肯定要查你的身份證等等信息核實你的信息。 而且RPC就省去了這些環節，就像你天天出來進去，樓管大媽早就對你很熟了，不需要每次核實你的信息，RPC省去了很多環節。
RESTful的優勢：
- 通用性更好，RESTful可以供任何接入互聯網的終端調用，各種平台，各種終端都可以用RESTful傳輸和交換數據，而且有一套標准和規范的傳輸格式，所以格式更加標准化和通用化。
- 安全性更高，因為屬於連接外圍和內網的通道，所以會經過一些列的安全和身份校驗。
- 移植性更好，從一個服務器遷移到另一個服務器，從一個節點遷移到另一個節點，從一個架構移植到另一種架構，都可以輕松完成。
RPC的應用場景：當你的框架和語言種類也比較多，內部之間調用量非常大的時候，RPC是最佳的選擇。RPC更多是內網之間的數據傳輸，一般是部署在服務層的分布式系統里面，或者微服務系統。有服務治理，服務限流、服務降級、服務熔斷、服務監控等等，類似於大樓里面配了治安處，物業處、后勤處、監控中心等。
RESTful的應用場景：數據更多是公網上的傳輸，比如服務端API供 IOS、Android、PC等客戶端調用， API供第三方合作方調用等 。