Dubbo基础使用_

在上面的章节，我们重点详述了，一个具体的 RPC 调用的全过程。那么在现
实工作中，服务节点间的 RPC 调用是非常普遍并且错踪复杂的

我们除了要关心 RPC 的过程实现，还需要考虑:

1. 服务方是集群时，如何挑选一台机器来响应客户端?
2. 因网络抖动引起的调用失败，如何重试来弥补?
3. 服务方机器的动态增减，如何能够让客户端及时了解到并做出调整? …

Dubbo 的使命，即是解决上述围绕 RPC 过程的问题

Dubbo服务的角色关系

节点角色说明:
调用关系说明:

1. 服务容器负责启动，加载，运行服务提供者。
2. 服务提供者在启动时，向注册中心注册自己提供的服务。
3. 服务消费者在启动时，向注册中心订阅自己所需的服务。
4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将 基于长连接推送变更数据给消费者。
5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供 者进行调用，如果调用失败，再选另一台调用。
6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟 发送一次统计数据到监控中心。

Dubbo的基础配置使用

xml 配置方式

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

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

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

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

<dubbo:registry/> 注册中心配置，用于配置连接注册中心相关信息。 dubbo:module/ 模块配置，用于配置当前模块信息，可选。

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

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

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

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

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

---

引入pom依赖

 <!--zk -->
 <dependency>
      <groupId>org.apache.curator</groupId>
      <artifactId>curator-recipes</artifactId>
      <version>2.7.1</version>
  </dependency>
  <dependency>
      <groupId>org.apache.curator</groupId>
      <artifactId>curator-client</artifactId>
      <version>2.7.1</version>
  </dependency>

  <!-- dubbo -->
  <dependency>
      <groupId>com.alibaba</groupId>
      <artifactId>dubbo</artifactId>
      <version>2.6.2</version>
  </dependency>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

服务端代码示例

创建dubbo-server.xml文件

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
	 http://www.springframework.org/schema/beans/spring-beans.xsd
	      http://www.springframework.org/schema/context
                        http://www.springframework.org/schema/context/spring-context-3.1.xsd
	 http://code.alibabatech.com/schema/dubbo
	 http://code.alibabatech.com/schema/dubbo/dubbo.xsd">

    <!--全局配置-->
    <dubbo:provider timeout="3000" />
    <!-- 服务提供方应用名称, 方便用于依赖跟踪 -->
    <dubbo:application name="busi-server" />
    <!-- 使用本地zookeeper作为注册中心 -->
    <dubbo:registry address="zookeeper://127.0.0.1:2181" />

    <!--name指示使用什么协议监听端口：dubbo/rmi/rest-->
    <dubbo:protocol id="d1"  name="dubbo" port="20880" />

    <!-- 通过xml方式配置为bean, 让spring托管和实例化 -->
    <bean id="orderService" class="com.enjoy.service.OrderServiceImpl"/>
    <!-- 声明服务暴露的接口，并暴露服务 -->
    <dubbo:service interface="com.enjoy.service.OrderService" ref="orderService" protocol="d1" />
</beans>
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

引入配置文件

@ImportResource(locations="classpath:spring/*.xml")
@Configuration
public class DubboConfig {


}
1
2
3
4
5
6

客户端代码示例

创建dubbo-client.xml配置文件

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
	 http://www.springframework.org/schema/beans/spring-beans.xsd
	      http://www.springframework.org/schema/context
                        http://www.springframework.org/schema/context/spring-context-3.1.xsd
	 http://code.alibabatech.com/schema/dubbo
	 http://code.alibabatech.com/schema/dubbo/dubbo.xsd">

    <dubbo:application name="busi-clint" />
    <dubbo:registry address="zookeeper://127.0.0.1:2181" />

    <dubbo:reference id="orderService" interface="com.enjoy.service.OrderService" />

</beans>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

调用服务端接口

@RestController
public class OrderController {

    @Autowired
    private OrderService orderService;

