A preliminary study on the use of Dubbo framework combined with Zookeeper registry

[Reference article] http://www.cnblogs.com/Javame/p/3632473.html (Thank you so much for this enlightening article!!)

 

[The article is wrong, see the strikethrough for revisions. .

 

1. Basic Concepts

 

【Dubbo】

Dubbo is a distributed service framework derived from Alibaba, which is essentially a service call, mainly used in distributed scenarios. It is registered on dubbo in a server/message mode.

Core: 1) RPC: remote communication - encapsulates the NIO framework of long connections (multi-threading model, serialization, information exchange in "request-response" mode);

  2) Cluster fault tolerance: remote procedure calls based on interface methods, various clusters support

  3) The service based on the registry directory (the zookeeper is used here), so that the consumers of the service can dynamically find the service provider, and the address is transparent, so that the service provider can smoothly increase or decrease the node.

 

【Zookeeper】

ZooKeeper is a distributed, open source distributed application coordination service, an open source implementation of Google's Chubby, and an important component of Hadoop and Hbase. It is a software that provides consistent services for distributed applications. The functions provided include: configuration maintenance, name service, distributed synchronization, group service, etc.

The goal of ZooKeeper is to encapsulate complex and error-prone key services, and provide users with an easy-to-use interface and a system with high performance and stable functions.

 

Understanding Zookeeper's algorithm can be substituted into real-life "voting elections".

Zookeeper literally means "zookeeper", which is a distributed service framework based on the Fast Paxos algorithm. In the Zookeeper distributed cluster, it is mainly divided into three roles:

Leader receives proposal requests from all Followers and coordinates the votes for initiating proposals in a unified manner, and is responsible for internal data exchange (synchronization) with all Followers;

Followers directly serve clients and participate in the voting of proposals, and at the same time exchange data (synchronize) with Leaders; 

The Observer directly serves the client but does not participate in the voting of the proposal, and also exchanges data (synchronization) with the Leader.

The goal of ZooKeeper is to encapsulate complex and error-prone key services, and provide users with an easy-to-use interface and a system with high performance and stable functions.

 

【Dubbo use background】

Background requirements for large-scale distributed services. Before large-scale distributed services, they simply used native RMI, simply exposed and referenced remote services, called by configuring the URL address of the remote service, and performed load balancing through hardware (load balancing: load balancing, the English name is Load Balance means that it is allocated to multiple operating units for execution, such as Web servers, FTP servers, enterprise key application servers and other mission-critical servers, so as to complete work tasks together.)

Under large-scale distributed requirements, problems arise:

(1) When there are more and more services, the management of service URL configuration becomes very difficult, and the single point pressure of F5 hardware load balancer is also increasing. ——Therefore, a service registration center is very necessary at this time to dynamically register and discover services, and manage service addresses.

(2) The dependencies between services have become complex and misunderstood, and it is not even clear which application should be started before which application - you need to sort out the dependency diagram between application services by yourself

(3) When the amount of service calls increases, the capacity limitation of services

 

——Dubbo solves the above problems.

 

2. Dubbo framework architecture

 


 

[Description] Provider - a service provider that provides services to the outside world

        Container - the container for the service side to run the service, responsible for starting, loading and running the service

        Registry - the center of service registration and service discovery (here we use zookeeper)

 Monitor - monitoring center, used to count the number of calls and call time of the service

 

Service call process:

Step1 First, when the server starts, it registers the services it can provide with the registration center;

Step 2 When the service consumer starts, subscribe to the registration center for the related services it needs

Step3 After receiving the subscription request, the registration center returns the address list of the service provider to the service consumer. If there is a change, the registration center will push the change data to the consumer based on the persistent connection.

Step4 The service consumer selects a service provider to call based on the load balancing algorithm from the provided address list. If the call fails, select another service provider

Step5 At the same time, during the calling process, both the server and the consumer will accumulate the number of calls and the calling time in the memory, and periodically send the statistical data to the monitoring center.

 

——Then the question is, how to use Dubbo?

 

3. Dubbo is easy to use

 

