RPC，即 Remote Procedure Call（遠程過程調用），調用遠程計算機上的服務，就像調用本地服務一
樣。 RPC 可以很好的解耦系統，如 WebService 就是一種基于 Http 協議的 RPC。這個 RPC 整體框架
如下：
8.1.3.2. 關鍵技術
1. 服務發布與訂閱：服務端使用 Zookeeper 注冊服務地址，客戶端從 Zookeeper 獲取可用的服務
地址。
2. 通信：使用 Netty 作為通信框架。
3. Spring：使用 Spring 配置服務，加載 Bean，掃描注解。
4. 動態代理：客戶端使用代理模式透明化服務調用。
5. 消息編解碼：使用 Protostuff 序列化和反序列化消息。
8.1.3.3. 核心流程
1. 服務消費方（client）調用以本地調用方式調用服務；
2. client stub 接收到調用后負責將方法、參數等組裝成能夠進行網絡傳輸的消息體；
3. client stub 找到服務地址，并將消息發送到服務端；
4. server stub 收到消息后進行解碼；
5. server stub 根據解碼結果調用本地的服務；
6. 本地服務執行并將結果返回給 server stub；
7. server stub 將返回結果打包成消息并發送至消費方；
8. client stub 接收到消息，并進行解碼；
9. 服務消費方得到最終結果。
RPC 的目標就是要 2~8 這些步驟都封裝起來，讓用戶對這些細節透明。 JAVA 一般使用動態代
理方式實現遠程調用。
8.1.3.1. 消息編解碼
息數據結構（接口名稱+方法名+參數類型和參數值+超時時間+ requestID）
客戶端的請求消息結構一般需要包括以下內容：
1. 接口名稱： 在我們的例子里接口名是“HelloWorldService”，如果不傳，服務端就不知道調用哪
個接口了；
2. 方法名：一個接口內可能有很多方法，如果不傳方法名服務端也就不知道調用哪個方法；
3. 參數類型和參數值：參數類型有很多，比如有 bool、 int、 long、 double、 string、 map、 list，
甚至如 struct（class）；以及相應的參數值；
4. 超時時間：
5. requestID，標識唯一請求 id，在下面一節會詳細描述 requestID 的用處。
6. 服務端返回的消息 ： 一般包括以下內容。返回值+狀態 code+requestID

序列化
? ?目前互聯網公司廣泛使用 Protobuf、 Thrift、 Avro 等成熟的序列化解決方案來搭建 RPC 框架，這
些都是久經考驗的解決方案。
?

總結

以上是生活随笔為你收集整理的rpc核心实现和原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。