前言:以前對於RPC方面的學習多限於對RMI原理的學習,直到今天在看陳康賢前輩的《大型分佈式網站架構-設計與實踐》這本書的時候,才發現原來RPC能夠基於TCP協議也能夠基於HTTP協議(這裏所說的TCP協議與HTTP協議更多的是指服務的消費者與遠端的提供方的一種鏈接或消息傳送形式),在此就簡單記錄一下,做爲以後研究其它相似框架的基礎。java
RPC全稱Remote Process Call,即遠程過程調用,其在服務的調用方與服務的提供方的調用大體以下圖所示(左邊爲一對一,右邊爲多對多)。在理解PRC基於這兩種協議前,首先要明確RPC的主要目的只是獲取由遠程機器上的程序所執行的結果。服務器
在Java中,能夠利用Socket API實現基於TCP協議的RPC調用,由服務的調用方與服務的提供方創建Socket鏈接,並由服務的調用方經過Socket將須要調用的接口名稱、方法名稱和參數序列化後傳遞給服務的提供方,服務的提供方反序列化後再利用反射調用相關的方法,最後將結果返回給服務的調用方。整個基於TCP協議的PRC調用大體如此,可是在實例應用中則會進行一系列的封裝,譬如RMI即是在TCP協議上傳遞可序列化的java對象。網絡
而基於HTTP協議的RPC調用則更像是咱們訪問網頁同樣,只是它的返回結果更加單一簡單。其大體流程爲:由服務的調用者向服務的提供者發送請求,這種請求的方式多是GET、POST、PUT、DELETE等中的一種(服務的提供者可能會根據不一樣的請求方式作出不一樣的處理,或者某個方法只容許某種請求方式),而調用的具體方法則根據URL進行方法調用,而方法所需參數則多是對服務調用方傳輸過去的XML數據或JSON數據解析後的結果,最後返回JOSN或XML的數據結果(這須要根據實際應用定義相關的協議)。因爲目前有不少開源的WEB服務器,如Tomcat,JBoss等,因此其實現起來更加容易(就跟作Web項目同樣)。架構
而基於TCP協議實現的RPC調用,因爲TCP協議處於協議棧的下層,可以更加靈活地對協議字段進行定製,減小網絡開銷,提升性能,實現更大的吞吐量和併發數。可是須要更多地關注底層複雜的細節,實現的代價更高。同時對於不一樣平臺(如安卓、IOS等),須要從新開發出不一樣的工具包來進行請求發送和響應解析,工做量大,難以快速響應和知足 用戶需求。併發
基於HTTP協議實現的RPC則能夠使用JSON和XML格式的請求或響應數據,而JSON和XML做爲通用的格式標準,開源的解析工具已經至關成熟,在其上進行二次開發會很是便捷和簡單。可是因爲HTTP協議是上層協議,發送包含同等內容的信息,使用HTTP協議傳輸所佔用的字節數會比使用TCP協議傳輸所佔用的字節數更高。所以,同等網絡環境下,經過HTTP協議傳輸相同內容,效率會比基於TCP協議的數據效率要低,信息傳輸所佔的時間也會更長,固然使用gzip壓縮數據,可以縮小這一差距。框架
注:以上僅爲我的筆記,未做詳細分析,甚至因爲我的知識面的不足,會顯得特別粗糙,若有錯誤或不當的地方,還請指正。另外,本文後兩段摘抄至陳康賢前輩的《大型分佈式網站架構-設計與實踐》,如需瞭解更多詳細內容,請閱讀原書。分佈式