dubbo2

启动服务检查

如果提供方没有启动的时候，默认会去检测所依赖的服务是否正常提供服务

比如说order依赖于pay，必须pay启动了，才能够使用order

如果check为false，表示启动的时候不去检查。当服务出现循环依赖的时候(两个服务彼此依赖)，check设置成false

dubbo:reference 属性： check 默认值是true 、false

dubbo:consumer check=”false” 没有服务提供者的时候，报错

dubbo:registry check=false 注册订阅失败报错

dubbo:provider

多协议支持

dubbo支持的协议： dubbo、RMI、hessian、webservice、http、Thrift、 memcached 、 redis 、rest

老项目协议无法改变，通过配置协议来解决

hessian协议

引入jar包

<dependency>
  <groupId>com.caucho</groupId>
  <artifactId>hessian</artifactId>
  <version>4.0.38</version>
</dependency>
<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>servlet-api</artifactId>
  <version>2.5</version>
</dependency>
<dependency>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty</artifactId>
  <version>6.1.26</version>
</dependency>

修改provider.xml

<!--增加hessian协议-->
<dubbo:protocol name="hessian" port="8090" server="jetty"/>

指定service服务的协议版本号

<dubbo:service interface="com.zzjson.IOrderServices" ref="orderService" protocol="hessian"/>

消费端改造

<dubbo:reference interface="com.zzjson.IOrderServices" id="orderServices" protocol="Hessain"/>

dubbo使用spring纯注解异常解决方案：

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>dubbo</artifactId>
    <version>2.5.3</version>
    <exclusions>
        <exclusion>
            <groupId>org.springframework</groupId>
            <artifactId>spring</artifactId>
        </exclusion>
    </exclusions>
</dependency

hessian%3A%2F%2F192.168.4.169%3A8080%2Fcom.zzjson.IOrderServices%3Fanyhost%3Dtrue%26application%3Dorder-provider%26dubbo%3D2.5.3%26interface%3Dcom.zzjson.IOrderServices%26methods%3DdoOrder%26owner%3Dzzy%26pid%3D61276%26server%3Djetty%26side%3Dprovider%26timestamp%3D1551776679018

dubbo%3A%2F%2F192.168.4.169%3A20880%2Fcom.zzjson.IOrderServices%3Fanyhost%3Dtrue%26application%3Dorder-provider%26dubbo%3D2.5.3%26interface%3Dcom.zzjson.IOrderServices%26methods%3DdoOrder%26owner%3Dzzy%26pid%3D61276%26side%3Dprovider%26timestamp%3D1551776679988

多注册中心支持

多版本支持

客户端调用的时候

dubbo%3A%2F%2F192.168.4.169%3A20880%2Fcom.zzjson.IOrderServices2%3Fanyhost%3Dtrue%26application%3Dorder-provider%26dubbo%3D2.5.3%26interface%3Dcom.zzjson.IOrderServices%26methods%3DdoOrder%26owner%3Dzzy%26pid%3D61661%26revision%3D1.0%26side%3Dprovider%26timestamp%3D1551778295256%26version%3D1.0

hessian%3A%2F%2F192.168.4.169%3A8080%2Fcom.zzjson.IOrderServices2%3Fanyhost%3Dtrue%26application%3Dorder-provider%26dubbo%3D2.5.3%26interface%3Dcom.zzjson.IOrderServices%26methods%3DdoOrder%26owner%3Dzzy%26pid%3D61661%26revision%3D1.0%26server%3Djetty%26side%3Dprovider%26timestamp%3D1551778294832%26version%3D1.0

dubbo%3A%2F%2F192.168.4.169%3A20880%2Fcom.zzjson.IOrderServices%3Fanyhost%3Dtrue%26application%3Dorder-provider%26dubbo%3D2.5.3%26interface%3Dcom.zzjson.IOrderServices%26methods%3DdoOrder%26owner%3Dzzy%26pid%3D61661%26revision%3D2.0%26side%3Dprovider%26timestamp%3D1551778294284%26version%3D2.0

