如何从零开始实现一个soa远程调用服务基础组件

说起soa远程调用基础组件，最著名的莫过于淘宝的dubbo了，目前很多的大型互联网公司都有一套自己的远程服务调用分布式框架，或者是使用开源的（例如dubbo）,或者是自己基于某种协议（例如hessian,http等）进行开发，总体来说，使用远程服务调用框架最大的好处莫过于以下三点：
1.透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
　　那么我们如何从零开始开发出自己的soa远程调用服务基础组件呢？
　　soa基础组件的主流架构图如下所示：
　　
节点角色说明：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心，一般都使用zookeeper作为注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。
调用关系说明：
0. 服务容器负责启动，加载，运行服务提供者。
1. 服务提供者在启动时，向注册中心注册自己提供的服务。
2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

说白了，就是消费端和提供端都通过长连接连到zookeeper，消费端通过zk获取到服务提供者的地址列表，存在内存中，当请求调用的时候直接从内存中选择一个服务提供端的地址去访问某一台机器的服务（具体选择哪一台服务器根据特定的负载均衡算法确定），当服务提供端有节点动态增加或者减少时，zk上也会相应的增加或者减少（通过心跳的方式实现），这个时候，服务节点的变化也会通过zk通知到消费端，消费端再把最新的zk中的服务提供端的地址列表刷新到本地内存中。这样就可以动态的进行服务提供端节点的增加和删除。