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 超时和重试配置示例：
<!-- 服务调用超时设置为 5 秒,超时不重试-->
<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 的版本号操作进行过渡。如果上线上测试新版本接口有缺陷，为了不影响业务，要迅速切回原版本接口，最大程度减少损失。
服务方：
<!--版本 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"/>
消费方：
<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" />。
建议使用两位版本号，因为第三位版本号通常表示兼容升级，只有不兼容时才需要变更服务版本。当不兼容时，先升级一半提供者为新版本，再将消费者全部升为新版本，然后将剩下的一半提供者升为新版本。
异常
建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多信息，并且语义更友好。
