（僅供參考，學習備忘）
首先說一下HTTP三次握手：
（1）瀏覽器向服務器發出請求，握手第一步java
（2）服務器迴應瀏覽器的請求，並要求確認，握手第二步spring
（3）瀏覽器迴應服務器的確認，鏈接成功，握手第三步編程
（4）瀏覽器發出一個頁面HTTP GET請求。小程序
目前有不少Java的RPC框架，有基於Json的，有基於XML，也有基於二進制對象的。
論複雜度，RPC框架確定是高於簡單的HTTP接口的。但毋庸置疑，HTTP接口因爲受限於HTTP協議，須要帶HTTP請求頭，致使傳輸起來效率或者說安全性不如RPC。
如今問題是，遇到怎樣的瓶頸了才須要或者說更適合用RPC（好比像阿里這麼大的請求併發量，簡單的HTTP確定達不到預期），但問題是你們所在的公司，要有像阿里這麼大的量是比較少的，甚至說1/1000的量可能都沒有，那咱們還須要使用RPC嗎？
技術應該不是爲了使用新技術而去使用，而應該是舊技術存在某些瓶頸，存在難以支撐或者擴展性越老越差等問題暴露出來以後，用新技術來進行解決。
那RPC最大的優勢，或者說它相比簡單的HTTP接口，它的優點、更適合它的業務場景是怎樣呢？簡單的HTTP又哪裏不足，哪些場景明顯不太適合呢？
RPC=Remote Produce Call 是一種技術的概念名詞. HTTP是一種協議,RPC能夠經過HTTP來實現,也能夠經過Socket本身實現一套協議來實現.因此能夠換一個問法,爲什麼RPC還有除HTTP 以外的實現法,有何須要.畢竟除了HTTP實現外,私有協議不具有通用性.那麼我想惟一的答案就在於HTTP不能知足其業務場景的地方,因此這個就要具體 案例具體分析了.
http接口是在接口很少、系統與系統交互較少的狀況下，解決信息孤島初期常使用的一種通訊手段；優勢就是簡單、直接、開發方便。利用現成的http協議 進行傳輸。可是若是是一個大型的網站，內部子系統較多、接口很是多的狀況下，RPC框架的好處就顯示出來了，首先就是長連接，沒必要每次通訊都要像http 同樣去3次握手什麼的，減小了網絡開銷；其次就是RPC框架通常都有註冊中心，有豐富的監控管理；發佈、下線接口、動態擴展等，對調用方來講是無感知、統 一化的操做。第三個來講就是安全性。最後就是最近流行的服務化架構、服務化治理，RPC框架是一個強力的支撐
rpc是一種概念，http也是rpc實現的一種方式。論複雜度，dubbo/hessian用起來是超級簡單的。最近用dubbo和hessian比較多，http的幾乎都被廢棄了。
至於爲何用，其實很簡單，業務場景不同。我最先的單位全部的代碼都在一個工程裏，一次要發佈幾百m的代碼。這種架構是很是有利於小程序的。可是咱們爲何要應用rpc層呢，一個功能，一套代碼下來不就解決了麼？我以爲有幾個好處：
1 靈活部署 2 解耦 至於爲何，當你用到的時候，你會體會。
系統作大了，確定是須要作微服務的。 如今咱們作電商就是這樣，單獨有一個訂單系統，支付系統，商品系統，用戶系統。都是分開部署，單獨上線的。 但咱們交互是用HTTP接口來交互的，我想轉用RPC，但問題是我如今還沒發現爲何須要用RPC，我還沒能理解它的做用和意義。
用http交互其實就已經屬於rpc了。
RPC:遠程過程調用。RPC的核心並不在於使用什麼協議。RPC的目的是讓你在本地調用遠程的方法，而對你來講這個調用是透明的，你並不知道這個調用的方法是部署哪裏。經過RPC能解耦服務，這纔是使用RPC的真正目的。RPC的原理主要用到了動態代理模式，至於http協議，只是傳輸協議而已。簡單的實現能夠參考spring remoting，複雜的實現能夠參考dubbo。
RPC是一個軟件結構概念，是構建分佈式應用的理論基礎。就比如爲啥你家能夠用到發電廠發出來的電？是由於電是能夠傳輸的。至於用銅線仍是用鐵絲仍是其餘 種類的導線，也就是用http仍是用其餘協議的問題了。這個要看什麼場景，對性能要求怎麼樣。好比在java中的最基本的就是RMI技術，它是java原 生的應用層分佈式技術。咱們能夠確定的是在傳輸性能方面，RMI的性能是優於HTTP的。那爲啥不多用到這個技術？那是由於用這個有不少侷限性，首先它要 保證傳輸的兩端都要要用java實現，且兩邊須要有相同的對象類型和代理接口，不須要容器，可是加大了編程的難度，在應用內部的各個子系統之間仍是會看到 他的身影，好比EJB就是基於rmi技術的。這就與目前的bs架構的軟件截然不同。用http必需要服務端位於http容器裏面，這樣減小了網絡傳輸方面 的開發，只須要關注業務開發便可。因此在架構一個軟件的時候，不能必定根據需求選定技術。
總結：RPC主要用於公司內部的服務調用，性能消耗低，傳輸效率高，服務治理方便。HTTP主要用於對外的異構環境，瀏覽器接口調用，APP接口調用，第三方接口調用等。
瀏覽器