上一次写了一个无注册中心的RPC，今天在前面的基础之上扩展为带注册中心的RPC框架。
先把provider整体代码目录
自定义一个注解Service，其中有参数interfaceName、version。这个主要是模仿dubbo的Service注解：源码如下
注册到zookeeper上，也就是在zookeeper上创建节点。
具体注册类，采用Curator来连接和操作zookeeper。
常量类
常量类链接地址我这里是写死的并且是单机，如果采用集群的话，可以写成public final static String CONNNECTION_STR
=”192.168.1.10:2181,192.168.1.11:2181,192.168.1.12:2181″;
至于第二个参数PATH这个自己爱好来吧。
RpcRequest参数中多了一个version,这就是应对客户端调用的时候穿来的RPC服务版本号。与之对应的是咱们自定义注解@Service中的version。
处理请求和无注册中心的版本差不多。
创建一个线程池用于处理消费方的请求。绑定服务名称和服务对象。
然后发布服务（就是去zookeeper的某个指点节点下面创建节点）。
然后启动
zookeeper上
OK。现在服务以及发布注册成功。
继续consumer端
因为添加了注册中心zookeeper，也就是发现服务
采用Curator连接和操作zookeeper。动态发现服务采用监听模式，通过动态发现服务获取服务列表repos。一旦服务端在path节点下的子节点有变动，则会出发监听重新拉取服务列表（动态更新服务列表，比如说一台服务挂掉、重启、新增服务等时候，这个服务列表也会跟着更新）。然后采用负载均衡算法得出即将要调用的url地址，这里采用的是策略模式（你只要选择你要的负载均衡算法就可以了，至于算法里面是怎么实现，你是不需要知道的。类似的列子：你要手机购物时候付款，你可以选择支付宝或者微信或者银行卡等支付方式中一种就可以了，至于支付里面是怎么实现的你根本就不需要知道）。
策略模式优点：
- 通过策略类的等级结构来管理算法族。
- 避免使用将采用哪个算法的选择与算法本身的实现混合在一起的多重条件(if-else if-else)语句。
策略模式缺点：
- 客户端必须知道所有的策略类，并自行决定使用哪一个策略类。
- 由于策略模式把每个算法的具体实现都单独封装成类，针对不同的情况生成的对象就会变得很多。
负载均衡接口
负载均衡抽象类，这里采用了模板方法模式。具体实现选举的算法是对应的子类里自己去实现。
模板方法模式总结：
先说优点：
1、封装性好
2、复用性好、
3、屏蔽细节
4、便于维护
至于缺点：
继承问题，在JAVA里只能继承一个父类。
使用流程：
分析场景–>步骤抽取–>重构代码–>重要、复杂的算法，核心算法设计为模版
应用注意点：
- 模版方法需要声明成 public final
- private方法是基本逻辑
- protect abstract 方法是可扩展方法
这里加单写了两个实现类。
请求处理没有变化。
采用JDK动态代理调用远程服务。
组装请求信息并发送请求
运行结果：
再次证明调用成功并且负载均衡算法也是成功的。
OK！！！！以上便是自己手写的带注册中心（zookeeper）的RPC框架。
后期会更多的优化和扩展
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.e1idc.net
