dubbo2

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纯注解异常解决方案:

dubbo2

<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

注册中心支持

dubbo2

多版本支持

dubbo2

客户端调用的时候

dubbo2

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();

dubbo2

主机绑定

  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

dubbo2

dubbo服务只订阅

dubbo2

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

dubbo服务只注册

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

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

<dubbo:registry subscribe="false"/>

负载均衡

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

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

Random LoadBalance

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

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

RoundRobin LoadBalance

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

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

dubbo2

LeastActive LoadBalance

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

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

ConsistentHash LoadBalance

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

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

连接超时timeout

​ 毫秒为单位 默认 1000

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

集群容错

dubbo2

修改集群容错方式

<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

dubbo2

服务改造

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

    • dubbo2

优雅停机

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

原理

服务提供方

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

服务消费方

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

原文 

https://segmentfault.com/a/1190000018428423

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » dubbo2

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址