Shulou(Shulou.com)06/02 Report--

This article mainly explains "how to use Dubbo+Zookeeper+Spring to achieve Demo", the content of the article is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in depth, together to study and learn "how to use Dubbo+Zookeeper+Spring to achieve Demo" bar!

Introduction to Dubbo 1. Introduction

Dubbo is a distributed services framework dedicated to providing high-performance and transparent RPC remote service invocation solutions, as well as SOA service governance solutions. The most widely used frameworks for microservices are SpringCloud and Dubbo. Dubbo is more focused on service governance, while SpringCloud Family Bucket provides a complete set of solutions for micro services.

2. Core

Remote communication: provides abstract encapsulation of a variety of long-connection-based NIO frameworks, including multiple thread models, serialization, and information exchange in the "request-response" pattern.

Cluster fault tolerance: provides transparent remote procedure calls based on interface methods, including multi-protocol support, as well as soft load balancing, failure fault tolerance, address routing, dynamic configuration and other cluster support.

Automatic discovery: based on the registry directory service, the service consumer can dynamically find the service provider, make the address transparent, and enable the service provider to smoothly increase or decrease the number of machines.

3. Function

Transparent remote method invocation, calling remote methods as if they were local methods, with simple configuration without any API intrusion.

Soft load balancing and fault-tolerant mechanism can replace F5 and other hardware load balancers in the intranet to reduce costs and reduce a single point.

Automatic service registration and discovery eliminates the need to write down the address of the service provider. The registry queries the IP address of the service provider based on the interface name, and can smoothly add or delete service providers.

4. Characteristics

Dubbo uses full Spring configuration and transparently accesses the application without any API intrusion. Both Provider and Consumer can be configured through the configuration file of Spring. After configuration, the service can be exposed and invoked just like using springbean, and dubboapi can not be seen at all. Dubbo is loaded based on Spring's Schema extension.

Now it can also be called through API.

5. Composition: node role

Provider: the provider of the exposed service.

Consumer: the service consumer that invokes the remote service.

Registry: the registry for service registration and discovery.

Monitor: the monitoring center that calculates the call time and call time of the service.

Container: the service running container.

6. Architecture diagram and invocation relationship between roles

Architecture diagram

Description of invocation relationship:

Service consumers and providers accumulate the number of calls and call time in memory and regularly send statistics to the monitoring center every minute.

The service consumer, from the provider address list, chooses one provider to call based on the soft load balancing algorithm, and then chooses another one if the call fails.

The registry returns a list of service provider addresses to the consumer, and if there is a change, the registry will push the change data to the consumer based on the persistent connection.

Service consumers subscribe to the services they need from the registry when they start up.

Upon startup, the service provider registers the services it provides with the registry.

The service container is responsible for starting, loading, and running the service provider.

7. Four characteristics

Connectivity: connectivity indicates that there is a relationship between them. For example, there is a long connection between Provider,Consumer and Registry, and Provider,Consumer has to report to Monitor when it registers with Registry and subscribes to the service.

Robustness: robustness means that it is stable, for example, when any one of the peer-to-peer clusters of the registry goes down, it will automatically switch to another. Even if the registry goes down, service providers and consumers can still communicate through the local cache.

Scalability: scalability means that new registries and service providers can be added by adding machine deployment instances

Upgrading: the vision for the future architecture mentioned in the document, compared with the current framework, is characterized by the ability to automatically deploy local proxies for services and to automatically increase or decrease service providers through access pressure.

2. Demo instance step (Dubbo+Zookeeper+Spring) 1. Install Zookeeper

The Zookeeper 3.4.14 version is used in this demo, which version can be used. Remember to change the ZK dependency configuration in the pom file in demo. For download and installation steps, please refer to the following link: https://blog.csdn.net/tlk20071/article/details/52028945

Why use Zookeeper?

When Zookeeper is used as the registry of Dubbo in this demo, ZK is a tree directory service that supports change push and can be used as a cluster management tool. Configuration files can be managed centrally.

