当前位置：首页 > news >正文

Dubbo之参数配置（一）

news 来源：原创 2024/5/21 18:25:51

启动时检查

集群容错

负载均衡

线程模型

直连提供者

服务只订阅,不注册

只注册

静态服务

多协议配置

多注册中心注册（服务端）和多注册中心引用（消费端）

多版本

服务分组

分组聚合

结果缓存

启动时检查

dubbo默认会在启动时检查依赖的服务是否可用，不可用会抛出异常
1）xml中配置
没有提供者时报错关闭某个服务的启动时检查： <dubbo:reference interface=“com.foo.Service” check=“false”/>
没有提供者时报错关闭所有服务的启动时检查：<dubbo:consumer check=“false”/>
注册订阅失败时报错关闭注册中心启动时检查： <dubbo:registry check=“false”/>
2）properties中配置
也可在dubbo.properties中配置
dubbo.reference.com.foo.Service.check=false
dubbo.reference.check=false 强制改变所有reference的check值,就算配置中有声明也会被覆盖
dubbo.consumer.check=false 只是设置check的缺省值，如果配置中有显示的声明，不会受影响
dubbo.registry.check=false

引用默认是延迟初始化的，只有引用被注入到其他Bean,或被getBean()获取，才会初始化
如果需要饥饿加载，没有引用也立即生成动态代理，可以配置
<dubbo:reference interface=“com.foo.Service” init=“true”/>

集群容错

集群模式配置

<dubbo:service cluster=“failsafe”/> 或 <dubbo:reference cluster=“failsafe”/>
failover:失败自动切换，重试次数默认为2（不包含第一次） retries=“2”
failfast:快速失败，只发起一次调用，失败立即报错，常用于非幂等性操作
failsafe:失败安全，出现异常时直接忽略，常用于写入审计日志等操作
failback:失败自动恢复，后台记录失败请求，定时重发，常用于消息通知
forking:并行调用多个服务器，只要一个成功即返回，通常用于实时性要求较高的读操作，但浪费更多服务资源，fork="2"设置最大并行数
**broadcast:**广播调用所有提供者，逐个调用，任意一台报错则报错，常用于通知所有提供者更新缓存或日志等本地资源信息

负载均衡

默认为random随机调用
<dubbo:service interface=“” loadbalance=“roundrobin”/> 或 <dubbo:reference interface=“” loadbalance=“roundrobin”/>
Random:随机，按权重设置随机概率，调用量越大分布越均匀，动态调整提供者权重
RoundRobin:轮询，按权重设置轮询比例，容易出现提供者累积请求问题，当某一台机器很慢，卡在那里，所有请求就全卡了
LeastActive:最少活跃调用数，相同活跃数的随机，慢的提供者收到更少请求
ConsistentHash:一致性Hash，相同参数的请求总是发到同一提供者，某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不会引起剧烈变动

线程模型

<dubbo:protocal name=“dubbo” dispatcher=“all” threadpool=“fixed” threads=“100”/>

Dispatcher

all:所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等
direct:所有消息都不派发到线程池，全部在IO线程上直接执行
message:只有请求响应消息派发到线程池
execution:只有请求消息派发到线程池
connection:在IO线程上，将连接断开事件放入队列，有序逐个执行，其他消息派发到线程池

ThreadPool

fixed：固定大小线程池，启动时建立线程，不关闭，一直持有
cached：缓存线程池，空闲一分钟自动删除，需要时重建
limited：可伸缩线程池，但池中线程数只会增长不会收缩。

直连提供者

使用场景：在开发及测试环境下，经常要绕过注册中心，只测试指定服务提供者，需要点对点直连A接口配置点对点，不影响B接口从注册中心获取列表
xml:<dubbo:reference interface=“” url=“dubbo://localhost:9999”/>
properties: 2.0以上自动加载${user.home}/dubbo-resolve.properties文件
com.demo.Service=dubbo://localhost:9999

服务只订阅,不注册

使用场景：有时候未开发完的服务放到注册中心，会影响消费者不能正常运行
<dubbo:registry address=“10.20.153.10:9090” register=“false” />
或
<dubbo:registry address=“10.20.153.10:9090register=false” />

只注册

使用场景：有时候需要将一个服务同时注册到两个注册中心，但是只从其中一个依赖其他服务
<dubbo:registry address=“10.20.153.10:9090” subscribe=“false” />
<dubbo:registry address=“10.20.153.223:9090” />

静态服务

使用场景：有时候希望人工管理服务提供者的上线和下线，此时须将注册中心标识为非动态管理模式
<dubbo:registry address=“10.20.153.10:9090” dynamic=“false” />
服务提供者初次注册时为禁用状态,需人工启用，断线时，将不会被自动删除，需人工禁用

多协议配置

使用场景：不同服务在性能上使用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议
//多协议配置
<dubbo:protocal name=“dubbo” port=“20880” />
<dubbo:protocal name=“rmi” port=“1099 />
//使用不同协议暴露服务
<dubbo:service interface=“com.demo.Service” ref=”" protocal=“dubbo” />
<dubbo:service interface=“” ref=“” protocal=“rmi”/>
//使用多个协议暴露服务
<dubbo:service id=“service” interface=“” ref=“” protocal=“dubbo,rmi” />

多注册中心注册（服务端）和多注册中心引用（消费端）

同多协议配置相似可以通过注册中心id进行引用和服务注册<dubbo:registry id=“r1” address=“” />

多版本

使用场景：当一个接口实现出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用
1.在低压力时间段，先升级一半提供者为新版本
2.再将所有消费者升级为新版本
3.然后将剩下的一半提供者升级为新版本
<dubbo:service interface=“” ref=“v1” version=“1.0.0” />
<dubbo:service interface=“” ref=“v2” version=“2.0.0” />

服务分组

使用场景：相同的接口，但是有不同的实现，需要区别对待
<dubbo:service group=“feedback” interface=“” />
<dubbo:service group=“member” interface=“” />
//任意组
<dubbo:service id=“” interface=“” group=“*” />

分组聚合

使用场景：比如菜单服务，接口一样，但有很多服务，用group区分，在消费方合并
搜索所有分组：<dubbo:reference interface=“” group=“*” merger=“true” />
合并指定分组：<dubbo:reference interface=“” group=“aaa,bbb” merger=“true”/>
指定方法合并(当设置为merger="false"时，可以指定某个方法不合并分组):
<dubbo:reference interface=“” group=“*”>
<dubbo:method name=“getMenuItems” merger=“true” />
</dubbo:reference>