rpc概述
第三方rpc
hadoop v2的rpc簡述
那麼，下面開始今天的學習之路。
首先，我們要弄明白，什麼是rpc？rpc能用來做什麼？
rpc的全程是remote procedure
call，中文釋為遠端過程調用。也就是說，調用的過程代碼（業務服務代碼）并不在調用者本地運作，而是要實作調用着和被調用着之間的連接配接通信，有同學可
能已經發現，這個和c/s模式很像。沒錯，rpc的基礎通信模式是基于c/s程序間互相通信的模式來實作的，它對client端提供遠端接口服務，其
rpc原理圖如下所示：
我們都知道，在過去的程式設計概念中，過程是由開發人員在本地編譯完成的，并且隻能局限在本地運作的某一段代碼，即主程式和過程程式是一種本地調用
關系。是以，這種結構在如今網絡飛速發展的情況下已無法适應實際的業務需求。而且，傳統過程調用模式無法充分利用網絡上其他主機的資源，如cpu，記憶體
等，也無法提高代碼在bean之間的共享，使得資源浪費較大。
而rpc的出現，正好有效的解決了傳統過程中存在的這些不足。通過rpc，我們可以充分利用非共享記憶體的機器，可以簡便的将應用分布在多台機器上，類似叢集分布。這樣友善的實作過程代碼共享，提高系統資源的使用率。減少單個叢集的壓力，實作負載均衡。
在學習hadoop v2的rpc機制之前，我們先來熟悉第三方的rpc機制是如何工作的，下面我以thrift架構為例子。
thrift是一個軟體架構，用來進行可擴充且跨語言的服務開發協定。它擁有強大的代碼生成引擎，支援
c++，java，python，php，ruby等程式設計語言。thrift允許定義一個簡單的定義檔案（以.thirft結尾），檔案中包含資料類型和
下面給出thrift的原理圖，如下所示：
下面為大家解釋一下上面的原理圖，首先，我們編譯完thrift定義檔案後（這裡我使用的是java語言），會生成對應的java類檔案，該類
的iface接口定義了我們所規範的接口函數。在服務端，實作iface接口，編寫對應函數下的業務邏輯，啟動服務。用戶端同樣需要生成的java類文
件，以供client端調用相應的接口函數，監聽服務端的ip和port來擷取連接配接對象。
server端代碼：
client端代碼：
statqueryservice類：
這個類的代碼量太大，暫不貼出。需要的同學請到以下位址下載下傳。
下載下傳位址：[email protected]:dengjie/resource.git
statqueryserviceimpl類：
下面實作其中一個函數的内容，代碼如下所示：
hadoop v2中的rpc采用的是自己獨立開發的協定，其核心内容包含服務端，用戶端，互動協定。源碼内容都在hadoop-common-project項目的org.apache.hadoop.ipc包下面。
versionedprotocol類：
該類中的兩個方法一個是作為版本，另一個作為簽名用。
rpc下的server類：
對外提供服務，處理client端的請求，并傳回處理結果。
至于client端，監聽server端的ip和port，封裝請求資料，并接受response。
這篇部落格贅述了rpc的相關内容，讓大家先熟悉一下rpc的相關機制和流程，并簡述了hadoop v2的rpc機制，關于hadoop v2的rpc詳細内容會在下一篇部落格中給大家分享。這裡隻是讓大家先對hadoop v2的rpc機制有個初步的認識。
這篇部落格就和大家分享到這裡，如果大家在研究學習的過程當中有什麼問題，可以加群進行讨論或發送郵件給我，我會盡我所能為您解答，與君共勉！
<b></b>