What is 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, Frankly, it's a distributed framework for remote service invocation (say goodbye to the WSDL in Web service mode, register on Dubbo as a service provider and 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 Dubbo can 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.

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.

before using the Web Service, I wanted to test that the interface could perform functional or performance tests via SOAPUI or LR via analog messaging. But now using Dubbo, the interface can not directly interact, I try to simulate the consumer address test, the result is unsightly, and then use JMeter through JUnit test, but still need to go to Dubbo to register, if not to provide source code premise, this test case is not good to write AH ....

3. The Dubbo Architecture 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.

I think it's a very good, well-defined character. Depending on the status of each node role, you can determine if the service is healthy. Call Relationship 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.

Dubbo's fault tolerance is obvious, performance has not yet been measured, we system a page needs to be 5 times the interface, would like to suggest a cache, but the business relationship can not be adopted, but also need to study the performance tuning problem of Dubbo ... 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. If you do not want to use the spring configuration and want to make calls through the API (not recommended)

Let's take a look at how spring is configured: Service providers:

1. Download Zookeeper Registration Center, download address: http://www.apache.org/dyn/closer.cgi/zookeeper/after download, enter D:\apach-zookeeper-3.4.5\bin,

Double-click Zkserver.cmd to start the registry service. 2. Define the Service interface: (the interface needs to be packaged separately, shared between the service provider and the consumer)

The following example is good, written in detail can be a model.      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)

  package com.unj.dubbotest.provider;      import java.util.arraylist;    import java.util.linkedlist;   import java.util.list;          public class demoserviceimpl implements demoservice{                public string sayhello (string name)  {                return  "hello "  + name;        }        public  list getusers ()  {            List  List = new arraylist ();            user  u1 = new user ();             U1.setname ("Jack");            u1.setage ();             u1.setsex ("male");                         User u2 =  New user ();            u2.setname ("Tom");             u2.setage (+);             u2.setsex ("female");                         user u3 = new user ();            u3.setname ("Rose");             u3.setage (;  )           u3.Setsex ("female");                         list.add (U1);             list.add (U2);            list.add (U3);            return list;         }  }  

  Declaration of exposure service with spring configuration: <?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            ">            <!--  Concrete implementation bean -->       <bean id= " Demoservice " class= "Com.unj.dubbotest.provider.DemoServiceImpl"  />              <!--  Provider application information for computing dependencies  -->       <dubbo : Application name= "Xixi_provider"   />            <!--  Use multicast broadcast registry to expose service addresses         <dubbo:registry address= "multicast://224.5.6.7:1234"  />-->            <! --  using zookeeper registry to expose service addresses  -->       <dubbo:registry address= " zookeeper://127.0.0.1:2181 " />             <!- -  with Dubbo protocol on 20880 Port exposure service  -->       <dubbo:protocol name= "Dubbo " port=" 20880 " />           <!--  Declaring a service interface that needs to be exposed -->       <dubbo:service interface= " Com.unj.dubbotest.provider.DemoService " ref=" Demoservice " />           </beans>   Load Spring configuration, start service: package com.unj.dubbotest.provider;      import org.springframework.context.support.classpathxmlapplicationcontext;       public class provider {           public  Static void main (String[] args)  throws Exception {            ClassPathXmlApplicationContext context = new  Classpathxmlapplicationcontext (new string[] {"Applicationcontext.xml"});            context.start ();                system.in.read ();  //&nbSP; to keep the service open, simulate        }      }   with blocking of the input stream
Service Consumers:

Applicationcontext-dubbo.xml in the registration of their own need to call the interface, I just started to test the interface a lot, so the file is full of writing, and then familiar with the interface by business type, write n multiple  Applicationcontext-dubbo-***.xml more concise. "

  1. Referencing remote services via spring configuration: <?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 app name, used to calculate dependencies, not match criteria, not as providers  -->       <dubbo:application  name= "Hehe_consumer"  />          <!--  Exposing a service address using the Zookeeper registry  -->        <!-- <dubbo:registry address= "multicast://224.5.6.7:1234"  / > -->       <dubbo:registry address= "zookeeper:// 127.0.0.1:2181 " />          <!--  Generate a remote service proxy, You can use demoservice -->       <dubbo:reference id= as you would with a local bean " Demoservice "           interface=" Com.unj.dubbotest.provider.DemoService " />      </beans>  
2. Load the spring configuration and invoke the remote service: package com.alibaba.dubbo.demo.pp;      import java.util.list ;      import org.springframework.context.support.classpathxmlapplicationcontext;       import com.unj.dubbotest.provider.demoservice;      Public class  Consumer {          public static void main ( String[] args)  throws Exception {            classpathxmlapplicationcontext context = new classpathxmlapplicationcontext (                    new  String[] {  "Applicationcontext.xml" &NBSP;});            context.start ();               demoservice demoservice =  (Demoservice)  context.getbean ("Demoservice"); //            string hello = demoservice.sayhello ("Tom");  // ִ            system.out.println (Hello); //                //             list list = demoservice.getusers ();            if  (List != null && list.size ()  > 0)  {               for  (int  I = 0; i < list.size ();  i++)  {                    system.out.println (List.get (i));               }            }           // system.out.println ( Demoservice.hehe ());           system.in.read ();       }     }  

The result of the call is:

Dubbo Administration Page:

This management page also need to deploy an environment, at first I thought it was Dubbo, found a half-day did not find ....

Application page:

Provider page:

Consumer page:

Service page:

The test is successful, I think as long as the status is normal, OK ....

Case code Download: http://download.csdn.net/detail/yiyu1/7116319

The agile testing team is no longer just after coding. But with the research and development staff throughout the requirements analysis, specifications, automated unit testing, automated acceptance testing, static code analysis, technical debt and other links. So agile projects are bound to become mainstream in future efficiency trends.