dubbo2

dubbo2_第1张图片

启动服务检查

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

比如说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包


  com.caucho
  hessian
  4.0.38


  javax.servlet
  servlet-api
  2.5


  org.mortbay.jetty
  jetty
  6.1.26

修改provider.xml


 

指定service服务的协议版本号

消费端改造

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

dubbo2_第2张图片


    com.alibaba
    dubbo
    2.5.3
    
        
            org.springframework
            spring
        
    
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 

多注册中心支持

dubbo2_第3张图片

多版本支持

image-20190305173240997

客户端调用的时候

image-20190305173300918

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 future = RpcContext.getContext().getFuture();
System.out.println("aaa");
DoOrderResponse response = future.get();

dubbo2_第4张图片

主机绑定

  1. 通过

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

    serviceconfig .class

dubbo2_第5张图片

dubbo服务只订阅

image-20190305181511757

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

dubbo服务只注册

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

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

负载均衡

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

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

Random LoadBalance

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

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

RoundRobin LoadBalance

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

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

img

LeastActive LoadBalance

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

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

ConsistentHash LoadBalance

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

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

连接超时timeout

​ 毫秒为单位 默认 1000

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

集群容错

dubbo2_第6张图片

修改集群容错方式

Failover cluster

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

Failfast cluster

快速失败,只发起一次调用

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

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

Failsafe cluster

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

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

Failback cluster

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

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

Forking cluster

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

 会浪费服务器的资源

Broadcast cluster

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

配置的优先级

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

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

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

dubbo2_第7张图片

服务改造

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

    • dubbo2_第8张图片

优雅停机

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

原理

服务提供方

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

服务消费方

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

你可能感兴趣的:(dubbo)