At present, HTTP interface automation and Dubbo interface automation in the company are managed by using scripts, and the technology stack is divided into Java and Python, which makes internal docking very inconvenient. In order to reduce the threshold of use and improve the efficiency of interface testing, we decided to add interface automation in the original function use case management platform for unified management.
MeterSphere
First of all, I think MeterSphere is the best interface automation platform with the most complete functions at present. The project is still being updated, and there is an open source version. If you are interested, you can have a look at the project code github.com/metersphere…
Part of my understanding of the platform’s Http interface testing is to package it with a front-end entry into a.jmx file that JMeter recognizes and execute it through JMeter’s open API.
It must be said that the members of the project are very familiar with JMeter. They abandoned JMeter’s GUI, which was difficult to use, and implemented a very user-friendly UI, MeterSphere.
Porting some functions of MeterSphere
Because only the interface test functionality is required, only the interface test section is moved. The first thing to do is to deploy MeterSphere locally. There are only docker deployment tutorials in official documents, but no tutorials for building Windows, and SQL files are placed under different files, which undoubtedly increases the cost of secondary development. Finally, I deployed the project in Linux, exported the SQL, added the database configuration in application.properties, commented some of the code in the original project, started it successfully in Windows, and ported the function of the interface test module. Dubbo interface failed to be called in the test, so there was the first operation to modify the source code…
Problem found: Dubbo interface test error reported
MeterSphere has a lot of configurations for Dubbo, originally intended to simplify the test, but it feels more troublesome to fill in this configuration than the original way, so I will write the default configuration here, because the company currently uses ZK as the registry. Other consumer&Service and Config Service configurations do not require personnel configuration.
However, when I fill in the corresponding parameters and request the Dubbo interface, the problem occurs
Failed to check the status of the service xxx.xxx.xxx . No provider available for the service
1
Copy the codeI have been reporting errors that I cannot find the corresponding service, but I can successfully request with the existing script. After confirming that there is no problem in the environment, I think it may be due to the Dubbo version
Location problem: Dubbo version
Let’s look at two pictures
I searched the maven repository and found that Dubbo was included by Apache in version 2.7.x, and groupId in version 2.6.x is com.Alibaba.
Therefore, I found the corresponding dependency in the project, and sure enough, the version of Dubbo used in our system is 2.5.x, ali’s version. The two versions connect to ZK in different ways, the old version through
<dependency>
<groupId>com.101tec</groupId>
<artifactId>zkclient</artifactId>
</dependency>
1234
Copy the codeThe new version uses
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
</dependency>
1234
Copy the codeDetermine the problem is the version asked, so began to change the source code
Fix the problem: modify the jmeter-plugins-for-apache-dubbo plug-in code
Jmeter supports the Dubbo interface, which requires the support of jmeter-plugins-for-apach-dubbo tripartite plug-in, which is currently used in 2.7.12 and is not suitable for our system
< the dependency > < groupId > IO. Metersphere < / groupId > < artifactId > jmeter - plugins - dubbo < / artifactId > < version > 2.7.12 < / version > </dependency> 12345Copy the codeSo I changed it to the official 1.3.x, but found that the Dubbo interface still failed to call, and the corresponding service could not be found.
Finally, I downloaded the 1.3.x tripartite package locally and studied the code of its generalization call. I found that a large part of the code is actually for different registries such as: Zookeeper, NacOS, Redis support, and the zooKeeper currently used by the company, I can completely comment out these unused codes and encapsulate a set of generalized call logic.
@SuppressWarnings({"unchecked", "rawtypes"}) private Object callDubbo(SampleResult res) { try { ReferenceConfig<GenericService> reference = new ReferenceConfig<GenericService>(); ApplicationConfig applicationConfig = new ApplicationConfig(); applicationConfig.setName("remoteInvoke"); applicationConfig.setVersion(""); RegistryConfig registryConfig = new RegistryConfig(); registryConfig.setFile("/tmp/dubbo.cachr"); String address = getAddress(); registryConfig.setAddress(address); registryConfig.setProtocol("zookeeper"); reference.setApplication(applicationConfig); reference.setRegistry(registryConfig); // weak type interfaceName String interfaceName = getInterface(); reference.setInterface(interfaceName); Reference. SetVersion (" 1.0.0 "); // Declare reference. SetGeneric (true); reference.setProtocol("dubbo"); // If no retry is performed, reference.setretries (0). reference.setTimeout(10000); String methodName = getMethod(); if (StringUtils.isBlank(methodName)) { res.setSuccessful(false); return ErrorCode.MISS_METHOD.getMessage(); } / / org. Apache. Dubboinfo. RPC. Service. The interface GenericService can replace all references to GenericService GenericService = reference. The get (); if (genericService == null) { res.setSuccessful(false); return MessageFormat.format(ErrorCode.GENERIC_SERVICE_IS_NULL.getMessage(), interfaceName); } String[] parameterTypes = null; Object[] parameterValues = null; List<MethodArgument> args = getMethodArgs(); List<String> paramterTypeList = new ArrayList<String>();; List<Object> parameterValuesList = new ArrayList<Object>();; for(MethodArgument arg : args) { ClassUtils.parseParameter(paramterTypeList, parameterValuesList, arg); } parameterTypes = paramterTypeList.toArray(new String[paramterTypeList.size()]); parameterValues = parameterValuesList.toArray(new Object[parameterValuesList.size()]); Object result = null; try { result = genericService.$invoke(methodName, parameterTypes, parameterValues); res.setSuccessful(true); } catch (Exception e) {log.error("RpcException: ", e); //TODO // When the interface returns an exception, sample is identified as successful. Assertion is made based on the response content to determine whether the error of sample is identified, because the error percentage of sample will be counted in the use case. Res.setsuccessful (true); // If the interface has some validation exceptions, it does not mean that the operation is wrong. result = e; } return result; } catch (Exception e) {log.error("UnknownException: ", e); res.setSuccessful(false); return e; } finally {//TODO cannot destroy // if (registry! = null) { // registry.destroyAll(); // } // reference.destroy(); }} 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646 566676869707172737475Copy the codeFinally, you jar the code and call it offline through Maven
< the dependency > < groupId > IO. Metersphere < / groupId > < artifactId > jmeter - plugins - dubbo < / artifactId > < version > 1.3.8 < / version > The < scope > system < / scope > < systemPath > ${project. The basedir} / lib/jmeter - plugins - dubbo - 1.3.8. Jar < systemPath > < / dependency > 1234567Copy the codeFinally request success
conclusion
Just when I was fantasizing about submitting issure to MeterSphere, submitting PR, becoming a contributor to a hot open source project, and getting to the top of my game. I found a submission record on the MeterSphere project that said:
“Fix: Fix No Provider error in dubbo client v2.7.7 or later when invoking server version before V2.6. x”
The BUG was actually fixed two months ago…