zookeeper+dubbo

转自求职季来一发zookeeper+dubbo吧

Dubbo是一种分布式服务框架。
Webservice也是一种服务框架，但是webservice并不是分布式的服务框架，他需要结合F5实现负载均衡。
dubbo除了可以提供服务之外，还可以实现软负载均衡。
还提供了两个功能Monitor 监控中心和调用中心。这两个是可选的，需要单独配置。
它有2部分，服务的提供方和服务的消费方，官方推荐用zookeeper作为一个注册中心。
（怎么用呢？）
1. 首先服务的提供方暴露出他所提供的服务接口，提供给zookeeper注册中心进行注册进行管理
2. 当消费方需要使用的时候，它会到zookeeper中查询相应的服务接口是否存在
3. 如果找到了，那么zookeeper注册中心把服务消息的提供方的具体IP地址返回给服务的消费方
4. 然后由你的服务的消费方直接去服务的提供方上去使用。

负载均衡
负载均衡是对外提供一个公共地址，请求过来时通过轮询、随机等，路由到不同server。目的分摊压力。失效备援是发现一台server挂了，就让另外一台去服务了。跟餐馆换个服务员继续招待你一样。

轮询（Polling）是一种cpu决策如何提供周边设备服务的方式，又称“程控输出入”（Programmed I/O）。轮询法的概念是，由CPU定时发出询问，依序询问每一个周边设备是否需要其服务，有即给予服务，服务结束后再问下一个周边，接着不断周而复始。

Java下的一套RPC框架(soa思想)，作用就是统一管理配置，各个系统服务间的调用。dubbo在淘宝也是解决他们实际问题的，不一定适合其他。 另外各家公司也都有大同小异的实现，所以没多少人用、也就没多少介绍。 原理就是： A系统调用B系统接口服务， 后面就是怎么把这个流程，动态化(zookeeper通知)、权限化、配置化、低耦合化、自动化。

---

zookeeper是一个精简的文件系统
是管理小文件的。
1.zookeeper提供了丰富的“构件”，这些构件可以实现很多协调数据结构和协议的操作。例如：分布式队列、分布式锁以及一组同级节点的“领导者选举”算法。
2.zookeeper是高可用的，它本身的稳定性是相当之好，分布式集群完全可以依赖zookeeper集群的管理，利用zookeeper避免分布式系统的单点故障的问题。
3.zookeeper采用了松耦合的交互模式。这点在zookeeper提供分布式锁上表现最为明显，
zookeeper可以被用作一个约会机制，让参入的进程不在了解其他进程的(或网络)的情况下能够彼此发现并进行交互，参入的各方甚至不必同时存在，只要在zookeeper留下一条消息，在该进程结束后，另外一个进程还可以读取这条信息，从而解耦了各个节点之间的关系。
4.zookeeper为集群提供了一个共享存储库，集群可以从这里集中读写共享的信息，避免了每个节点的共享操作编程，减轻了分布式系统的开发难度。

---

对于dubbo框架在编码的过程中最容易遗忘的：

就是服务的注册，大部分互联网公司用到的注册中心就是zookeeper；

<dubbo:service> dubbo:service> 
<dubbo:registry address=""/>  

timeout的时间设置
传参（对应的javavo类）必须实现序列化；即：implementsSerializable接口
Dubbo服务出现宕机，司机状态；不能注册新的服务；但是可以调用已经注册上的服务；因为dubbo有一个服务的缓存机制；已经注册上的服务都保存在缓存里
另外在以前的编码中经常遇到的dubbo调用的过程中容易出现服务的假死状态。