总结
RPC框架原理
客户端和服务端都可以访问到通用的接口，但是只有服务端有这个接口的实现
类，客户端调用这个接口的方式，是通过网络传输，告诉服务端我要调用这个
接口，服务端收到之后找到这个接口的实现类，并且执行，将执行的结果返回
给客户端，作为客户端调用接口方法的返回值。
客户端到服务端
客户端向服务端发送一个HelloObject 对象，服务端接收这个对象
传输格式
- 给服务端提供足够的信息，使服务端唯一确定需要调用的接口的方法，以
及方法的参数类型以及参数值。把以上内容写在RpcRequest 中 - 服务器调用完这个方法后，需要给客户端返回相应信息，如果调用成功的
话，显然需要返回值，如果调用失败了，就需要失败的信息，这里封装成一
个RpcResponse对象。信息包括状态码、补充信息和响应数据
客户端的动态代理
客户端方面，由于在客户端这一侧我们并没有接口的具体实现类，就没有办法
直接生成实例对象。这时我们可以通过动态代理的方式生成实例，并且调用方
法时生成需要的RpcRequest 对象并且发送给服务端。生成RpcRequest 对象
通过RpcClient 对象发送出去，并且接受返回的对象
服务端的实现——反射调用
使用一个ServerSocket监听某个端口，循环接收连接请求，如果发来了请求
就创建一个线程，在新线程中处理调用。WorkerThread实现了Runnable接口
，用于接收RpcRequest对象，解析并且调用，生成RpcResponse对象并传输
回去
客户端没有实现HelloService接口，通过动态代理的方式调用服务端的实现
类完成操作
服务注册表
继续优化，以上的操作在注册完helloService 后，服务器就自行启动了，也
就是说，一个服务器只能注册一个服务，接下来将服务的注册和服务器启动分
离，使得服务端可以提供多个服务。
需要一个容器保存本地服务的信息，并且在获得一个服务名字的时候能够返回
这个服务的信息
降低耦合度
我们不会把ServiceRegistry 和某一个RpcServer 绑定在一起，而是在创建
RpcServer 对象时，传入一个ServiceRegistry 作为这个服务的注册表。
在创建RpcServer 时需要传入一个已经注册好服务的ServiceRegistry，而原
来的register方法也被改成了start方法，因为服务的注册已经不由RpcServer
处理了，它只需要启动就行了。
而在每一个请求处理线程中也就需要传入ServiceRegistry 了，这里把处理
线程和处理逻辑分成了两个类：RequestHandlerThread 只是一个线程，从
ServiceRegistry 获取到提供服务的对象后，就会把RpcRequest 和服务对
象直接交给RequestHandler 去处理，反射等过程被放到了RequestHandler
里。
RequestHandler.java：通过反射进行方法调用。