rpc原理，和httpclient

 

客戶端（Client），服務的呼叫方。

• 服務端（Server），真正的服務提供者。
• 客戶端存根，存放服務端的地址訊息，再將客戶端的請求引數打包成網路訊息，然後通過網路遠端傳送給服務方。
• 服務端存根，接收客戶端傳送過來的訊息，將訊息解包，並呼叫本地的方法。

dubbo等框架做的事情 通訊問題 : 主要是通過在客戶端和伺服器之間建立TCP連線，遠端過程呼叫的所有交換的資料都在這個連線裡傳輸。連線可以是按需連線，呼叫結束後就斷掉，也可以是長連線，多個遠端過程呼叫共享同一個連線。 定址問題 ： A伺服器上的應用怎麼告訴底層的RPC框架，如何連線到B伺服器（如主機或IP地址）以及特定的埠，方法的名稱名稱是什麼，這樣才能完成呼叫。比如基於Web服務協議棧的RPC，就要提供一個endpoint URI，或者是從UDDI服務上查詢。如果是RMI呼叫的話，還需要一個RMI Registry來註冊服務的地址。 序列化 與 反序列化 ： 當A伺服器上的應用發起遠端過程呼叫時，方法的引數需要通過底層的網路協議如TCP傳遞到B伺服器，由於網路協議是基於二進位制的，記憶體中的引數的值要序列化成二進位制的形式，也就是序列化（Serialize）或編組（marshal），通過定址和傳輸將序列化的二進位制傳送給B伺服器。 同理，B伺服器接收引數要將引數反序列化。B伺服器應用呼叫自己的方法處理後返回的結果也要序列化給A伺服器，A伺服器接收也要經過反序列化的過程。 dubbo只解決了以上問題。但是沒解決服務註冊 服務發現 服務管理 負載均衡（專責）   所以rpc框架的好處 1解耦2負載均衡。專職專司3容錯。服務發現。呼叫方便。像呼叫本地方法一樣簡答4適合介面多的專案。 （寫一大堆 http請求 一大堆介面。難以管理。rpc是加在配置檔案中。然後呼叫去配置檔案中查。而httpclient 是用原生的請求響應模型。簡單方便。） 壞處就是麻煩：代理存根。容錯。需要註冊中心管理 zookeeper可以作為註冊中心 1負載均衡 自動選擇低負載的服務2基於介面找Ip找對應的服務。外部不感知。3容錯。如服務端重啟了。自動回覆。   1 rpc是基於自定義tcp 沒有太多的垃圾資料 而httpclient 基於http協議，做請求響應，要模仿網頁請求，訪問服務端，報文頭垃圾資料較多 簡單直接快速開發 面對小企業特別好用 但是當服務特別多的時候就不那麼好用 2rpc框架都是基於面向服務的，封裝了服務發現和函式代理呼叫，並且優化了效率。