一、dubbo注解：
提供端暴露服务时与消费端调用远程接口可以使用注解形式配置
》服务端：
》1.原来采用接口配置，暴露服务,ref:指向真正的实现对象
<dubbo:service interface="com.ll.service.UserService" ref="userServiceImpl" />
》2.现在采用注解扫描：
<dubbo:annotation package="com.ll.service.impl" />
》3.在接口实现类上使用dubbo的@Service注解：
import org.apache.dubbo.config.annotation.Service;
@Service
public class UserServiceImpl implements UserService {
》消费端：
》1.原来采用接口配置，声明需要调用的远程服务接口；生产远程服务代理： <dubbo:reference interface="com.ll.service.UserService" id="userService" />
》2.现在采用注解扫描，扫描远程接口调用处： <dubbo:annotation package="com.ll.service.impl" />
》3.在远程接口调用处使用dubbo的@Reference()注解： public class OrderServiceImpl implements OrderService { @Reference() UserService userService;
二、其他配置：
属性配置覆盖规则：消费端优先于提供端，方法优先于接口配置，接口优先于全局配置
负载均衡、服务降级，一般采用控制台动态控制。
1. 启动检查：check="false"
正常情况下，启动的时候会进行一些检查，如果检查到某些异常，会进行报错，可以使用配置将启动检查关闭，在真正调用的时候，在进行检查
<dubbo:reference interface="com.foo.BarService" check="false" /> //当前服务没有提供者时，不进行检查
<dubbo:consumer check="false" /> //所有服务没有提供者时，不进行检查
<dubbo:registry check="false" /> //注册中心没启动，不进行检查
2. 超时时间：timeout="1"
默认1000毫秒
<dubbo:reference interface="com.ll.service.UserService" id="userService" timeout="1000" >
<dubbo:method name="getUserAddressList" timeout="2000" />
</dubbo:reference>
<dubbo:consumer timeout="5000" />
3. 重试次数：
在幂等【查询、删除、修改】情况下可以设置重试次数（执行多次结果一样）
在非幂【增加】等情况下不能设置重试次数（不能执行多次）
<dubbo:reference interface="com.ll.service.UserService" id="userService" retries="2" >
<dubbo:method name="getUserAddressList" retries="1" />
</dubbo:reference>
<dubbo:consumer check="false" retries="3" />
4. 多版本：可以实现灰度发布
当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。
可以按照以下的步骤进行版本迁移：
0. 在低压力时间段，先升级一半提供者为新版本
1. 再将所有消费者升级为新版本
2. 然后将剩下的一半提供者升级为新版本
<dubbo:service interface="com.foo.BarService" version="1.0.0" /> //老版本服务提供者配置 <dubbo:service interface="com.foo.BarService" version="2.0.0" /> //新版本服务提供者配置 <dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" /> //老版本服务消费者配置 <dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" /> //新版本服务消费者配置 <dubbo:reference id="barService" interface="com.foo.BarService" version="*" /> //如果不需要区分版本，可以用*配置
5. 本地存根：
远程服务后，客户端通常只剩下接口，而实现全在服务器端，但提供方有些时候想在客户端也执行部分逻辑，比如：做 ThreadLocal 缓存，提前验证参数，调用失败后伪造容错数据等等，
此时就需要在 API 中带上 Stub，客户端生成 Proxy 实例，会把 Proxy 通过构造函数传给 Stub，然后把 Stub 暴露给用户，Stub 可以决定要不要去调 Proxy。
如果条件满足，在去调用远程接口，不满足就不去调用
》Stub 的实现：
public class UserServiceStub implements UserService { private final UserService userService;
// 构造函数传入真正的远程代理对象 public UserServiceStub(UserService userService) { this.userService = userService; } // 此代码在客户端执行, 你可以在客户端做ThreadLocal本地缓存，或预先验证参数是否合法，等等 @Override public List<UserAddress> getUserAddressList(String userId) { return StringUtils.isEmpty(userId) ? userService.getUserAddressList(userId) : null ; } }
》在spring dubbo配置文件中进行配置：
<dubbo:reference interface="com.ll.service.UserService" id="userService" stub="com.ll.service.impl.UserServiceStub" />
6. 高可用：zookeeper宕机与dubbo直连
zookeeper宕机：注册中心全部宕机后，服务提供者和服务消费者仍可以通过本地缓存通讯。当调过一次提供者后，提供者所在的主机信息，方法等都有缓存
》dubbo直连：
@Reference(url = "192.168.28.219:2181") //注解 <dubbo:reference interface="com.ll.service.UserService" id="userService" url="192.168.28.219:2181"> //配置文件
7. 负载均衡机制：
在集群负载均衡时，Dubbo 提供了多种均衡策略，默认为 random 随机调用。
》Random LoadBalance
随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
》RoundRobin LoadBalance
轮循，按公约后的权重设置轮循比率。
存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
》LeastActive LoadBalance
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
》ConsistentHash LoadBalance
一致性 Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。算法参见：http://en.wikipedia.org/wiki/Consistent_hashing
缺省只对第一个参数 Hash，如果要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />
</dubbo:reference> <!--服务端服务级别--> <dubbo:service interface="..." loadbalance="roundrobin" /> <!--服务端方法级别--> <dubbo:service interface="..."> <dubbo:method name="..." loadbalance="roundrobin"/> </dubbo:service> <!--客户端服务级别--> <dubbo:reference interface="..." loadbalance="roundrobin" /> <!--客户端方法级别--> <dubbo:reference interface="...">
<!--全局-->
<dubbo:consumer check="false" loadbalance="roundrobin" />
8. 服务降级：
当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。
可以通过服务降级功能临时屏蔽某个出错的非关键服务，并定义降级后的返回策略。
》mock=force:return+null 表示消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
》mock=fail:return+null 表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。
9. 服务容错：
在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。
》集群容错模式
Failover Cluster失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
Failfast Cluster快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
Failback Cluster失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
Broadcast Cluster广播调用所有提供者，逐个调用，任意一台报错则报错 [2]。通常用于通知所有提供者更新缓存或日志等本地资源信息。
//集群模式配置
<dubbo:service cluster="failsafe" /> <dubbo:reference cluster="failsafe" />
在实际的工作中通过整合"hystrix"进行容错：
(1). 导入依赖包：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
<version>2.1.2.RELEASE</version>
</dependency>
(2). 然后在Application类上增加@EnableHystrix来启用hystrix starter：
@SpringBootApplication @EnableHystrix //开启服务容错 public class ProviderApplication {
(3). 配置Provider端:
在Dubbo的Provider上增加@HystrixCommand配置，这样子调用就会经过Hystrix代理。
@HystrixProperty public String sayWord(String name) {
(4). 配置Consumer端:
对于Consumer端，则可以增加一层method调用，并在method上配置@HystrixCommand。当调用出错时，会走到fallbackMethod = "reliable"的调用里。
@HystrixCommand(fallbackMethod = "hello") //出错了，调用hello方法 public String sayHello(String name) {