在微服務中,使用什麼協議來構建服務體系,一直是個熱門話題。 爭論的焦點集中在兩個候選技術: (binary) RPC or Restful。前端
以Apache Thrift爲表明的二進制RPC,支持多種語言(但不是全部語言),四層通信協議,性能高,節省帶寬。相對Restful協議,使用Thrifpt RPC,在同等硬件條件下,帶寬使用率僅爲前者的20%,性能卻提高一個數量級。可是這種協議最大的問題在於,沒法穿透防火牆。服務器
以Spring Cloud爲表明所支持的Restful 協議,優點在於可以穿透防火牆,使用方便,語言無關,基本上可使用各類開發語言實現的系統,均可以接受Restful 的請求。 但性能和帶寬佔用上有劣勢。網絡
因此,業內對微服務的實現,基本是肯定一個組織邊界,在該邊界內,使用RPC; 邊界外,使用Restful。這個邊界,能夠是業務、部門,甚至是全公司。運維
使用RPC遠程服務調用方式與傳統http接口直接調用方式的差異在於:微服務
1. 從使用方面看,Http接口只關注服務提供方,對於客戶端怎麼調用,調用方式怎樣並不關心,一般狀況下,咱們使用Http方式進行調用時,只要將內容進行傳輸便可,這樣客戶端在使用時,須要更關注網絡方面的傳輸,比較不適用與業務方面的開發;而RPC服務則須要客戶端接口與服務端保持一致,服務端提供一個方法,客戶端經過接口直接發起調用,業務開發人員僅須要關注業務方法的調用便可,再也不關注網絡傳輸的細節,在開發上更爲高效。性能
2. 從性能角度看,使用Http時,Http自己提供了豐富的狀態功能與擴展功能,但也正因爲Http提供的功能過多,致使在網絡傳輸時,須要攜帶的信息更多,從性能角度上講,較爲低效。而RPC服務網絡傳輸上僅傳輸與業務內容相關的數據,傳輸數據更小,性能更高。代理
3. 從運維角度看,使用Http接口時,經常使用一個前端代理,來進行Http轉發代理請求的操做,須要進行擴容時,則須要去修改代理服務器的配置,較爲繁瑣,也容易出錯。而使用RPC方式的微服務,則只要增長一個服務節點便可,註冊中心可自動感知到節點的變化,通知調用客戶端進行負載的動態控制,更爲智能,省去運維的操做。blog
http://blog.lixf.cn/essay/2017/02/17/microservice-7-rpc/接口
https://www.zhihu.com/question/28570307開發