对于dubbo和zookeeper的浅见

         在服务器集群环境中，阿里推出的dubbo框架一直是让人仰望的存在，可如今想想，也没啥。

         dubbo其实就是一个调用工具，他的服务调度也就是知名的几个负载均衡算法，服务监控其实也就是有一个定时任务在定期检查服务情况，剩下的，调用的底层逃不开socket链接tcp协议，说白了，我其实完全可以自己实现自己的dubbo框架，至于注册中心zookeeper，也不再是高山仰止般的存在了。(PS：我讨厌那种有很多繁杂配置和很高学习成本的新技术)

        zookeeper其实也可以自己实现，我完全可以用redis存储各项配置，配合一套合理的缓存管理系统实时刷新各项服务的最新信息，譬如：A服务的配置是一个json信息：

{
   'url':'192.168.1.123',
   'serviceName':'A_Service'
   'last_service_time':'12ms'
}

           然后A服务有N台机器，那么这个服务其实是一个json数组的配置，这时路由策略就可以根据这些配置和算法去进行负载均衡，至于监控，也有很多实现方式，譬如：服务每次调用完更新配置时间到redis，如果不更新，则默认为它不在状态，邮件通知运维同学。

各种框架在这些道理上做了N多扩展，因为要让更多不通的场景使用，所以它必须要有很高的兼容性，所以每一个框架都是有很多功能是用不到的。