技術應該不是為了使用新技術而去使用，而應該是舊技術存在某些瓶頸，存在難以支撐或者擴充套件性越老越差等問題暴露出來之後，用新技術來進行解決。
那rpc最大的優點，或者說它相比簡單的http介面，它的優勢、更適合它的業務場景是怎樣呢？簡單的http又**不足，哪些場景明顯不太適合呢？
rpc=remote produce call 是一種技術的概念名詞.rpc 包括傳輸協議和編碼協議。 http是一種傳輸協議,rpc可以通過http來實現,也可以通過socket自己實現一套協議來實現.
http介面是在介面不多、系統與系統互動較少的情況下，解決資訊孤島初期常使用的一種通訊手段；優點就是簡單、直接、開發方便。利用現成的http協議 進行傳輸。但是如果是乙個大型的**，內部子系統較多、介面非常多的情況下，rpc框架的好處就顯示出來了，首先就是長鏈結，不必每次通訊都要像http 一樣去3次握手什麼的，減少了網路開銷；其次就是rpc框架一般都有註冊中心，有豐富的監控管理；發布、下線介面、動態擴充套件等，對呼叫方來說是無感知、統 一化的操作。第三個來說就是安全性。最後就是最近流行的服務化架構、服務化治理，rpc框架是乙個強力的支撐
rpc是一種概念，http也是rpc實現的一種方式。論複雜度，dubbo/hessian用起來是超級簡單的。最近用dubbo和hessian比較多，http的幾乎都被廢棄了。
ps:更多技術講解請關注360linker官方
，並有資格加入社群免費獲取it技術
，讓你快速精煉漲知識漲技術。
有http了，為什麼還要用rpc？
http 和 rpc 並不是乙個並行概念。http是超文字傳輸協議，應用層網路協議。rpc不是協議，是指遠端過程呼叫，對不同應用間相互呼叫的一種描述。其呼叫協議通常包含傳輸協議和編碼協議 支援http和tcp rpc呼叫是面向服務的封裝，針對服務的可用性和效率等都做了優化。單純使用http呼叫則缺少...
有http 請求，為什麼還要用rpc呼叫？
這個回答裡恰巧講了一些rpc通訊協議的細節，但是強調一遍通訊協議不是rpc最重要的部分，不要被這個回答帶偏了。如果要了解rpc請更多的去了解服務治理 soa 的一些基本策略,推薦去看看dubbo的文件。這個問題其實是有理解誤區的，首先 http 和 rpc 並不是乙個並行概念。rpc是遠端過程呼叫，...
為什麼有了scanf還要getchar
getchar在scanf 後，可以吸收回車符，以便輸入下乙個字元。如 int n char a scanf d n getchar 清除回車符 scanf c a 參考網頁 本markdown編輯器使用stackedit修改而來，用它寫部落格，將會帶來全新的體驗哦 markdown 是一種輕量級標...