Dubbo是一个被国内很多互联网公司广泛使用的开源分布式服务治理框架，是一个非常全面的SOA基础框架，当当网在Dubbo基础上新增了一些功能，并将其命名为Dubbox（Dubbo eXtensions）。
为什么需要Dubbo？
以前所有的业务处理，都在一个系统当中；
接着，这个大系统按照业务领域划分为N个业务系统；
各个业务系统之间不可避免需要交互，采用什么呢？HTTP的方式？WebService？...
我们将面临很多URL的管理，服务之间的调用链，依赖关系，服务的负载均衡、监控等等
Dubbo是什么？
Dubbo本质上就是一个分布式服务调用的东西，高性能透明化的RPC调用方案 + SOA服务治理方案。
Dubbo的架构：
<a href="https://s5.51cto.com/wyfs02/M00/97/7F/wKiom1ku1-Pi5h7pAAExunnyfM8634.png" target="_blank"></a>
第一，Dubbo有一个注册中心Registry的概念，服务的提供者Provider将服务注册到Registry，消费者Consumer需要从Registry中发现、监听到服务的变动；
第二，Provider需要运行在Container容器中，另外Dubbo提供Monitor来对服务的调用次数以及调用时间进行监控。
OK，说了一些理论，咱们快速开始吧！
这里我将为大家演示一个订单服务调用商品服务的Demo。
我们先来看看商品服务的工程结构：
<a href="https://s3.51cto.com/wyfs02/M00/97/80/wKioL1ku2LPh05maAABl1QV4LHY275.png" target="_blank"></a>
ProductService工程，下面分为2个Module：一个是product-api，一个是product-service。要知道，所谓的发布服务，就是将接口对外暴露，生产者和消费者都是需要引用接口的，所以在这里接口将在product-api中提供。
<a href="https://s4.51cto.com/wyfs02/M02/97/80/wKioL1ku2N2yXlt8AAAyi7ilS7k520.png" target="_blank"></a>
在product-service模块中依赖product-api并实现接口：
<a href="https://s5.51cto.com/wyfs02/M01/97/7F/wKiom1ku2QqwLKorAAAUxpo9MW8091.png" target="_blank"></a>
<a href="https://s2.51cto.com/wyfs02/M02/97/7F/wKiom1ku2SrxyHgEAAApncbDOoQ324.png" target="_blank"></a>
注意Product需要实现序列化Serializable接口。
<a href="https://s2.51cto.com/wyfs02/M02/97/80/wKioL1ku2VvDBQlGAAC2uWfTaaY926.png" target="_blank"></a>
从XML中你可以发现，我们需要在product-service模块中依赖dubbo、Zookeeper、Curator。（我这里就不贴XML呢）
每一个服务都有一个Name，其实也可以指定Owner。
注册中心采用Zookeeper，客户端采用Curator框架。
Dubbo其实是支持很多协议，上述指明了是采用Dubbo协议，对外的服务端口是20880。
我们需要发布服务，就是向Zookeeper注册，告诉我们对外提供的接口是什么，以及该接口对应的服务实现是什么。
启动商品服务：
<a href="https://s1.51cto.com/wyfs02/M01/97/80/wKioL1ku2YzTrgahAAAYM3VPUO0377.png" target="_blank"></a>
这种启动方式到底做了些什么？从哪里读取的配置文件？启动又是怎么回事呢？
我们稍微来看一看源码：
<a href="https://s2.51cto.com/wyfs02/M02/97/7F/wKiom1ku2bSQ9332AAAdgoKHEds952.png" target="_blank"></a>
看SpringContainer如何启动：
<a href="https://s2.51cto.com/wyfs02/M02/97/7F/wKiom1ku2duD-mvHAABGPx1-B2g306.png" target="_blank"></a>
<a href="https://s2.51cto.com/wyfs02/M01/97/7F/wKiom1ku2fjDeQqAAAAbrPeDDNY772.png" target="_blank"></a>
OK，到这里，商品服务已经就绪了！
先看依赖：
<a href="https://s3.51cto.com/wyfs02/M00/97/7F/wKiom1ku2iOxzVpcAABazSN-9DE767.png" target="_blank"></a>
注意订单服务需要依赖product-api。
看dubbo配置：
<a href="https://s1.51cto.com/wyfs02/M00/97/80/wKioL1ku2lGjlFkZAAA-jnBkfJc640.png" target="_blank"></a>
消费者启动：
<a href="https://s2.51cto.com/wyfs02/M01/97/80/wKioL1ku2nzwKMxpAABF5a4juMo704.png" target="_blank"></a>
消费者运行结果：
<a href="https://s4.51cto.com/wyfs02/M02/97/7F/wKiom1ku2sbDx_e5AAAwS67J1WQ538.png" target="_blank"></a>
看Zookeeper：
<a href="https://s2.51cto.com/wyfs02/M00/97/7F/wKiom1ku2ubQHajLAAAoVW4sQUQ791.png" target="_blank"></a>
在Zookeeper中看得很清楚，接口将以目录节点的形式创建，providers下面就是接口协议，分机器，分协议，从而可以实现负载均衡！
如同rocketmq一样，dubbo也提供给了dubbo-admin.war，直接部署到Tomcat下，并修改下dubbo.properties指定好注册中心地址即可。
<a href="https://s3.51cto.com/wyfs02/M02/97/7F/wKiom1ku2x_gMWbsAADkElIoVTQ026.png" target="_blank"></a>
透明化的远程调用，如同调用本地方法一样，只需要简单配置，没有任何API侵入！
我们可以平滑的增加、减少机器，消费者能够动态的查找到服务提供方，使得我们的服务避免了单点问题，强大的容错机制以及软负载能力（要知道硬件负载器F5是很贵的）。
dubbo和Spring结合紧密，透明化的接入应用！
本篇博客不可能将Dubbo全部的特性、配置都讲解完，因此这里提出一些问题，来和大家一起思考学习：
1.A服务依赖B服务，如果B服务没有启动或者禁用，A服务是否能够启动？Dubbo是否会替我们做服务依赖调用检查呢？
2.我们是否可以绕开注册中心，直接调用呢？
3.考虑这样一种情况，如果A调用B，出现了网络抖动，调用异常，这个时候dubbo是否会替我们重试调用？如果dubbo有重试机制，那么是否意味着存在重复调用？如果我们的服务是一个对数据库的操作，那么这种重试机制是否会造成影响或是问题？我们应该如何处理？（好像想起了RocketMQ的一些事情....哈哈）
4.dubbo提供了哪些负载均衡的机制？可以具体到每一个方法么？
5.服务的调用，到了Server端，最后肯定是要走线程池进行调用的，那么我们根据不同场景可以对线程池进行定制么？
<b>本文转自zfz_linux_boy 51CTO博客，原文链接：http://blog.51cto.com/zhangfengzhe/1931170，如需转载请自行联系原作者</b>
![Java小案例——随机数猜测随机数猜测[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)