深入dubbo（四）配置参考

配置项分为三大类：服务发现：表示该配置项用于服务的注册与发现，目的是让消费方找到提供方。服务治理：表示该配置项用于治理服务间的关系，或为开发测试提供便利条件。性能调优：表示该配置项用于调优性能，不同的选项对性能会产生影响。
注意：只有 group，interface，version 是服务的匹配条件，三者决定是不是同一个服务，其它配置项均为调优和治理参数。
（一）启动时检查参数 check
使用标签 reference consumer registry
xml配置法
 
<dubbo:reference interface="com.foo.BarService" check="false" /><dubbo:consumer check="false" /><dubbo:registry check="false" />
配置文件
 
dubbo.reference.com.foo.BarService.check=falsedubbo.reference.check=falsedubbo.consumer.check=falsedubbo.registry.check=false
Dubbo 缺省会在启动时检查依赖的服务是否可用，可以通过 check="false" 关闭检查（有些服务不关心，或者出现了循环依赖，必须有一方先启动， Spring 容器是懒加载的，或者通过 API 编程延迟引用服务）
（二）集群容错配置
1.默认Failover Cluster
失败自动切换，当出现失败，重试其它服务器 1。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。配置如下： 
<dubbo:service retries="2" /><dubbo:reference retries="2" /><dubbo:reference>    <dubbo:method name="findFoo" retries="2" /></dubbo:reference>
2.Failfast Cluster
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
3.Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
4.Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
5.Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
6.Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错 2。通常用于通知所有提供者更新缓存或日志等本地资源信息。
7.集群模式配置
以上六种按照以下示例在服务提供方和消费方配置集群模式
<dubbo:service cluster="failsafe" /><dubbo:reference cluster="failsafe" />
（三）负载均衡配置

Random LoadBalance随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
RoundRobin LoadBalance轮循，按公约后的权重设置轮循比率。存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
LeastActive LoadBalance最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance一致性 Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

缺省只对第一个参数 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>
（四）线程池

对于Dubbo的服务提供者，主要有两种线程池，一种是IO处理线程池，另一种是服务调用线程池。而作为IO处理线程池，由于Dubbo基于Mina、Grizzly和Netty框架做IO组件，IO线程池都是基于这些框架来配置，比如Netty中的boss和worker线程池，Dubbo选择的是“无边界”的CachedThreadPool，这意味着对所有服务请求先做到“来者不拒”，但它进一步限制了IO处理的线程数，默认是核数+1
如果事件处理的逻辑能迅速完成，并且不会发起新的 IO 请求，比如只是在内存中记个标识，则直接在 IO 线程上处理更快，如果事件处理逻辑较慢，或者需要发起新的IO请求，比如需要查询数据库，则必须派发到IO线程池中

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

Dispatcher
all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。
message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
connection 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。
ThreadPool
fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
cached 缓存线程池，空闲一分钟自动删除，需要时重建。
limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
（五）直接链接

在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连
点对点，可在 <dubbo:reference> 中配置 url 指向提供者，将绕过注册中心，多个地址用分号隔开

<dubbo:reference id="xxxService" interface="com.alibaba.xxx.XxxService" url="dubbo://localhost:20890" />
注意：为了避免复杂化线上环境，不要在线上使用这个功能，只应在测试阶段使用。






查看原文：http://hi-kys.me/?p=207