There is actually a lot of information about dubbo on the Internet, especially there is a more comprehensive official documentation tutorial.
But as the saying goes, it's easier to know than to do it. If you don't do anything, you don't know the details.
Although I wanted to learn dubbo for a long time, Naihe needed to learn too much, so he started with "work-oriented" and learned other techniques first.
This time, based on the above starting point, one of our projects needs to be restructured into a dubbo project, so we just started learning from the basic environment of dubbo and wrote a note.
This note will probably contain the following contents:
1. Records of the construction process
2. Records of problems encountered and solutions, which will be explained at the same time as the recording of the construction process, and will not be pointed out otherwise.
The whole process is basically as follows:
zookeeper registry
Understanding of the Registry
Since I have learned springcloud microservices before, I think it is relatively easy to understand the zookeeper registry. For a specific understanding, please refer to the article on the registration center of springcloud written at that time: http://blog.csdn.net/tuzongxun/article/details/72650100
The obvious difference is that the zookeeper here needs to download and install a zookeeper software.
zookeeper installation
When I installed it, I mainly referred to the blog of "Little Treasure Pigeon", he wrote very detailed, so I don't think it is necessary to repeat the wheel, just need to remember where to find the reference materials. His blog address about zookeeper installation is as follows:
http://blog.csdn.net/u013142781/article/details/50395650
dubbo management platform
Since the management platform has nothing to do with the business logic itself, I have no in-depth understanding, and I also directly refer to the blog of "Xiao Baoge":
http://blog.csdn.net/u013142781/article/details/50396621
dubbo server
Create project
According to the current mainstream, I have created a maven-managed web project in eclipse.
base dependency
The basic dependencies of the project mainly refer to the description of the dubbo official guidance document http://dubbo.io/books/dubbo-user-book/dependencies.html
According to this document, the following dependencies need to be included, namely:
dubbo.jar
spring.jar
log4j.jar
commons-logging.jar
javassist.jar
netty.jar
will be found when actually imported, dubbo.jar already depends on spring.jar and netty.jar, this version is also based on the imported dubbo.jar version to be determined.
In order to avoid conflicts and use the version of spring and netty that you want, you need to exclude these two when importing dubbo.jar. The configuration of the dependent package in the pom.xml is basically as follows:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>org.jboss.netty</groupId>
<artifactId>netty</artifactId>
<version>3.2.5.Final</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.3.9.RELEASE</version>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>dubbo</artifactId>
<version>2.5.3</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
</exclusion>
<exclusion>
<groupId>org.jboss.netty</groupId>
<artifactId>netty</artifactId>
</exclusion>
</exclusions>
</dependency>
spring configuration
Dubbo itself integrates spring, so the configuration of spring is essential, and the simplest configuration is used here, and the file header is omitted first:
<context:property-placeholder location="classpath:config.properties" /> <import resource="spring-dubbo-provider.xml" />
config.properties configuration
To configure the dubbo service, you need to specify the address of the zookeeper registration center, and the port of the service exposed by dubbo, etc. These configurations are configured in the config.properties file:
dubbo.zookepper.address=127.0.0.1:2181 dubbo.provider.port=29880
dubbo configuration
To register our project as a service in the zookeeper registry, we need to configure it accordingly. The configuration is as follows:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://code.alibabatech.com/schema/dubbo
http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
<!-- provider application information for calculating dependencies -->
<dubbo:application name="dubboServerDemo-pro"/>
<!-- registry configuration, the file value is application name plus instance name -->
<dubbo:registry protocol="zookeeper" address="${dubbo.zookepper.address}" file="dubboServerDemo-pro-1.cache"/>
<!-- Use the dubbo protocol to expose the service on port 20880, and output the dubbo access log to the application log-->
<dubbo:protocol name="dubbo" port="${dubbo.provider.port}" accesslog="true"/>
<!-- Declare that the service interface to be exposed has a timeout of 90 minutes, and the timeout will not be retried-->
<dubbo:service interface="dubboServerTest.DubboServerService" ref="dubboServiceTest" cluster="failfast" timeout="5400000" />
<!-- Implement service like local bean -->
<bean id="dubboServiceTest" class="dubboServerTest.DubboServerServiceImpl" />
</beans>
Dubbo specific service interface and implementation
The specific service interface and implementation of dubbo are very common java interfaces and classes, as follows:
package dubboServerTest;
public interface DubboServerService {
public void sayHello();
}
package dubboServerTest;
public class DubboServerServiceImpl implements DubboServerService {
@Override
public void sayHello() {
System.out.println("dubbo测试");
}
}
web.xml configuration
The spring.xml file needs to be loaded. It can be loaded with java code or in other ways. Here I choose to use the configuration of web.xml to load. The configuration of web.xml is as follows:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:spring.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
problem statement
It stands to reason that the program should be able to run according to the above method, and the server can be displayed in the management platform, but in fact, the following exception was thrown after I started:
java.lang.NoClassDefFoundError: org/I0Itec/zkclient/exception/ZkNoNodeException
The reason is that the dependency package of zookeeper is missing, and the following dependency configuration needs to be added in pom.xml:
<dependency>
<groupId>com.101tec</groupId>
<artifactId>zkclient</artifactId>
<version>0.10</version>
</dependency>
consumer
Project construction
The project construction of consumers is actually similar to that of service providers. The difference is that the configuration of dubbo is slightly different. The configuration of consumers is roughly as follows:
<!-- Consumer application name, used to calculate dependencies, not matching conditions, not the same as the provider -->
<dubbo:application name="consumer-of-helloworld-app" />
<!-- Use the multicast broadcast registry to expose the discovery service address-->
<dubbo:registry address="${dubbo.zookepper.address}" />
<!-- Generate remote service proxy, you can use demoService like local bean -->
<dubbo:reference id="demoService" interface="dubboServerTest.DubboServerService" />
Similarly, the address of the registry also needs to be specified here, which is also configured in config.properties:
dubbo.zookepper.address=zookeeper://127.0.0.1:2181
It should be noted that the writing method of the zookeeper registration center address configured here is slightly different from the writing method configured by the service center.
interface declaration
The consumer side needs an interface that is the same as the server side, but does not need to implement this interface. The practice here is actually similar to the webservice interface, like cxf, xfire, and hessian.
service call
On the consumer side, the abstract method of the interface declared above can be called directly, but what actually runs is the concrete implementation of the server side. The code at the calling place is as follows:
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import dubboServerTest1.DubboServerService;
public class MyController {
public static void main(String[] args) {
ApplicationContext applicationContext = new ClassPathXmlApplicationContext(
"classpath:spring.xml");
DubboServerService dubboServerService = (DubboServerService) applicationContext
.getBean("demoService");
dubboServerService.sayHello();
}
}
problem statement
Consumers are relatively simple here, but in addition to the details that need to be paid attention to in the configuration of the zookeeper registry address, special attention should also be paid to the declaration of the interface.
In order to verify whether it is the same as the webservice, the consumer interface including the package name must be the same as the server. I deliberately used a different package name when declaring the interface, so that the actual class content and the configuration in the dubbo configuration file as follows:
package dubboServerTest1;
public interface DubboServerService {
public void sayHello();
}
<dubbo:reference id="demoService" interface="dubboServerTest1.DubboServerService" />
Then when the main method is run, the following exception will be thrown:
Caused by: java.lang.IllegalStateException: Failed to check the status of the service dubboServerTest1.DubboServerService. No provider available for the service
This also proves that the interface declaration on the consumer side, including the package name, must be exactly the same as that on the server side. In response to this problem, there is a recommended approach, which is to package this interface class and make it common to the server and the consumer.