Dubbo服务框架的常用xml配置标签用途、解释说明及配置(覆盖引用关系),dubbo启动检查、集群容错、负载均衡方式、并发、连接数等的设置

作者: admin 分类: Dubbo 发布时间: 2019-07-09 21:22  阅读: 134 views

以下罗列下dubbo框架使用过程中常用到的必备xml配置标签,以及性能优化配置等标签。

常用标签

<dubbo:service/>  
用途:服务配置
解释:用于暴露一个服务,定义服务的元信息,一个服务可以用个多个协议暴露,一个服务也可以注册到多个注册中心。

<dubbo:reference/>
用途:引用配置
解释:用于创建一个远程服务代理,一个引用可以指向多个注册中心。

<dubbo:protocol/>
用途:协议配置
解释:用于配置提供服务的协议信息,协议由提供方指定,消费方被动接受。

<dubbo:application/>
用途:应用配置
解释:用于配置当前应用信息,不管该应用是提供者还是消费者。

<dubbo:monitor/>
用途:监控中心配置
解释:用于配置连接监控中心相关信息,可选。

<dubbo:provider/>
用途:提供方配置
解释:当ProtocolConfig和ServiceConfig某属性没有配置时,采用此缺省值,可选。

<dubbo:consumer />
用途:消费方配置
解释:当ReferenceConfig某属性没有配置时,采用此缺省值,可选。

<dubbo:method/>
用途:方法配置
解释:用于ServiceConfig和ReferenceConfig指定方法级的配置信息。

<dubbo:argument/>
用途:参数配置
解释:用于指定方法参数配置。

 

标签执行优先级

查找规则,1方法级优先,接口级次之,全局配置再次之;2如果基本一样,则消费方优先,提供方次之。
(建议由服务提供方设置超时,因为一个方法需要执行多长时间,服务提供方更清楚,如果一个消费方同时引用多个服务,就不需要关系每个服务的超时设置)。

启动时检查

<!--关闭某个服务的启动时检查 -->
<dubbo:reference interface="com.xxx.service" check="false">
<!--关闭所有服务的启动时检查 -->
<dubbo:consumer check="false">
<!--关闭注册中心的启动时检查 -->
<dubbo:registry check="false">

 

集群容错模式

Failover Cluster:失败自动切换,当出现失败,重试其他服务器。通常用于非幂等性的写操作。
Failsafe Cluster:失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作。
Failback Cluster:失败自动恢复,后台记录失败请求,定时重复。通常用于消息通知操作。
Forking Cluster:并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但浪费服务资源
Broadcast Cluster:广播调用所有提供者,逐个调用,任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

<!--重试机制配置 -->
<dubbo:service retries="2">
<dubbo:reference retries="2">
<dubbo:reference>
<dubbo:method name="a"  retries="2">
</dubbo:reference>
<!-- 集群配置 -->
<dubbo:service cluster="failsafe" />
<dubbo:reference cluster="failsafe" />

 

负载均衡模式

在集群负载均衡时,Dubbo提供了多种均衡策略,缺省为random随机调用。策略有以下几种。

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

 

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

 

LeastActive LoadBalance
方式:最小活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。
说明:使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大。

 

ConsistentHash LoadBalance
方式:一致性Hash,相同参数的请求总是发到同一提供者。
说明:
● 当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。
● 算法参见:http://en.wikipedia.org/wiki/Consistent_hashing
● 缺省只对第一个参数 Hash,如果要修改,请配置
● 缺省用 160 份虚拟节点,如果要修改,请配置

服务端服务级别
<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>

 

dubbo线程模型

如果事件处理的逻辑能够迅速完成,并且不会发起新的IO请求,比如只是在内存中记个标识,则直接在IO上处理更快,因为减少了线程池调度。
但如果事件处理逻辑较慢,或者需要发起新的IO请求,比如需要查询数据库,则必须怕发到线程池,否则IO线程阻塞,将导致不能接受其他请求。
如果用IO线程处理时间,又在时间处理过程中发起新的IO请求,比如在连接时间中发起登录请求,会报”可能引发死锁”异常,但不会真死锁。因此需要通过不同的派发策略和不同的线程池配置的组合来应对不同的场景:

<dubbo:protocol name=”dubbo” dispatcher=”all” threadpool=”fixed” threads=”100″ />

dubbo默认dispatcher=all,threadpool=fixed

dispatcher线程调度方式:

.all 所有消息都派发到线程池,包括请求,响应,连接时间,断开事件,心跳等。
.direct 所有消息都不派发到线程池,全部在IO线程上直接执行。
.message 只有请求响应消息派发到线程池,其他连接断开事件,心跳等消息,直接在IO线程上执行。
.execution 只请求消息派发到线程池,不含响应,响应和其他拦截断开事件,心跳等消息,直接在IO线程上执行。
.connection 在IO县城上,将连接断开事件放入队列,有序逐个执行,其他消息派发到线程池。

 

ThreadPool线程池类型

.fixed 固定大小线程池,启动时建立线程,不关闭,一直持有(缺省)
.cached 换成线程池,空闲一分钟后删除,需要时重建。
.limited 可伸缩线程池,但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
.eager 优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时,优先创建Worker来处理任务。当任务数量大于maximumPoolSize时,将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException.(cached是在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列)

Dubbo并发控制

服务端并发控制
<dubbo:service interface="com.foo.BarService" executes="10" />

或
<dubbo:service interface="com.foo.BarService">
    <dubbo:method name="sayHello" executes="10" />
</dubbo:service>

客户端并发控制
<dubbo:service interface="com.foo.BarService" actives="10" />

或
<dubbo:reference interface="com.foo.BarService">
    <dubbo:method name="sayHello" actives="10" />
</dubbo:service>

 

Dubbo连接数设置

服务端<dubbo:provider protocol="dubbo" accepts="10" />

或 <dubbo:protocol name="dubbo" accepts="10" />


客户端<dubbo:reference interface="com.foo.BarService" connections="10" />

<dubbo:service interface="com.foo.BarService" connections="10" />

 

Dubbo线程自动dump

当业务线程池满时,我们需要知道哪些线程都在等待哪些资源、条件,已找到系统的瓶颈点或异常点。dubbo可以通过jstack自动导出堆栈线程来保留现场,方便排查问题
<dubbo:application ...>
    <dubbo:parameter key="dump.directory" value="/tmp" /><!--指定导出路径 -->
</dubbo:application>

更多schema配置请参考以下文章上下文
http://dubbo.apache.org/zh-cn/docs/user/references/xml/introduction.html


   原创文章,转载请标明本文链接: Dubbo服务框架的常用xml配置标签用途、解释说明及配置(覆盖引用关系),dubbo启动检查、集群容错、负载均衡方式、并发、连接数等的设置

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

更多阅读