一、首先說明什麼是RPC？
RPC是指遠程過程調用，也就是說兩臺服務器A，B。一個應用部署在A服務器上，想要調用B服務器上應用提供的函數/方法，但是由於兩個應用程序不在一個內存空間，不能直接調用，需要通過網絡來表達調用的語義和傳達調用的數據。
RPC 解決了什麼問題？讓分佈式或者微服務系統中不同服務之間的調用像本地調用一樣簡單。
二、HTTP和RPC的區別
只要是遠程調用都可以叫RPC，不管通過什麼方式，所以：
其實HTTP就是一種RPC，HTTP通過一定的方法去調用HTTP服務器的某個procedure，執行完以後把結果返回。但是在一些特定的場景，我們覺得標準的HTTP太慢/太複雜等待，我們就會自己定義一種新的方式。
HTTP的"臃腫"：
通常定義的HTTP1.1（HTTP2.0已經優化編碼問題了）協議中包含太多廢信息：比如報頭的鍵值對使用的是文本編碼，非常佔字節數，使得無效報文佔比非常高。
而RPC通常使用自定義的TCP協議來進行通信，TCP的報頭只有16個字節，極大提高了傳輸效率。
三、實現一個RPC
-
首先，要解決通信的問題，主要是通過在客戶端和服務端直接建立TCP連接
-
第二，要解決尋址的問題，即要告知RPC框架服務器的IP地址以及特定的端口，方法的名稱等等。
-
數據在網絡中傳輸時，是以二進制進行的，固需要進行序列化
-
服務端收到請求後，進行反序列化，然後找到對應的方法，進行本地調用，得到返回值
-
把返回值序列化後發給客戶端，客戶端進行反序列化後得到結果。
四、常見的 RPC 框架總結
這裏只介紹較主流的兩種：
Dubbo: Dubbo是 阿里巴巴公司開源的一個高性能優秀的服務框架，使得應用可通過高性能的 RPC 實現服務的輸出和輸入功能，可以和 Spring框架無縫集成。目前 Dubbo 已經成爲 Spring Cloud Alibaba 中的官方組件。
Thrift： Apache Thrift是Facebook開源的跨語言的RPC通信框架，目前已經捐獻給Apache基金會管理，由於其跨語言特性和出色的性能，在很多互聯網公司得到應用，有能力的公司甚至會基於thrift研發一套分佈式服務框架，增加諸如服務註冊、服務發現等功能。
-
要實現一個RPC不算難，難的是實現一個高性能高可靠的RPC框架：
比如，既然是分佈式了，那麼一個服務可能有多個實例，你在調用時，要如何獲取這些實例的地址呢？
這時候就需要一個服務註冊中心，比如在Dubbo裏頭，就可以使用Zookeeper作爲註冊中心，在調用時，從Zookeeper獲取服務的實例列表，再從中選擇一個進行調用。
那麼選哪個調用好呢？這時候就需要負載均衡了，於是你又得考慮如何實現複雜均衡，比如Dubbo就提供了好幾種負載均衡策略。
這還沒完，總不能每次調用時都去註冊中心查詢實例列表吧，這樣效率多低呀，於是又有了緩存，有了緩存，就要考慮緩存的更新問題，blablabla……
你以爲就這樣結束了，沒呢，還有這些：
-
客戶端總不能每次調用完都乾等着服務端返回數據吧，於是就要支持異步調用；
-
服務端的接口修改了，老的接口還有人在用，怎麼辦？總不能讓他們都改了吧？這就需要版本控制了；
-
服務端總不能每次接到請求都馬上啓動一個線程去處理吧？於是就需要線程池；
-
服務端關閉時，還沒處理完的請求怎麼辦？是直接結束呢，還是等全部請求處理完再關閉呢？
-
……
如此種種，都是一個優秀的RPC框架需要考慮的問題。
當然，接下來我們還是先實現一個簡單的RPC，再在上面一步步優化！