很多語言都內置了RPC技術。
Java RMI
.NET Remoting
遠古時期，就有很多嘗試：
- Corba（Common ObjectRequest Broker Architecture）公共對象請求代理體系結構，OMG組織在1991年提出的公用對象請求代理程序結構的技術規範。底層結構是基於面向對象模型的，由OMG接口描述語言(OMG Interface Definition Language，OMG IDL)、對象請求代理(Objec tRequest Broker，ORB)和IIOP標準協議（Internet Inter ORB Protocol，也稱網絡ORB交換協議）3個關鍵模塊組成。
- COM（Component Object Model，組件對象模型）是微軟公司於1993年提出的一種組件技術，它是一種平臺無關、語言中立、位置透明、支持網絡的中間件技術。很多老一輩程序員心目中的神書《COM本質論》。
1 從使用者考慮
定義過程接口
客戶端使用生成的stub代理對象
2 客戶端的設計
客戶端生成過程接口的代理對象。
客戶端代理工廠，用JDK動態代理（或者 AOP 實現）即可生成接口的代理對象。
-
ClientStubInvocationHandler
消息協議是固定不變的嗎?它與什麼有關?
看框架對協議的支持廣度，如果支持多種協議，就是會靈活變化的，它與具體的服務相關，
A服務提供者可能選用的是協議1，B服務提供者可能選用協議2。某服務是用的什麼消息協議這個信息從哪來?
從獲取的服務信息中來，因此需要一個服務信息發現者。
把發現者設計出來, 要求:可靈活支持多種發現機制
-
想要做到可以支持多種協議，類該如何設計?面向接口、策略模式、組合
問題:
➢ marshalling和unmarshalling方法該定義怎樣的參數與返回值?
➢ 編組、解組的操作對象是請求、響應，請求、響應的內容是不同的。編組、解組兩個方法是否滿足?
設計客戶端協議層
定義框架標準的請求, 響應類
-
將協議層擴展爲四個
消息協議獨立爲一層(客戶端、服務端均需要)
網絡層
發送請求,獲得響應
要發起網絡請求,則須知道服務地址
-
客戶端完整類圖
在實現過程中，協議層涉及一個重要概念
- 參數序列化、反序列
3 設計服務端
3.1 RPCServer
客戶端請求過來了，服務端首先需要通過RPCServer接收請求。
-
RPCServer
3.2 思考
RPCServer接收到客戶端請求後，還需要做哪些工作?
網絡層在RPCServer中提供多線程來處理請求，消息協議層複用客戶端設計的。
(設計一個請求處理類，來完成網絡層以上的事情。)
3.3 RequestHandler
RPCServer接收到請求後，將請求交給RequestHandler來處理
RequestHandler調用協議層來解組請求消息爲Request對象，然後調用過程!
人性的拷問
➢ RequestHandler如何得到過程對象?
➢ Request中有什麼?
➢ 服務名、方法名、參數類型、參數值
➢ 是否需要一個過程註冊模塊?
看看之後的設計
➢ 過程註冊模塊:讓用戶將他們的過程註冊到RPC框架
➢ 過程暴露模塊:想對外發布(暴露)服務註冊、暴露可以由同一個類實現
- RPCServer 中實現網絡層: Netty, 使用RequestHandler
- ServiceRegister 模塊實現服務註冊、發佈。
- RequestHandler 中實現消息協議處理、過程調用
代碼實現
-
首先,用戶需要設置你的端口和協議哦