今天完成的事情：

1. IRM配置完成

2. 分离了web 和service

3. 思考如何配置多个service并能负载均衡

明天计划的事情

1. 学习一下spring+ zookeeper +RMI（网上没有相关内容 只有spring + zookeeper 、spring + RMI，zookeeper +RMI）,看看能不能整合

按道理我能想到的早有人想到，为什么不这么用，是我的思路哪里出了问题了吗？

2. RMI的对service随机访问

遇到的问题：

1. spring zookeeper+rmi难以整合

明天思考思考

2. 服务和客户端之间的传输需要把传输的对象序列化，即需要把modle层的对象实例化：

public class Student implements Serializable {

否则会出现IO错误

收获：

1. IRM配置完成

只有Server端使用的是JAVA语言并且Client端也是用的JAVA语言，才能使用RMI技术

要定义和使用一套基于RMI框架工作的系统：

1、定义RMI Remote接口 

service 的启动器，加载配置文件启动bean

private static Logger logRMIService = LoggerFactory.getLogger(RMIService.class);
public static void main(String[] args) {
    ApplicationContext ac = new ClassPathXmlApplicationContext("classpath:conf/spring-*");
    logRMIService.info("初始化完成！ ");
}

client:

<bean id="studentRMIService" class="org.springframework.remoting.rmi.RmiProxyFactoryBean">
    <property name="serviceUrl" value="rmi://127.0.0.1:9999/studentRMI"/>
    <property name="serviceInterface" value="jnshu.taskeight.service.StudentService"/>
</bean>

service:

<bean id="studentRMIService" class="org.springframework.remoting.rmi.RmiServiceExporter">
    <property name="serviceName" value="studentRMI"/>
    <property name="service" ref="studentServiceImpl"/>
    <property name="serviceInterface" value="jnshu.taskeight.service.StudentService"/>
    <property name="registryPort" value="9999"/>
    <property name="servicePort" value="10000"/>
</bean>

红色部分一定要在相关的实现类里加上@service的注解

下面红字为通讯端口，用于参数的传递和信息通信，而上面是的端口是用于rmi的服务注册。

2. 分离了web 和service

配合起来向在一个scr下使用：

3. 思考如何配置多个service并能负载均衡

把rmi的服务端的服务信息在zookeeper里进行注册。然后通过安装zookeeper的客户端进行通信

要想解决 RMI 服务的高可用性问题，我们需要利用 ZooKeeper 充当一个 服务注册表（Service Registry），让多个 服务提供者（Service Provider）形成一个集群，让 服务消费者（Service Consumer）通过服务注册表获取具体的服务访问地址（也就是 RMI 服务地址）去访问具体的服务提供者。如下图所示：

需要注意的是，服务注册表并不是 Load Balancer（负载均衡器），提供的不是“反向代理”服务，而是“服务注册”与“心跳检测”功能。

利用服务注册表来注册 RMI 地址，这个很好理解，那么“心跳检测”又如何理解呢？说白了就是通过服务中心定时向各个服务提供者发送一个请求（实际上建立的是一个 Socket 长连接），如果长期没有响应，服务中心就认为该服务提供者已经“挂了”，只会从还“活着”的服务提供者中选出一个做为当前的服务提供者。

也许读者会考虑到，服务中心可能会出现单点故障，如果服务注册表都坏掉了，整个系统也就瘫痪了。看来要想实现这个架构，必须保证服务中心也具备高可用性。

ZooKeeper 正好能够满足我们上面提到的所有需求。

1. 使用 ZooKeeper 的临时性 ZNode 来存放服务提供者的 RMI 地址，一旦与服务提供者的 Session 中断，会自动清除相应的 ZNode。
2. 让服务消费者去监听这些 ZNode，一旦发现 ZNode 的数据（RMI 地址）有变化，就会重新获取一份有效数据的拷贝。
3. ZooKeeper 与生俱来的集群能力（例如：数据同步与领导选举特性），可以确保服务注册表的高可用性。

理解了一下：

 在不断地对服务端进行试探，看是否有不响应的，如果有就删除其节点，如果RMI的服务信息有变化就重新获取一份信息。

进度： 

         任务开始时间：11.09

         预计完成时间：11.12

          是否有延期风险：暂无

禅道：http://task.ptteng.com/zentao/project-task-264.htm