java实现dubbo接口测试（java调用dubbo接口测试）

本篇文章给大家谈谈java实现dubbo接口测试，以及java调用dubbo接口测试对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享java实现dubbo接口测试的知识，其中也会对java调用dubbo接口测试进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、dubbo协议的服务 怎么接口测试
• 2、Duplicate spring bean id 问题调查
• 3、14. dubbo源码-集群容错之MergeableCluster
• 4、怎么把mybatis的mapper接口通过dubbo暴漏
• 5、dubbo调用问题之序列化

dubbo协议的服务 怎么接口测试

dubbo支持多种远程调用方式java实现dubbo接口测试，例如dubbo RPC（二进制序列化 + tcp协议）、http invoker（二进制序列化 + http协议java实现dubbo接口测试，至少在开源版本没发现对文本序列化java实现dubbo接口测试的支持）、hessian（二进制序列化 + http协议）、WebServices （文本序列化 + http协议）等等，但缺乏对当今特别流行的REST风格远程调用（文本序列化 + http协议）的支持。有鉴于此，我们基于标准的Java REST API——JAX-RS 2.0（Java API for RESTful Web Services的简写），为dubbo提供了接近透明的REST调用支持。由于完全兼容Java标准API，所以为dubbo开发的所有REST服务，未来脱离dubbo或者任何特定的REST底层实现一般也可以正常运行。
特别值得指出的是，我们并不需要完全严格遵守REST的原始定义和架构风格。即使著名的Twitter REST API也会根据情况做适度调整，而不是机械的遵守原始的REST风格。
附注：我们将这个功能称之为REST风格的远程调用，即RESTful Remoting（抽象的远程处理或者调用），而不是叫RESTful RPC（具体的远程“过程”调用），是因为REST和RPC本身可以被认为是两种不同的风格。在dubbo的REST实现中，可以说有两个面向，其一是提供或消费正常的REST服务，其二是将REST作为dubbo RPC体系中一种协议实现，而RESTful Remoting同时涵盖了这个面向。

Duplicate spring bean id 问题调查

问题背景 ：从本地调用服务器的dubbo接口进行测试

实现思路 ：基于IDEA+Spring+maven+Dubbo搭建测试项目，从本地直接调用

具体实现思路可参考博客： https://www.cnblogs.com/xiuxingzhe/p/9250737.html

碰到问题 ：引入测试目标jar后，调用其接口运行测试类时，报错如下
Caused by: java.lang.IllegalStateException: Duplicate spring bean id cfgDistributorServiceImpl

    at com.alibaba.dubbo.config.spring.schema.DubboBeanDefinitionParser.parse(DubboBeanDefinitionParser.java:106)

    at com.alibaba.dubbo.config.spring.schema.DubboBeanDefinitionParser.parse(DubboBeanDefinitionParser.java:77)

    at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:74)

    at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1411)

    at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1401)

    at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:168)

    at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:138)

    at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:94)

    at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:508)

    at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:392)
调查思路 ：

1.检查项目中spring是否加载了两个一样的配置文件

 spring对于id的重复，默认的处理策略是覆盖

 但是dubbo的新版本对重复的id做了特殊处理，如果有重复直接抛异常，就会出现上述问题

 检查结果：自己的项目中并没有重复加载配置文件



2.spring扫描项目时，不仅会扫描当前项目中dubbo消费者，新建的类等需要注册的bean

　还会扫描pom.xml中引入的jar包中的带有以下注解的类：@Component，@Repository，@Service，@Controller，@RestController，@ControllerAdvice, @Configuration

　所以在引入包的时候，不能引入service包，因为service层的类多包含有注解@service，需要引入的是facade接口层的jar包
   检查了一下，自己引入的就是service层的jar包，至此问题找到了



            com.msa.base

            base-service

            1.0-SNAPSHOT
修改成facade层的引入



            com.msa.base

            base-service-facade

            1.0-SNAPSHOT
　 重跑测试类：调用成功

14. dubbo源码-集群容错之MergeableCluster

在dubbo官方的用户手册中java实现dubbo接口测试，提到了使用 MergeableCluster 的场景--分组聚合：

功能示意图如下：

定义菜单接口方式：

Provider暴露服务--一个服务属于 group-hot ，一个服务属于 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 ，java实现dubbo接口测试我们先看一下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。只需要一下几步实现即可：

怎么把mybatis的mapper接口通过dubbo暴漏

