在一次的面試交談中，聊到業務實作的技術架構。不管系統大小，一般都是微服務的架構，是以就産生了一個問題，為什麼服務之間調用，選擇用RPC，http 不也能實作服務之間的通信嗎？怎麼不用呢？或者 RPC 比 http 好在哪裡？
什麼是RPC提到RPC（Remote Procedure Call），就躲不開提到分布式，這個促使RPC誕生的領域。
假設你有一個Calculator，以及它的實作類CalculatorImpl，那麼單體應用時，要調用Calculator的add方法來執行一個加運算，你可以方法中直接使用，
因為在同一個位址空間，或者說在同一塊記憶體，這個稱為本地函數調用。
現在，将系統改造為分布式應用，接口調用和實作分别在兩個子系統内，
服務A裡頭并沒有CalculatorImpl這個類，那它要怎樣調用服務B的CalculatorImpl的add方法呢？可以模仿B/S架構的調用方式，在B服務暴露一個Restful接口，然後A服務通過調用這個Restful接口來間接調用CalculatorImpl的add方法。
這樣，已經很接近RPC了，不過，像這種每次調用時，是不是都需要寫一串發起http請求的代碼呢？比如httpClient.sendRequest...之類的，能不能簡單一下，
像本地方法調用一樣，去發起遠端調用，讓使用者感覺不到遠端調用的過程。
。
這就是很多RPC架構要解決的問題和解決的思路，比如阿裡的Dubbo。
總結一下，
RPC要解決的兩個問題： 1. 解決分布式系統中，服務之間的調用問題。 2. 遠端調用時，要能夠像本地調用一樣友善，讓調用者感覺不到遠端調用的邏輯。 RPC是一種技術的概念名詞RPC=Remote Produce Call 是一種技術的概念名詞，HTTP是一種協定,RPC可以通過 HTTP 來實作,也可以通過Socket自己實作一套協定來實作.是以題目可以換一種了解,為何 RPC 還有除 HTTP 之外的實作法,有何必要，畢竟除了HTTP實作外,私有協定不具備通用性.
RPC架構好處http接口是在接口不多、系統與系統互動較少的情況下，解決資訊孤島初期常使用的一種通信手段；
優點就是簡單、直接、開發友善。
如果是一個大型的網站，内部子系統較多、接口非常多的情況下，RPC架構的好處就顯示出來了：
首先就是長連結，不必每次通信都要像http一樣去3次握手什麼的，減少了網絡開銷；
其次就是RPC架構一般都有注冊中心，有豐富的監控管理；釋出、下線接口、動态擴充等，對調用方來說是無感覺、統一化的操作。
最後是安全性。
rpc是一種概念，http也是rpc實作的一種方式。
論複雜度，dubbo/hessian用起來是超級簡單的。
至于為什麼用dubbo/hessian，有幾點：
一是調用簡單，真正提供了類似于調用本地方法一樣調用接口的功能 。
二是參數傳回值簡單明了 參數和傳回值都是直接定義在jar包裡的，不需要二次解析。
三是 輕量，沒有多餘的資訊。
四是便于管理，基于dubbo的注冊中心。
RPC能解耦服務RPC:遠端過程調用。RPC的核心并不在于使用什麼協定。RPC的目的是讓你在本地調用遠端的方法，而對你來說這個調用是透明的，你并不知道這個調用的方法是部署哪裡。
通過RPC能解耦服務，這才是使用RPC的真正目的。RPC的原理主要用到了動态代理模式，至于
http協定，隻是傳輸協定而已。簡單的實作可以參考spring remoting，複雜的實作可以參考dubbo。
rpc=socket + 動态代理伺服器通訊原理就是一台socket伺服器A,另一台socket用戶端B,現在如果要通訊的話直接以流方式寫入或讀出。這樣能實作通訊，但有個問題。如何知道更多資訊？
比如需要發送流大小，編碼，Ip等。這樣就有了協定，協定就是規範，就是發送的流中攜帶了很多的内容。那回到剛剛的問題。發送的内容就是文本類型，用戶端就得序列化，那麼常用的就有json，xml之類，
如果想把内容變得更小，那就有二進制了。把文本變成二進制傳遞。說到 rpc 與http接口，不要太複雜了。rpc 協定更簡單内容更小，那麼來說效率是要高一點
rpc 是什麼？就是socket 加動态代理。 總結學技術應該是知其然知其是以然，我們得明白什麼場景，或者什麼業務需要它，它能解決其他技術不能解決或者不友善解決的問題。
RPC是一個軟體結構概念，是建構分布式應用的理論基礎。就好比為啥你家可以用到發電廠發出來的電？是因為電是可以傳輸的。至于用銅線還是用鐵絲還是其他種類的導線，也就是用http還是用其他協定的問題了。這個要看什麼場景，對性能要求怎麼樣。
在java中的最基本的就是RMI技術，它是java原生的應用層分布式技術。我們可以肯定的是在傳輸性能方面，RMI的性能是優于HTTP的。
那為啥很少用到這個技術？那是因為用這個有很多局限性，首先它要保證傳輸的兩端都要要用java實作，且兩邊需要有相同的對象類型和代理接口，不需要容器，但是加大了程式設計的難度，在應用内部的各個子系統之間還是會看到他的身影，比如EJB就是基于rmi技術的。
這就與目前的bs架構的軟體大相徑庭。用http必須要服務端位于http容器裡面，這樣減少了網絡傳輸方面的開發，隻需要關注業務開發即可。是以在架構一個軟體的時候，不能一定根據需求標明技術。