Dubbo 入门

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:

<dubbo:application name="hello-world-app-provider" />

<dubbo:registry address="zookeeper://127.0.0.1:2181" />

<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的服务注入进来:

<dubbo:registry address="zookeeper://127.0.0.1:2181" />

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

相关阅读:
Pyhon的json库常用方法
常用的Python操作
Leetcode: 1301.Number of Paths with Max Score
redis 源码阅读杂记
二分查找性能试验
leetcode: 600. Non-negative Integers without Consecutive Ones
Leetcode: 902. Numbers At Most N Given Digit Set
leetcode:956. Tallest Billboard
innodb 插入性能简单测试
redis 源码阅读之 redis.c

原文地址：https://www.cnblogs.com/FlyAway2013/p/7904414.html