(1) when initializing, the service provider will create a child node under the service node under the Dubbo node under the Zookeeper and write to URL under the providers node. The path is similar to / dubbo/servicename/providers/, and all the child nodes under this path are service providers. At this time, these child nodes are temporary nodes, because the life cycle of the temporary node is related to the client session, so if the provider's machine fails and the provider cannot provide services, the temporary node will be automatically deleted from the Zookeeper.

At this time, because there is a long connection between the service provider, the registry, and the consumer, the registry can sense the service provider's downtime and will inform the consumer.

The monitoring center is an important part of the Dubbo service governance system, and it needs to know the changes of all service providers and consumers. So it registers a watcher on the service node at startup to listen for child node changes with a path of / dubbo/servicename/, so it can also sense the downtime of the service provider.

(2) another feature is the node structure design of Zookeeper (tree), which takes the service name and type, that is, / dubbo/servicename/ type, as the node path, which meets the requirements of Dubbo subscription and notification, and ensures change notification with service granularity, and the notification scope is easy to control. So even if service providers and consumers change frequently, it won't have much impact on the performance of Zookeeper.

2. Create a Maven project

Create Maven project project, and then create three modules moudle in the project, namely: dubbo-api (common service interface), dubbo-consumer (consumer, calling remote service) and dubbo-provider (providing remote service).

(1) you need to add related dependencies in the pom.xml file of the entire project: you need to pay attention to the version of dubbo here, which will be discussed below.

4.0.0 com.test dubbo_demo 1.0-SNAPSHOT dubbo_consumer dubbo_provider dubbo_api pom dubbo_demo Maven Webapp http://www.example.com UTF-8 1.7 1.7 junit junit 4.11 test org.springframework spring-context 5.0.4.RELEASE org.slf4j slf4j-api 1. 7.24 com.alibaba dubbo 2.6.3 org.apache.zookeeper zookeeper 3.4.14 org.apache.curator curator-framework 2.8.0 org.apache.curator curator-recipes 2.8.0 com.github.sgroschupf zkclient 0.1 dubbo _ demo maven-clean-plugin 3.1.0 maven-resources-plugin 3.0.2 maven-compiler-plugin 3.8.0 maven-surefire-plugin 2.22.1 Maven-war-plugin 3.2.2 maven-install-plugin 2.5.2 maven-deploy-plugin 2.8.2

(2) create a dubbo_api moudle and define the service interface in the project: this interface needs to be packaged separately, and the service interface DemoService is defined in the dubbo-api shared by the service provider and consumer, as follows:

Package com.test;public interface DemoService {public String sayHello (String name);}

(3) create a dubbo_provider moudle, and then implement the above interface in dubbo_provider. Why can we call the interface across moudle and complete the interface implementation here? because dubbo_api is added as a dependency in the pom.xml file of provider, the above interface can be introduced. As shown in the picture

The DemoServiceImpl code of the API implementation class is as follows:

Import com.test.DemoService;public class DemoServiceImpl implements DemoService {public String sayHello (String name) {return "hello" + name;}}

At the same time, write a startup test class under this moudle so that you can start provider later:

