Configuration and use of Dubbo

1. What is Dubbo?

Dubbo is a distributed service framework dedicated to providing high-performance and transparent RPC remote service invocation scenarios, as well as SOA service governance scenarios. Simply put, Dubbo is a service framework, if there is no distributed demand, in fact, it is not needed, only in the distributed time, only Dubbo such a distributed service framework needs, and essentially a service invocation of the Dongdong, Plainly, Dubbo is a distributed framework for remote service invocation (to say goodbye to the WSDL in Web Service mode and register on Dubbo in the way that the service and the consumer)

The core part contains:
1. Remote communication: Provides an abstract encapsulation of various NIO frameworks based on long connections, including multiple threading models, serialization, and "request-response" mode of information exchange.
2. Cluster fault tolerance: Provide transparent remote procedure call based on interface method, including multi-protocol support, and cluster support such as soft load balancing, failure fault tolerance, address routing, dynamic configuration, etc.
3. Autodiscover: based on the Registry directory Service , the service consumer can dynamically find the service provider, make the address transparent, so that the service provider can increase or decrease the machine smoothly.

2. What can Dubbo do?

1. Transparent remote method calls, just like calling a local method, call the remote method, simply configure, without any API intrusion.
2. Soft load balancing and fault tolerant mechanism, can replace F5 and other hardware load balancer in intranet, reduce cost and reduce single point.
3. Service autoenrollment and discovery, no longer required to write dead service provider addresses, the registry queries the IP address of the service provider based on the interface name, and is able to smoothly add or remove service providers.

3. Architecture of the DubboThe Dubbo frame composition is as follows:

Node role Description:

Provider: The service provider that exposes the service.

Consumer: Invokes the service consumer of the remote service.

Registry: Registration Center for service Registration and discovery.

Monitor: The monitoring center of the call times of the statistics service and the call time.

Container: The service runs the container.

Call Procedure Description:

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

1. Upon launch, the service provider registers its services with the registry.

2. When the service consumer starts, it subscribes to the registration center for the services it needs.

3. The registry returns the service provider address list to the consumer, and if there is a change, the registry will push the change data to the consumer based on a long connection.

4. Service consumers, from the provider address list, based on the soft load equalization algorithm, select a provider to make the call, if the call fails, then choose another call.

5. Service consumers and providers, the cumulative number of calls in memory and call time, timed to send statistics every minute to the monitoring center.

4. How to use Dubbo

Dubbo uses a full spring configuration, transparent access to the application, no API intrusion to the application, just load the Dubbo configuration with spring, and Dubbo the spring-based schema extension.

Dubbo usually uses zookeeper as the registration center, which is also the official recommended way

1. Start zookeeper before using Dubbo, here you can consider another article zookeeper installation and deployment-cluster

2. Define the Service interface: (the interface needs to be packaged separately, shared between the service provider and the consumer)

Service Provider

 Package Com.unj.dubbotest.provider;     Import java.util.List;      Public Interface Demoservice {        string SayHello (string name);          Public List getusers ();    }  

implementing interfaces in the service provider: (Hidden implementations for service consumers)

 PackageCom.unj.dubbotest.provider; Importjava.util.ArrayList; Importjava.util.LinkedList; Importjava.util.List;  Public classDemoserviceimplImplementsdemoservice{ Publicstring SayHello (string name) {return"Hello" +name; }        PublicList getusers () {List List=NewArrayList (); User U1=NewUser (); U1.setname ("Jack"); U1.setage (20); U1.setsex (Male); User U2=NewUser (); U2.setname ("Tom"); U2.setage (21st); U2.setsex (Female); User U3=NewUser (); U3.setname ("Rose"); U3.setage (19); U3.setsex (Female);           List.add (U1);           List.add (U2);           List.add (U3); returnlist; }  }  

To declare an exposure service with spring configuration:

<?XML version= "1.0" encoding= "UTF-8"?>  <Beansxmlns= "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 ">         <!--the specific implementation of the bean generally does not write the bean in the Dubbo configuration, for example, when using annotations development, by scanning the bean to spring management, here do not need to write, directly in the Dubbo-service reference is good -      <BeanID= "Demoservice"class= "Com.unj.dubbotest.provider.DemoServiceImpl" />            <!--provider app information for calculating dependencies -      <dubbo:applicationname= "Xixi_provider"  />         <!--use multicast broadcast registry to expose the service address <dubbo:registry address= "multicast://224.5.6.7:1234"/> -          <!--exposing a service address using the Zookeeper Registration center -   　　 <!--define the address of the zookeeper in the actual project using the Properties file Form - 　　 <-- <dubbo:registry Protocol= "Zookeeper"Address= "${zookeeper.address}"Check= "false"file= "Dubbo.properties" /> -<Dubbo:registryAddress= "zookeeper://127.0.0.1:2181" />           <!--exposing services on 20880 ports with the Dubbo protocol -      <Dubbo:protocolname= "Dubbo"Port= "20880" />         <!--Declares that the service interface version that needs to be exposed is the revision number of the service Dubbo only the service provider that has the corresponding version number to call timeout time exceeded the time of the error -      <Dubbo:serviceInterface= "Com.unj.dubbotest.provider.DemoService"ref= "Demoservice"version= "1.0"Timeout= "the"/>        </Beans> 

Dubbo.properties file (the first line is the address of the configuration zookeeper)

Zookeeper.address=zookeeper://zkserver1.vko.cn:2181?backup=zkserver2.vko.cn:2181,zkserver3.vko.cn : 2181#zookeeper. address=n/Agoods.dubbo.url=Video.dubbo.url=Study.dubbo.url= Tiku.dubbo.url=Member.dubbo.url=Group.dubbo.url=Search.dubbo.url=  Comment.dubbo.url=Cms.dubbo.url=

Service Consumers:

1. Referencing remote services via spring configuration:

<?XML version= "1.0" encoding= "UTF-8"?>  <Beansxmlns= "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 app name, used to calculate dependencies, not match criteria, not as provider -      <dubbo:applicationname= "Hehe_consumer" />        <!--exposing a service address using the Zookeeper Registration center -     <!--<dubbo:registry address= "${zookeeper.address}" check= "false" file= "Dubbo.properties" > </dubbo: Registry> -    <Dubbo:registryAddress= "zookeeper://127.0.0.1:2181" />        <!--Build a remote service proxy that can be used like a local bean demoservice -   　　 <!--Configure URL properties You can directly specify the address of the interface service to facilitate testing this is usually a Dubbo direct connection and does not require a zookeeper registry -    <dubbo:referenceID= "Demoservice"Interface= "Com.unj.dubbotest.provider.DemoService"URL= "${study.dubbo.url}"version= "1.0"Timeout= "20000"Check= "false"/>    </Beans> 

Then the service providers and service consumers can invoke the remote Interface service in the same way as the local method, and for distributed service, the service provider is also the consumer of other services, and the service consumers will provide services.

There is a problem with a Dubbo loop call, which you should try to avoid when programming

5. Installation and use of the Dubbo console

Dubbo Management services are required to be deployed separately.

The open source section of the Dubbo Management Console includes: Provider routing rules dynamically configure access control weights to regulate load balancer principals, and other management functions.

1. Download Dubbo, there is a dubbo-admin-xxxx.war thrown into Tomcat,

2. Configure Dubbo.properties

Vim Webapps/root/web-inf/dubbo.properties  

dubbo.registry.address=zookeeper://10.0.65.3:2181dubbo.admin.root.password=rootdubbo.admin.guest.password= Guest

3. Launch Tomcat localhost:8080/

Login password is root/root

Configuration and use of Dubbo