Dubbox以及微服务

Dubbox以及微服务

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

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

这样会有什么问题呢？

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

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

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

注册中心

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

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

节点角色说明

调用关系说明

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

要使用注册中心，只需要将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.

该算法比较适合每个服务器的性能差不多的场景，如果有性能存在差异的情况下，那么性能较差的服务器可能无法承担过大的负载

加权轮询

加权轮序是在轮询的基础上，根据服务器的性能差异，为服务器赋予一个的权值，性能高的服务器分配更高的权值。例如下图中，服务器1被赋予的权值为5，服务器2被赋予的权值为1，那么（1,2,3,4,5）请求会被发送到服务器1,（6）请求会被发送到服务器2。

最少连接

由于每个请求的连接时间不一样，使用轮询或者加权轮询算法的话，可能会让一台服务器当前连接数过大，而另一台服务器的连接过小，造成负载不平衡。

例如下图中，(1, 3, 5) 请求会被发送到服务器 1，但是 (1, 3) 很快就断开连接，此时只有 (5) 请求连接服务器 1；(2, 4,6) 请求被发送到服务器 2，只有 (2) 的连接断开，此时 (6, 4) 请求连接服务器 2。该系统继续运行时，服务器 2 会承担过大的负载。

最少连接算法就是将请求发送给当前最少连接数的服务器上。

例如下图中，服务器 1 当前连接数最小，那么新到来的请求 6 就会被发送到服务器 1 上。

加权最少连接

在最少连接的基础上，根据服务器的性能为每台服务器分配权重，再根据权重计算出每台服务器能处理的连接数

随机算法

把请求随机发送到服务器上

和轮询算法类似，该算法比较适合服务器性能差不多的场景

源地址哈希法（IP Hash）

源地址哈希通过对客户端IP计算哈希值之后，再对服务器数量取模的得到目标服务器的序号。

可以保证同一IP的客户端的请求会转发到同一台服务器上，用来实现会话粘滞。

 

Dubbo的整体架构如下：

 

 

 

 

 

 

 

zhengti11