Dubbo is an excellent open source distributed service invocation framework. Fortunately, it can be seamlessly integrated with Spring MVC without any API intrusion. Dubbo is loaded based on Spring's Schema extension. So it is often used in web platform projects.

And zookeeper as Dubbo's service registry, we first need to install zookeeper to start the registry service.

To put it simply, it is to define an interface and its implementation class in the A application, and then configure the corresponding configuration file, and type the implementation class into a jar package. Application B references the jar package and needs to define the same interface. The interface name and path must be consistent with the external interface path of application A.

Steps: To create two web applications, you must first import the relevant jar package (to obtain the jar package, you can first download a dubbo-admin-2.5.4.war package, and then unzip it, there will be related jar packages in it):

dubbo-2.5.4-SNAPSHOT.jar  

netty-3.2.5.Final.jar  

slf4j-api-1.7.2.jar  

slf4j-log4j12-1.6.2.jar  

slf4j-simple-1.7.2.jar  

zkclient-0.1.jar  

zookeeper-3.3.3.jar

 

Here's an example of getting started with Dubbo:

 

【Service provider】

1. First define the A application (as the external service provider), and define multiple interfaces (considering that when it is actually used in the project in the future, there must be more than one interface, so I use 2 interfaces to simulate):

 

Interface one:

 

 

public interface ServiceDemo {
	String sayHello(String name);
}

 

 

Interface two:

 

 

public interface ServiceDemo2 {
	String print(String name);
}

 

 

 And their implementation classes:

 

 

public class ServiceDemoImpl implements ServiceDemo {

	@Override
	public String sayHello(String name) {
		return "hello " + name;
	}
	
}

 

 

And the implementation class of interface two:

 

 

public class ServiceDemoImpl2 implements ServiceDemo2 {

	@Override
	public String print(String name) {
			return "My name is " + name;
	}

}

 

 

Configuration of service provider:

 

 

<?xml version="1.0" encoding="UTF-8"?>
<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 ">
        
    <bean id="demoService" class="com.xxx.demo.dubbo.ServiceDemoImpl" />
    <bean id="demoService2" class="com.xxx.demo.dubbo.ServiceDemoImpl2" />
    
    <!-- Provider Application Information-->
   <dubbo:application name="service_provider" />
 
	<!-- Expose service address with zookeeper registry -->
	<dubbo:registry address="zookeeper://127.0.0.1:2181" subscribe="false"/>
	
	<!-- Expose the service on the specified port using the dubbo protocol -->
	<dubbo:protocol name="dubbo" port="20880" />
	
	<!-- Declare the (multiple) service interfaces that need to be exposed -->
	<dubbo:service interface="com.xxx.demo.dubbo.ServiceDemo" ref="demoService" />
	<dubbo:service interface="com.xxx.demo.dubbo.ServiceDemo2" ref="demoService2" />
</beans>

 

 

Then put these multiple implementation classes (note that it is an implementation class , [it should be an interface not an implementation class!!!! ] here are 2) separately into 1 (note that it is 1) jar package (select these multiple implementation classes) , [ is the interface ] right-click ->Export->JAR file->Next (only check Export Java source files and resources)->Name->Next export), here named dubbo-test.jar.

 

【Service consumer】

2. Define the B application (service consumer), respectively and define the same interface as the A application path (the code will not be displayed here because it is exactly the same as the definition of the above interface), and the interface here is also consistent with the service provider . Wrong! The correct thing is to make the interface of the service provider into a jar package (not the implementation class into a jar package), and send the jar package to the consumer of the service. The implementation class of the service should be hidden from the consumer! ] Here are ServiceDemo and ServiceDemo2, and their package name paths should be consistent with the interface package name paths provided by the A application.

 

[Note] In addition to the jar package mentioned above, add the jar package dubbo-test.jar just provided by the A application to the B application.

 

Configuration of the service consumer (the IP here is 127.0.0.1 because the service is on my computer)

 

 