    @GetMapping("/find")
    public Object findOrder(){
        OrderEntity detail = orderService.getDetail("1");
        System.out.println(detail.toString());
        return detail;
    }

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

注解方式

注解方式的底层与 XML 一致，只是表现形式上的不同。目标都是将 Dubbo 基础信息配入，主要涉及 以下五个必不可少的信息:ApplicationConfig、ProtocolConfig 、RegistryConfig、service、reference

EnableDubbo 开启服务
@EnableDubbo:开启注解 Dubbo 功能 ，其中可以加入 scanBasePackages 属性配置包扫描的路径，用于扫描并 注册 bean。其中 封装了组件 @DubboComponentScan，来扫描 Dubbo @Service 注解暴露 Dubbo 服务，以及 扫描Dubbo @Reference字段或者方法注入Dubbo服务代理。

Dubbo高级特性

启动时检查

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 check=“true”
可以通过 check="false"关闭检查，比如，测试时，有些服务不关心，或者出 现了循环依赖，必须有一方先启动
另外，如果你的 Spring 容器是懒加载的，或者通过 API 编程延迟引用服务， 请关闭 check，否则服务临时不可用时，会抛出异常，拿到 null 引用，如果 check=“false”，总是会返回引用，当服务恢复时，能自动连上

关闭某个服务的启动时检查(没有提供者时报错):
<dubbo:reference id=“xxxService” check=“false” interface=“com.xxx.XxxService”/>
关闭所有服务的启动时检查(没有提供者时报错):
<dubbo:consumer check=“false” />
关闭注册中心启动时检查(注册订阅失败时报错):
<dubbo:registry check=“false” />

Dubbo 超时重连

Dubbo 消费端在发出请求后，需要有一个临界时间界限来判断服务端是否正常。这样消费端达到超 时时间，那么 Dubbo 会进行重试机制，不合理的重试在一些特殊的业务场景下可能会引发很多问题， 需要合理设置接口超时时间
Dubbo 超时和重试配置示例:

 <!-- 服务调用超时设置为 5 秒,超时不重试-->
<dubbo:reference id="xxxService" interface="com.xxx.XxxService" retries="0" timeout="5000"/>
1
2

Dubbo在调用服务不成功时，默认会重试 2 次
Dubbo的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 Dubbo 的重试机 制也能一定程度的保证服务的质量

集群容错

当消费端某次调用失败是一些环境偶然因素造成的(如网络抖动)，dubbo 还给予了容错补救机会。补救方式存在以下几种

<dubbo:consumer cluster="failover” retries="2" forks="2" />
1

1. Failover :当出现失败，重试其它服务器。 retries=“2” 来设置重试次数(不含第一次)。幂等性操作使用，如读操作
2. Failfast :快速失败，只发起一次调用，失败立即报错非幂等性操作，如写操作
3. Failsafe :出现异常时，直接忽略无关紧要的旁支操作，如打日志
4. Failback :后台记录失败请求，定时重发后续专业处理
5. Forking :并行调用多个服务器，只要一个成功即返回forks=“2” 来设置最大并行数

负载均衡配置

在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。 可以自行扩展负载均衡策略

<dubbo:consumer loadbalance="random"/>
1

1. Random :按权重随机------根据weight值(服务方设置)来随机–
2. RoundRobin :轮询
3. LeastActive :最少活跃数(正在处理的数)，慢的机器，收到的请求少

结果缓存

dubbo对方法调用的结果，还有缓存功能。在服务消费方和提供方都可以配置使用缓存。 以消费方为例，可以配置全局缓存策略，这样所有服务引用都启动缓存

<dubbo:consumer cache="lru"/>
1

还可以仅对某个服务引用配置缓存策略

<dubbo:reference id="xxxService" interface="com.xxx.XxxService" cache="lru" >
1

还支持对单个方法启用缓存策略

<dubbo:reference id="xxxService" interface="com.xxx.XxxService" >
<dubbo:method name="sayHello" cache="lru"> </dubbo:method> </dubbo:reference>
1
2

服务方配置方法与消费端完全一样。

服务分组

比如，想在同一个注册中心中，分隔测试和开发环境(省一套注册服务)

<dubbo:consumer group ="dev"/> 
<dubbo:provider group ="dev"/>
1
2

只要 group 按开发组和测试组对应，同一个注册中心里的两套服务就互不干扰

多版本

服务端提供接口的实现升级时，可由 dubbo 的版本号操作进行过渡。如果上线上测试新版本接口有 缺陷，为了不影响业务，要迅速切回原版本接口，最大程度减少损失。
服务方:

<!--版本 1 接口-->
<dubbo:service interface="com.xxx.XxxServices" ref="xxxService" protocol="hessian" version="1.0"/>
<!--版本 2 接口-->
<dubbo:service interface="com.xxx.XxxServices" ref="xxxService2" protocol="hessian" version="2.0"/>
1
2
3
4

消费方:

<dubbo:reference id="xxxService" interface="com.xxx.XxxServices"  version="2.0"/>
1

只订阅/只注册

只订阅
场景:我们在本地开发的时候，不能把自己机器的未开发好的服务注册到开发环境，但是又需要使 用注册中心的其他服务
服务提供者配置禁止注册 register=“false”

<dubbo:registry protocol="zookeeper" register="false"/>
1

只注册
比如开发环境为了省机器，没有部署某个服务，如短信/邮件功能。但整个系统又必须要调用它。此时我们可以借用一下测试环境的此服务（不能影响测试环境原本的服务闭环）。将测试环境的短信/邮件服务也向开发环境注册一份，只注册（其依赖的服务必须还是测试环境的）服务提供者配置禁止订阅 subscribe=“false”

<dubbo:registry protocol="zookeeper" subscribe="false"/>
1

异步调用

Dubbo 的异步调用是非阻塞的 NIO 调用，一个线程可同时并发调用多个远程服务，每个服务的调用都是非阻塞的，线程立即返回。就是对 java 中 Futrue模式的扩展支持

如上图，userThread 发出调用后，IOThread 会立即返回，并在 RPC 上下RpcContext中设置Future。userThread后续可以从RpcContext中取得此Future，
然后 wait 这个 Future 其它的事情都由 IOThread 完成。
总之，userThread 发出调用后 IOThread 会立刻返回，而不是等调用在服务端执行完代码、返回结果后返回。用户返回后可以去做点其它事情，比如调用另外一个服务，然后回头等待前一个调用完成。从上图可以看出，异步调用完全是 Consumer 端的行为。

配置：

<dubbo:reference id="xxxService" interface="com.xxx.XxxService">
<dubbo:method name="doSomething" async="true" />
</dubbo:reference>
1
2
3

async=true 表示异步调用，可以看到配置发生在 Consumer 端，能精确到方法。

此方法异步后不再有返回值，会立刻返回 NULL
xxxService.doSomething(xxx);
立刻得到当前调用的 Future 实例，当发生新的调用时这个东西将会被覆盖
Future xxxFuture = RpcContext.getContext().getFuture();

等待调用完成，线程会进入 Sleep 状态，当调用完成后被唤醒。
Foo foo = fooFuture.get();

配置是否等待 IOThread 发送完 Request 后再返回：
sent=“true” ，等待请求发送出去后再返回，如果发送失败直接抛出异常。
sent=“false” ，将调用交给 IOThread 后立即返回。实际这个时候请求进入到 IOThread的队列，排除等着被发送出去。

<dubbo:method name="xxx" async="true" sent="true" />
1

如果对返回结果没有兴趣：

<dubbo:method name="xxx" async="true" return="false" />
1

事件通知

对于一次远程方法调用，有 oninvoke、onreturn、onthrow 三个事件，分别为调用之前、返回之后，抛出异常三个事件。在 Consumer 端，可以为三个事件指定事件处理方法。

首先，需要在 SpringIOC 容器中，创建一个实现了回调接口的 Bean

第一个参数是接口的返回值，第二个参数的调用接口的入参

@Component
public class Callback {
    public void onreturn(OrderEntity msg, String id) {
        System.out.println(msg.toString());
    }

