十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
Dubbo是一个被国内很多互联网公司广泛使用的开源分布式服务治理框架,是一个非常全面的SOA基础框架,当当网在Dubbo基础上新增了一些功能,并将其命名为Dubbox(Dubbo eXtensions)。
成都创新互联公司主营北戴河网站建设的网络公司,主营网站建设方案,重庆APP软件开发,北戴河h5成都微信小程序搭建,北戴河网站营销推广欢迎北戴河等地区企业咨询
为什么需要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,说了一些理论,咱们快速开始吧!
这里我将为大家演示一个订单服务调用商品服务的Demo。
我们先来看看商品服务的工程结构:
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,到这里,商品服务已经就绪了!
先看依赖:
注意订单服务需要依赖product-api。
看dubbo配置:
消费者启动:
消费者运行结果:
看Zookeeper:
在Zookeeper中看得很清楚,接口将以目录节点的形式创建,providers下面就是接口协议,分机器,分协议,从而可以实现负载均衡!
如同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端,最后肯定是要走线程池进行调用的,那么我们根据不同场景可以对线程池进行定制么?