RPC的設計思想及原理圖
解決了RPC的呼叫問題，現在還要解決的一個關鍵問題是，客戶端怎麼知道呼叫哪一臺機器上的服務。這就需要引入一箇中間的第三者目標伺服器
服務提供者向目標伺服器註冊服務，客戶機從目標伺服器（一種叫法叫服務註冊中心）中獲取可呼叫的機器列表。如果有用過類似dubbo這樣的RPC框架是不是對這個圖很熟悉？因為所有的RPC架構的原理大多都是類似的。服務提供者往目標伺服器裡面通常會註冊機器的ip和埠資訊。
下面我們來談下RPC的好處和注意的地方。
好處：遮蔽了底層通訊的複雜性，在分散式系統中提供了通訊的透明性。
需要注意的地方：RPC是點對點的通訊方式，要求通訊兩端必須同時執行，當其中一端掛了就會導致通常異常，並且呼叫者一般會阻塞住等待結果的返回，效能相對不是很高，當然也有非同步RPC，超時重試情況下服務端提供者需要做好服務冪等性處理。相對於RPC而言採用了面向訊息通訊模型的架構比如MQ則不要求通訊兩端同時執行，傳送訊息時也不需要阻塞等待處理結果的返回通訊效能就高出很多。
最後我們總結一下：RPC呼叫是指不同機器間的程序通訊。程式不需要關心某個遠端服務是在哪臺機器上執行的，遠端服務呼叫就和呼叫本地服務一樣。要在不同機器間進行通訊我們需要知道通訊機器的ip和埠號。ip幫助我們定位是哪一臺機器，埠號幫我們定位是機器上的哪一個程序。RPC的出現使用得機器的程序通訊透明化，這在分散式系統中是很重要的。RPC呼叫架構中客戶端和服務端都和一個叫服務註冊中心的第三方通訊。
原文連結：https://www.cnblogs.com/linlinismine/p/9205676.html
您的資助是我最大的動力！
金額隨意,歡迎來賞！
如果，您希望更容易地發現我的新部落格，可以關注我哦！【關注我】。
如果，想給予我更多的鼓勵，這可以支付寶掃碼哦！求打因為，我的寫作熱情也離不開您的肯定支援，感謝您的閱讀，我是【未來可期】！