在實際後臺服務開發中,好比訂單服務(開發者A負責)須要調用商品服務(開發者B負責),那麼開發者B會和A約定調用API,以接口的形式提供給A。一般都是B把API上傳到Maven私服,而後B開始寫API的實現,A只須要引入API依賴進行開發便可。 網絡
注意,我將商品服務的API以及實現分爲Maven的2個模塊來開發。這裏,咱們想給定一個商品ID,查詢獲得商品對象信息。ide
要注意的是,Product是能夠被序列化的,Why?3d
很顯然,訂單系統調用商品系統的時候,須要商品系統返回一個商品,必然涉及到發生網絡傳輸,這就涉及對象的序列化和反序列化了。代理
在訂單系統工程中須要引入商品服務API依賴。對象
在上圖代碼中,最重要的就是rpc方法了!blog
第一,咱們看到了Proxy.newProxyInstance,很顯然在進行動態代理。也便是說,在訂單服務調用商品服務的代碼中,咱們先是經過動態代理返回一個代理的IProductService類型對象,這意味着當代理對象調用queryById方法的時候,會自動調用invoke方法!接口
第二,咱們看看invoke到底作了些什麼?開發
它本質上就是進行Socket通訊,那麼它須要傳遞什麼信息給到商品服務呢?rpc
咱們知道訂單系統就是想調用商品服務的某個類的某個方法,而後把這個方法的返回結果傳輸給訂單系統!it
想想,如何調用某個類的某個方法呢?
只要咱們能肯定這個類的全限定類名、肯定方法名、肯定方法的參數類型,給定方法須要的具體參數,經過反射就能實現。
商品服務調用後獲得的結果,咱們序列化寫入Socket流中,在訂單系統中反序列化獲得對象便可。
第三,這裏須要思考一個問題:在訂單系統中咱們只知道商品服務的API,並不知道這背後的API究竟是如何實現的,因此咱們須要有一個映射,就是商品服務的API到商品服務的實現的一個映射關係,其實這就是所謂的服務的註冊!
從這裏,能夠清晰的看到,商品服務讀取了訂單系統調用商品系統時發送的數據,利用反射機制,進行方法調用,並把調用結果寫入Socket輸出流。
啓動商品服務後,經過訂單系統發起對商品服務的調用。
之前總認爲RPC是高不可攀的,感受是個很神奇的東西,實際上它的底層實現不就是這樣的麼~