dubbo中常用配置说明

上次搭建了简单dubbo项目。今天就来说说dubbo中常用的配置含义。

• 启东时检查（check=“true"）,在dubbo服务起来的时候，回检查该服务是否有对应的提供者，一般配置在consumer方。 默认为true。 <dubbo:reference id="helloDubboProvider1" check="false" interface="com.chenyi.dubbochen.api.HelloDubboProvider" retries="0" />
• 集群容错(cluster=failover)，dubbo是一个分布式服务，在多台服务器进行调用时，可能存在某台服务器异常，而导致服务异常。 集群容错就是来解决服务器在调用时异常无法保证方法的正常调用 <dubbo:service cluster="failsafe" /> // 服务提供者的熔断。 或者 <dubbo:reference cluster="failsafe" />// 服务调用放的熔断
  其中： cluster还有其他的几种容错策略
• failvoer: 失败自动切换，在调用失败后，调用方进行方法的重试调用，一把配合retries参数使用，retries的默认值为2.
  failsafe: 失败安全，出现异常时，直接忽略，常用于不需要过多记录内容使用
• failfast: 快速失败，调用方调用服务方，但是只调用一次，如果失败则直接提示调用失败，常用于幂等性操作，比如 更新，删和插入等。
• failBack 失败自动恢复，会记录失败的记录，在是否后定时重复调用，适用于消息通知。
• broadcast： 广播所有调用者，只要有一太服务异常，则认为全部失败，常用于对于更新服务器的内存或者对于服务器远程最新内容缓存到本地时
• Forking 并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过forks=2 来设置最大并行数

3. dubbo提供了各种各样的负载均衡算法

• Random 随机，在所有的服务提供者中进行随机的调用，主要是按照权重来设置随机概率。
• RoundRobin 轮训，在所有的服务提供者接受调用者的调用时，按照顺序调用。但是如果其中一太机器处理速度慢的话，会导致服务积压多。
• LeastActive 最少活跃数。最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
• ConsistentHash 一致性 Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。<dubbo:service interface="..." loadbalance="roundrobin" /> 或者 <dubbo:reference interface="..." loadbalance="roundrobin" />

4. 直连服务提供者
   在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直连方式，将以服务接口为单位，忽略注册中心的提供者列表。在服务的调用方直接指定服务提供者的信息，就可以不通过注册中心的方式调动服务提供者

   <dubbo:reference id="helloDubboProvide" interface="com.chenyi.dubbochen.api.HelloDubboProvider" url="dubbo://localhost:20890" />

5. 多版本
   当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。
   指定版本号，在服务方调用时，也需要进行服务版本号的说明和配置。

<dubbo:service interface="com.chenyi.dubbochen.api.HelloDubboProvider" version="1.0.0" />

如果服务调用方不区分版本就可以进行调用，则就配置 version = “*”

<dubbo:reference id="helloDubboProvider" interface="com.chenyi.dubbochen.api.HelloDubboProvider" version="*" />

6. 线程模型
   通过不同的派发策略和不同的线程池配置的组合来应对不同的场景

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

• Dispatcher
  • all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
  • direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。
    message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
  • execution 只有请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
  • connect 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。
• threadPool 对应于Java提供的4中线程池。
  • fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
  • cached缓存线程池，空闲一分钟自动删除，需要时重建。
  • limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
  • eager优先创建worker线程池。在任务数量大于corePoolSize但是小于maxPoolSize时，优先创建worker处理任务。当任务数量大于maxPoolSIze时，将任务放入阻塞队列中。阻塞队列充满时抛出RejectExecutionException。

7. 分组
   在dubbo服务调用方添加分组

<dubbo:registry  address="zookeeper://127.0.0.1:2181" group="/dubbo/abc"/>

在指定注册中心的分组后，在服务提供者使用此注册中心时也会注册到注册中心所在的分组上。
到对应的zookeeper上看相关服务的提供者和内容
1. 连接到zkserver上
2. 找到对应的路径（group = “/dubbo/abc”）

3… 查看服务注册情况 由于在项目中只配置服务调用反的注册中心有分组的信息，但是对应的provider没有，那么provider的默认分组路径是在哪里呢？

答案是在/dubbo路径下
原因看下图

这次的dubbo常用配置就写到这里了,下章看是看dubbo注册中心的内容哦