1、概念

　　Dubbo是一个分布式服务框架，以及阿里巴巴内部的SOA服务化治理方案的核心框架。其功能主要包括：高性能NIO通讯及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与降级等。

　　说通俗点，就是首先将程序组件化成一个个相对独立的服务，然后就可以对服务进行分布式；而且，它有注册中心通过监听，实时发现着新服务，并部署，还可以推送给客户端；它还集成了负载均衡的解决方案，利用随机算法来讲各个服务科学地分配到多台服务器上；当然，它也集成了容错机制，来提高集群的稳定性。

2、架构

　节点角色说明：

　　?  Provider: 暴露服务的服务提供方。

　　?  Consumer: 调用远程服务的服务消费方。

　　?  Registry: 服务注册与发现的注册中心。

　　?  Monitor: 统计服务的调用次调和调用时间的监控中心。

　　?  Container: 服务运行容器。

　调用关系说明：

　　0. 服务容器负责启动，加载，运行服务提供者。

　　1. 服务提供者在启动时，向注册中心注册自己提供的服务。

　　2. 服务消费者在启动时，向注册中心订阅自己所需的服务。

　　3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

　　4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

　　5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

　注册中心（Registry）说明：

　　对于Dubbo架构中的控制中心及Registry，阿里提供了两种方案：Zookeeper和Redis。生产环境建议大家都使用Zookeeper，推荐理由是：

　　1.     Dubbo的官网上写着，使用Dubbo-2.3.3及以上的版本，推荐使用Zookeeper注册中心。

　　2.     Zookeeper是Apache Hadoop的子项目，强度相对较好，能够完全胜任生产环境的扮演稳定的角色。

　　3.     Dubbo未对Zookeeper服务端做任何侵入修改，只需安装原生的Zookeeper服务器即可，所有注册中心逻辑适配都在调用Zookeeper客户端完成。

3、实例

下面将不贴出来源码，只对项目结构即部分核心代码进行简单说明。源码自行下载，下载地址：点击打开链接

　　为了简单起见，这个实例中，我们没有使用Zookeeper注册中心暴露服务地址，而是使用外网的multicast广播注册中心暴露服务地址。这样我们可以快速的认识一下Dubbo的作用。

　　案例中，我们建立了两个WebProject：dubboprovider和dubboconsumer，前者为服务提供方，后者作为客户端。我们将dubboprovider服务类的接口引入到dubboconsumer项目中（不能引用服务的实现类），然后通过multicast广播注册中心（真实环境用Registry）来远程调用dubboprovider服务的实现，如果能成功调到，就算成功。（项目中applicationContext.xml会报错，是由http://code.alibabatech.com/schema/dubbo/dubbo.xsd引起，说是阿里的相关服务换地方了，不过没关系，可以正常运行）

暴露服务和引用服务的核心配置如下，其它代码比较简单，这里不多介绍，直接下载源码（点击打开链接）看即可看懂：

版权声明：本文为博主原创文章，未经博主允许不得转载。