dubbo2

启动服务检查如果提供方没有启动的时候，默认会去检测所依赖的服务是否正常提供服务比如说order依赖于pay，必须pay启动了，才能够使用order如果check为false，表示启动的时候不去检查。当服务出现循环依赖的时候(两个服务彼此依赖)，check设置成falsedubbo:reference 属性： check 默认值是true 、falsedubbo: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></dependencyhessian%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%3D1551776679018dubbo%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.0hessian%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.0dubbo%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.0hessian%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();主机绑定通过<dubbo:protocol host配置的地址去找<dubbo:protocol name=“dubbo” port=“20880” host=“192.168.4.169”/>host = InetAddress.getLocalHost().getHostAddress()通过socket发起连接连接到注册中心的地址。再获取连接过去以后本地的ip地址host = NetUtils.getLocalHost();serviceconfig .classdubbo服务只订阅 测试过程中，正在开发，有问题，注册到注册中心了，只需要订阅服务，只订阅，不注册,开发的时候设置为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.propertiesdubbo.service.shutdown.wait=15000