一.消费方

1.需要使用到动态代理，代理指定的接口，这样子接口被调用时，就可以拿到："类名+ 方法名+参数+返回值" 这些类型。

2.既然是rpc，那么接口被调用时，肯定在动态代理中会进行网络消息的发送，由于是远程调用，那么必然动态代理的proxy参数其实是用不到的，因为返回的话，是依赖于远程的服务提供者。

3.阻塞，等待消息的返回，支持超时。

二.服务提供者

1.必然要注册到zk中，其实就是本地一个Map，知道了调用者想调用啥时，知道具体的实现。也就是维护了一个Map<String, InterfaceImpl>的map。

2.消费者通过网络 把想要调用的信息传递过来后，服务提供者就找到实现，从而调用，调用后，再返回。

三、请求返回统一封装

RpcRequest

RpcResponse

为啥要封装下呢？

对于Request，这是因为有一些共性，比如：消费者需要存储"类名+ 方法名+参数+返回值"。

对于Response，则要告诉是否调用成功，还是说超时了。

四、序列化

我们这里采用kryo，因为我们希望是二进制级别的，而且是: 在修改签名时，我们不希望再直接生成下proto。