系統如果元件比較多，在做技術選型時，元件通訊該選擇rpc還是http呢？
有人說rpc效能好，有人偏向http，對此有些疑惑，有必要細細思維一下。

從通訊內容/功能上看

http應用於web環境，rpc應用於分散式排程
從功能上看沒有太大區別，很多情況下rpc與訊息中介軟體結合通訊實現分散式排程

從用法上看

兩者都是c/s結構，無太大區別

從實現上看

從效能上看

1. 聽說rpc是長連結，http是三次握手。
   長連結雖然，可以減少tcp開銷，相對的它會匯入新的缺點，是否會對連線數數量有限制呢？

2. 假如rpc的效能比http高,無非就是socket多連線了三次。如果http結合非阻塞io伺服器(例如tornado)，這三次連線開銷真沒啥消耗。
   當然網路也會有一點消耗. 非阻塞io伺服器可以將rpc與http的效能差距拉平

從連結開銷上，比較效能問題，本就是錯誤，兩者是在解決不同問題，所有沒有必要在這個問題上糾結。請繼續看下面

從概念上看

rpc遠端呼叫
http超文字傳輸協議

該如何選擇呢？

1. 思考這個問題，應該用最簡單的方式，相信協議設計者，會選擇最好方式來解決它面臨的問題(畢竟協議代表著公認)，我們只用關注它解決什麼問題。
   rpc解決什麼問題呢？遠端呼叫。“呼叫”屬於程式內部之間。呼叫總不可能只傳簡單引數，會涉及到物件序列化，
   這個物件在開發是程式碼總不會用兩套吧，server與client很可能是在一起的屬於一個元件.

2. 連線數不該是”呼叫”考慮的事。在建立一個全域性連線後，不會再頻繁建立連線. 如果rpc作為服務，頻繁連線的場景不適合它

總結

1. c與s關係緊密程度
   rpc遠端呼叫，屬於程式內部之間，cs關係密切。
   http，適合不同元件, cs關係獨立。

2. 連線數
   rpc叫呼叫，頻繁連線的場景不適合它
   http的應用的web環境，本就是頻繁連線的場景