<?xml version="1.0" encoding="UTF-8"?>
<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 ">
   
	
   <!-- Consumer Application Information-->
     <dubbo:application name="service_consumer" />  
	<!-- Expose service address with zookeeper registry -->
	<dubbo:registry address="zookeeper://127.0.0.1:2181" />
   
	<!-- Generate remote service proxy so that remotely exposed (multiple) interface services can be used locally -->
	<dubbo:reference interface="com.xxx.demo.dubbo.ServiceDemo" id="caller"/>
	<dubbo:reference interface="com.xxx.demo.dubbo.ServiceDemo2" id="caller2"/>
</beans>

 

 

Then I tried to create a service consumer on another machine (Jar package import, interface definition, etc. are the same as the above operations), and its configuration is (the IP here must write the ip address of the machine where the service provider is located, that is for my computer's ip):

 

 

<?xml version="1.0" encoding="UTF-8"?>
<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 ">
   
	
   <!-- Consumer Application Information-->
     <dubbo:application name="service_consumer" />  
	<!-- Expose service address with zookeeper registry -->
	<dubbo:registry address="zookeeper://192.168.0.105:2181" />
   
	<!-- Generate a remote service proxy so that multiple interface services exposed remotely can be used locally -->
	<dubbo:reference interface="com.xxx.demo.dubbo.ServiceDemo" id="caller"/>
	<dubbo:reference interface="com.xxx.demo.dubbo.ServiceDemo2" id="caller2"/>
</beans>

 

 

[Zookeeper registration center starts]

3. Start the zookeeper service registration center, enter the zookeeper installation path/bin, and double-click the zkServer.cmd command to open it.

 

【Service Test Section】

Start the service provider in the A application (project) (register the service with Zookeeper):

 

 

public class Provider {
	public static void main(String[] args) throws Exception {
		 ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
				 new String[] {"context-dubbo-provider.xml"});  
	     context.start();  
	     System.in.read();//Used to simulate the service is always on
	}
}

 

 

Next, start the service consumer (subscribing from Zookeeper) on this machine and another machine :

 

 

public class Consumer {
	public static void main(String[] args) throws Exception {
		FileSystemXmlApplicationContext context = new FileSystemXmlApplicationContext(
				 new String[] {
						 "webRoot/WEB-INF/conf/spring/sys/context-dubbo-consumer.xml"});  
		context.start();
		ServiceDemo demo = (ServiceDemo) context.getBean("caller");
		String hello = demo.sayHello("Lily");
		System.out.println("After call the remote (sayHello): " + hello);
		
		System.out.println("================");
		
		ServiceDemo2 demo2 = (ServiceDemo2) context.getBean("caller2");
		System.out.println(demo2.print("Tom"));
		
		System.in.read();
	}

}

 

 

After that, the following print results can be obtained on this machine and another machine (2 service consumers):

 

After call the remote (sayHello): hello Lily

======================

My name is Tom

 

It shows that the multiple interface services provided by the A application have been successfully called remotely!

 

======================

Exception encountered:

No provider available  for  the service xxxxx One of the reasons for this exception is probably because the consumer of the service did not import the jar package provided by the service provider (the jar package encapsulates the implementation class instead of the interface!), of course, there may be other reasons. cause. .   

 

4. Dubbo management control

 

All right. . Because the previous articles on the Internet have this part, so I did it myself. . .

 

The downloaded war package will be downloaded. I downloaded dubbo-admin-2.5.4-SNAPSHOT.war (war package managed by dubbo service)

 

Delete the webapps/ROOT under the tomcat installation file (it is recommended to back it up first), and then copy all the decompressed files of the above war package to ROOT, and the jdk version used by tomcat should not be too high, controlled at jdk1.7 or Best of the following. After successfully starting tomcat, enter http://loclahost:8080 in the browser address bar, and a dialog box will pop up asking you to enter the username and password, fill in root, and you can get the dubbo management interface:

 

Entering the management interface, you can see the statistics of service providers, consumers, service calls, etc. Here, to save space, just look at the screenshots of consumers (because there are two machines that have accessed the external interface provided by application A , so there are 2 columns of data):

 



 

To sum up: In simple terms, the combination of Dubbo and Zookeeper achieves the effect of remote calling. Dubbo is a distributed service framework (especially in terms of RPC performance), and Zookeeper is used as Dubbo's service registry.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326964119&siteId=291194637