分布式服务治理框架Dubbo

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分布式服务治理框架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端,最后肯定是要走线程池进行调用的,那么我们根据不同场景可以对线程池进行定制么?





本文出自 “学海无涯 心境无限” 博客,请务必保留此出处http://zhangfengzhe.blog.51cto.com/8855103/1931170

以上是关于分布式服务治理框架Dubbo的主要内容,如果未能解决你的问题,请参考以下文章

分布式服务治理框架Dubbo

Dubbo

谈谈分布式服务治理框架 Dubbo的重大升级

励精图治:Dubbo分布式服务治理

分布式RPC框架Dubbo实现服务治理:集成Kryo实现高速序列化,集成Hystrix实现熔断器

Dubbo:来自于阿里巴巴的分布式服务框架