本篇文章给大家谈谈dubbo接口测试类,以及dubbo 接口对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
今天给各位分享dubbo接口测试类的知识,其中也会对dubbo 接口进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!
本文目录一览:
3、dubbo服务前后台线程池隔离
目前, 前台 (C端) 和后台( B端 )dubbo接口用 同一线程池 , cost长 和 一般接口 也在同一 线程池 。这样有风险, ex: cost长 接口和 B端 的接口 并发 上来(业务量或系统bug)会对前台的 请求稳定性 和响应时间造成冲击, 降低系统的健壮性。 所以, 要接口隔离,每种出现异常不影响其他。
能进行接口隔离的方式: 线程池隔离和并发数量限制
(1)新增 一个 protocol 指定 线程池 的信息, 新增端口 , 然后在 service 中 增加该protocol 。
(2)在dubbo源码级别进行线程池隔离。
Note: 第二种彻底,但有开发难度和工作量, 选第一种。
<dubbo:service 和 <dubbo:method 中增加 executes 参数来限制该service/method的并发性。
Note: a 该种方式 隔离不彻底 。 b 目前使用dubbo版本 不支持method c 对以后新员工有一定的维护风险
最终方案: 前后端采用增加protocol方式, 超时的接口采用executes限制的方式?
第一步: 定义protocol
第二步: 修改service
第三步: 在环境上测试
测试的方法: 可以加显示日志, 打印出: Thread.currentThread().getName(), 也可以在log4j.xml的xxAppender中增加%t, 打印线程名的配置, 上图:
Note : xxAppender是要接入监控的, 为了避免影响监控采集, 上线别忘记把测试的删除掉。如果想加, 可以加载proc_time后面。
Dubbo的基本使用
官网地址
dubbo接口测试类: http://dubbo.apache.org/zh/docs/v2.7/user/examples/loadbalance
如果在消费端和服务端都配置了负载均衡策略,以消费端为准。
在服务提供者和服务消费者上都可以配置服务超时时间,这两者是不一样
dubbo接口测试类的。
消费者调用一个服务,分为三步:
1.消费者发送请求(网络传输)
2.服务端执行服务
3.服务端返回响应(网络传输)
如果在服务端和消费端各配置了一个timeout,那就比较复杂了,假设
1.服务执行为5s
2.消费端timeout=3s
3.服务端timeout=6s
那么消费端掉用服务时,消费端会收到超时异常(因为消费端超时了),服务端一切正常(服务端没有超时)。
官网地址: http://dubbo.apache.org/zh/docs/v2.7/user/examples/fault-tolerent-strategy/
集群容错表示:服务消费者在掉用某个服务时,这个服务有多个服务提供者,在经过负载均衡后选择其中一个服务提供者之后进行调用,但调用报错后,Dubbo所采取
dubbo接口测试类的后续处理策略。
官网地址: http://dubbo.apache.org/zh/docs/v2.7/user/example/service-downgrade/
服务降级表示:服务消费者在调用某个服务提供者时,如果该服务提供者报错了,所采取的措施。
集群容错和服务降级的区别在于:
1.集群容错时整个集群范围内的容错
2.服务降级时单个服务提供者的自身容错
官网地址: http://dubbo.apache.org/zh/docs/v2.7/user/examples/local-stub/
本地存根:名字很抽象,但实际上不难理解,本地存根就是一段逻辑,这段逻辑是在服务消费端执行的,这段逻辑一般都是由服务提供者提供,服务提供者可以利用这种机制在服务消费者远程调用服务提供者之前或之后再做一些其他事情,比如结果缓存,请求参数验证等等。
官网地址: http://dubbo.apache.org/zh/docs/v2.7/user/examples/local-mock
本地伪装就是Mock,Dubbo中的Mock的功能相对于本地存根更简单一点,Mock其实就是Dubbo中的服务容错的解决方案。
官网地址: http://dubbo.apache.org/zh/docs/v2.7/user/examples/callback-parameter/
如果当前服务支持参数回调,意思就是对于某个服务接口中的某个方法,如果想支持消费者在调用这个方式时能设置回调逻辑,那么该方法就是需要提供一个入参用来表示回调逻辑
因为Dubbo协议是基于长连接,所以消费者在两次调用同一个方法想指定不同的回调逻辑,那么就需要在调用时在指定一定key进行区分。
官网地址: http://dubbo.apache.org/zh/docs/v2.7/user/examples/async-call/
理解起来比较容易,主要要理解CompletableFuture,如果不理解,就直接把它理解为Future
其他异步调用方式: https://mp.weixin.qq.com/s/U3eyBUy6HBVy-xRw3LGbRQ
官网地址: http://dubbo.apache.org/zh/docs/v2.7/user/example/generic-reference/
泛化调用可以用来做服务测试。
在Dubbo中,如果某个服务想要支持泛化调用,就可以将该服务的generic属性设置为true,那对于服务消费者来说,就可以不用依赖该服务的接口,直接利用GenericService接口来进行服务调用
官网地址: http://dubbo.apache.org/zh/docs/v2.7/user/examples/generic-service/
实现了GenericService接口就是泛化服务
官网地址: http://dubbo.apache.org/zh/docs/v2.7/user/rest/
github地址: https://github.com/apache/dubbo-admin
官网地址: http://dubbo.apache.org/zh/docs/v2.7/user/examples/config-rule/
注意动态配置修改的是服务参数,并不能修改服务的协议,IP,PORT,VERSION,GROUP,因为这5个信息是服务的标识信息,是服务的身份证号,是不能修改的。
官网地址: http://dubbo.apache.org/zh/docs/v2.7/user/example/routing-rule/
https://zhuanlan.zhihu.com/p/42671353
14. dubbo源码-集群容错之MergeableCluster
在dubbo官方的用户手册中dubbo接口测试类,提到了使用 MergeableCluster 的场景--分组聚合:
功能示意图如下:
定义菜单接口方式:
Provider暴露服务--一个服务属于 group-hot dubbo接口测试类,一个服务属于 group-cold :
笔者测试时启动了两个Provider,所以总计有四个服务,dubbo-monitor监控显示如下:
Consumer调用服务:
几个重要的配置说明:
com.alibaba.dubbo.rpc.cluster.Merger 文件内容如下:
核心源码在 MergeableClusterInvoker.java 中,源码如下所示:
在条件分支 if ( merger.startsWith(".") ) {} 中,有一段逻辑: method = returnType.getMethod( merger, returnType ); ,即从dubbo服务接口方法返回类型即 java.util.List 中查找merger配置的方法,例如 .addAll ,我们先看一下debug过程各变量的值:
dubbo源码中 method = returnType.getMethod( merger, returnType ); 调用 Method method = getMethod0(name, parameterTypes, true); ,再调用 Method res = privateGetMethodRecursive(name, parameterTypes, includeStaticMethods, interfaceCandidates); ,最后调用 searchMethods(privateGetDeclaredMethods(true), name, parameterTypes)) ,得到最后方法匹配的核心逻辑如下:
从searchMethods()源码可知,方法匹配需要满足几个条件:
由上面的分析可知,如果要merger=".addAll"能够正常工作,那么只需要将dubbo服务的返回类型改成 Collection 即可,例如:
如果 com.alibaba.dubbo.rpc.cluster.Merger 文件集中方法无法满足需求,需要自定义实现,那么还是和dubbo其他扩展实现一样,依赖SPI。只需要一下几步实现即可:
看一下“Dubbo 2.7”的三大新特性
如果你不想将接口的返回值定义为Future类型,或者存在定义好的同步类型接口,则可以额外定义一个异步接口并提供Future类型的方法。
如果你的原始接口定义不是Future类型的返回值,Provider端异步也提供了类似Servlet3.0里的Async Servlet的编程接口: RpcContext.startAsync()
异步过滤器链回调。
从本地的 zookeeper 中取出一条服务数据,通过解码之后,可以看出,的确有很多参数是不必要。
在 2.7 中,如果不进行额外的配置,zookeeper 中的数据格式仍然会和 Dubbo 2.6 保持一致,这主要是为了保证兼容性,让 Dubbo 2.6 的客户端可以调用 Dubbo 2.7 的服务端。如果整体迁移到 2.7,则可以为注册中心开启简化配置的参数:
Dubbo 将会只上传那些必要的服务治理数据,一个简化过后的数据如下所示:
元数据中心的数据可以被用于服务测试,服务 MOCK 等功能。目前注册中心配置中 simplified 的默认值为 false,因为考虑到了迁移的兼容问题,在后续迭代中,默认值将会改为 true。
引入配置中心后,需要注意配置项的覆盖问题。
关于dubbo接口测试类和dubbo 接口的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。
dubbo接口测试类的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于dubbo 接口、dubbo接口测试类的信息别忘了在本站进行查找喔。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
暂时没有评论,来抢沙发吧~