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框架都是基於面向服務的，封裝了服務發現和函數代理調用，並且優化了效率。