项目分三层，model存放数据，view页面展示、controller下面具体逻辑实现。通过dubbo消费方和供应方注册，供应方给消费方暴露接口，供消费方调用。
工程部署需要配置文件有java实现dubbo接口测试：
applicationContext-dubbo.xml
{--
<-- 消费方应用名，用于计算依赖关系，不是匹配条件，不要与提供方一样 --
<-- 使用zookeeper注册中心暴露服务地址 --
<-- 生成远程服务代理，可以像使用本地bean一样使用demoService --
<dubbo:reference id="demoService" interface="com.unj.dubbotest.provider.DemoService" /
--}
dubbo.properties
{--
<--基于ZooKeeper的Dubbo注册中心直接部署tomcat，修改WEB-INF下文件--
dubbo.registry.address=zookeeper://127.0.0.1:2181
dubbo.admin.root.password=root
dubbo.admin.guest.password=guest
--}
zoo_sample.cfg
{--
zookeeper/conf/下，修改zoo_sample.cfg为zoo.cfg，启动bin/下zkServer.cmd
--}
因为引入dubbo，摒弃java实现dubbo接口测试了原有Web Service项目的wdls暴露，由于项目依赖关系严重，项目使用maven构建，通过Maven pom.xml三维坐标引入jar包，调用dubbo暴露接口开发。
性能测试工具java实现dubbo接口测试：LoadRunner、jmeter
接口测试工具：LoadRunner、jmeter、soapUI、Spotlight
安全测试工具：NStalker-Web、AppScan、TamperIESetup
自动化工具 ：BadboyInstaller、QTP
/**
* @author wonter
* <b描述:</b 一天学一个模式 更新中，请关注我的博客！<br
* <b博客:</b http://www.cnblogs.com/javame <br
* <b邮件：</b yiyu1@163.com <br
敏捷测试团队，不再仅仅是在coding之后。而是和研发人员贯穿在需求分析、规格说明、自动化单元测试、自动化验收测试、静态代码分析、技术债等环节中。所以敏捷项目必定在将来效率的趋势下成为主流。
1. 使用阿里巴巴Druid连接池（高效、功能强大、可扩展性好的数据库连接池、监控数据库访问性能、支持Common-Logging、Log4j和JdkLog，监控数据库访问）
2. 提供高并发JMS消息处理机制
3. 所有功能模块化、所有模块服务化、所有服务原子化的方式，提供可拓展的服务模型，使程序稳定运行，永不宕机
4. 提供Wink Rest、Webservice服务，故可作为独立服务平台部署
框架整合:
Springmvc + Mybatis + Shiro（权限） + REST(服务) + WebService(服务) + JMS(消息) + Lucene(搜搜引擎) + Quartz(定时调度) + Bootstrap Html5（支持PC、IOS、Android）
框架简介:

项目Maven构建，真实大型互联网架构，做到高并发，大数据处理，整个项目使用定制化服务思想，提供模块化、服务化、原子化的方案，将功能模块进行拆分，可以公用到所有的项目中。架构采用分布式部署架构，所有模块进行拆分，使项目做到绝对解耦，稳定压倒一切~~

dubbo调用问题之序列化

dubbo的版本是2.5.3，接口调用后，provider方接收不到请求，超时后报错：Waiting server-side response timeout by scan timer.详细日志如下：

通过dubbo admin查看providers和consumers，可以找到服务，双方状态正常，dubbo版本也一致。 其实如果接口的provider方异常，调用方直接会收到类似于No provider available 或Forbid consumer access service from registry use dubbo version 2.5.3, Please check registry access list (whitelist/blacklist)的错误提示。
然后，查看接口请求参数，发现其实现了java序列化接口，和错误日志中的序列化方式一致。

后来测试时发现，竟然存在部分请求成功，着重分析后发现请求对象数据存在差异，请求对象的类定义中部分自定义域没有实现序列化接口。之前调用成功的请求中，其请求参数中未实现序列化的字段值为null。后来测试当整个请求参数不实现序列化时，发现接收方也可以收到请求。

跨服务调用时，传参必须实现序列化，其内部引用的对象也必须序列化。

1.方法的参数没有实现序列化，或其内部引用的对象没有实现序列化。
2.方法返回值没有序列化。（根据错误日志就能看明确发现）
3.调用双方形参版本不一致。（根据错误日志就能看明确发现）
4.注册中心配置错误导致的异常。（根据错误日志或dubbo admin可以明确发现）
5.网络异常导致的超时。 关于java实现dubbo接口测试和java调用dubbo接口测试的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 java实现dubbo接口测试的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java调用dubbo接口测试、java实现dubbo接口测试的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。