Dubbo简介
Dubbo是什么
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分包括：
- 远程通讯：提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型、序列化、"请求-响应"模式的信息交换方案
- 集群容错：提供基于借口方法的透明远程过程调用，包括多协议支持、软负载均衡、失败容错、地址路由、动态配置等集群支持
- 自动发现：基于注册中心目录服务，使服务消费方能动态地查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器
Dubbo能做什么
Dubbo功能强大，总结下来，它大致可以做以下几件事：
- 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需要简单配置，没有任何API侵入
- 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本、减少多拿点
- 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者
Dubbo架构图
这是最重要的，理解Dubbo的架构图是理解Dubbo的第一步，我从Dubbo官网手册上截了一下Dubbo架构图：
接下来认识一下图中的结点：
- Provider：暴露服务的服务提供方，或者直白点说就是服务生产者
- Consumer：调用远程服务的服务消费方，也就是服务消费者
- Registry：服务注册与发现的注册中心
- Monitor：统计服务的调用次数和调用时间的监控中心
- Container：服务（生产者）运行容器
图中已经有了调用步骤了，接着对步骤进行说明：
- 0：服务容器负责启动、加载、运行服务提供者（生产者）
- 1：服务提供者（生产者）在启动时，向注册中心注册自己提供的服务
- 2：服务消费者在启动时，向注册中心订阅自己所需的服务
- 3：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中细腻将基于长连接推送变更数据给消费者
- 4：服务消费者从服务生产者地址列表中，基于软负载均衡算法，选择一台提供者（生产者）进行调用，如果调用失败，再选另一台调用
- 5：服务消费者和提供者（生产者），在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心
Dubbo实战
Dubbo用法
Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入（这句话的意思是应用程序不会、不需要手动调用Dubbo的任何类和任何接口），只需用Spring加载Dubbo的配置即可（意思是对Dubbo的使用只需要写Spring配置文件或注解），Dubbo基于Spring的Schema扩展进行加载。
如果不想使用Spring配置，而希望通过API的方式进行调用，可以自己看一下官方手册Dubbo API配置，但是，这种做法十分不推荐。
1. 开发环境
开发语言：Java
构建工具：Maven
注册中心：ZooKeeper
将下载下来的包zookeeper-3.4.6.tar.gz解压，得到zookeeper-3.4.6文件夹之后，将其文件夹复制到个人喜好的位置。
进入文件夹zookeeper-3.4.6下的conf目录，复制zoo_sample.cfg文件，并将其命名为zoo.cfg，然后打开zoo.cfg文件进行编辑:
全部使用默认值， 端口默认是： 2181，
2. 编码
这个例子需要两个项目，一个为服务提供方Provider，一个为服务消费方Consumer
Provider项目
使用Maven构建一个简单的J2SE项目
新建一个服务接口DemoService.java:
public interface DemoService {
/**
* 测试方法
* @param name
* @return
*/
String sayHello(String name);
}
新建一个服务接口实现类DemoServiceImpl:
public class DemoServiceImpl implements DemoService {
/**
* 测试方法 - 实现
* @param name
* @return
*/
public String sayHello(String name) {
return "Hello " + name;
}
}
通过Spring进行注入，并将其服务注册到ZooKeeper:
<!-- 和本地bean一样实现服务 -->
<bean id="demoService" class="cn.eaglefire.app.service.impl.DemoServiceImpl" />
<!-- 提供方应用信息，用于计算依赖关系 -->
<dubbo:application name="hello-world-app-provider" />
<!-- 使用zookeeper广播注册中心暴露服务地址 -->
<dubbo:registry address="zookeeper://127.0.0.1:2181" />
<!-- 用dubbo协议在20880端口暴露服务 -->
<dubbo:protocol name="dubbo" port="20880" />
<!-- 声明需要暴露的服务接口 -->
<dubbo:service interface="cn.eaglefire.app.service.DemoService" ref="demoService" />
Consumer项目
使用Maven构建一个简单的J2SE项目
新建一个服务接口DemoService.java:
public interface DemoService {
/**
* 测试方法
* @param name
* @return
*/
String sayHello(String name);
}
通过Spring把注册到ZooKeeper的服务注入进来:
<!-- 使用zookeeper注册中心暴露服务地址 -->
<dubbo:registry address="zookeeper://127.0.0.1:2181" />
<!-- 生成远程服务代理，可以像使用本地bean一样使用demoService -->
<dubbo:reference id="demoService" interface="cn.eaglefire.app.service.DemoService" />
项目之间的连接点
可以很明显的看到，在两个项目中都必须有服务接口DemoService.java， 这个服务接口必须是完全相同的：包括相同的package、name及内容，在实际开发应用中，这个接口将打包在一个jar包，并提供给Provider和Consumer两个项目使用，Provider对接口进行实现并注册到ZooKeeper，而Consumer在到ZooKeeper中寻找对应的接口实现。
3. 测试
不测试一下，怎么知道做得对不对
Provider项目
实际情况，我们可以通过容器来启动这些服务， 这里简单起见， 我们使用main 方法来启动服务。
编写个主方法并直接运行，运行之后将在ZooKeeper中注册接口实现:
public class Provider {
/**
* 主方法
* @param args
* @throws Exception
*/
public static void main(String[] args) throws Exception {
//
System.out.println("Begin to load");
// 加载Spring配置文件
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"spring/ApplicationContext.xml"});
context.start();
//
System.out.println("End to load");
// 为保证服务一直开着，利用输入流的阻塞来模拟
System.in.read();
}
}
运行结果:
Connected to the target VM, address: '127.0.0.1:50305', transport: 'socket'
Begin to load
log4j:WARN No appenders could be found for logger (org.springframework.core.env.StandardEnvironment).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
End to load
Consumer项目
同Provider项目，简单起见， 我们使用main 方法来启动服务
编写个主方法并直接运行，运行之后将在ZooKeeper中寻找接口实现:
public class Consumer {
/**
* 主方法
* @param args
* @throws Exception
*/
public static void main(String[] args) throws Exception {
//
System.out.println("Begin to load");
// 加载Spring配置文件
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"spring/ApplicationContext.xml"});
context.start();
//
System.out.println("End to load");
// 调用远程方法
DemoService demoService = (DemoService)context.getBean("demoService");
String result = demoService.sayHello("Eagle");
System.out.println("The result is: "+result);
// 为保证服务一直开着，利用输入流的阻塞来模拟
System.in.read();
}
}
运行结果
Connected to the target VM, address: '127.0.0.1:50309', transport: 'socket'
Begin to load
log4j:WARN No appenders could be found for logger (org.springframework.core.env.StandardEnvironment).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
End to load
The result is: Hello Eagle
看到整个过程中：
1、没有任何Dubbo的代码，使用Dubbo的时候全部都是Spring配置，这就是前面提到的Dubbo对应用没有任何API侵入
2、不需要考虑底层线程模型、序列化、反序列化、url解析等问题，这些都是Dubbo底层做好的
Dubbo配置
Dubbo常用标签
首先说一个优先级的问题，在dubbo中比如timeout、retries、loadbalance等参数可以在多个标签内同时配置，它们之间的优先级，dubbo手册上是这么说的：
OK，下面罗列一些Dubbo常用的，也就是说每个项目的Dubbo的xml文件中基本都会出现的标签，并以表格形式列举标签中常见的可用属性。
1、<dubbo:service /> 用于服务生产者暴露服务配置
|
属 性 |
类 型 |
是否必填 |
缺省值 |
描 述 |
|
interface |
class |
必填 |
无 |
服务接口全路径 |
|
ref |
object |
必填 |
无 |
服务对象实现引用 |
|
version |
string |
可选 |
0.0.0 |
服务版本，建议使用两位数字版本如1.0，通常在接口不兼容时版本号才需要升级 |
|
timeout |
int |
可选 |
1000 |
远程服务调用超时时间（毫秒） |
|
retries |
int |
可选 |
2 |
远程服务调用重试次数，不包括第一次调用，不需要重试请设为0 |
|
connections |
int |
可选 |
100 |
每个生产者的最大连接数，短连接协议如rmi，表示限制连接数；长连接协议如dubbo表示建立的长连接个数 |
|
loadbalance |
string |
可选 |
random |
负载均衡策略，可选值为：random（随机）、roundrobin（轮询）、leastactive（最少活跃调用） |
|
async |
boolean |
可选 |
false |
是否缺省异步执行，不可靠的异步，只是忽略返回值，不阻塞执行线程 |
|
register |
boolean |
可选 |
true |
该协议的服务是否注册到注册中心 |
2、<dubbo:reference /> 用于服务消费者引用服务配置
|
属 性 |
类 型 |
是否必填 |
缺省值 |
描 述 |
|
id |
string |
必填 |
无 |
服务引用beanId |
|
interface |
class |
必填 |
无 |
服务接口全路径 |
|
version |
string |
可选 |
无 |
服务版本，与服务生产者的版本一致 |
|
timeout |
long |
可选 |
使用<dubbo:consumer>的timeout |
服务方法调用超时时间（毫秒） |
|
retries |
int |
可选 |
使用<dubbo:consumer>的retries |
远程服务调用重试次数，不包括第一次调用，不需要重试请设为0 |
|
connections |
int |
可选 |
使用<dubbo:consumer>的connections |
每个生产者的最大连接数，短连接协议如rmi，表示限制连接数；长连接协议如dubbo表示建立的长连接个数 |
|
loadbalance |
string |
可选 |
使用<dubbo:consumer>的loadbalance |
负载均衡策略，可选值为：random（随机）、roundrobin（轮询）、leastactive（最少活跃调用） |
|
async |
boolean |
可选 |
使用<dubbo:consumer>的async |
是否缺省异步执行，不可靠的异步，只是忽略返回值，不阻塞执行线程 |
|
check |
boolean |
可选 |
使用<dubbo:consumer>的check |
启动时检查服务生产者是否存在，true则报错，false则忽略 |
|
url |
string |
可选 |
无 |
点对点直连服务提供者地址，将绕过注册中心，比如"dubbo://localhost:20890"，这个比较多的使用在测试中 |
|
protocol |
string |
可选 |
无 |
只调用指定协议的服务生产者，其他协议忽略 |
3、<dubbo:protocol /> 用于服务生产者协议配置（如果需要支持多协议，可以声明多个此标签，并在<dubbo:service />通过protocol属性指定使用的协议）
|
属 性 |
类 型 |
是否必填 |
缺省值 |
描 述 |
|
id |
string |
可选 |
dubbo |
协议beanId，<dubbo service />中的protocol引用此ID，如果不填缺省和name属性值一样 |
|
name |
sring |
必填 |
dubbo |
协议名称 |
|
port |
int |
可选 |
dubbo->20800,rmi->1099,http->80,hessian->80 如果配置为-1或未配置，则会分配一个没有被占用的端口 |
服务端口 |
|
host |
string |
可选 |
自动查找本机ip |
为空则自动查找本机ip，建议不配置让Dubbo自动获取本机ip |
|
threadpool |
string |
可选 |
fixed |
线程池类型，可选fixed/cached |
|
threads |
int |
可选 |
100 |
服务线程池大小（固定大小） |
|
serialization |
string |
可选 |
dubbo->hession2,rmi->java,http->json |
协议序列化方式，当协议支持多种序列化方式时使用 |
|
register |
boolean |
可选 |
true |
该协议的服务是否注册到注册中心 |
4、<dubbo:registry /> 用于注册中心配置（如果有多个不同的注册中心可以声明多个标签并且<dubbo:service />或<dubbo:reference />中使用registry属性指定）
|
属 性 |
类 型 |
是否必填 |
缺省值 |
描 述 |
|
id |
string |
可选 |
无 |
注册中心引用beanId，可在<dubbo:service />或<dubbo:reference />中引用此ID |
|
address |
string |
必填 |
无 |
注册中心服务地址，如果地址没有端口缺省为9090，同一个集群内的多个地址用逗号分隔，如：ip:port,ip:port，不同的 集群注册中心请配置多个<dubbo:registry />标签 |
|
protocol |
string |
可选 |
dubbo |
注册中心地址协议，支持dubbo、http、local三种协议，分别表示dubbo地址、http地址和本地注册中心 |
|
port |
int |
可选 |
9090 |
注册中心缺省端口，当address没有带端口时使用此端口作为缺省值 |
|
username |
string |
可选 |
无 |
登陆注册中心用户名，如果注册中心不需要验证可不填 |
|
password |
string |
可选 |
无 |
登陆注册中心密码，如果注册中心不需要验证可不填 |
|
transport |
string |
可选 |
netty |
网络传输方式，可选mina、netty |
|
timeout |
int |
可选 |
5000 |
注册中心请求超时时间（毫秒） |
|
file |
string |
可选 |
无 |
使用文件缓存注册中心地址列表以及服务提供者列表，应用重启时将基于此文件恢复，注意两个注册中心不能使用同一文件存储 |
|
check |
boolean |
可选 |
true |
注册中心不存在时，是否报错 |
|
register |
boolean |
可选 |
true |
是否向此注册中心注册服务，如果设为false，将只订阅，不注册 |
|
subscribe |
boolean |
可选 |
true |
是否向此注册中心订阅服务，如果设为false，将只注册，不订阅 |
5、<dubbo:method />用于方法级配置（该标签为<dubbo:service/>或<dubbo:reference/>的子标签，用于控制到方法级）
|
属 性 |
类 型 |
是否必填 |
缺省值 |
描 述 |
|
method |
string |
必填 |
无 |
方法名 |
|
timeout |
int |
可选 |
缺省为<dubbo:reference/>的timeout |
方法调用超时时间（毫秒） |
|
retires |
int |
可选 |
缺省为<dubbo:reference/>的retries |
远程服务调用重试次数，不包括第一次调用，不需要重试请设为0 |
|
loadbalance |
string |
可选 |
缺省为<dubbo:reference/>的loadbalance |
负载均衡策略，可选值为：random（随机）、roundrobin（轮询）、leastactive（最少活跃调用） |
|
async |
boolean |
可选 |
缺省为<dubbo:reference/>的async |
是否异步执行，不可靠异步，只是忽略返回值，不阻塞执行线程 |
|
actives |
int |
可选 |
0 |
每服务消费者最大并发调用限制 |
|
executes |
int |
可选 |
0 |
每服务每方法最大使用线程数限制，此属性只在<dubbo:method/>作为<dubbo:service/>子标签时有效 |
另外，还有<dubbo:provider/>和<dubbo:consumer/>分别表示服务提供者（生产者）和服务消费者的缺省值配置，就不列举了。
参考：
http://www.cnblogs.com/xrq730/p/5316805.html
Dubbo原理
Registry
Dubbo 的关键是Registry，可以理解为注册中心、服务发现中心或者配置中心，它和每个Server/Client之间会作一个实时的心跳检测（因为它们都是建立的Socket长连接），比如几秒钟检测一次。收集每个Server提供的服务的信息，每个Client的信息，整理出一个服务列表，如：
|
serviceName |
serverAddressList |
clientAddressList |
|
UserService |
192.168.0.1，192.168.0.2，192.168.0.3，192.168.0.4 |
172.16.0.1，172.16.0.2 |
|
ProductService |
192.168.0.3，192.168.0.4，192.168.0.5，192.168.0.6 |
172.16.0.2，172.16.0.3 |
|
OrderService |
192.168.0.10，192.168.0.12，192.168.0.5，192.168.0.6 |
172.16.0.3，172.16.0.4 |
当某个Server不可用
当某个Server不可用，那么就更新受影响的服务对应的serverAddressList，即把这个Server从serverAddressList中踢出去（从地址列表中删除），同时将推送serverAddressList给这些受影响的服务的clientAddressList里面的所有Client。如：192.168.0.3挂了，那么UserService和ProductService的serverAddressList都要把192.168.0.3删除掉，同时把新的列表告诉对应的Client 172.16.0.1，172.16.0.2，172.16.0.3；
当某个Client挂了
当某个Client挂了，那么更新受影响的服务对应的clientAddressList
Registry根据服务列表，就能提供一个web管理界面，来查看管理服务的提供者和使用者。
新加一个Server时，由于它会主动与Registry取得联系，而Registry又会将这个信息主动发送给Client，所以新加一个Server时，只需要启动Server，然后几秒钟内，Client就会使用上它提供的服务
Client
调用服务的机器，每个Client启动时，主动与Registry建立Socket长连接，并将自己的IP等相应信息发送给Registry。
Client在使用服务的时候根据服务名称去Registry中获取服务提供者信息（这样Registry就知道某个服务是当前哪几个Client在使用），Client拿到这些服务提供者信息后，与它们都建立连接，后面就可以直接调用服务了，当有多个服务提供者的时候，Client根据一定的规则来进行负载均衡，如轮询，随机，按权重等。
一旦Client使用的服务它对应的服务提供者有变化（服务提供者有新增，删除的情况），Registry就会把最新的服务提供者列表推送给Client，Client就会依据最新的服务提供者列表重新建立连接，新增的提供者建立连接，删除的提供者丢弃连接
Server
真正提供服务的机器，每个Server启动时，主动与Registry建立Scoket长连接，并将自己的IP，提供的服务名称，端口等信息直接发送给Registry，Registry就会收集到每个Server提供的服务的信息。
优点
1，只要在Client和Server启动的时候，Registry是好的，服务就可调用了，如果后面Registry挂了，那只影响Registry挂了以后服务提供者有变化，而Client还无法感知这一变化。
2，Client每次调用服务是不经过Registry的，Client只是与它建立联系，从它那里获取提供服务者列表而已
3，调用服务-负载均衡：Client调用服务时，可以根据规则在多个服务提供者之间轮流调用服务。
4，服务提供者-容灾：某一个Server挂了，Client依然是可以正确的调用服务的，当前提是这个服务有至少2个服务提供者，Client能很快的感知到服务提供者的变化，并作出相应反应。
5，服务提供者-扩展：添加一个服务提供者很容易，而且Client会很快的感知到它的存在并使用它。
参考：
http://blog.163.com/tsing_hua/blog/static/13962222420128195258383/