摘要：
本文介紹了分佈式框架的簡單實現，說明了自己的設計思路，以及RPC的一些具體細節。在文末，貼出一些關於rpc的資料。
0x00:什麼是RPC
wiki給出的定義如下：In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space (commonly on another computer on a shared network), which is coded as if it were a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction.也就是說rpc實際上是這樣的一項技術，他使得開發人員能夠像調用本地方法一樣的調用遠程方法。使得我們可以完全解耦服務端和客戶端。隨着計算資源和網絡資源的進步，RPC可以說會變得越來越流行。在我剛開始接觸RPC時，我一直在想，既然是遠程方法調用，我們之前對於網絡服務的獲取，不是可以通過http來獲取麼，隨着對於RPC的學習，我發現這兩者其實並不衝突，只不過應用的場景不同罷了。可以簡單的這麼理解，http和rpc作爲交通工具，各自有着不同的使用場景，儘管去某個目的地，可能自行車和汽車都能到達，但是我們還是會根據路況和路程來綜合考量我們的選擇。
0x01:從功能倒推實現
既然我們想設計這樣的一款框架，他能夠替我們屏蔽掉所有的RPC實現細節，讓我們感覺起來就像在使用本地方法調用，那麼最終的接口應該看起來像這樣的：
(remote-call service-name service-paras)
這樣的封裝使得客戶端絲毫感受不到遠程服務的存在，這也就屏蔽掉了RPC的細節，使得客戶端能夠完全聚焦於業務邏輯，而不用去關心網絡通信，服務發現等的問題。但我們知道，計算機編程不是魔法，並不是隨便念兩句咒語就能真的指揮計算機完成我們想做的事情，框架所做的，只不過是把細節都屏蔽掉了而已。作爲框架的實現者，我們需要負責實現這些細節。下面就讓我們來分模塊的來分析RPC都需要有哪些功能。
- 服務主機的選取：既然服務是在遠程主機上實現的，而客戶端又不關心具體那臺主機爲我們實現了這些服務。因此我們需要有一個模塊來爲我們完成服務主機的選取。我們的服務又想構建成分佈式的，那麼勢必還牽扯到服務主機選擇的一些算法。服務選擇模塊爲我們提供這樣的功能:
(host,port) = (service-choose service choosen-algs)
- 網絡通信部分：在服務端和客戶端，涉及到的網絡傳輸就是將客戶端的請求服務信息傳輸到服務端，然後再服務端完成調用，再將結果返回。這樣看起來，特別想http的應答響應式服務。仿照JavaEE的httpservlet協議，我們也定義我們的Rpc protocal。將request封裝成rpcRequest，將服務器的應答response封裝成rpcResponse。同時既然涉及到網路傳輸，由於網絡只能傳輸字節流，我們肯定還得涉及到對象序列化技術。這樣網絡部分我們就設計完畢了。
- 服務的具體實現，由於我們選用的java實現，而服務是在服務端完成的。因此我們可以使用java的反射技術來爲我們完成服務的具體執行過程。同時，我們還涉及到服務中java對象的具體管理，因此我們選用sping的IoC來爲我們自動管理這些服務對象。
這樣分析完畢，大致框架基本上清楚了，我們再通過幾張圖來具體的說明：
首先我們來看一下著名的RPC框架Dubbo的模塊圖：
我們依次來說下這些模塊和我們上面剖析的具體對應：
Provider和Container具體對應我們上面所說的服務具體實現部分，Registry對應我們所說的服務主機的選取模塊，而網絡服務模塊，架構中並沒有直接體現，但是肯定是發生在invoke和notify之間。對於這樣網絡服務軟件，我們不妨分層看一下其結構，這樣能更清晰的把握整個工作流程。
可以看到整個層次還是非常清晰的，在應用層，我們只能看到看到rpc協議的封裝。遵循我們軟件設計中的分層原則。
具體技術選型
首先對於網絡連接，我們選擇netty框架，因爲netty的網絡連接是非阻塞的，而且爲我們的網絡編程提供了非常好的抽象。使得我們只需要關注應用層的協議涉及即可。序列化選擇Protostuff框架。他爲我們提供了非常強大高效的序列化工具。由於我們想將該框架設計成分佈式的，我們選擇ZooKeeper來爲我們管理集羣，提供分佈式服務。最後，服務端服務對象的自動管理，我們採用sping，該框架的IoC容器爲我們提供了非常強大的自動化對象管理功能。