遠端過程呼叫（Remote Procedure Call，RPC）是一個計算機通訊協議。該協議允許運行於一臺計算機的程式呼叫另一臺計算機的子程式，而程式設計師無需額外地為這個互動作用程式設計。RPC的主要目標是讓構建分散式應用更加容易，在提供強大的遠端呼叫能力的同時不損失本地呼叫的語義的簡潔性。
趁實習前的這段業餘時間，我實現了一個輕量級的分散式RPC框架，名字叫做 buddha（https://github.com/tinylcy/buddha），程式碼量不大，但是麻雀雖小卻五臟俱全。本篇文章將一步步闡明buddha的設計、框架元件的拆解以及需要考慮的因素。
序列化與反序列化
在網路中，所有的資料都將會被轉化為位元組進行傳送，所以在程式碼層面上，一個RPC框架需要實現特定格式的資料與位元組陣列之間的相互轉化。像Java已經提供了預設的序列化方式，但是如果是在高併發的場景下，使用Java原生的序列化方式可能會遇到效能瓶頸。於是，出現了許多開源的、高效的序列化框架：如Kryo、fastjson和Protobuf等。buddha目前支援Kryo和fastjson兩種序列化框架。
TCP拆包、粘包
由於TCP只關心位元組流，並不知曉上層的資料格式。如果客戶端應用層一次要傳送的資料過大時，TCP會將該資料進行分解傳送，因此在服務端需要進行粘包處理（由TCP來保證資料的有序性）；如果客戶端一次要傳送的資料量很小時，TCP並不會馬上把資料傳送出去，而是將其儲存在緩衝區，當達到某個閾值的時候再發送出去，因此在服務端需要進行拆包的工作。
透過以上分析，我們瞭解了TCP粘包或者拆包的原因，解決這個問題的關鍵在於向資料包新增邊界資訊，常用的方法有如下三個。
傳送端給每個資料包新增包首部，首部中至少包含資料包的長度，這樣在接收端接收到資料時，透過讀取首部的長度資訊得到該資料包有效資料的長度。
傳送端將每個資料包封裝為固定長度（多餘用0填充），這樣接收端在接收到資料後根據約定好的固定長度讀取每個資料包的資料。
使用特殊符號將每個資料包區分開來，接收端也是透過該特殊符號的劃分資料包的邊界。
buddha採用第一種方式來解決TCP拆包、粘包的問題。
BIO與NIO
BIO往往用於經典的每連線每執行緒模型，之所以使用多執行緒，是因為像accept()、read()和write()等函式都是同步阻塞的，這意味著當應用為單執行緒且進行IO操作時，如果執行緒阻塞那麼該應用必然會進入掛死狀態，但是實際上此時CPU是處於空閒狀態的。開啟多執行緒，就可以讓CPU去為更多的執行緒服務，提高CPU的利用率。但是在活躍執行緒數較多的情況下，採用多執行緒模型迴帶來如下幾個問題。
執行緒的建立和銷燬代價頗高，在Linux作業系統中，執行緒本質上就是一個程序，建立和銷燬執行緒屬於重量級的操作。
在JVM中，每個執行緒會佔用固定大小的棧空間，而JVM的記憶體空間是有限的，因此如果執行緒數量過多那麼執行緒本身就會佔據過多的資源。
執行緒的切換成本較高，每次執行緒切換需要涉及上下文的儲存、恢復以及使用者態和核心態的切換。如果執行緒數過多，那麼會有較大比例的CPU時間花費線上程切換上。
使用執行緒池的方式解決前兩個問題，但是執行緒切換帶來的開銷還是存在。所以在高併發的場景下，傳統的BIO是無能為力的。而NIO的重要特點是：讀、寫、註冊和接收函式，在等待就緒階段都是非阻塞的，可以立即返回，這就允許我們不使用多執行緒充分利用CPU。如果一個連線不能讀寫，可以把這個事件記錄下來，然後切換到別的就緒的連線進行資料讀寫。在buddha中，Netty被用來編寫結構更加清晰的NIO程式。
服務註冊與發現
在實際應用中，RPC服務的提供者往往需要使用叢集來保證服務的穩定性與可靠性。因此需要實現一個服務註冊中心，服務提供者將當前可用的服務地址資訊註冊至註冊中心，而客戶端在進行遠端呼叫時，先透過服務註冊中心獲取當前可用的服務列表，然後獲取具體的服務提供者的地址資訊（該階段可以進行負載均衡），根據地址資訊向服務提供者發起呼叫。客戶端可以快取可用服務列表，當註冊中心的服務列表發生變更時需要通知客戶端。同時，當服務提供者變為不可用狀態時也需要通知註冊中心服務不可用。buddha使用ZooKeeper實現服務註冊與發現功能。
程式碼實現
buddha是我學習驗證RPC過程中誕生的一個輕量級分散式RPC框架，程式碼放在了 GitHub（https://github.com/tinylcy/buddha）。
參考
RPC 的概念模型與實現解析（http://mindwind.me/blog/2016/05/22/RPC-的概念模型與實現解析.html）
NettyRpc（https://github.com/luxiaoxun/NettyRpc）
遠端過程呼叫（Remote Procedure Call，RPC）是一個計算機通訊協議。該協議允許運行於一臺計算機的程式呼叫另一臺計算機的子程式，而程式設計師無需額外地為這個互動作用程式設計。RPC的主要目標是讓構建分散式應用更加容易，在提供強大的遠端呼叫能力的同時不損失本地呼叫的語義的簡潔性。
趁實習前的這段業餘時間，我實現了一個輕量級的分散式RPC框架，名字叫做 buddha（https://github.com/tinylcy/buddha），程式碼量不大，但是麻雀雖小卻五臟俱全。本篇文章將一步步闡明buddha的設計、框架元件的拆解以及需要考慮的因素。
序列化與反序列化
在網路中，所有的資料都將會被轉化為位元組進行傳送，所以在程式碼層面上，一個RPC框架需要實現特定格式的資料與位元組陣列之間的相互轉化。像Java已經提供了預設的序列化方式，但是如果是在高併發的場景下，使用Java原生的序列化方式可能會遇到效能瓶頸。於是，出現了許多開源的、高效的序列化框架：如Kryo、fastjson和Protobuf等。buddha目前支援Kryo和fastjson兩種序列化框架。
TCP拆包、粘包
由於TCP只關心位元組流，並不知曉上層的資料格式。如果客戶端應用層一次要傳送的資料過大時，TCP會將該資料進行分解傳送，因此在服務端需要進行粘包處理（由TCP來保證資料的有序性）；如果客戶端一次要傳送的資料量很小時，TCP並不會馬上把資料傳送出去，而是將其儲存在緩衝區，當達到某個閾值的時候再發送出去，因此在服務端需要進行拆包的工作。
透過以上分析，我們瞭解了TCP粘包或者拆包的原因，解決這個問題的關鍵在於向資料包新增邊界資訊，常用的方法有如下三個。
傳送端給每個資料包新增包首部，首部中至少包含資料包的長度，這樣在接收端接收到資料時，透過讀取首部的長度資訊得到該資料包有效資料的長度。
傳送端將每個資料包封裝為固定長度（多餘用0填充），這樣接收端在接收到資料後根據約定好的固定長度讀取每個資料包的資料。
使用特殊符號將每個資料包區分開來，接收端也是透過該特殊符號的劃分資料包的邊界。
buddha採用第一種方式來解決TCP拆包、粘包的問題。
BIO與NIO
BIO往往用於經典的每連線每執行緒模型，之所以使用多執行緒，是因為像accept()、read()和write()等函式都是同步阻塞的，這意味著當應用為單執行緒且進行IO操作時，如果執行緒阻塞那麼該應用必然會進入掛死狀態，但是實際上此時CPU是處於空閒狀態的。開啟多執行緒，就可以讓CPU去為更多的執行緒服務，提高CPU的利用率。但是在活躍執行緒數較多的情況下，採用多執行緒模型迴帶來如下幾個問題。
執行緒的建立和銷燬代價頗高，在Linux作業系統中，執行緒本質上就是一個程序，建立和銷燬執行緒屬於重量級的操作。
在JVM中，每個執行緒會佔用固定大小的棧空間，而JVM的記憶體空間是有限的，因此如果執行緒數量過多那麼執行緒本身就會佔據過多的資源。
執行緒的切換成本較高，每次執行緒切換需要涉及上下文的儲存、恢復以及使用者態和核心態的切換。如果執行緒數過多，那麼會有較大比例的CPU時間花費線上程切換上。
使用執行緒池的方式解決前兩個問題，但是執行緒切換帶來的開銷還是存在。所以在高併發的場景下，傳統的BIO是無能為力的。而NIO的重要特點是：讀、寫、註冊和接收函式，在等待就緒階段都是非阻塞的，可以立即返回，這就允許我們不使用多執行緒充分利用CPU。如果一個連線不能讀寫，可以把這個事件記錄下來，然後切換到別的就緒的連線進行資料讀寫。在buddha中，Netty被用來編寫結構更加清晰的NIO程式。
服務註冊與發現
在實際應用中，RPC服務的提供者往往需要使用叢集來保證服務的穩定性與可靠性。因此需要實現一個服務註冊中心，服務提供者將當前可用的服務地址資訊註冊至註冊中心，而客戶端在進行遠端呼叫時，先透過服務註冊中心獲取當前可用的服務列表，然後獲取具體的服務提供者的地址資訊（該階段可以進行負載均衡），根據地址資訊向服務提供者發起呼叫。客戶端可以快取可用服務列表，當註冊中心的服務列表發生變更時需要通知客戶端。同時，當服務提供者變為不可用狀態時也需要通知註冊中心服務不可用。buddha使用ZooKeeper實現服務註冊與發現功能。
程式碼實現
buddha是我學習驗證RPC過程中誕生的一個輕量級分散式RPC框架，程式碼放在了 GitHub（https://github.com/tinylcy/buddha）。
參考
RPC 的概念模型與實現解析（http://mindwind.me/blog/2016/05/22/RPC-的概念模型與實現解析.html）
NettyRpc（https://github.com/luxiaoxun/NettyRpc）