Import org.springframework.context.support.ClassPathXmlApplicationContext;import java.io.IOException;public class ProviderTest {public static void main (String [] args) {ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext ("classpath:dubbo-provider.xml"); applicationContext.start (); System.out.println ("Dubbo provider start, start service provider.."); try {System.in.read () } catch (IOException e) {e.printStackTrace ();}

(4) create a dubbo_consumer moudle, and then write a startup test class in dubbo_consumer to enable consumer to invoke the services provided by provider:

Import com.test.DemoService;import org.springframework.context.support.ClassPathXmlApplicationContext;import java.io.IOException;public class ConsumerTest {public static void main (String [] args) {ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext ("classpath:dubbo-consumer.xml"); applicationContext.start (); DemoService demoService = (DemoService) applicationContext.getBean ("ddemoService"); System.out.println (demoService.sayHello ("guy")) Try {System.in.read ();} catch (IOException e) {e.printStackTrace ();}

(5) after the above code is written, it seems that each moudle does not seem to be connected? Everyone is curious about how Dubbo implements service publishing and remote invocation. Next, let's focus on configuring provider and consumer.

a. Create a new dubbo_provider.xml file in the resource of dubbo_provider to implement the configuration of provider in dubbo:

First of all, complete the application configuration, and the current provider application is named dubbo_provider.

Then complete the registry configuration, use Zookeeper as the registry, and set its address.

Then configure the protocol, which is used to configure the protocol information that provides the service. The protocol is only specified by provider, using port= "20880" as the interface provided by the service for consumer to invoke.

Finally, the service is configured to expose a service interface whose absolute path is interface= "com.test.DemoService", codenamed ref= "demoService".

You also need to configure a bean for the interface implementation class to call the methods in bean in the startup test class of provider.

b. Create a new dubbo_consumer.xml file in the resource of dubbo_consumer to realize the configuration of consumer in dubbo.

First, complete the application configuration, and configure the current consumer application named dubbo_consumer

Then complete the configuration of the registry, use Zookeeper as the registry, and set its address. Consumers subscribe to the services they need from the registry

Finally, a remote service proxy is generated, and the interface whose absolute path is interface= "com.test.DemoService" is called, and its code name is set to id= "ddemoService". You can use ddemoService, like the local bean,

Here you may have a question about why there is an extra d, in order to distinguish it from the service interface and bean exposed by dubbo_provider.xml. It indicates that after the consumer calls this API service, it is equivalent to having this interface locally, so the interface name can be different from that of provider. It's equivalent to taking an apple from someone else. I don't have to call him an apple here, or I can call him a pear, because this thing is in my hand (locally). I know how to use it locally, and I don't need an outsider (provider) to know.

(6) the structure of the project is as follows. You can download the project demo at the end of the article.

3. Test results

Start zookeeper in turn (open zkServer.cmd under the bin file, and do not close it. If you flicker, you can open it with the cmd call file name), run dubbo-provider, and run dubbo-consumer to get the test results as follows.

4. Problems encountered in the project

This project has encountered a strange problem. I have been looking for me all day. The following problems occur every time I run provider and consumer.

Problem: the Spring namespace handler could not be found.

Offending resource: class path resource [dubbo-consumer.xml]; nested exception is org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://dubbo.apache.org/schema/dubbo]

Offending resource: class path resource [dubbo-consumer.xml]

There is a problem with the two addresses in the red box below, but both addresses can be opened.

The problem is: it was finally found that dubbo was closed for a period of time, during that time, the domain name of dubbo was code.alibabatech.com, and the following addresses were all configured in other people's cases found on the Internet, only to find that these addresses were invalid. According to reason, I should be right to use the latest one in my program now, why I reported it wrong. And can only continue to look everywhere for bug.

Http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd ">

Later, I began to wonder if the version I used at first was older (2.5.X); then it turned out to be the case. The problem is that the configuration in dubbo-config-spring-2.6.1.jar-- > META-INF-- > spring.handlers is still the previous domain name code.alibabatech.com, but this domain name is no longer available, so you need to pay attention to this problem if you use the old version of dubbo (see https://blog.csdn.net/huweijun_2012/article/details/80239803)

However, this problem no longer occurs in version 2.6.2 or above, and the previous domain name in spring.handlers still contains the old and new domain names, which is equivalent to being compatible. However, because the code.alibabatech.com domain name is no longer available, the solution can only be to modify the version of dubbo in the pom.xml file. If you use version 2.6.2 or above, this problem will not occur.

Thank you for your reading, the above is "how to use Dubbo+Zookeeper+Spring to achieve Demo" content, after the study of this article, I believe you have a deeper understanding of how to use Dubbo+Zookeeper+Spring to achieve Demo this problem, the specific use of the situation also needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.