Dubbo架构

本文介绍了Dubbo架构中的核心组件及其工作流程,包括服务提供者、消费者、注册中心及监控中心的功能。深入探讨了Zookeeper作为注册中心的Leader选举过程,并解释了Dubbo如何利用Zookeeper实现服务注册与发现。此外,还详细介绍了Dubbo提供的多种负载均衡策略。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Dubbo架构

Provider: 暴露服务的服务提供方。 
Consumer: 调用远程服务的服务消费方。 
Registry: 服务注册与发现的注册中心。 
Monitor: 统计服务的调用次数和调用时间的监控中心。

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

zookeeper 作为注册中心,服务器和客户端都要访问,如果有大量的并发,肯定会有等
待。所以可以通过zookeeper 集群解决。
了解Leader 选举
Zookeeper 的启动过程中leader 选举是非常重要而且最复杂的一个环节。那么什么是
leader 选举呢?zookeeper 为什么需要leader 选举呢?zookeeper 的leader 选举的过程又是什
么样子的?
首先我们来看看什么是leader 选举。其实这个很好理解,leader 选举就像总统选举一样,
每人一票,获得多数票的人就当选为总统了。在zookeeper 集群中也是一样,每个节点都会
投票,如果某个节点获得超过半数以上的节点的投票,则该节点就是leader 节点了。
以一个简单的例子来说明整个选举的过程.
假设有五台服务器组成的zookeeper 集群,它们的id 从1-5,同时它们都是最新启动的,也
就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器依序启动,来看看会
发生什么。
1) 服务器1 启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的
选举状态一直是LOOKING 状态
2) 服务器2 启动,它与最开始启动的服务器1 进行通信,互相交换自己的选举结果,由于
两者都没有历史数据,所以id 值较大的服务器2 胜出,但是由于没有达到超过半数以上的服务
器都同意选举它(这个例子中的半数以上是3),所以服务器1,2 还是继续保持LOOKING 状态.
3) 服务器3 启动,根据前面的理论分析,服务器3 成为服务器1,2,3 中的老大,而与上面不
同的是,此时有三台服务器选举了它,所以它成为了这次选举的leader.
4) 服务器4 启动,根据前面的分析,理论上服务器4 应该是服务器1,2,3,4 中最大的,但是
由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当小弟的命了.
5) 服务器5 启动,同4 一样,当小弟
Dubbox 连接zookeeper 集群
<!-- 指定注册中心地址-->
<dubbo:registry
protocol="zookeeper"
address="192.168.25.135:2181,192.168.25.135:2182,192.168.25.135:2183">
</dubbo:registry>
zookeeper负载均衡
在集群负载均衡时,Dubbo 提供了多种均衡策略,缺省为 random 随机调用

可以自行扩展负载均衡策略,参见:负载均衡扩展

负载均衡策略

Random LoadBalance

  • 随机,按权重设置随机概率。
  • 在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。

RoundRobin LoadBalance

  • 轮循,按公约后的权重设置轮循比率。
  • 存在慢的提供者累积请求的问题,比如:第二台机器很慢,但没挂,当请求调到第二台时就卡在那,久而久之,所有请求都卡在调到第二台上。

LeastActive LoadBalance

  • 最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。
  • 使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

  • 一致性 Hash,相同参数的请求总是发到同一提供者。
  • 当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。
  • 算法参见:http://en.wikipedia.org/wiki/Consistent_hashing
  • 缺省只对第一个参数 Hash,如果要修改,请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
  • 缺省用 160 份虚拟节点,如果要修改,请配置 <dubbo:parameter key="hash.nodes" value="320" />

配置

服务端服务级别

<dubbo:service interface="..." loadbalance="roundrobin" />

客户端服务级别

<dubbo:reference interface="..." loadbalance="roundrobin" />

服务端方法级别

<dubbo:service interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>

客户端方法级别

<dubbo:reference interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值