    public void onthrow(Throwable ex, Integer id) {

    }
}
1
2
3
4
5
6
7
8
9
10

方法中，第一个参数是远程方法的返回值，其它是方法的参数。

然后在 Dubbo 中配置：

<dubbo:reference interface="com.xxx.XxxService" >
	<dubbo:method name="doSomeThing" async="true" onreturn = "callback.onreturn" onthrow="callback.onthrow" />
</dubbo:reference>
1
2
3

配置中 async 与 onreturn、onthrow 是成对配置，组合不同，功能也不同：
异步回调模式：async=true onreturn=“xxx”
同步回调模式：async=false onreturn=“xxx”
异步无回调 ：async=true
同步无回调 ：async=false

服务拆分最佳实现

分包
建议将服务接口、服务模型、服务异常等均放在 API 包中，因为服务模型和异常也是 API 的一部分，这样做也符合分包原则：重用发布等价原则(REP：复用的粒度即是发布的粒度，我们所重用的任何东西必须同时被发布和跟踪)，共同重用原则(CRP：如果你重用了一个组件中的一个类，那么就要重用包中的所有类)。

粒度
服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题，Dubbo 暂未提供分布式事务支持。不建议使用过于抽象的通用接口，如：Map query(Map)，这样的接口没有明确语义，会给后期维护带来不便。

版本
每个接口都应定义版本号，为后续不兼容升级提供可能，如：
<dubbo:service interface="com.xxx.XxxService"version=“1.0” />。
建议使用两位版本号，因为第三位版本号通常表示兼容升级，只有不兼容时才需要变更服务版本。当不兼容时，先升级一半提供者为新版本，再将消费者全部升为新版本，然后将剩下的一半提供者升为新版本。

异常
建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多信息，并且语义更友好。