Dubbo第二天

2020-12-03 本文已影响0人 Curtain_call

4. Dubbo 高级特性

4.1Dubbo 控制台部署

从 2.6 版本之后，dubbo 控制台已单独版本管理（目前只到 0.1 版本），使用了前后端分离的模式。前端使用 Vue 和 Vuetify 分别作为 Javascript 框架和 UI 框架，后端采用 Spring Boot 框架。考虑到后端人员操作的简易性，本文只介绍 Maven 部署方案（即将前端 vue产出的静态内容集成到 springboot 包内）。

 下载：git clone https://github.com/apache/dubbo-admin.git

在 dubbo-admin-server 子项目的属性文件中，设置 zk 地址及登陆帐户/密码：

 编译：

cd dubbo-admin

mvn clean package ##编译时间稍长，请耐心等待（前提是配置好你的 maven 环境）

 启动：

cd dubbo-admin-distribution/target

java -jar dubbo-admin-0.1.jar

 访问：

http://localhost:8080

 条件路由的使用示例：

查询服务列表后，对目标服务添加路由：

点击创建按钮后，如下填写条件信息：

保存后测试，你会发现消费方已无法调用此服务。

4.2启动时检查

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" />

4.3Dubbo 超时重连

4.3.1 超时

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

Dubbo 超时和重试配置示例：

<dubbo:reference id="xxxService" interface="com.xxx.XxxService" retries="0" timeout="5000"/>

4.3.2 重连

Dubbo 在调用服务不成功时，默认会重试 2 次；

Dubbo 的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 Dubbo 的重试机制也能一定程度的保证服务的质量。

4.4 集群容错

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

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

1、 Failover ：当出现失败，重试其它服务器。 retries=“2” 来设置重试次数(不含第一次)。

幂等性操作使用，如读操作。

2、 Failfast ：快速失败，只发起一次调用，失败立即报错。

非幂等性操作，如写操作。

3、 Failsafe ：出现异常时，直接忽略。

无关紧要的旁支操作，如打日志。

4、 Failback ：后台记录失败请求，定时重发。

后续专业处理。

5、 Forking ：并行调用多个服务器，只要一个成功即返回。

forks=“2” 来设置最大并行数。

4.5负载均衡配置

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

可以自行扩展负载均衡策略：

<dubbo:consumer loadbalance="random"/>

1、 Random ：按权重随机------根据 weight 值（服务方设置）来随机--

2、 RoundRobin ：轮询

3、 LeastActive ：最少活跃数（正在处理的数），慢的机器，收到的请求少

4.6结果缓存

dubbo 对方法调用的结果，还有缓存功能。在服务消费方和提供方都可以配置使用缓存。

以消费方为例，可以配置全局缓存策略，这样所有服务引用都启动缓存：

<dubbo:consumer cache="lru"/>

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

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

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

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

<dubbo:method name="sayHello" cache="lru"> </dubbo:method>

</dubbo:reference>

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

4.7服务分组

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

<dubbo:consumer group ="dev"/>

<dubbo:provider group ="dev"/>

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

4.8多版本

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

服务方：



<dubbo:service interface="com.xxx.XxxServices" ref="xxxService" protocol="hessian" version="1.0"/>



<dubbo:service interface="com.xxx.XxxServices" ref="xxxService2" protocol="hessian" version="2.0"/>

消费方：

<dubbo:reference id="xxxService1.0"

interface="com.xxx.XxxServices" protocol="hessian" version="2.0"/>

4.9只订阅/只注册

4.9.1 只订阅

场景：我们在本地开发的时候，不能把自己机器的未开发好的服务注册到开发环境，但是又需要使用注册中心的其他服务。

服务提供者配置禁止注册： register="false"

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

4.9.2 只注册

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

服务提供者配置禁止订阅： subscribe="false"

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

4.10异步调用

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>

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

方法异步调用后，Consumer 端的代码写法：

// 此方法异步后不再有返回值，会立刻返回 NULL

xxxService.doSomething(xxx);

// 立刻得到当前调用的 Future 实例，当发生新的调用时这个东西将会被覆盖

Future<XXX> 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" />

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

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

4.11事件通知

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

首先，需要在 SpringIOC 容器中，创建一个实现了回调接口的 Bean,假设 id=callback：

interface Callback {

public void onreturn(Person msg, Integer id);

public void onthrow(Throwable ex, Integer id);

}

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

然后在 Dubbo 中配置：

<dubbo:reference interface="com.xxx.XxxService" >

<dubbo:method name="doSomeThing" async="true" onreturn = "callback.onreturn" onthrow="callback.onthrow" />

</dubbo:reference>

配置中 async 与 onreturn、onthrow 是成对配置，组合不同，功能也不同：

 异步回调模式：async=true onreturn="xxx"

 同步回调模式：async=false onreturn="xxx"

 异步无回调：async=true

 同步无回调：async=false

4.12 Provider 端应尽量配置的属性

Dubbo 的属性配置优先度上，遵循如下顺序：

reference 属性 > service 属性 >Consumer 属性;

其中 reference 和 Consumer 是消费端配置，service 是服务端配置而对于服务调用的超时时间、重试次数等属性，服务的提供方比消费方更了解服务性能，因此我们应该在 Provider 端尽量多配置 Consumer 端属性，让其漫游到消费端发挥作用。

Provider 端尽量多配置 Consumer 端的属性，也让 Provider 的实现者一开始就思考 Provider 端的服务特点和服务质量等问题。

建议在 Provider 端配置的 Consumer 端属性有：

timeout：方法调用的超时时间

retries：失败重试次数

loadbalance：负载均衡算法，缺省是随机 random。

actives：消费者端的最大并发调用限制，即当 Consumer 对一个服务的并发调用到上限后，新调用会阻塞直到超时，在方法上配置 dubbo:method 则针对该方法进行并发限制，在接口上配置 dubbo:service，则针对该服务进行并发限制。

<dubbo:service interface="com.xxx.xxxService" timeout="300" retries="2" loadbalance="random" actives="0" >

<dubbo:method name="xxx" timeout="10000" retries="9" loadbalance="leastactive" actives="5" />

<dubbo:service/>

建议在 Provider 端配置的 Provider 端属性有：

threads：服务线程池大小。

executes：一个服务提供者并行执行请求上限，即当 Provider 对一个服务的并发调用达到上限后，新调用会阻塞，此时 Consumer 可能会超时。

在方法上配置 dubbo:method 则针对该方法进行并发限制；

在接口上配置dubbo:service，则针对该服务进行并发限制。

<dubbo:protocol threads="200" />

<dubbo:service interface="com.xxx.xxxService" version="1.0.0" ref="xxxService" executes="200" >

<dubbo:method name="xxx" executes="50" />

</dubbo:service>

4.13服务拆分最佳实现

分包

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

粒度

服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题，Dubbo 暂未提供分布式事务支持。

不建议使用过于抽象的通用接口，如：Map query(Map)，这样的接口没有明确语义，会给后期维护带来不便。

版本

每个接口都应定义版本号，为后续不兼容升级提供可能，如：

<dubbo:service interface="com.xxx.XxxService" version="1.0" />。

建议使用两位版本号，因为第三位版本号通常表示兼容升级，只有不兼容时才需要变更服务版本。当不兼容时，先升级一半提供者为新版本，再将消费者全部升为新版本，然后将剩下的一半提供者升为新版本。

异常

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