From today onwards we learn a high-performance RPC Framework Dubbo, we from the use of Dubbo to the source code in-depth learning and analysis.
Dubbo is a high-performance service framework of Alibaba's open source, which enables applications to implement the output and input capabilities of services through high-performance RPC, which can be seamlessly integrated with the spring framework and is the core framework of Alibaba's SOA service governance solution. Dubbo Overview 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 site traffic is small, you need only one app 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
As traffic 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 the vertical application is more and more, the interaction between applications inevitably, the core business extracted, as a separate service, gradually formed a stable service center, so that the front-end application can respond more quickly to the market demand. At this point, the Distributed Service Framework (RPC) that is used to improve business reuse and consolidation is critical.
Flow Computing Architecture
When the service is more and more, the evaluation of capacity, and the waste of small service resources appear gradually, it is necessary to add a dispatch center to manage cluster capacity and improve cluster utilization based on access pressure.
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. Core Components
Remoting: The network communication framework realizes the Sync-over-async and request-response message mechanism.
RPC: Abstraction of a remote procedure call that supports load balancing, disaster recovery, and cluster functionality
Registry: Service catalog framework for service registration and service event Publishing and subscription how it works
Node role description
Provider:The exposed service party calls the service provider.
Consumer:Calling a remote service is called a "service consumer."
Registry:The service registration and Discovery Central Directory service is called the "Service registry."
Monitor:The log service for the call and call time of the statistics service is called the Service Monitoring Center.
Container:Service Run 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:
The Registry is responsible for registering and locating service addresses, equivalent to directory services, where service providers and consumers interact with the registry only at startup, and the registry does not forward requests and is less stressful. Monitoring Center is responsible for statistics of the number of service calls, call time, etc., statistics are first sent to the Monitoring center server every minute after the memory summary, and the report is displayed. The service provider registers its services with the registry and reports the call time to the Monitoring center, which does not include network overhead, the service consumer obtains the service provider address list from the registry, and invokes the provider directly based on the load algorithm, while reporting the call time to the Monitoring center, which includes the network overhead. Registration Center, service provider, service consumers are long connections between all, except the monitoring Center, 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 impacting the already running providers and consumers, who cache the provider list locally. Registries and monitoring centers are optional and service consumers can connect directly to service providers
(2) Jian-like sex:
Monitoring Center outage does not affect the use, just lost part of the sampled data, the database is down, the registry can still provide service list query through the cache, but not to register the new service. Registry peer cluster, after any one outage, will automatically switch to another registry after all the outage, service providers and service consumers can still communicate through the local cache. The service provider is stateless, and any one outage is not affected by the use. After the service provider is all down, the service consumer app will not work and unlimited re-connect waits for the service provider to recover
(3) Flexibility:
The registry is a peer cluster that dynamically increases the machine deployment instance and 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 the consumer
(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:
Let's take a look at the complete diagram of the Dubbo operating architecture
Deployer: The local agent for the automatic deployment service.
Repository: The warehouse is used for storage service app release packages.
Scheduler: The dispatch center automatically increases and decreases the service provider based on the access pressure.
Admin: Unified Management Console.use of Dubbo (integrated spring)
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 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 in the provider, add the reference service configuration in the consumer
For example:
Service provider 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-
Service consumption put Remote-consumer.xml
<dubbo:reference id= "Xxxservice" interface= "Com.xxx.XxxService"/> <!--Add Reference remote service configuration--
<bean id= " Xxxaction "class=" Com.xxx.XxxAction "> <!--and local services using remote service--
<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. Zookeeper Installation
We recommend that you use the Zookeeper Registry Client for dubbo-2.3.3 or later
Zookeeper is a sub-project of Apache Hadoop, which is relatively strong and recommends that the production environment use the registry.
Dubbo does not make any intrusive modifications to the zookeeper server, just install the native zookeeper server, and all the registry logic adaptations are done when the zookeeper client is called.
Online installation
wget http://www.apache.org/dist//zookeeper/zookeeper-3.3.3/zookeeper-3.3.3.tar.gz
Tar zxvf zookeeper-3.3.3.tar.gz
CD zookeeper-3.3.3
CP conf/zoo_sample.cfg conf/zoo.cfg
Configure Zoo.cfg
VI conf/zoo.cfg
If you do not need a cluster, the contents of Zoo.cfg are as follows: (where the data directory needs to be changed to your real output directory)
ticktime=2000 # #ZK中的一个时间单元. All time in ZK is based on this time unit and is configured in integer multiples. For example, the minimum time-out period for a session is 2*ticktime.
initlimit=10 # #Follower在启动过程中, all the latest data is synced from leader, and then you can determine the starting state of your external service. Leader allows F to do this work in Initlimit time
synclimit=5 # #在运行过程中, leader is responsible for communicating with all the machines in the ZK cluster, for example, through some heartbeat detection mechanisms, to detect the machine's survival status. If L make a heartbeat packet after Synclimit and have not received a response from F, then I think this f is out of line. Note: Do not set this parameter too large, or it may obscure some problems
Datadir=/home/dubbo/zookeeper-3.3.3/data # #存储快照文件snapshot的目录
clientport= 2181 # #客户端连接server的端口, external service port
If a cluster is required, the contents of the zoo.cfg are as follows: (where the Data directory and server address need to be changed to the information of your actual deployment machine)
ticktime=2000
initlimit=10
synclimit=5
datadir=/home/dubbo/zookeeper-3.3.3/data
clientPort= 2181
server.1=10.20.153.10:2555:3555 # #server. x=[hostname]:nnnnn[:nnnnn] The x here is a number that is consistent with the ID in the myID file. On the right can be configured with two ports, the first port for data synchronization between F and L and other communication, the second port is used to leader voting communication during the election process.
server.2=10.20.153.11:2555:3555
and place the myID file in the Data directory: (DataDir in the zoo.cfg above)
mkdir Data
VI myID
myID indicates its own ID, corresponding to the server in the above zoo.cfg. The first set of contents is 1 and the second one is 2.
Start and stop
./bin/zkserver.sh start
./bin/zkserver.sh stop
After launch we are using the following configuration
dubbo.registry.address=zookeeper://10.20.153.10:2181?backup=10.20.153.11:2181
<!--or-
< Dubbo:registry protocol= "Zookeeper" address= "10.20.153.10:2181,10.20.153.11:2181"/>
Service Provider
Define the Service interface: (this interface needs to be packaged separately, shared between service providers and consumers)
Public interface Demoservice {
string SayHello (string name);
}
implementing interfaces in service providers: (hiding implementations for service consumers, consumers don't need to focus on how to implement them)
public class Demoserviceimpl implements Demoservice {public
String SayHello (String name) {
return "Hello" + Name ;
}
}
Exposing services through 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 > <!--provider app information for calculating dependencies--<dubbo:application name= "Hello-world-app"/> <!--using Multicas T broadcast registry exposes service address--<dubbo:registry address= "multicast://224.5.6.7:1234"/> <!--exposed with Dubbo protocol on 20880 Ports- <dubbo:protocol name= "Dubbo" port= "20880"/> <!--declaration needs exposed service interface--<dubbo:service Interfa Ce= "Com.alibaba.dubbo.demo.DemoService" ref= "Demoservice"/> <!--and local beans as a service--<bean id= "Demoser Vice "class=" Com.alibaba.dubbo.demo.provider.DeMoserviceimpl "/> </beans>
Load Spring Configuration
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
}
}
Once the spring configuration file is loaded this time Dubbo service provider has been up to serve the consumer
Referencing remote services through spring configuration files
<?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 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--and
<dubbo: Reference id= "Demoservice" interface= "Com.alibaba.dubbo.demo.DemoService"/>
</beans>
Load the spring configuration file and invoke the remote service
Import Org.springframework.context.support.ClassPathXmlApplicationContext;
public class Consumer {public
static void Main (string[] args) throws Exception {
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
}
}
Reference: "Dubbo Development Guide"