原文出处： 等你回去来

dubbo作为一个长途挪用框架，虽与同范例的框架，不知道谁优谁劣，可是就公司层面利用来说，照旧很棒的。这里简朴的写一下怎么利用和调试能力，就算是作个利用总结吧，供快速利用和问题办理！

dubbo是基于spring做设置利用的，虽也提供其他要领，可是较量贫苦，所以利用spring照旧有长处的吧。

先来一个整体架构图，这对付相识其是如何事情的是很有须要的。（好比我当初就误觉得dubbo会做一个处事转发，好难过）

下面是一个更完整架构图，可以更清晰的看到软件是如何事情的：

（以下是官方说明，我以为很有须要相识下，软件开发，so）节点脚色说明：

Provider: 袒露处事的处事提供方。

Consumer: 挪用长途处事的处事消费方。

Registry: 处事注册与发明的注册中心。

Monitor: 统计处事的挪用次和谐挪用时间的监控中心。

Container: 处事运行容器。

挪用干系说明：

0. 处事容器认真启动，加载，运行处事提供者。
1. 处事提供者在启动时，劳务派遣管理系统，向注册中心注册本身提供的处事。
2. 处事消费者在启动时，向注册中心订阅本身所需的处事。
3. 注册中心返回处事提供者地点列表给消费者，假如有改观，注册中心将基于长毗连推送改观数据给消费者。
4. 处事消费者，从提供者地点列表中，基于软负载平衡算法，选一台提供者举办挪用，假如挪用失败，再选另一台挪用。
5. 处事消费者和提供者，在内存中累计挪用次数和挪用时间，按时每分钟发送一次统计数据到监控中心。

(1) 连通性：

注册中心认真处事地点的注册与查找，相当于目次处事，处事提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小

监控中心认真统计各处事挪用次数，挪用时间等，统计先在内存汇总后每分钟一次发送到监控中心处事器，并以报表展示

处事提供者向注册中心注册其提供的处事，并讲述挪用时间到监控中心，此时间不包括网络开销

处事消费者向注册中心获取处事提供者地点列表，并按照负载算法直接挪用提供者，同时讲述挪用时间到监控中心，此时间包括网络开销

注册中心，处事提供者，处事消费者三者之间均为长毗连，监控中心除外

注册中心通过长毗连感知处事提供者的存在，处事提供者宕机，注册中心将当即推送事件通知消费者

注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在当地缓存了提供者列表

注册中心和监控中心都是可选的，处事消费者可以直连处事提供者

(2) 健状性：

监控中心宕掉不影响利用，只是丢失部门采样数据

数据库宕掉后，注册中心仍能通过缓存提供处事列表查询，但不能注册新处事

注册中心对等集群，任意一台宕掉后，将自动切换到另一台

注册中心全部宕掉后，软件开发，处事提供者和处事消费者仍能通过当地缓存通讯

处事提供者无状态，任意一台宕掉后，不影响利用

处事提供者全部宕掉后，处事消费者应用将无法利用，并无限次重连期待处事提供者规复

(3) 伸缩性：

注册中心为对等集群，可动态增加呆板陈设实例，所有客户端将自动发明新的注册中心

处事提供者无状态，可动态增加呆板陈设实例，注册中心将推送新的处事提供者信息给消费者

(4) 进级性：

当处事集群局限进一步扩大，发动IT管理布局进一步进级，需要实现动态陈设，举办活动计较，现有漫衍式处事架构不会带来阻力：

以上，官方文档很全面的哦，有时间请查察 官网 说明。

利用设置如下（分提供者和消费者设置，这很容易领略）：

- 提供者设置 dubbo-provider.xml

<bean id="xxxService" class="com.xxx.XxxServiceImpl" /> <!-- 声明bean id, 以便和消费者的id相匹配 -->
 
<dubbo:service interface="com.xxx.XxxService" ref="xxxService" /> <!-- 利用dubbo:service要领，增加袒露长途处事设置 -->

- 消费者设置 dubbo-consumer.xml

<dubbo:reference id=“xxxService” interface=“com.xxx.XxxService” /> <!-- 利用dubbo:reference，引用长途处事实现设置，利用 @Resource等要领注入引用 -->

以上，两个设置好后，就可以启动dubbo, 处事端， 然后通过consumer举办测试了。

可是，此刻考究的都是微处事化，那么就大概是，提供者是一波人，消费者是另一波人，这是正常环境，那么假如要测试提供者怎么办呢？