The business needs to provide an interface. I need to use the dubbo protocol interface. I provided the interface and deployed it in the test environment, and then provided the interface information to the other party, but the other party was still unable to communicate.
The doubboadmin of the test environment is abnormal. Even if the service registration is successful, no information about the registered service can be found. I had to ask the operation and maintenance for the user password of the registration center machine to check it out. The command is as follows: /p>
1)cd /opt/zookeeper/bin
cd command to go to the bin directory where zookeeper is located
2).zkCli.sh -server ip:port
enter blablabla
3) ls /dubbo
List all dubbo services
4) ls /dubbo/com.blablabla .YourService/provider
Print out your service provider information, and replace provider with consumer to print out your service consumer information
I found out the existence of my dubbo service through the above query In the provider list, but the other party is always unable to communicate, and it keeps prompting No provider available for the service.
So I wrote the code locally to call the test service, and found that the same error was reported, but I really couldn’t figure it out.
So I changed the protocol of the dubbo interface to json, and wrote the code and found that it worked. At this point, the sensitive children’s boots may have discovered the problem. That’s right, the port number used by the json protocol and the dubbo protocol is different, and it may be that the port number of dubbo cannot be accessed.
So almost,
telnet [IP][space][port number] For example, telnet 192.168.1.133 8080
Sure enough, the port is blocked.
Then I applied for permission with the operation and maintenance personnel. At this point, the problem that tortured me for two days was finally solved.
There is another remaining question. How can the interface of the dubbo protocol be tested more easily? Studying DubboClient and JMETER···