dubbo 知识总结 dubbo配置参考

dubbo官方文档

项目的规模越来越大，总得解耦，不能在一个项目里，这时候，公司采用了dubbo作为分布式应用，将多项业务拆分，并做了库存服务统一、价格服务统一等等一些特殊需要统一性的服务。

作为dubbo我也接触了快一年的时间，总会有一些自己的对dubbo的想法。

下面是对dubbo的说明：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Lur8Gtnn-1660431706270)(http://dubbo.io/dubbo-architecture.jpg-version=1&modificationDate=1330892870000.jpg)]

节点角色说明：
    Provider: 暴露服务的服务提供方。
    Consumer: 调用远程服务的服务消费方。
    Registry: 服务注册与发现的注册中心。
    Monitor: 统计服务的调用次调和调用时间的监控中心。
    Container: 服务运行容器。
    调用关系说明：
0. 服务容器负责启动，加载，运行服务提供者。
1. 服务提供者在启动时，向注册中心注册自己提供的服务。
2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
(1) 连通性：
注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销
服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销
注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
注册中心和监控中心都是可选的，服务消费者可以直连服务提供者
(2) 健状性：

监控中心宕掉不影响使用，只是丢失部分采样数据
数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
注册中心对等集群，任意一台宕掉后，将自动切换到另一台
注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
服务提供者无状态，任意一台宕掉后，不影响使用
服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
(3) 伸缩性：

注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者
(4) 升级性：

当服务集群规模进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来阻力：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

当zookeeper挂掉了，其实dubbo的消费者也能访问生产者，因为项目在启动的时候，会去主动拉取所有生产者的地址端口等数据。每次消费者应用访问的时候首先是从本地地址缓存中读取。

服务提供方调试：

    

    
    

    
    

    
    

    
    
1
2
3
4
5
6
7
8
9
10
11
12
13
14

服务消费方配置：

    
    

    
    

    
    
1
2
3
4
5
6
7
8

官方给的文档可以根据包直接扫描包下含com.alibaba.dubbo.config.annotation.Service注直接解的类，但一般不采用这个，一般都是在xml文件里面配，因为这样可以清楚的看到你配的所有dubbo服务提供方接口以及接口的限制条件

1
2

常用消费者的属性

    

1
2
3
4
5
6
7
8
9
10
11
12

dubbo调用服务的负载均衡，最后一种比较适合短时间内大量参数一样的请求

Random LoadBalance
    随机，按权重设置随机概率。
    在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
RoundRobin LoadBalance
    轮循，按公约后的权重设置轮循比率。
    存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
LeastActive LoadBalance
    最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
    使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance
    一致性Hash，相同参数的请求总是发到同一提供者。
    当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
    算法参见：http://en.wikipedia.org/wiki/Consistent_hashing。
    缺省只对第一个参数Hash，如果要修改，请配置
    缺省用160份虚拟节点，如果要修改，请配置
配置如：


或：


或：


    

或：


    


事件处理线程说明
    如果事件处理的逻辑能迅速完成，并且不会发起新的IO请求，比如只是在内存中记个标识，则直接在IO线程上处理更快，因为减少了线程池调度。
    但如果事件处理逻辑较慢，或者需要发起新的IO请求，比如需要查询数据库，则必须派发到线程池，否则IO线程阻塞，将导致不能接收其它请求。
    如果用IO线程处理事件，又在事件处理过程中发起新的IO请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁。
    Dispatcher
    all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
    direct 所有消息都不派发到线程池，全部在IO线程上直接执行。
    message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在IO线程上执行。
    execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在IO线程上执行。
    connection 在IO线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。
    ThreadPool
    fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
    cached 缓存线程池，空闲一分钟自动删除，需要时重建。
    limited 可伸缩线程池，但池中的线程数只会增长不会收缩。(为避免收缩时突然来了大流量引起的性能问题)。

配置如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

下面这个配置可以造成服务提供方只订阅不向注册中心注册

为方便开发测试，经常会在线下共用一个所有服务可用的注册中心，这时，如果一个正在开发中的服务提供者注册，可能会影响消费者不能正常运行。
禁用注册配置：

或者：

1
2
3
4
5

下面这个配置可以造成服务消费方只注册不向注册中心订阅

如果有两个镜像环境，两个注册中心，有一个服务只在其中一个注册中心有部署，另一个注册中心还没来得及部署，而两个注册中心的其它应用都需要依赖此服务，所以需要将服务同时注册到两个注册中心，但却不能让此服务同时依赖两个注册中心的其它服务。
禁用订阅配置：



或者：


1
2
3
4
5
6
7
8

不同服务在性能上适用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议。

   
   

   
   
   

   
   
   
   
   
   
1
2
3
4
5
6
7
8
9
10
11
12
13

多注册中心

中文站有些服务来不及在青岛部署，只在杭州部署，而青岛的其它应用需要引用此服务，就可以将服务同时注册到两个注册中心。

 

    
    
    

    
    

CRM有些服务是专门为国际站设计的，有些服务是专门为中文站设计的。


    
    
    

    
    

    
    

当一个接口有多种实现时，可以用group区分。





任意组：(2.2.0以上版本支持，总是只调一个可用组的实现)


当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。
在低压力时间段，先升级一半提供者为新版本
再将所有消费者升级为新版本
然后将剩下的一半提供者升级为新版本






不区分版本：(2.2.0以上版本支持)


按组合并返回结果，比如菜单服务，接口一样，但有多种实现，用group区分，现在消费方需从每种group中调用一次返回结果，合并结果返回，这样就可以实现聚合菜单项。比较鸡肋，小点的项目应该都用不到
配置如：(搜索所有分组)

(合并指定分组)


(指定方法合并结果，其它未指定的方法，将只调用一个Group)

    


(某个方法不合并结果，其它都合并结果)




(指定合并策略，缺省根据返回值类型自动匹配，如果同一类型有两个合并器时，需指定合并器的名称)

    


(指定合并方法，将调用返回结果的指定方法进行合并，合并方法的参数类型必须是返回结果类型本身)

    

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

dubbo 参数验证

    字段验证
    @NotNull // 不允许为空
    @Size(min = 1, max = 20) // 长度或大小范围
    private String name;

    @NotNull(groups = ValidationService.Save.class) // 保存时不允许为空，更新时允许为空 ，表示不更新该字段
    @Pattern(regexp = "^\s*\w+(?:\.{0,1}[\w-]+)*@[a-zA-Z0-9]+(?:[-.][a-zA-Z0-9]+)*\.[a-zA-Z]+\s*$")
    private String email;

    @Min(18) // 最小值
    @Max(100) // 最大值
    private int age;

    @Past // 必须为一个过去的时间
    private Date loginDate;

    @Future // 必须为一个未来的时间
    private Date expiryDate;

    分组验证示例：
     //下面这个验证应该是用于作用在参数类属性上的时候，当被调用的方法属于ValidationService接口的时候校验不为空
     // 缺省可按服务接口区分验证场景，如：@NotNull(groups = ValidationService.class)
    public interface ValidationService { 

        //下面这个验证应该是用于作用在参数类属性上的时候，当被调用的方法属于ValidationService接口的save方法的时候校验不为空
        @interface Save{} // 与方法同名接口，首字母大写，用于区分验证场景，如：@NotNull(groups = ValidationService.Save.class)，可选
        void save(ValidationParameter parameter);

        @interface Update{} // 与方法同名接口，首字母大写，用于区分验证场景，如：@NotNull(groups = ValidationService.Update.class)，可选
        void update(ValidationParameter parameter);

        void delete(@Min(1) long id, @NotNull @Size(min = 2, max = 16) @Pattern(regexp = "^[a-zA-Z]+$") String operator);

    }

    关联验证示例：
    public interface ValidationService {

         //下面这个验证应该是指该方法的调用参数必须满足Update组合Save组验证规则
        @GroupSequence(Update.class) // 同时验证Update组规则
        @interface Save{}
        void save(ValidationParameter parameter);

        @interface Update{} 
        void update(ValidationParameter parameter);

    }

    在客户端验证参数：
    

    在服务器端验证参数：
    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

dubbo的令牌验证

防止消费者绕过注册中心访问提供者
在注册中心控制权限，以决定要不要下发令牌给消费者
注册中心可灵活改变授权方式，而不需修改或升级提供者
可以全局设置开启令牌验证：





也可在服务级别设置：





1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

dubbo常用配置：

 version version string  可选  0.0.0   服务发现    服务版本，建议使用两位数字版本，如：1.0，通常在接口不兼容时版本号才需要升级

 group   group   string  可选      服务发现    服务分组，当一个接口有多个实现，可以用分组区分

//主要因为dubbo服务在spring2.X初始化所有类之前被暴露出去，导致被请求锁死了singletonObjects、beanDefinitionMap
 delay   delay   int  可选 0   性能调优    延迟注册服务时间(毫秒) ，设为-1时，表示延迟到Spring容器初始化完成时暴露服务

 timeout timeout int 可选  1000    性能调优    远程服务调用超时时间(毫秒)

 retries retries int 可选  2   性能调优    远程服务调用重试次数，不包括第一次调用，不需要重试请设为0

//这里应该还有个一致性Hash的方式，文档介绍有，但是配置文档没有。
 loadbalance loadbalance string  可选  random  性能调优    负载均衡策略，可选值：random,roundrobin,leastactive，分别表示：随机，轮循，最少活跃调用

 token   token   string/boolean  可选  false   服务治理    令牌验证，为空表示不开启，如果为true，表示随机生成动态令牌，否则使用静态令牌，令牌的作用是防止消费者绕过注册中心直接访问，保证注册中心的授权功能有效，如果使用点对点调用，需关闭令牌功能

 registry        string  可选  缺省向所有registry注册 配置关联    向指定注册中心注册，在多个注册中心时使用，值为的id属性，多个注册中心ID用逗号分隔，如果不想将该服务注册到任何registry，可将值设为N/A

 provider        string  可选  缺使用第一个provider配置    配置关联    指定provider，值为的id属性

 dynamic dynamic boolean 可选  true    服务治理    服务是否动态注册，如果设为false，注册后将显示后disable状态，需人工启用，并且服务提供者停止时，也不会自动取消册，需人工禁用。

 cluster cluster string  可选  failover    性能调优    集群方式，可选：failover/failfast/failsafe/failback/forking

 register    register    boolean 可选  true    服务治理    该协议的服务是否注册到注册中心

 owner   owner   string  可选      服务治理    服务负责人，用于服务治理，请填写负责人公司邮箱前缀

   version version string  可选      服务发现    服务版本，与服务提供者的版本一致

   group   group   string  可选      服务发现    服务分组，当一个接口有多个实现，可以用分组区分，必需和服务提供方一致

   timeout timeout long    可选  缺省使用的timeout    性能调优    服务方法调用超时时间(毫秒)

   retries retries int 可选  缺省使用的retries    性能调优    远程服务调用重试次数，不包括第一次调用，不需要重试请设为0

   loadbalance loadbalance string  可选  缺省使用的loadbalance    性能调优    负载均衡策略，可选值：random,roundrobin,leastactive，分别表示：随机，轮循，最少活跃调用

   check   check   boolean 可选  缺省使用的check  服务治理    启动时检查提供者是否存在，true报错，false忽略

   url    string  可选      服务治理    点对点直连服务提供者地址，将绕过注册中心

   cache   cache   string/boolean  可选      服务治理    以调用参数为key，缓存返回结果，可选：lru, threadlocal, jcache等   

   validation  validation  boolean 可选      服务治理    是否启用JSR303标准注解验证，如果启用，将对方法参数上的注解进行校验

   registry        string  可选  缺省将从所有注册中心获服务列表后合并结果    配置关联    从指定注册中心注册获取服务列表，在多个注册中心时使用，值为的id属性，多个注册中心ID用逗号分隔

   owner   owner   string  可选      服务治理    调用服务负责人，用于服务治理，请填写负责人公司邮箱前缀

    id      string  可选  dubbo   配置关联    协议BeanId，可以在中引用此ID，如果ID不填，缺省和name属性值一样，重复则在name后加序号

    name      string  必填  dubbo   性能调优    协议名称

    port      int 可选  dubbo协议缺省端口为20880，rmi协议缺省端口为1099，http和hessian协议缺省端口为80 
如果配置为-1 或者 没有配置port，则会分配一个没有被占用的端口。Dubbo 2.4.0+，分配的端口在协议缺省端口的基础上增长，确保端口段可控。 服务发现    服务端口

    threadpool  threadpool  string  可选  fixed   性能调优    线程池类型，可选：fixed/cached

    heartbeat   heartbeat   int 可选  0   性能调优    心跳间隔，对于长连接，当物理层断开时，比如拔网线，TCP的FIN消息来不及发送，对方收不到断开事件，此时需要心跳来帮助检查连接是否已断开

    register    register    boolean 可选  true    服务治理    该协议的服务是否注册到注册中心

    id      string  可选      配置关联    注册中心引用BeanId，可以在或中引用此ID

    address  string  必填      服务发现    注册中心服务器地址，如果地址没有端口缺省为9090，同一集群内的多个地址用逗号分隔，如：ip:port,ip:port，不同集群的注册中心，请配置多个标签

    protocol      string  可选  dubbo   服务发现    注同中心地址协议，支持dubbo, http, local三种协议，分别表示，dubbo地址，http地址，本地注册中心

    port      int 可选  9090    服务发现    注册中心缺省端口，当address没有带端口时使用此端口做为缺省值

    username      string  可选      服务治理    登录注册中心用户名，如果注册中心不需要验证可不填

    password      string  可选      服务治理    登录注册中心密码，如果注册中心不需要验证可不填

    timeout registry.timeout    int 可选  5000    性能调优    注册中心请求超时时间(毫秒)

    check   check   boolean 可选  true    服务治理    注册中心不存在时，是否报错

    register    register    boolean 可选  true    服务治理    是否向此注册中心注册服务，如果设为false，将只订阅，不注册

    subscribe   subscribe   boolean 可选  true    服务治理    是否向此注册中心订阅服务，如果设为false，将只注册，不订阅

 name    application string  必填      服务治理    当前应用名称，用于注册中心计算应用间依赖关系，注意：消费者和提供者应用名不要一样，此参数不是匹配条件，你当前项目叫什么名字就填什么，和提供者消费者角色无关，比如：kylin应用调用了morgan应用的服务，则kylin项目配成kylin，morgan项目配成morgan，可能kylin也提供其它服务给别人使用，但kylin项目永远配成kylin，这样注册中心将显示kylin依赖于morgan


标签  属性  对应URL参数 类型  是否必填    缺省值 作用  描述  兼容性
 name    application string  必填      服务治理    当前应用名称，用于注册中心计算应用间依赖关系，注意：消费者和提供者应用名不要一样，此参数不是匹配条件，你当前项目叫什么名字就填什么，和提供者消费者角色无关，比如：kylin应用调用了morgan应用的服务，则kylin项目配成kylin，morgan项目配成morgan，可能kylin也提供其它服务给别人使用，但kylin项目永远配成kylin，这样注册中心将显示kylin依赖于morgan   1.0.16以上版本

 version application.version string  可选      服务治理    当前应用的版本
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90

这两个标签感觉没什么特殊的，应该是可以配一些共通的配置在service和reference上使用而已。

注册中心上一般采用zookeeper作为注册中心，阿里内部并没有采用Zookeeper做为注册中心，而是使用自己实现的基于数据库的注册中心，即：Zookeeper注册中心并没有在阿里内部长时间运行的可靠性保障，此Zookeeper桥接实现只为开源版本提供，其可靠性依赖于Zookeeper本身的可靠性。

dubbo全部的配置信息都看了一遍，受益良多，发现了很多平时没注意的地方。大家得多看看官方文档。

。