Dubbox以及微服务

zookeeper在Dubbo中扮演了一个什么角色，起到了什么作用？

现在整体架构是如下图（假设服务消费者为订单服务，服务提供者为用户服务）：

这样会有什么问题呢？

当服务提供者增加节点时，需要修改配置文件

当其中一个服务提供者宕机时，服务消费者不能及时感知到，还会往宕机的服务发送请求

这个时候就得引入注册中心了

注册中心

Dubbo目前支持4种注册中心,（multicast zookeeper redis simple）推荐使用Zookeeper注册中心，本文就讲一下用zookeeper实现服务注册和发现（敲黑板，又一种zookeeper的用处），大致流程如下

现在我们来看Dubbo官网对Dubbo的介绍图，有没有和我们上面画的很相似

节点角色说明

调用关系说明

服务容器负责启动（上面例子为Spring容器），加载，运行服务提供者。
服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者在启动时，向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

要使用注册中心，只需要将provider.xml和consumer.xml更改为如下

如果zookeeper是一个集群，则多个地址之间用逗号分隔即可

注册信息在zookeeper中如何保存？

启动上面服务后，我们观察zookeeper的根节点多了一个dubbo节点及其他，图示如下

最后一个节点中192.168.1.104是内网地址，你可以任务和上面配置的localhost一个效果，大家可以想一下我为什么把最后一个节点标成绿色的。没错，最后一个节点是临时节点，而其他节点是持久节点，这样，当服务宕机时，这个节点就会自动消失，不再提供服务，服务消费者也不会再请求。如果部署多个DemoService，则providers下面会有好几个节点，一个节点保存一个DemoService的服务地址

其实一个zookeeper集群能被多个应用公用，如Storm集群和Dubbo配置的就是一个zookeeper集群，为什么呢？因为不同的框架会在zookeeper上建不同的节点，互不影响。如dubbo会创建一个/dubbo节点，storm会创建一个/storm节点，如图

如何同样的方法调用由Dubbox集群提供那么就会需要提供负载均衡的机制。（注：zookeeper自己本身没有负载均衡功能，但是他的特性（可以通过心跳机制发现那些Dubbo服务器死机了，从而维护可调用列表）可以借助其他方法实现类似负载均衡的能力。比如dubbo消费者取得了服务器列表之后，会随机调用其中的一个。常用的负载均衡实现方式如下：

轮询（Round Robin）

轮询算法把每个请求轮流发送到每个服务器上。

下图中，一共有6个客户端产生了6个请求，这6个请求按（1,2,3,4,5,6）的顺序发送。（1,3,5）的请求会被发送到服务器1，（2,4,6）的请求会被发送到服务器2.