分布式服务治理框架Dubbo

前言

Dubbo是一个被国内不少互联网公司普遍使用的开源分布式服务治理框架，是一个很是全面的SOA基础框架，当当网在Dubbo基础上新增了一些功能，并将其命名为Dubbox（Dubbo eXtensions）。

为何须要Dubbo？

之前全部的业务处理，都在一个系统当中；

接着，这个大系统按照业务领域划分为N个业务系统；

各个业务系统之间不可避免须要交互，采用什么呢？HTTP的方式？WebService？...

咱们将面临不少URL的管理，服务之间的调用链，依赖关系，服务的负载均衡、监控等等

Dubbo是什么？

Dubbo本质上就是一个分布式服务调用的东西，高性能透明化的RPC调用方案 + SOA服务治理方案。

Dubbo的架构：

第一，Dubbo有一个注册中心Registry的概念，服务的提供者Provider将服务注册到Registry，消费者Consumer须要从Registry中发现、监听到服务的变更；

第二，Provider须要运行在Container容器中，另外Dubbo提供Monitor来对服务的调用次数以及调用时间进行监控。

第三，经常使用的Registry有Zookeeper，Redis等；博主将采用Zookeeper做为注册中心。（能够参考：《分布式利器Zookeeper（一）》）

OK，说了一些理论，我们快速开始吧！

QuickStart 

这里我将为你们演示一个订单服务调用商品服务的Demo。

商品服务：ProductService

咱们先来看看商品服务的工程结构：

ProductService工程，下面分为2个Module：一个是product-api，一个是product-service。要知道，所谓的发布服务，就是将接口对外暴露，生产者和消费者都是须要引用接口的，因此在这里接口将在product-api中提供。

在product-service模块中依赖product-api并实现接口：

注意Product须要实现序列化Serializable接口。

从XML中你能够发现，咱们须要在product-service模块中依赖dubbo、Zookeeper、Curator。（我这里就不贴XML呢）

每个服务都有一个Name，其实也能够指定Owner。

注册中心采用Zookeeper，客户端采用Curator框架。

Dubbo实际上是支持不少协议，上述指明了是采用Dubbo协议，对外的服务端口是20880。

咱们须要发布服务，就是向Zookeeper注册，告诉咱们对外提供的接口是什么，以及该接口对应的服务实现是什么。

启动商品服务：

这种启动方式到底作了些什么？从哪里读取的配置文件？启动又是怎么回事呢？

咱们稍微来看一看源码：

看SpringContainer如何启动：

OK，到这里，商品服务已经就绪了！

订单服务：OrderService

先看依赖：

注意订单服务须要依赖product-api。

看dubbo配置：

消费者启动：

消费者运行结果：

看Zookeeper：

在Zookeeper中看得很清楚，接口将以目录节点的形式建立，providers下面就是接口协议，分机器，分协议，从而能够实现负载均衡！

dubbo-admin管控台

如同rocketmq同样，dubbo也提供给了dubbo-admin.war，直接部署到Tomcat下，并修改下dubbo.properties指定好注册中心地址便可。

小结

透明化的远程调用，如同调用本地方法同样，只须要简单配置，没有任何API侵入！

咱们能够平滑的增长、减小机器，消费者可以动态的查找到服务提供方，使得咱们的服务避免了单点问题，强大的容错机制以及软负载能力（要知道硬件负载器F5是很贵的）。

dubbo和Spring结合紧密，透明化的接入应用！

一些思考

本篇博客不可能将Dubbo所有的特性、配置都讲解完，所以这里提出一些问题，来和你们一块儿思考学习：

1.A服务依赖B服务，若是B服务没有启动或者禁用，A服务是否可以启动？Dubbo是否会替咱们作服务依赖调用检查呢？

2.咱们是否能够绕开注册中心，直接调用呢？

3.考虑这样一种状况，若是A调用B，出现了网络抖动，调用异常，这个时候dubbo是否会替咱们重试调用？若是dubbo有重试机制，那么是否意味着存在重复调用？若是咱们的服务是一个对数据库的操做，那么这种重试机制是否会形成影响或是问题？咱们应该如何处理？（好像想起了RocketMQ的一些事情....哈哈）

4.dubbo提供了哪些负载均衡的机制？能够具体到每个方法么？

5.服务的调用，到了Server端，最后确定是要走线程池进行调用的，那么咱们根据不一样场景能够对线程池进行定制么？