分布式服务治理框架Dubbo

  1. 云栖社区>
  2. 博客>
  3. 正文

分布式服务治理框架Dubbo

科技小先锋 2017-11-15 21:57:00 浏览1013
展开阅读全文

前言

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

为什么需要Dubbo?

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

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

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

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


Dubbo是什么?

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

Dubbo的架构:

wKiom1ku1-Pi5h7pAAExunnyfM8634.png

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

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

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

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


QuickStart 

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

商品服务:ProductService

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

wKioL1ku2LPh05maAABl1QV4LHY275.png

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

wKioL1ku2N2yXlt8AAAyi7ilS7k520.png

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

wKiom1ku2QqwLKorAAAUxpo9MW8091.png

wKiom1ku2SrxyHgEAAApncbDOoQ324.png

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

wKioL1ku2VvDBQlGAAC2uWfTaaY926.png

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

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

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

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

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


启动商品服务:

wKioL1ku2YzTrgahAAAYM3VPUO0377.png

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

我们稍微来看一看源码:

wKiom1ku2bSQ9332AAAdgoKHEds952.png

看SpringContainer如何启动:

wKiom1ku2duD-mvHAABGPx1-B2g306.png

wKiom1ku2fjDeQqAAAAbrPeDDNY772.png

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

订单服务:OrderService

先看依赖:

wKiom1ku2iOxzVpcAABazSN-9DE767.png

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

看dubbo配置:

wKioL1ku2lGjlFkZAAA-jnBkfJc640.png

消费者启动:

wKioL1ku2nzwKMxpAABF5a4juMo704.png

消费者运行结果:

wKiom1ku2sbDx_e5AAAwS67J1WQ538.png


看Zookeeper:

wKiom1ku2ubQHajLAAAoVW4sQUQ791.png


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


dubbo-admin管控台

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

wKiom1ku2x_gMWbsAADkElIoVTQ026.png


小结

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

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

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


一些思考

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

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

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

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

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

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


本文转自zfz_linux_boy 51CTO博客,原文链接:http://blog.51cto.com/zhangfengzhe/1931170,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
科技小先锋
+ 关注