非侵入式：这个也可以叫做松耦合，对于java的web开发，最好的解耦方式就是使用spring技术，当我们系统里把远程调用框架引入后，配置好相关的参数，我们可以把用于远程调用的方法定义在spring的配置文件里，那么在程序里调用的时候，利用spring直接获取这个bean，那么对于远程调用的开发就和我们在action里调用server的方法没啥区别了。下面是一段实例代码：

　　负载均衡：分布式系统都离不开负载均衡，好的负载均衡可以充分利用好不同服务器的计算资源，提供系统的并发量和运算能力，对于网站而言(我们公司现在网站服务器不是太多)少于10台服务器可以使用两种策略：一种是简单轮询，比如有6台服务端，我们会把第一个请求给第一台服务器，第二个请求给第二台，依次类推，等6台循环完毕，又从第一台开始;第二种是随机方式，即使用random函数，当然更多的服务器我就不知道有什么轮询机制比较好，希望有知道的童鞋可以给我推荐下。

　　我这里设计的远程调用框架，除了以上的功能外，我希望它还能有心跳管理机制，超时管理机制，服务分级管理，就是根据服务的重要性或者系统的繁忙度可以调节网络资源。

　　哈哈，讲了这么久估计有童鞋可能有点烦了，不是说应用zookeeper的实例吗?怎么还没见到zookeeper的影子。别着急，zookeeper马上就要上场了。

　　还是以我前面博客里写分布式网站讲起，服务端系统我们可以当做服务提供者，前端系统当做服务调用者，提供者可以类比商户，调用者可以类比客户，商户和客户可以直接进行交易，这种直接交易方式非常原始甚至还会有风险，现代社会商户和客户直接的交易十分高效，高效的原因是因为有一个规范的大市场，商户和客户的交易在市场里进行的，这样交易会变得更加安全和高效，我设计的分布式框架最大的特点就是提供了一个类似市场的角色，它来管理服务提供者和服务调用者，我把这个功能模块称为远程调用管理组件。

　　远程调用管理组件是本框架的核心，它的主要作用是接收服务端提供者的注册的通知，该通知一般是接口以及该接口的实现类还有服务器的ip地址，管理组件会将这些通知记录下来，并且根据配置对这些服务程序进行分组和标记，注册好的信息管理组件会将这些信息推送到服务调用者。远程调用管理组件还包含心跳机制，这个心跳机制是针对服务提供者，通过心跳机制检测服务提供者的健康状况，管理组件不会检测服务调用者的健康状态，因为这个没必要，因为本框架的使用还是调用者直接去请求提供者，逻辑上是没必要关心调用者的状态，这和bs架构里浏览器一样，我们不会去关心浏览器用户是不是存在。服务提供者、服务调用者和远程调用管理组件的关系如下图所示：

　　远程调用框架运行的过程是：当服务提供者启动时候，它会将自己的ip地址和注册的方法传输到远程调用管理组件，管理组件接收到注册信息会将这些信息存储下来，存储技术就是使用zookeeper，存储成功后，管理组件会将成功通知传回给服务提供者，同时管理组件还会通过心跳检测服务提供者是否健康;当服务调用者启动时候，它会向管理组件请求服务提供者信息，管理组件接收到请求后会将相关信息推送给服务调用者。在实际系统运行时候，服务调用者直接和服务提供者进行通信交互了，通信方式是netty，如果调用者和提供者有相关变化，都会先通知服务管理组件，服务管理组件会将相关变更信息推送给相应的系统。

　　远程调用管理组件主要是通过zookeeper实现，zookeeper拥有一个层次的命名空间，它的模型是一个树状结构，树状结构是一个强大的数据类型，它几乎能存储所有不同的数据类型，我们通过zookeeper将这些信息保存起来，便于我们管理整个远程调用框架，同时zookeeper还是高可靠的，这个我在前面zookeeper文章里讲到了，这样就保证了整个远程调用框架的稳定性，实际应用中我们会将组件编译成一个jar包，不同的项目直接引用这个jar包，这样管理组件服务端和服务的提供者和调用者就联系起来。至于提供者和调用者的通信机制是直接进行，因为我们将通信程序集成在jar包里，只不过相应的管理机制抽取到外部服务端进行统一管理。

　　这就是我设计的远程调用框架，可惜的是，这个构思我还没有真正实现过，今天拿出来是想体现zookeeper的实际应用，为我后面讲解zookeeper做铺垫，至于是否可行，看以后有没有机会开发个类似的系统，到时估计还有很多意想不到的问题要解决。