接下來的文章中，我将會去分析Java語言中常用的RPC架構，包括但不限于RMI、dubbo、Hessian、Spring Remoting架構。這篇文章将簡要介紹Java語言自帶的RMI協定。
RMI（Remote Method Invocation），遠端方法調用，程式調用方無需關心跨機器跨程序的協定調用，更多的把精力放在業務上，而且這也隐藏了伺服器實作的細節。
Java RMI整體結構圖如下：
一般情況下，Register為注冊中心，一般是和Server在同一個Java 虛拟機中。Server通過開啟一個注冊中心，将所需要釋出的服務注冊到Register中，Client通過Register和服務類名稱，得到服務，然後通過服務進行調用，完成一個RPC過程。
下面根據源碼，和自己的歸納總結，給出下面的細節分析：
1、生成存根Stub和骨架Skeleton對象，實作類需要繼承UnicastRemoteObject 類，并通過構造器調用UnicastRemoteObject 的預設構造器。
2、通過命名服務将存根Stub對象注冊到注冊中心Register
3、用戶端Client通過lookup向注冊中心Register請求服務的存根Stub
4、注冊中心Register向用戶端Client傳回存根Stub，用戶端将Stub強轉為相關服務接口
5、用戶端Client使用存根Stub對象，進行接口調用
6、存根Stub通過TCP協定socket發起接口調用，通過網絡将相關資料傳送到socket服務端即骨架Skeleton
7、骨架Skeleton拿到資料，解析并對具體的服務實作類ServerImpl進行調用
8、服務實作類ServerImpl完成在服務端java虛拟機的調用，将結果資料傳回給骨架Skeleton
9、骨架Skeleton通過網絡協定将結果資料傳回存根Stub
10、存根Stub拿到結果傳回上層Client，一個調用過程結束
即使RMI在一定程度上對于開發來說簡便了很多的細節，開發也不需要關心其中的TCP調用過程，但是RMI也存在一定的劣勢。主要表現在
1、RMI的Register一般情況下跟Server在同一個Server下，對于分布式的Server叢集，Client并不能很智能的選擇，無法做到負載均衡等
2、Register對于端口和ip有嚴重的依賴，一旦伺服器更換了ip，那麼Client中的注冊中心Register就變成不存在的，對應用影響比較大。這同時也說明了RMI架構更加适用于單系統的簡單内部項目中，無法在大型分布式系統上得到更多的發展。不過這裡存在一個優化的空間，就是單獨把注冊中心Register從服務端Server中提出來實作。
3、RMI的發展依舊更多的停留在jdk1.1，後期更新比較少。
盡管如此，但是RMI作為早起的RPC架構，依舊給後來的RPC架構帶來了很多的參考意義，例如注冊中心、協定等等。
參考：
（1）https://blog.csdn.net/xinghun_4/article/details/45787549