dubbo学习过程、使用经验分享及实现原理简单介绍

迷南。 2022-05-11 00:28 193阅读 0赞

# 转载： #

# 一、前言 #

部门去年年中开始各种改造，第一步是模块服务化，这边初选dubbo试用在一些非重要模块上，慢慢引入到一些稍微重要的功能上，半年时间，学习过程及线上使用遇到的些问题在此总结下。

整理这篇文章差不多花了两天半时间，请尊重劳动成果，如转载请注明出处http://blog.csdn.net/hzzhoushaoyu/article/details/43273099

# 二、什么是dubbo #

Dubbo是阿里巴巴提供的开源的SOA服务化治理的技术框架，据说只是剖出来的一部分开源的，但一些基本的需求已经可以满足的，而且扩展性也非常好（至今没领悟到扩展性怎么做到的），通过spring bean的方式管理配置及实例，较容易上手且对应用无侵入。更多介绍可戳[http://alibaba.github.io/dubbo-doc-static/Home-zh.htm][http_alibaba.github.io_dubbo-doc-static_Home-zh.htm]。

# 三、如何使用dubbo #

## 1.服务化应用基本框架 ##

![dubbo-architecture.jpg-version_1_modificationDate_1330892870000.jpg][]

如上图所示，一个抽象出来的基本框架，consumer和provider是框架中必然存在的，Registry做为全局配置信息管理模块，推荐生产环境使用Registry，可实时推送现存活的服务提供者，Monitor一般用于监控和统计RPC调用情况、成功率、失败率等情况，让开发及运维了解线上运行情况。

应用执行过程大致如下：

*  服务提供者启动，根据协议信息绑定到配置的IP和端口上，如果已有服务绑定过相同IP和端口的则跳过
 *  注册服务信息至注册中心
 *  客户端启动，根据接口和协议信息订阅注册中心中注册的服务，注册中心将存活的服务地址通知到客户端，当有服务信息变更时客户端可以通过定时通知得到变更信息
 *  在客户端需要调用服务时，从内存中拿到上次通知的所有存活服务地址，根据路由信息和负载均衡机制选择最终调用的服务地址，发起调用
 *  通过filter分别在客户端发送请求前和服务端接收请求后，通过异步记录一些需要的信息传递到monitor做监控或者统计

## 2.服务接口定义 ##

一般单独有一个jar包，维护服务接口定义、RPC参数类型、RPC返回类型、接口异常、接口用到的常量，该jar包中不处理任何业务逻辑。

比如命名api-0.1.jar，在api-0.1.jar中定义接口

1.  `public interface UserService`
2.  `{`
3.  `public RpcResponseDto isValidUser(RpcAccountRequestDto requestDto) throws new RpcBusinessException, RpcSystemException;`
4.  `}`

并在api-0.1.jar中定义RpcResponseDto,RpcAccountRequestDto,RpcBusinessException,RpcSystemException。

服务端通过引用该jar包实现接口并暴露服务，客户端引用该jar包引用接口的代理实例。

## 3.注册中心 ##

开源的dubbo已支持4种组件作为注册中心，我们部门使用推荐的zookeeper做为注册中心，由于就瓶颈来说不会出现在注册中心，风险较低，未做特别的研究或比较。

*  zookeeper，推荐集群中部署奇数个节点，由于zookeeper挂掉一半的机器集群就不可用，所以部署4台和3台的集群都是在挂掉2台后集群不可用
 *  redis
 *  multicast,广播受到网络结构的影响，一般本地不想搭注册中心的话使用这种调用
 *  dubbo简易注册中心

对于zookeeper客户端，dubbo在2.2.0之后默认使用zkclient，2.3.0之后提供可选配置Curator，提到这个点的原因主要是因为zkclient发现一些问题：①服务器在修改服务器时间后zkClient会抛出日志错误之类的异常然后容器（我们使用resin）挂掉了，也不能确定就是zkClient的问题，接入dubbo之前无该问题②dubbo使用zkclient不传入连接zookeeper等待超时时间，使用默认的Integer.MAX\_VALUE，这样在zookeeper连不上的情况下不报错也无法启动；目前我们准备寻找其他解决方案，比如使用curator试下，还没正式投入。

## 4.服务端 ##

配置应用名

<dubbo:application name="test"/>

配置dubbo注解识别处理器，不指定包名的话会在spring bean中查找对应实例的类配置了dubbo注解的

<dubbo:annotation/>

配置注册中心，通过group指定注册中心分组，可通过register配置是否注册到该注册中心以及subscribe配置是否从该注册中心订阅

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

配置服务协议，多网卡可通过IP指定绑定的IP地址，不指定或者指定非法IP的情况下会绑定在0.0.0.0，使用Dubbo协议的服务会在初始化时建立长连接

<dubbo:protocol name="dubbo" port="20880" accesslog="d:/access.log"></dubbo:protocol>

通过xml配置文件配置服务暴露，首先要有个spring bean实例（无论是注解配置的还是配置文件配置的），在下面ref中指定bean实例ID，作为服务实现类

<dubbo:service interface="com.web.foo.service.FirstDubboService" ref="firstDubboServiceImpl" version="1.0"></dubbo:service>

通过注解方式配置服务暴露，Component是Spring bean注解，Service是dubbo的注解（不要和spring bean的service注解弄混），如前文所述，dubbo注解只会在spring bean中被识别

1.  `@Component`
2.  `@Service(version="1.0")`
3.  `public class FirstDubboServiceImpl implements FirstDubboService`
4.  `{`
5.   
6.  `@Override`
7.  `public void sayHello(TestDto test)`
8.  `{`
9.  `System.out.println("Hello World!");`
10. `}`
11.  
12. `}`

## 5.客户端 ##

同服务端配置应用名、注解识别处理器和注册中心。

配置客户端reference bean。客户端跟服务端不同的是客户端这边没有实际的实现类的，所以配置的dubbo:reference实际会生成一个spring bean实例，作为代理处理Dubbo请求，然后其他要调用处直接使用spring bean的方式使用这个实例即可。

xml配置文件配置方式,id即为spring bean的id,之后无论是在spring配置中使用ref="firstDubboService"还是通过@Autowired注解都OK

1. `<dubbo:reference interface="com.web.foo.service.FirstDubboService"`
2. `version="1.0" id="firstDubboService" ></dubbo:reference>`

另外开发、测试环境可通过指定Url方式绕过注册中心直连指定的服务地址，避免注册中心中服务过多，启动建立连接时间过长，如

1. `<dubbo:reference interface="com.web.foo.service.FirstDubboService"`
2. `version="1.0" id="firstDubboService" url="dubbo://127.0.0.1:20880/"></dubbo:reference>`

注解配置方式引用，

1.  `@Component`
2.  `public class Consumer`
3.  `{`
4.  `@Reference(version="1.0")`
5.  `private FirstDubboService service;`
6.   
7.  `public void test()`
8.  `{`
9.  `TestDto test = new TestDto();`
10. `test.setList(Arrays.asList(new String[]{"a", "b"}));`
11. `test.setTest("t");`
12. `service.sayHello(test);`
13. `}`
14. `}`

Reference被识别的条件是spring bean实例对应的当前类中的field，如上是直接修饰spring bean当前类中的属性

这个地方看了下源码，本应该支持当前类和父类中的public set方法，但是看起来是个BUG，Dubbo处理reference处部分源码如下

1.  `Method[] methods = bean.getClass().getMethods();`
2.  `for (Method method : methods) {`
3.  `String name = method.getName();`
4.  `if (name.length() > 3 && name.startsWith("set")`
5.  `&& method.getParameterTypes().length == 1`
6.  `&& Modifier.isPublic(method.getModifiers())`
7.  `&& ! Modifier.isStatic(method.getModifiers())) {`
8.  `try {`
9.  `Reference reference = method.getAnnotation(Reference.class);`
10. `if (reference != null) {`
11. `Object value = refer(reference, method.getParameterTypes()[0]);`
12. `if (value != null) {`
13. `method.invoke(bean, new Object[] { });//？？这里不是应该把value作为参数调用么，而且为什么上面if条件判断参数为1这里不传参数`
14. `}`
15. `}`
16. `} catch (Throwable e) {`
17. `logger.error("Failed to init remote service reference at method " + name + " in class " + bean.getClass().getName() + ", cause: " + e.getMessage(), e);`
18. `}`
19. `}`
20. `}`

## 6.监控中心 ##

如果使用Dubbo自带的监控中心，可通过简单配置即可，先通过github获得dubbo-monitor的源码，部署启动后在应用配置如下

<dubbo:monitor protocol="registry" />

<dubbo:monitor address="dubbo://127.0.0.1:7070/com.alibaba.dubbo.monitor.MonitorService" />

## 7.服务路由 ##

最重要辅助功能之一，可随时配置路由规则调整客户端调用策略，目前dubbo-admin中已提供基本路由规则的配置UI，到github下载源码部署后很容易找到地方，这里简单介绍下怎么用路由。

下面是dubbo-admin的新建路由界面，可配置信息都在图片中有，

比如现在我们有10.0.0.1~3三台消费者和10.0.0.4~6三台服务提供者，想让1和2调用4，3调用5和6的话，则可以配置两个规则，

1.消费者IP：10.0.0.1,10.0.0.2 ；提供者IP：10.0.0.4

2.消费者IP：10.0.0.3；提供者IP：10.0.0.5,10.0.0.6

另外，IP地址支持结尾为\*匹配所有，如10.0.0.\*或者10.0.\*等。

不匹配的配置规则和匹配的配置规则是一致的。

![Center][]

配置完成后可在消费者标签页查看路由结果

![Center 1][]

## 8.负载均衡 ##

dubbo提供4种负载均衡方式:

*  Random，随机，按权重配置随机概率，调用量越大分布越均匀，默认是这种方式
 *  RoundRobin，轮询，按权重设置轮询比例，如果存在比较慢的机器容易在这台机器的请求阻塞较多
 *  LeastActive，最少活跃调用数，不支持权重，只能根据自动识别的活跃数分配，不能灵活调配
 *  ConsistentHash，一致性hash，对相同参数的请求路由到一个服务提供者上，如果有类似灰度发布需求可采用

dubbo的负载均衡机制是在客户端调用时通过内存中的服务方信息及配置的负责均衡策略选择，如果对自己系统没有一个全面认知，建议先采用random方式。

## 9.dubbo过滤器 ##

有需要自己实现dubbo过滤器的，可关注如下步骤：

1.  dubbo初始化过程加载META-INF/dubbo/internal/，META-INF/dubbo/，META-INF/services/三个路径(classloaderresource)下面的com.alibaba.dubbo.rpc.Filter文件
2.  文件配置每行Name=FullClassName，必须是实现Filter接口
3.  @Activate标注扩展能被自动激活
4.  @Activate如果group（provider|consumer）匹配才被加载
5.  @Activate的value字段标明过滤条件，不写则所有条件下都会被加载，写了则只有dubbo URL中包含该参数名且参数值不为空才被加载

如下是dubbo rpc access log的过滤器，仅对服务提供方有效，且参数中需要带accesslog，也就是配置protocol或者serivce时配置的accesslog="d:/rpc\_access.log"

1.  `@Activate(group = Constants.PROVIDER, value = Constants.ACCESS_LOG_KEY)`
2.  `public class AccessLogFilter implements Filter {`
3.  `}`

## 10.其他特性 ##

[http://alibaba.github.io/dubbo-doc-static/User+Guide-zh.htm\#UserGuide-zh-%][http_alibaba.github.io_dubbo-doc-static_User_Guide-zh.htm_UserGuide-zh-][3Cdubbo%3Amonitor%2F%3E][http_alibaba.github.io_dubbo-doc-static_User_Guide-zh.htm_UserGuide-zh-]

可关注以上链接内容，dubbo提供较多的辅助功能特性，大多目前我们暂时未使用到，后续我们这边关注到的两个特性可能会再引进来使用：

*  结果缓存，省得自己再去写一个缓存，对缓存没有特殊要求的话直接使用dubbo的好了
 *  分组合并，对RPC接口不同的实现方式分别调用然后合并结果的一种调用模式，比如我们要查用户是否合法，一种我们要查是否在黑名单，同时我们还要关注登录信息是否异常，然后合并结果

# 四、前车之鉴 #

这个主要是在整个学习及使用过程中记录的，以及一些同事在初识过程问过我的，这边做了整理然后直接列举在下面：

## 1.服务版本号 ##

*  引用只会找相应版本的服务

1. `<dubbo:serviceinterface=“com.xxx.XxxService” ref=“xxxService” version=“1.0” />`
2. `<dubbo:referenceid=“xxxService” interface=“com.xxx.XxxService” version=“1.0”/>`

*  为了今后更换接口定义发布在线时，可不停机发布，使用版本号

## 2.暴露一个内网一个外网IP问题 ##

为了在测试环境提供一个内网访问的地址和一个办公区访问的地址。

•增加一个指定IP为内网地址的服务协议

•增加一个不指定IP的服务协议，但是在/etc/hosts中hostname对应的IP要为外网IP

上面这种方案是一开始使用的方案，后面发现dubbo在启动过程无论是否配路由还是会一个个去连接，虽然不影响启动，但是由于存在超时所以会影响启动时间，而且每台机器还得特别配置指定IP，后面使用另外一套方案：

1.  服务不配置ip，绑定到0.0.0.0，自动获取保证获取到是内网IP注册到注册中心即可，如果不是想要的IP，可以在/etc/hosts中通过绑定Hostname指定IP
2.  内网访问方式通过注册中心或者直连指定内网IP和端口
3.  外网访问方式通过直连指定外网IP和端口

使用这种方式需要注意做好防火墙控制等，比如在线默认也是不指定IP，会绑定在0.0.0.0，如果非法人员知道调用的外网IP和端口，而且可以直接访问就麻烦了（如果在应用中做IP拦截也成，需要注意有防范措施）。

## 3.dubbo reference注解问题 ##

前文介绍使用时已经提到过，@Reference只能在spring bean实例对应的当前类中使用，暂时无法在父类使用；如果确实要在父类声明一个引用，可通过配置文件配置dubbo:reference，然后在需要引用的地方跟引用spring bean一样就行

## 4.服务超时问题 ##

目前如果存在超时，情况基本都在如下几点：

*  客户端耗时大，也就是超时异常时的client elapsed xxx，这个是从创建Future对象开始到使用channel发出请求的这段时间，中间没有复杂操作，只要CPU没问题基本不会出现大耗时，顶多1ms属于正常
 *  IOThread繁忙，默认情况下，dubbo协议一个客户端与一个服务提供者会建立一个共享长连接，如果某个客户端处于特别繁忙而且一直往一个服务提供者塞请求，可能造成IOThread阻塞，一般非常特殊的情况才会出现
 *  服务端工作线程池中线程全部繁忙，接收消息后塞入队列等待，如果等待时间比预想长会引起超时
 *  网络抖动，如果上述情况都排除了，还出现在请求发出后，服务接收请求前超过预想时间，只能归类到网络抖动了，需要SA一起查看问题
 *  服务自身耗时大，这个需要应用自身做好耗时统计，当出现这种情况的时候需要用数据来说明问题及规划优化方案，建议采用缓存埋点的方式统计服务中各个执行阶段的耗时情况，最终如果超过预想时间则把缓存统计的耗时情况打日志，减少日志量，且能够得到更明确的信息

现在我们应用使用过程中发现两种类型的耗时，一种我们目前只能归类到网络抖动，后续需要找运维一起关注这个问题，另外一种是由于一些历史原因，数据库查询容易发生抖动，总有一个时间点会突然多出很多超时。

## 5.服务保护 ##

服务保护的原则上是避免发生类似雪崩效应，尽量将异常控制在服务周围，不要扩散开。

说到雪崩效应，还得提下dubbo自身的重试机制，默认3次，当失败时会进行重试，这样在某个时间点出现性能问题，然后调用方再连续重复调用，很容易引起雪崩，建议的话还是很据业务情况规划好如何进行异常处理，何时进行重试。

服务保护的话，目前我们主要从以下几个方面来实施，也不成熟，还在摸索：

*  考虑服务的dubbo线程池类型（fix线程池的话考虑线程池大小）、数据库连接池、dubbo连接数限制是否都合适
 *  考虑服务超时时间和重试的关系，设置合适的值
 *  一定时间内服务异常数较大，则可考虑使用failfast让客户端请求直接返回或者让客户端不再请求

经领导推荐，还在学习Release it，后续有其他想法，再回头来编辑。

## 6.zkclient的问题 ##

前文已经提到过zkclient有两个问题，修改服务器时间会导致容器挂掉；dubbo使用zkclient没有传超时时间导致zookeeper无法连接的时候，直接阻塞Integer.MAX\_VALUE。

正在调研curator，目前只能说curator不会在无法连接的时候直接阻塞。

另外zkclient和curator的jar包应该都是jdk1.6编译的，所以系统还在jdk1.5以下的话无法使用。

## 7.注册中心的分组group和服务的不同实现group ##

这两个东西完全不同的概念，使用的时候不要弄混了。

registry上可以配置group，用于区分不同分组的注册中心，比如在同一个注册中心下，有一部分注册信息是要给开发环境用的，有一部分注册信息时要给测试环境用的，可以分别用不同的group区分开，目前对这个理解还不透彻，大致就是用于区分不同环境。

service和reference上也可以配置group，这个用于区分同一个接口的不同实现，只有在reference上指定与service相同的group才会被发现，还有前文提到的分组合并结果也是用的这个。

# 五、dubbo如何工作的 #

其实dubbo整个框架内容并不算大，仔细看的话可能最多两天看完一遍，但是目前还是没领悟到怎么做到的扩展性，学习深度还不够~

要学习dubbo源码的话，必须要拿出官方高清大图才行。

![dubbo-framework.jpg-version_1_modificationDate_1341329396000.jpg][]

这张图看起来挺复杂的样子，真正拆分之后对照源码来看会发现非常清晰、简单直观。

## 1.如何跟进源码 ##

入口就是各种dubbo配置项的解析，<dubbo:xxx />都是spring namespace，可以看到dubbo jar包下META-INF里面的spring.handlers，自定义的spring namespace处理器。

对于spring不太熟的同学可以先了解下这个功能，入口都在这里，解析成功后每个<dubbo:xxx />配置项都对应一个spring实例。

## 2.服务提供者 ##

首先把这张图拆分成三块，首先是服务端剖去网络传输模块，也就是大图中的右上角。

![Center 2][]

这里主要抽几个主要的类，从服务初始化到接收消息的流程简单说明下，有兴趣的再对照源码看下会比较清晰。

*  ServiceBean

继承ServiceConfig，做为服务配置管理和配置信息校验，每一个dubbo:service配置或者注解都会对应生成一个ServiceBean的实例，维护当前服务的配置信息，并把一些全局配置塞入到该服务配置中。

另外ServiceBean本身是一个InitializingBean，在afterPropertiesSet时通过配置信息引导服务绑定和注册。

可以留意到ServiceBean还实现了ApplicationListener，在全部spring bean加载完成后判断是否延迟加载的逻辑。

*  ProtocolFilterWrapper

经过serviceBean引导后进入该类，这个地方注意下，Protocol使用的装饰模式，叶子只有DubboProtocol和RegistryProtocol，在中间调用中会绕来绕去，而且registry会走一遍这个流程，然后在RegistryProtocol中暴露服务再走一遍，注意每个类的作用，不要被绕昏了就行，第一次跟进代码的时候没留意就晕头转向的。

在这之前其实还有个ProtocolListenerWrapper，封装监听器，在服务暴露后通知到监听器，没有复杂逻辑，如果没特殊需求可以先绕过。

再来说ProtocolFIlterWrapper，这个类的作用就是串联filter调用链，如果有看过struts或者spring mvc拦截器源码的应该不会陌生。

*  RegistryProtocol

注册中心协议，如果配置了注册中心地址，每次服务暴露肯定首先引导进入这个类中，如果没有注册中心连接则会先创建连接，然后再引导真正的服务协议暴露流程，会再走一次ProtocolFilterWrapper的流程（这次引导到的叶子是DubboProtocol）。

在服务暴露返回后，会再执行服务信息的注册和订阅操作。

*  DubboProtocol

这个类的export相对较简单，就是引导服务bind server socket。

另外该类还提供了一个内部类，用于处理接收请求，就是下面要提到的ExchangeHandler。

*  DubboProtocol$ExchangeHandler

接收反序列化好的请求消息，然后根据请求信息找到执行链，将请求再丢入执行链，让其最终执行到实现类再将执行结果返回即整个过程完成。

## 3.客户端 ##

客户端模块与服务端模块比较类似，只是刚好反过来，一个是暴露服务，一个是引用服务，然后客户端多出路由和负载均衡。

![Center 3][]

*  ReferenceBean

继承ReferenceConfig，维护配置信息和配置信息的校验，该功能与ServiceBean类似

其本身还实现了FactoryBean，作为实例工厂，创建远程调用代理类；而且如果不指定为init的reference都是在首次getBean的时候调用到该factoryBean的getObject才进行初始化

另外实现了InitializingBean，在初始化过程中引导配置信息初始化和构建init的代理实例

*  InvokerInvocationHandler

看到这个类名应该就知道是动态代理的handler，这里作为远程调用代理类的处理器在客户端调用接口时引导进入invoker调用链

*  ProtocolFIlterWrapper

与Service那边的功能类似，构建调用链

*  RegistryProtocol

与service那边类似，如果与注册中心还没有连接则建立连接，之后注册和订阅，再根据配置的策略返回相应的clusterInvoker

比service那边有个隐藏较深的逻辑需要留意的，就是订阅过程，RegistryDirectory作为订阅监听器，在订阅完成后会通知到RegistryDirectory，然后会刷新invoker，进入引导至DubboProtocol的流程，与变更的service建立长连接，第一次发生订阅时就会同步接收到通知并将已存在的service存到字典

*  DubboProtocol

在订阅过程中发现有service变更则会引导至这里，与服务建立长连接，整个过程为了得到串联执行链Invoker

*  ClusterInvoker

ClusterInvoker由RegistryProtocol构建完成后，内部封装了Directory，在调用时会从Directory列举存活的service对应的Invoker,Directory作为被通知对象，在service有变更时也会及时得到通知

调用时在集群中发现存在多节点的话都会通过clusterInvoker来根据配置抉择最终调用的节点，包括路由方式、负载均衡等

dubbo本身支持的节点调用策略包括比如failoverClusterInvoker在失败时进行重试其他节点，failfastClusterInvoker在失败时返回异常，mergeableClusterInvoker则是对多个实现结果进行合并的等等很多

*  DubboInvoker

承接上层的调用信息，作为调用结构的叶子，将信息传递到exchange层，主要用来和echange交互的功能模块

## 4.网络传输层 ##

从exchange往下都是算网络传输，包括做序列化、反序列化，使用Netty等IO框架发送接收消息等逻辑，先前看的时候没有做统一梳理，后续有机会再来编辑吧。

1.Dubbo是一个分布式服务框架，致力于提供高性能和透明化的远程服务调用方案，这容易和负载均衡弄混，负载均衡是对外提供一个公共地址，请求过来时通过轮询、随机等，路由到不同server。目的分摊压力。dubbo在淘宝也是解决他们实际问题的，不一定适合其他。 另外各家公司也都有大同小异的实现，所以没多少人用、也就没多少介绍。

原理就是：A系统调用B系统接口服务， 后面就是怎么把这个流程，动态化(zookeeper通知)、权限化、配置化、低耦合化、自动化。

# **一．dubbo出现的背景** #

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，需一个治理系统确保架构有条不紊的演进。

目前市场一些基本的架构：

*  **单一应用架构**
    
     *  当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
     *  此时，用于简化增删改查工作量的 **数据访问框架(ORM)** 是关键。
 *  **垂直应用架构**
    
     *  当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
     *  此时，用于加速前端页面开发的 **Web框架(MVC)** 是关键。
 *  **分布式服务架构**
    
     *  当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
     *  此时，用于提高业务复用及整合的 **分布式服务框架(RPC)** 是关键。
 *  **流动计算架构**
    
     *  当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
     *  此时，用于提高机器利用率的 **资源调度和治理中心(SOA)** 是关键。

在大规模服务化之前，一般只是简单的暴露和引用远程服务，通过配置url进行调用，用f5或者nginx等进行负载均衡；

# 二．**Dubbo架构** #

官网架构图：

![1024208-20161115160104060-1001941336.png][]

**节点角色说明：**

*  **Provider:** 暴露服务的服务提供方。
 *  **Consumer:** 调用远程服务的服务消费方。
 *  **Registry:** 服务注册与发现的注册中心。
 *  **Monitor:** 统计服务的调用次调和调用时间的监控中心。
 *  **Container:** 服务运行容器。

**调用关系说明：**

*  0. 服务容器负责启动，加载，运行服务提供者。
 *  1. 服务提供者在启动时，向注册中心注册自己提供的服务。
 *  2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
 *  3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
 *  4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
 *  5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

**连通性：**

*  注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
 *  监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
 *  服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销
 *  服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销
 *  注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
 *  注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
 *  注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
 *  注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

**健状性：**

*  监控中心宕掉不影响使用，只是丢失部分采样数据
 *  数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
 *  注册中心对等集群，任意一台宕掉后，将自动切换到另一台
 *  注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
 *  服务提供者无状态，任意一台宕掉后，不影响使用
 *  服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

# 三．**用法** #

本地服务配置文件：local.xml

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> &lt;bean&nbsp;id=“xxxService” class=“com.xxx.XxxServiceImpl” /&gt; &nbsp; &lt;bean&nbsp;id=“xxxAction” class=“com.xxx.XxxAction”&gt; &nbsp;&nbsp;&nbsp;&nbsp;&lt;property&nbsp;name=“xxxService” ref=“xxxService” /&gt; &lt;/bean&gt; </td> 
 </tr> 
 </tbody> 
</table>

远程服务配置

在本地服务的基础上，只需做简单配置，即可完成远程化：

* 将上面的local.xml配置拆分成两份，将服务定义部分放在服务提供方remote-provider.xml，将服务引用部分放在服务消费方remote-consumer.xml。
 * 并在提供方增加暴露服务配置<dubbo:service>，在消费方增加引用服务配置<dubbo:reference>。

服务者配置**provider.xml**：

<**bean** id=“xxxService” class=“com.xxx.XxxServiceImpl” />

<**dubbo:service** interface=“com.xxx.XxxService” ref=“xxxService” />

Throwbill作为服务者实例：

<bean id=*"iTSMService"* class=*"com.sitech.throwbill.easyask.service.itsm.impl.ITSMServiceImpl"* />

<dubbo:service interface=*"com.sitech.throwbill.easyask.service.itsm.ITSMService"* ref=*"iTSMService"* version=*"1.0"*>

<dubbo:method name=*"putChatMessage"* servicecode=*"33.1013.putChatMessage"*/>

<dubbo:method name=*"queryAllChatMessage"* servicecode=*"33.1013.queryAllChatMessage"*/>

</dubbo:service>

作为服务者完整配置文件：

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> &lt;?xml&nbsp;version="1.0"&nbsp;encoding="UTF-8"?&gt; &lt;beans&nbsp;xmlns="<a href="http://www.springframework.org/schema/beans" rel="nofollow">http://www.springframework.org/schema/beans"</a> &nbsp;&nbsp;&nbsp;&nbsp;xmlns:xsi="<a href="http://www.w3.org/2001/XMLSchema-instance" rel="nofollow">http://www.w3.org/2001/XMLSchema-instance"</a> &nbsp;&nbsp;&nbsp;&nbsp;xmlns:dubbo="<a href="http://code.alibabatech.com/schema/dubbo" rel="nofollow">http://code.alibabatech.com/schema/dubbo"</a> &nbsp;&nbsp;&nbsp;&nbsp;xsi:schemaLocation="http://www.springframework.org/schema/beans&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://www.springframework.org/schema/beans/spring-beans.xsd&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://code.alibabatech.com/schema/dubbo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://code.alibabatech.com/schema/dubbo/dubbo.xsd" rel="nofollow">http://code.alibabatech.com/schema/dubbo/dubbo.xsd"</a>&gt; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&lt;!-- 提供方应用信息，用于计算依赖关系 --&gt; &nbsp;&nbsp;&nbsp;&nbsp;&lt;dubbo:application&nbsp;name="hello-world-app"&nbsp; /&gt; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&lt;!-- 使用multicast广播注册中心暴露服务地址 --&gt; &nbsp;&nbsp;&nbsp;&nbsp;&lt;dubbo:registry&nbsp;address="multicast://224.5.6.7:1234"&nbsp;/&gt; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&lt;!-- 用dubbo协议在20880端口暴露服务 --&gt; &nbsp;&nbsp;&nbsp;&nbsp;&lt;dubbo:protocol&nbsp;name="dubbo"&nbsp;port="20880"&nbsp;/&gt; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&lt;!-- 声明需要暴露的服务接口 --&gt; &nbsp;&nbsp;&nbsp;&nbsp;&lt;dubbo:service&nbsp;interface="com.alibaba.dubbo.demo.DemoService"&nbsp;ref="demoService"&nbsp;/&gt; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&lt;!-- 和本地bean一样实现服务 --&gt; &nbsp;&nbsp;&nbsp;&nbsp;&lt;bean&nbsp;id="demoService"&nbsp;class="com.alibaba.dubbo.demo.provider.DemoServiceImpl"&nbsp;/&gt; &nbsp; &lt;/beans&gt; </td> 
 </tr> 
 </tbody> 
</table>

消费者配置**consumer.xml****：**

<**dubbo:reference** id=“xxxService” interface=“com.xxx.XxxService” />

<**bean** id=“xxxAction” class=“com.xxx.XxxAction”>

<**property** name=“xxxService” ref=“xxxService” />

</**bean**>

作为服务者的完整配置：

Throwbill作为消费者实例：

<bean id=*"easkMessageService"* class=*"com.sitech.service.dubbo.EaskMessageServiceImpl"*></bean>

<dubbo:reference id=*"ymItsmService"* interface=*"com.ffcs.itsm.zj.service.EasyAsk2ItsmService"* version=*"1.0"*>

<dubbo:method name=*"launchItsmEventFlow** *servicecode=*"33.1404.launchEventFlow"*/>

<dubbo:method name=*"changeItsmEventState"*  servicecode=*"33.1404.changeEventFlowState"* />

</dubbo:reference>

作为消费者完整配置文件：

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> &lt;?xml&nbsp;version="1.0"&nbsp;encoding="UTF-8"?&gt; &lt;beans&nbsp;xmlns="<a href="http://www.springframework.org/schema/beans" rel="nofollow">http://www.springframework.org/schema/beans"</a> &nbsp;&nbsp;&nbsp;&nbsp;xmlns:xsi="<a href="http://www.w3.org/2001/XMLSchema-instance" rel="nofollow">http://www.w3.org/2001/XMLSchema-instance"</a> &nbsp;&nbsp;&nbsp;&nbsp;xmlns:dubbo="<a href="http://code.alibabatech.com/schema/dubbo" rel="nofollow">http://code.alibabatech.com/schema/dubbo"</a> &nbsp;&nbsp;&nbsp;&nbsp;xsi:schemaLocation="http://www.springframework.org/schema/beans&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://www.springframework.org/schema/beans/spring-beans.xsd&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://code.alibabatech.com/schema/dubbo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://code.alibabatech.com/schema/dubbo/dubbo.xsd" rel="nofollow">http://code.alibabatech.com/schema/dubbo/dubbo.xsd"</a>&gt; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&lt;!-- 消费方应用名，用于计算依赖关系，不是匹配条件，不要与提供方一样 --&gt; &nbsp;&nbsp;&nbsp;&nbsp;&lt;dubbo:application&nbsp;name="consumer-of-helloworld-app"&nbsp; /&gt; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&lt;!-- 使用multicast广播注册中心暴露发现服务地址 --&gt; &nbsp;&nbsp;&nbsp;&nbsp;&lt;dubbo:registry&nbsp;address="multicast://224.5.6.7:1234"&nbsp;/&gt; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&lt;!-- 生成远程服务代理，可以和本地bean一样使用demoService --&gt; &nbsp;&nbsp;&nbsp;&nbsp;&lt;dubbo:reference&nbsp;id="demoService"&nbsp;interface="com.alibaba.dubbo.demo.DemoService"&nbsp;/&gt; &nbsp; &lt;/beans&gt; </td> 
 </tr> 
 </tbody> 
</table>

** **

* <dubbo:service/> 服务配置，用于暴露一个服务，定义服务的元信息，一个服务可以用多个协议暴露，一个服务也可以注册到多个注册中心。
 * <dubbo:reference/> 引用配置，用于创建一个远程服务代理，一个引用可以指向多个注册中心。
 * <dubbo:protocol/> 协议配置，用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受。
 * <dubbo:application/> 应用配置，用于配置当前应用信息，不管该应用是提供者还是消费者。
 * <dubbo:module/> 模块配置，用于配置当前模块信息，可选。
 * <dubbo:registry/> 注册中心配置，用于配置连接注册中心相关信息。
 * <dubbo:monitor/> 监控中心配置，用于配置连接监控中心相关信息，可选。
 * <dubbo:provider/> 提供方的缺省值，当ProtocolConfig和ServiceConfig某属性没有配置时，采用此缺省值，可选。
 * <dubbo:consumer/> 消费方缺省配置，当ReferenceConfig某属性没有配置时，采用此缺省值，可选。
 * <dubbo:method/> 方法配置，用于ServiceConfig和ReferenceConfig指定方法级的配置信息。
 * <dubbo:argument/> 用于指定方法参数配置。

# 四．**注册中心** #

![1024208-20161115160127482-951082358.png][]

流程：  
1.服务提供者启动时向/dubbo/com.foo.BarService/providers目录下写入URL  
2.服务消费者启动时订阅/dubbo/com.foo.BarService/providers目录下的URL向/dubbo/com.foo.BarService/consumers目录下写入自己的URL  
3.监控中心启动时订阅/dubbo/com.foo.BarService目录下的所有提供者和消费者URL

支持以下功能：

1.当提供者出现断电等异常停机时，注册中心能自动删除提供者信息。

2.当注册中心重启时，能自动恢复注册数据，以及订阅请求。

3.当会话过期时，能自动恢复注册数据，以及订阅请求。

4.当设置<dubbo:registry check="false" />时，记录失败注册和订阅请求，后台定时重试。

5.可通过<dubbo:registry username="admin" password="1234" />设置zookeeper登录信息。

6.可通过<dubbo:registry group="dubbo" />设置zookeeper的根节点，不设置将使用无根树。

7.支持\*号通配符<dubbo:reference group="\*" version="\*" />，可订阅服务的所有分组和所有版本的提供者。

注：阿里内部并没有采用Zookeeper做为注册中心，而是使用自己实现的基于数据库的注册中心，即：Zookeeper注册中心并没有在阿里内部长时间运行的可靠性保障，此Zookeeper桥接实现只为开源版本提供，其可靠性依赖于Zookeeper本身的可靠性。

[http_alibaba.github.io_dubbo-doc-static_Home-zh.htm]: http://alibaba.github.io/dubbo-doc-static/Home-zh.htm
[dubbo-architecture.jpg-version_1_modificationDate_1330892870000.jpg]: /images/20220511/dbb63f9bcd38486592408597099da8e5.png
[Center]: /images/20220511/571d09a476ac4aaaacf53c978d6328ae.png
[Center 1]: /images/20220511/923031c6cb574c3cb6007c4524d2b0c9.png
[http_alibaba.github.io_dubbo-doc-static_User_Guide-zh.htm_UserGuide-zh-]: http://alibaba.github.io/dubbo-doc-static/User+Guide-zh.htm
[dubbo-framework.jpg-version_1_modificationDate_1341329396000.jpg]: /images/20220511/64bf407cb24f492aa71b82943615a992.png
[Center 2]: /images/20220511/778505d278c14607b96e96e29d3a8e23.png
[Center 3]: /images/20220511/53504465704e4d90b90e23199f6106a2.png
[1024208-20161115160104060-1001941336.png]: /images/20220511/05b0f6b793d84a5f858640c24dccde75.png
[1024208-20161115160127482-951082358.png]: /images/20220511/44ec06f9a0fe4850b222ccfc4cf49885.png