成都创新互联网站制作重庆分公司

分布式服务治理框架Dubbo-创新互联

前言

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

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

分布式服务治理框架Dubbo

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

分布式服务治理框架Dubbo

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

分布式服务治理框架Dubbo

分布式服务治理框架Dubbo

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

分布式服务治理框架Dubbo

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

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

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

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

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

启动商品服务:

分布式服务治理框架Dubbo

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

我们稍微来看一看源码:

分布式服务治理框架Dubbo

看SpringContainer如何启动:

分布式服务治理框架Dubbo

分布式服务治理框架Dubbo

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

订单服务:OrderService

先看依赖:

分布式服务治理框架Dubbo

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

看dubbo配置:

分布式服务治理框架Dubbo

消费者启动:

分布式服务治理框架Dubbo

消费者运行结果:

分布式服务治理框架Dubbo

看Zookeeper:

分布式服务治理框架Dubbo

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


dubbo-admin管控台

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

分布式服务治理框架Dubbo


小结

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

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

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

一些思考

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

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

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

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

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

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

另外有需要云服务器可以了解下创新互联cdcxhl.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。


本文名称:分布式服务治理框架Dubbo-创新互联
分享网址:http://cxhlcq.com/article/dhsjio.html

其他资讯

在线咨询

微信咨询

电话咨询

028-86922220(工作日)

18980820575(7×24)

提交需求

返回顶部