您现在的位置是:首页 > 文章详情

分布式服务治理框架Dubbo

日期:2018-09-15点击:381

前言

Dubbo是一个被国内很多互联网公司广泛使用的开源分布式服务治理框架,是一个非常全面的SOA基础框架,当当网在Dubbo基础上新增了一些功能,并将其命名为Dubbox(Dubbo eXtensions)。

为什么需要Dubbo?

以前所有的业务处理,都在一个系统当中;

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

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

我们将面临很多URL的管理,服务之间的调用链,依赖关系,服务的负载均衡、监控等等

Dubbo是什么?

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

Dubbo的架构:

Dubbo的架构

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

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

第三,常用的Registry有Zookeeper,Redis等;博主将采用Zookeeper作为注册中心。(可以参考:《分布式利器Zookeeper(一)》

OK,说了一些理论,咱们快速开始吧!

QuickStart 

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

商品服务:ProductService

我们先来看看商品服务的工程结构:

ProductService

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

 

对外暴露的接口

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

product-service:pom.xml

 

接口的具体实现

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

 

product-service.xml

从XML中你可以发现,我们需要在product-service模块中依赖dubbo、Zookeeper、Curator。(我这里就不贴XML呢)

每一个服务都有一个Name,其实也可以指定Owner。

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

Dubbo其实是支持很多协议,上述指明了是采用Dubbo协议,对外的服务端口是20880。

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

启动商品服务:

dubbo提供Main方式启动服务

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

我们稍微来看一看源码:

容器启动服务

看SpringContainer如何启动:

注意默认扫描的位置

 

通过wait进行阻塞,使得服务一直可用!

OK,到这里,商品服务已经就绪了!

订单服务:OrderService

先看依赖:

OrderService:pom.xml

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

看dubbo配置:

spring-dubbo.xml

消费者启动:

扫描配置文件,启动Spring容器,进行接口调用

消费者运行结果:

就如同本地调用似的

看Zookeeper:

注册什么鬼?

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

dubbo-admin管控台

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

 

web管控台

 

小结

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

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

dubbo和Spring结合紧密,透明化的接入应用!

 

一些思考

本篇博客不可能将Dubbo全部的特性、配置都讲解完,因此这里提出一些问题,来和大家一起思考学习:

1.A服务依赖B服务,如果B服务没有启动或者禁用,A服务是否能够启动?Dubbo是否会替我们做服务依赖调用检查呢?

2.我们是否可以绕开注册中心,直接调用呢?

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

4.dubbo提供了哪些负载均衡的机制?可以具体到每一个方法么?

5.服务的调用,到了Server端,最后肯定是要走线程池进行调用的,那么我们根据不同场景可以对线程池进行定制么?


欢迎工作一到五年的Java工程师朋友们加入Java架构开发:744677563

群内提供免费的Java架构学习资料(里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码,MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料)合理利用自己每一分每一秒的时间来学习提升自己,不要再用"没有时间“来掩饰自己思想上的懒惰!趁年轻,使劲拼,给未来的自己一个交代!
 

原文链接:https://yq.aliyun.com/articles/681404
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章