Dubbo是一款高性能、轻量级的开源Java RPC框架。

dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）

 

三大核心能力：

面向接口的远程方法调用：提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。（像调用本地方法一样调用远程方法，采用全spring配置方式，基于Spring的Schema扩展进行加载，透明化接入应用，没有任何API侵入。）

智能容错和负载均衡：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。（可在内网替代F5等硬件负载均衡器，降低成本，减少单点。）

服务自动注册和发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。（不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。）

 

 

Provider　　   暴露服务方称之为“服务提供者”。

Consumer　　调用 方称之为“服务消费者”。

Registry　　    服务注册与发现的中心目录服务称之为“服务注册中心”。

Monitor　　     统计服务的调用次数和调用时间的日志服务称之为“服务监控中心”。

 

我们用这张图来形容 , 那么映射到 项目中:

      当我们在多个Tomcat部署不同的系统时, 例如A系统(TomcatA)想调用B系统(TomcatB)中的服务, 这时Dubbo就有了用武之地. 首先我们需要B系统在注册中心将自己的Url注册进去, 然后注册中心将Url返还给系统A, 那么系统A就可以调用了. 当然了我这里说的只是Dubbo的一种用法, 在这个项目中使用的也是Dubbo的远程调用功能. (感觉真的和webservice有点像)

 

Dubbo框架设计一共划分了10个层：

服务接口层（Service）：该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。

配置层（Config）：对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类。

服务代理层（Proxy）：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。

服务注册层（Registry）：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。

集群层（Cluster）：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。

监控层（Monitor）：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor和MonitorService。

远程调用层（Protocol）：封将RPC调用，以Invocation和Result为中心，扩展接口为Protocol、Invoker和Exporter。Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。

信息交换层（Exchange）：封装请求响应模式，同步转异步，以Request和Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

网络传输层（Transport）：抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec。

数据序列化层（Serialize）：可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool。

 

Dubbo适用于哪些场景

1.RPC分布式服务

当网站变大后，不可避免的需要拆分应用进行服务化，以提高开发效率，调优性能，节省关键竞争资源等。

比如：为了适用不断变化的市场需求，以及多个垂直应用之间数据交互方便，我们把公共的业务抽取出来作为独立的模块，为其他的应用提供服务，系统逐渐依赖于抽象和rpc远程服务调用。

2.配置管理

当服务越来越多时，服务的URL地址信息就会爆炸式增长，配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。

3.服务依赖

当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。

4.服务扩容

接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？…...在遇到这些问题时，都可以用Dubbo来解决。

 

dubbo-provider.xml:

1 
     
      22         23         24         
      25         
      26         
      27         
      28         
      29         
      30         
      31         
      32         
      33         
      34         35 
     

dubbo-cusmer.xml:

1 
     
      22         23         
      24         
      25         
      26         
      27         
      28         
      29         
      30         
      31         32 
     

 

 注意先启动服务提供方, 然后再启动服务消费方.