Dubbo User Guide

Original address: http://dubbo.io/User+Guide-zh.htm

Getting Started

(+) (#)

background

(#)

With the development of the Internet, the scale of website application is expanding, the conventional vertical application architecture cannot be solved, the distributed service architecture and the mobile computing architecture are imperative, and a governance system is urgently needed to ensure an orderly evolution of the architecture.

Single Application Architecture when the site traffic is small, only one application is deployed to deploy all the features together to reduce deployment nodes and costs. At this point, the data Access Framework (ORM) is the key to simplifying the effort of adding and deleting changes. Vertical Application Architecture when the number of accesses increases, a single application increases the acceleration of the machine, and the application is split into several unrelated applications to improve efficiency. At this point, the Web Framework (MVC) used to accelerate the development of front-end pages is critical. Distributed Service Architecture when vertical application is more and more, the interaction between applications is unavoidable, the core business is extracted, as an independent service, gradually form a stable service center, so that the front-end application can respond to the changeable market demand more quickly. At this point, the Distributed Service Framework (RPC) that is used to improve business reuse and consolidation is critical. Flow Computing Architecture when more and more services, capacity assessment, the waste of small service resources are gradually emerging, it is necessary to add a dispatch center based on access pressure real-time management of cluster capacity, improve cluster utilization. At this point, the resource Scheduling and Governance Center (SOA) that is used to improve machine utilization is critical.

Demand

(#)

Before a large-scale service, the application may simply expose and reference remote services through tools such as RMI or Hessian, call through the URL address of the configuration service, and load balance through hardware such as F5.

(1) with more and more services, service URL configuration management becomes very difficult, and the F5 hardware load Balancer's single point of pressure is getting bigger.

At this point, a service registry, dynamic registration and discovery services are required to make the location of the service transparent.

It also reduces the reliance on the F5 hardware load balancer by obtaining a list of service provider addresses in the consumer, which can reduce the partial cost.

(2) When further development, inter-service dependencies become a complex, even unclear which application to start before which application, the architect can not fully describe the application's architectural relationship.

At this point, you need to automatically draw a dependency graph between applications to help the architect clean up the relationship.

(3) Then, the service is more and more calls, the capacity of the service problem is exposed, the service requires how much machine support. When to add the machine.

To solve these problems, the first step is to count the number of calls and response times for the service now, as a reference for capacity planning.

Secondly, to be able to dynamically adjust the weight, on-line, the weight of a machine has been increased, and in the process of increasing the time to record the change in response times, until the response time to reach the threshold, record the amount of traffic at this time, and then the amount of this traffic multiplied by the number of machines to push back total capacity.

These are some of the most basic needs of Dubbo, more services governance issues see:

Http://code.alibabatech.com/blog/experience_1402/service-governance-process.html

Architecture

(#)

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 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.

(1) Connectivity: Registration Center is responsible for service address registration and lookup, the equivalent of directory services, service providers and consumers only at the start-up with the registration center interaction, the Registry does not forward the request, the pressure of the small Monitoring Center is responsible for statistics of the number of service calls, call time, etc. Statistics are sent to the Monitoring Center server once every minute after the memory summary, and the reporting service provider registers its services with the registry and reports the call time to the Monitoring center, which does not include the network overhead service consumer to obtain the service provider address list from the registry, and directly invokes the provider based on the load algorithm. At the same time reporting the call time to the Monitoring center, which includes the network cost registry, service providers, service consumers are long connections between the three, monitoring center except the registration center through the presence of long-connection-aware service providers, service providers down, the registry will immediately push events to notify consumers The Registry and Monitoring Center are all down, without affecting the already running providers and consumers, the consumer caches the provider list registry and the monitoring center are optional, the service consumers can directly connect the service provider

(2) Health: Monitoring Center downtime does not affect the use, just lost part of the sampled data database outage, the registry can still provide a list of services through the cache query, but can not register the new service registry peer cluster, any one outage, will automatically switch to another registry after all the outage, Service providers and service consumers will still be able to use the local cache communication service provider stateless, after any one outage, does not affect the use of service providers are all down, service consumer applications can not be used, and unlimited re-connect waiting for service provider recovery

(3) Scalability: Registration Center for peer cluster, can dynamically increase the machine deployment instance, all clients will automatically discover the new registry service provider stateless, can dynamically increase the machine deployment instance, the registry will push the new service provider information to consumers

(4) Upgrade: When the scale of service cluster expands further, it needs to realize dynamic deployment and flow calculation, and the existing distributed service architecture will not bring resistance:

D Eployer: The local agent for the automatic deployment service. R epository: The warehouse is used for storage service app release packages. S Cheduler: The dispatch center automatically increases and decreases the service provider based on the access pressure. A DMin: Unified Management Console.

usage

(#)

Local Service: (Spring configuration)

Local.xml

<bean id= "Xxxservice" class= "Com.xxx.XxxServiceImpl"/> <bean id= "xxxaction" class= "Com.xxx.XxxAction" > <property name= "Xxxservice" ref= "Xxxservice"/> </bean>

Remote Service: (Spring configuration)

On the basis of local services, you can complete the remoting by simply configuring: Split the above local.xml configuration into two parts, place the service definition part on the service provider Remote-provider.xml, and place the service reference part in the service consumer Remote-consumer.xml. and increase the exposure service configuration <dubbo:service> in the provider, add the Referral service configuration <dubbo:reference> in the consumer.

As follows:

Remote-provider.xml

<bean id= "Xxxservice" class= "Com.xxx.XxxServiceImpl"/> <!--and local services for remote service-- <dubbo:service interface= "Com.xxx.XxxService" ref= "Xxxservice"/> <!--increased exposure remote service configuration--

Remote-consumer.xml

<dubbo:reference id= "Xxxservice" interface= "Com.xxx.XxxService"/> <!--Add reference to remote service configuration- <bean id= "xxxaction" class= "Com.xxx.XxxAction" > <!--and local services use remote services like-- <property name= "Xxxservice" ref= "Xxxservice"/> </bean>

Quick Start

(+) (#)

	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), see: API configuration (+)

Service Provider

(#)

Complete installation steps, see: Example Provider installation (+)

Define the Service interface: (this interface needs to be packaged separately, shared between service providers and consumers)

Demoservice.java

Package Com.alibaba.dubbo.demo; Public interface Demoservice { String SayHello (string name); }

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

Demoserviceimpl.java

Package com.alibaba.dubbo.demo.provider; Import Com.alibaba.dubbo.demo.DemoService; public class Demoserviceimpl implements Demoservice { public string SayHello (string name) { Return "Hello" + name; } }

To declare an exposure service with spring configuration:

Provider.xml

<?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 " > <!--provider application information for computing dependencies-- <dubbo:application name= "Hello-world-app"/> <!--use the multicast broadcast registry to expose the service address-- <dubbo:registry address= "multicast://224.5.6.7:1234"/> <!--exposed at 20880 ports with the Dubbo protocol-- <dubbo:protocol name= "Dubbo" port= "20880"/> <!--declaring a service interface that needs to be exposed-- <dubbo:service interface= "Com.alibaba.dubbo.demo.DemoService" ref= "Demoservice"/> <!--as well as local beans-- <bean id= "Demoservice" class= "Com.alibaba.dubbo.demo.provider.DemoServiceImpl"/> </beans>

To load the spring configuration:

Provider.java

Import Org.springframework.context.support.ClassPathXmlApplicationContext; public class Provider { public static void Main (string[] args) throws Exception { Classpathxmlapplicationcontext context = new Classpathxmlapplicationcontext (new string[] {"Http://10.20.160.198/wiki /display/dubbo/provider.xml "}); Context.start (); System.in.read (); Press any key to exit } }

Service Consumers

(#)

Complete installation steps, see: Sample Consumer Installation (+)

To reference a remote service through spring configuration:

Consumer.xml

<?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 for calculating dependencies, not matching criteria, not the same as the provider-- <dubbo:application name= "Consumer-of-helloworld-app"/> <!--using the multicast broadcast registry to expose the Discovery service address-- <dubbo:registry address= "multicast://224.5.6.7:1234"/> <!--generate a remote service proxy that can be used like a local bean demoservice-- <dubbo:reference id= "Demoservice" interface= "Com.alibaba.dubbo.demo.DemoService"/> </beans>

Load the spring configuration and invoke the remote service: (You can also use IOC injection)

Consumer.java

Import Org.springframework.context.support.ClassPathXmlApplicationContext; Import Com.alibaba.dubbo.demo.DemoService;   Public class Consumer {       public static void Main (string[] args) throws Exc eption {         classpathxmlapplicationcontext context = new Classpathxmlapplicationcontext (new string[] {"Http://10.20.160.198/wiki/display/dubbo/consumer.xml"});         context.start ();           demoservice Demoservice = (demoservice) Context.getBean (" Demoservice "); Get remote service proxy         string hello = Demoservice.sayhello ("World"); Execute remote method           system.out.println (hello);//Show Call result     }   }

Dependent

(+) (#)

must depend on jdk1.5+

Theoretically Dubbo can only rely on the JDK and not rely on any of the three-party libraries to run, just configure the use of JDK-related implementation policies.

Default Dependency

With mvn dependency:tree > Dep.log command Analysis, Dubbo relies on the following three-party libraries by default:

[INFO] +-Com.alibaba:dubbo:jar:2.1.2:compile [INFO] | +-Log4j:log4j:jar:1.2.16:compile [INFO] | +-Org.javassist:javassist:jar:3.15.0-ga:compile [INFO] | +-Org.springframework:spring:jar:2.5.6.sec03:compile [INFO] | +-Commons-logging:commons-logging:jar:1.1.1:compile [INFO] | \-Org.jboss.netty:netty:jar:3.2.5.final:compile

All dependencies here are Dubbo by default configuration, which is based on stability and performance considerations. Log4j.jar and Commons-logging.jar log output packages. can be removed directly, the log of the Dubbo itself is automatically switched to the java.util.logging output of the JDK. But if other three-party libraries such as Spring.jar indirectly rely on commons-logging, it cannot be removed. Javassist.jar byte code generation. If <dubbo:provider proxy= "jdk"/> or <dubbo:consumer proxy= "JDK"/>, and <dubbo:application compiler= "JDK"/ , it is not required. Spring.jar configuration resolution. If called with the API of ServiceConfig and Referenceconfig, it is not required. Netty.jar Network transmission. If <dubbo:protocol server= "Mina"/> or <dubbo:protocol server= "Grizzly"/>, then switch to Mina.jar or Grizzly.jar. If <protocol name= "RMI"/>, it is not required.

Optional Dependencies

The following dependencies, which are used when the active configuration uses the corresponding implementation strategy, need to be self-reliant. mina:1.1.7 grizzly:2.1.4 httpclient:4.1.2 hessian_lite:3.2.1-fixed xstream:1.4.1 fastjson:1.1.8 zookeeper:3.3.3 Jed is:2.0.0 xmemcached:1.3.6 jfreechart:1.0.13 hessian:4.0.7 jetty:6.1.26 hibernate-validator:4.2.0.final zkclient:0.1 curator:1.1.10 cxf:2.6.1 thrift:0.8.0

jee:servlet:2.5 bsf:3.1 Validation-api:1.0.0.ga jcache:0.4

Maturity Level

(+) (#)

Functional Maturity Level

(#)

Feature	Maturity	Strength	problem	Advise	User
concurrency control	Tested	concurrency control		Trial
Connection control	Tested	Connection Count Control		Trial
Direct Connect Provider	Tested	Point-to-point direct-connect service provider for testing		Test environment use	Alibaba
grouping aggregations	Tested	Grouped aggregate return values for services such as menu aggregation	Special scenes use	Can be used in production environments
Parameter Validation	Tested	Parameter validation, JSR303 validation Framework Integration	has an impact on performance	Trial	Laiwang
Result Cache	Tested	Result cache, for accelerating requests		Trial
Generalization reference	Stable	Generalization calls, without the need for a business interface class for remote calls, for test platforms, open network Guan, etc.		Can be used in production environments	Alibaba
Generalization implementation	Stable	Generalization implementation without the need for a business interface class to implement arbitrary interfaces for mock platforms		Can be used in production environments	Alibaba
echo Test	Tested	echo Test		Trial
Implicit pass-through parameters	Stable	Additional parameters		Can be used in production environments
asynchronous invocation	Tested	Unreliable asynchronous invocation		Trial
Local call	Tested	Local call		Trial
Parameter callback	Tested	Parameter callback	Special scenarios use	Trial