手寫RPC框架，我學會了什麼？（二）
摘要：
上一篇 談到了動態代理在RPC框架中的作用，這一篇會繼續談談框架設計時的一些模型、理念和簡單的思考。
相關名詞
服務介面（Service Interface）服務提供者和消費者溝通的“橋樑”，通常需要通過打包成jar釋出出去，比如：
public...
上一篇 談到了動態代理在RPC框架中的作用，這一篇會繼續談談框架設計時的一些模型、理念和簡單的思考。
相關名詞
服務介面（Service Interface）服務提供者和消費者溝通的“橋樑”，通常需要通過打包成jar釋出出去，比如：
public interfere IHelloService {
String sayHi(String somebody);
}
服務例項類（Service Instance）實現真正的業務邏輯，比如：
public class HelloServiceImpl implements IHelloService {
@Override
String sayHi(String somebody) {
return "Hello, " + somebody + "!";
}
}
服務提供者（Service Provider）提供服務的一方，實際上也是服務例項類執行的地方。
服務消費者（Service Consumer）使用服務的一方，呼叫介面提供的方法獲得結果並進行後續處理，比如：
IHelloService helloService = RpcClient.getRemoteInstanceProxy(IHelloService.class);
String msg = helloService.sayHi("world");
//- 返回：Hello, world!
配置中心（Config Center）提供服務提供者相關的資訊，比如IP地址，監聽的埠號，服務名等。比如：
10.100.100.01:8000 IHelloService 10.100.100.02:8000 IHelloService
服務註冊（Service Register）服務提供者向配置中心推送自身資訊的行為。
框架需要做什麼
服務提供者啟動後，首先生成服務例項類，並維護一個“類名-例項類”的對映關係（Map）。接著向配置中心進行服務註冊。
服務消費者啟動後，首先從配置中心獲得服務提供者的資訊。接著嘗試與某一個服務提供者建立通訊。
當服務消費者呼叫RpcClient.getRemoteInstanceProxy()
時，通過動態代理獲得服務介面的一個“傀儡”例項。當呼叫介面的具體方法時，“傀儡”例項會通過Socket將呼叫資訊，比如：類名、方法名、方法引數等傳送給提供者。
提供者首先通過類名在Map中找到例項，再通過反射執行例項方法，最後再將執行結果回傳給消費者。