hessian%3A%2F%2F192.168.4.169%3A8080%2Fcom.zzjson.IOrderServices%3Fanyhost%3Dtrue%26application%3Dorder-provider%26dubbo%3D2.5.3%26interface%3Dcom.zzjson.IOrderServices%26methods%3DdoOrder%26owner%3Dzzy%26pid%3D61661%26revision%3D2.0%26server%3Djetty%26side%3Dprovider%26timestamp%3D1551778293346%26version%3D2.0

异步调用

​ 调用接口过程可能比较慢，我们有时候并不需要同步等待，原理使用的是future异步回调机制

async="true"表示接口异步返回

hessian协议，使用async异步回调会报错

Future<DoOrderResponse> future = RpcContext.getContext().getFuture();
System.out.println("aaa");
DoOrderResponse response = future.get();

主机绑定

1. 通过<dubbo:protocol host配置的地址去找

   <dubbo:protocol name="dubbo" port="20880" host="192.168.4.169"/>

2. host = InetAddress.getLocalHost().getHostAddress()
3. 通过socket发起连接连接到注册中心的地址。再获取连接过去以后本地的ip地址
4. host = NetUtils.getLocalHost();

   serviceconfig .class

dubbo服务只订阅

​ 测试过程中，正在开发，有问题，注册到注册中心了，只需要订阅服务，只订阅，不注册,开发的时候设置为false，只订阅，不注册

dubbo服务只注册

​ 只提供服务，不订阅服务

​ 多注册中心情况下，服务发布到两个注册中心，其中一个注册中心还没有发布，但是需要注册，dubbo只会选择其中一个可用的去使用

<dubbo:registry subscribe="false"/>

负载均衡

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

​ http://dubbo.apache.org/zh-cn...

Random LoadBalance

​ 随机，按权重设置随机概率。

​ 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance

​ 轮循，按公约后的权重设置轮循比率。

​ 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance

​ 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。

​ 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

​ 一致性Hash，相同参数的请求总是发到同一提供者。

​ 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

连接超时timeout

​ 毫秒为单位 默认 1000

​ 必须要设置服务的处理的超时时间

集群容错

​

修改集群容错方式

<dubbo:service cluster="failsafe" />

Failover cluster

​ 失败的时候自动切换并重试其他服务器。 通过retries=2。 来设置重试次数

Failfast cluster

​ 快速失败，只发起一次调用

​ 写操作。比如新增记录的时候， 非幂(服务调用后端某一接口发起多次结果不变)等请求

​ insert 唯一的key,影响行数只会影响一行

Failsafe cluster

​ 失败安全 。 出现异常时，直接忽略异常

​ 写日志，不一定要日志保存成功，失败了不能影响主程序的运行

Failback cluster

​ 失败自动恢复 。 后台记录失败请求，定时重发

​ 比如说消息通知，失败了一直发送

Forking cluster

​ 并行调用多个服务器，只要一个成功就返回。 只能应用在读请求

会浪费服务器的资源

Broadcast cluster

​ 广播调用所有提供者，逐个调用。其中一台报错就会返回异常

配置的优先级

如果消费端和服务端都设置了超时时间，那么谁的优先级最大

消费端优先级别最高 – 服务端

Reference method>servicemethod>reference>service>consumer>provider

服务改造

• dubbo依赖spring版本是2.几太低,更改依赖

  • 

优雅停机

​ Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的，所以如果用户使用 kill -9 PID 等强制关闭指令，是不会执行优雅停机的，只有通过 kill PID 时，才会执行。

原理

服务提供方

• 停止时，先标记为不接收新请求，新请求过来时直接报错，让客户端重试其它机器。
• 然后，检测线程池中的线程是否正在运行，如果有，等待所有线程执行完成，除非超时，则强制关闭。

服务消费方

• 停止时，不再发起新的调用请求，所有新的调用在客户端即报错。
• 然后，检测有没有请求的响应还没有返回，等待响应返回，除非超时，则强制关闭。

# dubbo.properties
dubbo.service.shutdown.wait=15000