Dubbox以及微服务

Posted kexinxin

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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

以上是关于Dubbox以及微服务的主要内容,如果未能解决你的问题,请参考以下文章

主流的微服务框架

SpringBoot微服务搭建指南架构设计

dubbox系列——dubbox简介

微服务框架对比

微服务之架构技术选型与设计

微服务架构引入的问题及解决方案