服务方配置即将容错配置放在服务提供方,这样一来所有消费方就可以使用统一的容错机制,而不用每个消费方都配一遍;
<!--接口级别:--> <dubbo:service interface="com.yyh.service.HelloService" ref="helloService" cluster="failover" retries="2"/> <!--方法级别:--> <dubbo:service interface="com.yyh.service.HelloService" cluster="failover" ref="helloService"> <dubbo:method retries="2"/> </dubbo:service> 消费方配置: <!--接口级别:--> <dubbo:service interface="com.yyh.service.HelloService" ref="helloService" cluster="failsafe"/> <!--方法级别--> <dubbo:service interface="com.yyh.service.HelloService" cluster="failover" ref="helloService"> <dubbo:method retries="2"/> </dubbo:service> 3.负载均衡为了提高系统的可用性,能够承受更大的并发量,我们会将压力的服务部署为集群,但是如果每词请求都交给集群中的同一个节点,那这个几点很可能直接就宕了,所以合理的分配任务给集群中的每一台机器也是我们必须考虑的事情,好在dubbo已经提供相应的功能,我们只需简单的配置即可完成负载均衡;
dubbo支持的任务分配方式:
随机random顾名思义,从Provider列表中选择随机选择一个,但是我们可以为Provider指定权重,权重越大的被选中的几率越高,因此对于性能更好的机器应设置更大的权重,反之则反,如果不指定负载均衡，默认使用随机负载均衡;
轮询roundrobin即依次调用所有Provider,每个Provider轮流处理请求,当然我们也可以指定权重,Provider收到的请求数量比约等于权重比; 性能差的机器可能会累积一堆请求,最终拖慢整个系统;
基于活跃数leastactive每个Provider收到一个请求则将活跃数+1,每处理完成一个请求则活跃数-1,新的请求将会交给活跃数最少的Provider; 简单的说性能越好的机器将收到更多的请求,反之则反;
基于hash一致consistenthash将根据Provider的 ip 或者其他的信息为Provider生成一个 hash，并将这个 hash 投射到 [0, 232 - 1] 的圆环上。当有请求时，则使用请求参数计算得出一个hash值。然后查找第一个大于或等于该 hash 值的缓存Provider，并将请求交予该Provider处理。如果当前Provider挂了，则在下一次请求时，为缓存项查找另一个大于其 hash 值的Provider即可。 具体算法参考:去官网看看
配置方法:与容错配置一样,我们可以选择在服务方或是消费方进行设置;
服务方:
<!--接口级别--> <dubbo:service interface="com.yyh.service.HelloService" loadbalance="roundrobin" /> <!--方法级别--> <dubbo:service interface="com.yyh.service.HelloService" cluster="failover" ref="helloService"> <dubbo:method retries="2" loadbalance="roundrobin"/> </dubbo:service>消费方:
<!--接口级别--> <dubbo:reference interface="com.yyh.service.HelloService" loadbalance="roundrobin"/> <!--方法级别--> <dubbo:reference interface="com.yyh.service.HelloService"> <dubbo:method loadbalance="roundrobin"/> </dubbo:reference> 直连即跳过注册中新直接找服务提供方,必须提前明确服务提供方的地址,所以该方式一般仅用于开发调试;
<dubbo:registry address="N/A"/> 仅订阅仅订阅指的是,不发布服务到注册中心,只从注册中心订阅依赖的服务;
使用场景:当我们要开发一个新的Provider,而这个Provider需要依赖其他Provider时,使用,其目的是避免正在开发的服务发布后被消费方调用,因为开发还未完成,可能造成意想不到的结果; 这就用到了仅订阅,再搭配直连即可完成开发调试;
<dubbo:registry protocol="zookeeper" address="10.211.55.8:2181" register="false"/> 仅注册仅注册指的是,发布自身服务到注册中心,但不从注册中心订阅依赖的服务;