前言:
目前各位老铁们对“dubbo负载均衡 在客户端还是服务端”可能比较关怀,姐妹们都需要分析一些“dubbo负载均衡 在客户端还是服务端”的相关内容。那么小编在网上搜集了一些有关“dubbo负载均衡 在客户端还是服务端””的相关资讯,希望小伙伴们能喜欢,你们一起来学习一下吧!概述
Dubbo是一个分布式服务框架,能避免单点故障和支持服务的横向扩容。一个服务通常会部署多个实例。如何从多个服务提供者组成的集群中挑选出一个进行调用,就涉及到一个负载均衡的策略。
Dubbo对一个服务调用的负载均衡配置,可以从服务提供者端dubbo:service标签配置,也可以在服务消费者端dubbo:reference标签进行配置;另外,按粒度划分,可以分为服务级别(dubbo:service和dubbo:reference)和方法级别(dubbo:method)的配置,服务级别针对的是整个服务实现类中所有方法的调用,而方法级别则是针对服务实现类中具体的一个方法进行的配置。
配置优先级
针对同一个服务或方法,Dubbo的负载均衡配置方式比较灵活,这些配置方式可以单独使用、也可以组合使用,其遵循一定的优先级规则:
消费者端的配置优先于提供者端方法级别的配置优先与服务级别的配置不同提供者端配置,后注册的配置优先
也就是,对于同一个服务(接口名、版本号、分组都相同)或方法的配置,若消费者与提供者均设置了负载均衡策略,消费者端设置的优先级高。若消费者端没有显式的设置,但提供者端显式的设置了,则最后一个注册的会将前面注册的信息覆盖,消费者端将使用最后一个注册的服务提供者设置的策略调用服务。如果服务及其方法同时配置了负载均衡,则以方法的配置为准。
负载均衡算法
Dubbo中内置了4种负载均衡算法
random
随机算法,按权重设置随机概率,权重使用weight属性设置。存在服务堆积问题。
roundrobin
轮询算法,按照设定好的权重依次进行调度,权重使用weight属性设置。轮询算法,慢的服务提供者,存在服务堆积问题。
leastactive
最少活跃调用数算法,被调度的次数越少,其优选级就越高,被调度到的机率就越高。 如果活跃数相同,则随机调用。
consistenthash
一致性哈希算法。相同参数的请求总是落在同一台机器上。当某些节点下线时,相比直接使用哈希而言,一致性哈希算法可以将请求平摊到其它节点,不会引起剧烈变动。
4种负载均衡算法中,随机算法random是Dubbo默认的负载均衡算法。
负载均衡配置示例
配置负载均衡的属性为loadbalance,可以在dubbo:service、dubbo:reference和dubbo:method标签上按需进行配置。
服务提供端配置
<!-- 声明orderService的实现bean --><bean id="orderService" class="com.fandou.coffee.order.service.OrderServiceImpl" /><!-- 曝露orderService服务,并设置使用最小活跃数算法 --><dubbo:service interface="com.fandou.coffee.api.order.OrderService" ref="orderService" loadbalance="leastactive"/>
服务消费端配置
<!-- 引用运营平台提供的订单服务orderService:使用随机算法,覆盖运营平台的最小活跃算法 --><dubbo:reference id="orderService" interface="com.fandou.coffee.api.order.OrderService" loadbalance="random"> <!-- 指定query方法使用随机算法,但会被后面的设置所覆盖 --> <dubbo:method name="query" loadbalance="random" /> <!-- 另外指定query方法使用轮询算法 --> <dubbo:method name="query" loadbalance="roundrobin" /></dubbo:reference>总结
大部分时候,建议在服务提供方一端进行负载均衡设置,因为服务提供方更清楚服务提供者的负载能力。
#java开发工程师# #架构师#
标签: #dubbo负载均衡 在客户端还是服务端