dubbozookeeper(dubbozookeeper配置)
本篇文章给大家谈谈dubbozookeeper,以及dubbozookeeper配置对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
本文目录一览:
- 1、dubbo和zookeeper的关系
- 2、Dubbo与Zookeeper集群配置
- 3、Dubbo + Zookeeper 浅析
- 4、dubbo和zookeeper
- 5、zookeeper在Dubbo中扮演了一个什么角色,起到了什么作用
- 6、dubbo中为什么要用zookeeper
dubbo和zookeeper的关系
如果不用zk,你去调用rpc的时候你就得知道对方的地址,这样如果以后对方部署的服务器变了,你那边也得跟着芹悔改,就耦合了,如果加入zk,对方把服务注册到zk上,你只要通过zk获取就行了,别人变了ip也不会影响你。zk在dubbo中肆首液就是用来进行服务注册的,dubbo也支持用redis进行服务注册
Dubbo建议使用Zookeeper作为服务注册中心。
dubbo和zookeeper的关系1
dubbo和zookeeper的关裂物系2
[img]Dubbo与Zookeeper集群配置
dubbo.properties配置:
dubbo.application.name=sdp_order_srv
#zk集群的时候dubbo只能这样配置
dubbo.service.register.address=zookeeper://10.10.100.152:3181?backup=10.10.100.152:4181,10.10.100.152:5181
#zk单点的话下面两种简辩配置都可乎念以
#dubbo.service.register.address=zookeeper:/拦顷缺/${zookeeper.address}
#dubbo.service.register.address=zookeeper://10.1.203.171:2181
dubbo.service.protocol.name=dubbo
dubbo.service.protocol.port=20885
zk配置
#\u7cfb\u7edf\u53c2\u6570\u914d\u7f6e
zookeeper.sessionTimeout=60000
zookeeper.connectionTimeout=5000
#zk集群配置
zookeeper.address=10.10.100.152:3181,10.10.100.152:4181,10.10.100.152:5181
zookeeper.connect.status=true
zookeeper.connect.countersign=false
zookeeper.connect.username=
zookeeper.connect.password=
Dubbo + Zookeeper 浅析
Dubbo + zookeeper 是现在比较流行的架构,也是我们行部分系统正在使用的架构,例如支撑平台。下面就介绍一下为什么要使用这个架构和这个架构的工作流程。
Dubbo使用registry进行服务注册和订阅,当我们新增生产者服务时,只需要向注册中心注册便可,不同以往,需要修改消费者的配置文件才可以实现集群的扩展。
对于开发者来说,通过dubbo的框架,消费者和生产贺伍铅者在使用或提供服务时,只需要在配置文件里声明要使用或提供的服务,配上注册中心的配置,便可以使用和调用对应的服务,因此在消费者一侧,无需关心要调用哪台服务器的服务,IP、URL等等信息,调用远程接口的时候也不用像传统的new一个httpclient,然后输入url这样去调用,直接像调用本地接口一样,提高了开发的效率
对于开发者来说,通过dubbo的框架,消费者和生产者在使用或提供服务时,只需要在配置文件里声明要使用或提供的服务,配上注册中心的配置,便可以使用和调用对应的服务,因此在消费者一侧,无需关心要调用哪台服务器的服务,IP、URL等等信息,调用远程接口的时候也不用像传统的new一个httpclient,然后输入url这样去调用,直接像调用本地接口一样,提高了开发的效率
一个RPC调用服务的工作流程:
可能有人会问,这么多的工作流程,http调用不香么?其实各有各的优点。HTTP调用,每次都会建立一次TCP连接,三次握手四次分手,像平时网银微信的服务器,访问的人多了,就出现很多ESTABLISHED和TIME_WAIT状态的连接,EST状态的连接就不说了,肯定会占用比较多的带宽资源,而TIMEWAIT状态的也会占用一定的资源去等待握手结束。这样对于应用性能和环境资源都不太友好。
而RPC调用通过两边stub进行通讯,这两个相当于一个代理,建立一次TCP连接,每次TCP连接可调用多个接口,这样不仅提高了应用程序的性能,还减少了网络资源的负担。
RPC调用与传统的HTTP调用不同有以下优点:
从上面的分析应该禅好可以得出,zookeeper不是dubbo必须的,只是zookeeper暴露的接口和内部机制比较适合作为dubbo的注册中心。
那么zookeeper作为dubbo的注册中心做了什么呢?引用dubbo的架构图,zookeeper做了以下三个步骤:
1. register(服务注册)
2. subscribe(订阅)
3. notify(通知)
这三个步骤主要调用了zookeeper提供的两种接口:
创建节点
zookeeper提供了两种节点,一种是持久节点,一种是临时节点,而dubbo注册服务其实就是在zookeeper上面创建一个节点,然后利用临时节点的特性,当生产者服务器崩溃时,不能提供服务,与zookeeper的连接断开会话结束,就会销毁创建的临时节点,也就是注销服务。这样消费者就不会调用崩溃的服务器的接口。这里可以试着在生产者的服务器上,用防火墙屏蔽橘旁其应用端口的出局,模拟应用程序的崩溃,这是监视zookeeper的节点数量,就会发现其节点的数量相比之前减少了,也就是所谓的临时节点被销毁了。
设置监视器
设置监视器的接口实现了订阅和通知,dubbo消费者端在zookeeper的节点上,对需要订阅的服务(也就是一个节点)设置一个监视器
dubbo和zookeeper
dubbo 是一个远程调用服务的分布式框架,可以实现远程通讯、动态配置、地址路由等等功能。比如在入门demo里的暴露服务,使得远程调用的协议可以使用dobbo协议( dubbo://x.x.x.x )或者其它协议,可以配置zookeeper集群地址,实现软负载均衡并配置均衡方式等。在不搭配注册中心的时候,它也是可以实现服务端和调用端的通信的,这种方式是点对点通信的,所谓“没有中间商”。但是如果配置服务发布和调用端过多特别是集群的方式提供服务的时候,就会暴露许多的问题:增加节点需要修改配置文件、服务端机器宕机后不能被感知等。它可以通过集成注册中心,来动态地治理服务发布和服务调用。相当于把服务注册和发布推送的功能分摊给了(zookeeper)注册中心。
Dubbo实现服务调用是通过RPC的方式,即客户端和服务端共用一个接口(将接口打成一个jar包,在客户端和服务端引入这个jar包),客户端面向接口写调用,服务端面向接口写实现,中间的网络通信交给框架去实现。
咱们来看下Spring 配置声明暴露服务,provider.xml文件
再来看服务消费者,consumer.xml文件
这就是典型的点对点的服务调用。当然我们为了高可用,可以在consumer.xml中配置多个服务提供者,并配置响应的负载均衡策略。
配置多个服务调用者在comsumer.xml的dubbo:reference标签的url属性中加入多个地址,中间用分号隔开即可;配置负载均衡策略在comsumer.xml的dubbo:reference标签中增加loadbalance属性即可,值可以为如下四种类型:
那么目前的架构有什么问题呢?
1.当服务提供者增加节点时,需要修改配置文件。
2.当其中一个服务提供者宕机时,服务消费者不能及时感知到,还会往宕机的服务发送请求。
这个时候就需要引入注册中心了,Dubbo目前支持4种注册中心(multicast、zookeeper、redis、simple)推荐使用Zookeeper注册中心,要使用注册中心,只需要将provider.xml和consumer.xml更改为如下:
如果zookeeper是一个集群,则多个地址之间用逗号分隔即可
把consumer.xml中配置的直连的方式去掉
注册信息在zookeeper中如何保存?
启动上面服务后,我们观察zookeeper的根节点多了一个dubbo节点及其他,图示如下
最后一个节点中服务的地址,为什么把最后一个节点标成绿色?因为最后一个节点是肢竖临时节点,而其他节点是持久节点,这样,当服务宕机时,这个节点就会自动消失,不再提供服务,服务消费者也不会再请求。如果部署多个DemoService,则providers下面会有好几个节点,一个节点保存一个DemoService的服务地址。
其实一个zookeeper集群能被多个应用公用,因为不同的框架会在zookeeper上建不同的节点,互不影响。如dubbo会创建一个/dubbo节点,storm会创建一个/storm节点。
zookeeper 介绍:
zookeeper是 Apacahe Hadoop 的子项目,是一个树型的目录服务,支持变更推送,适合作为 Dubbo 服务的注册中心,工业强度较高,可用于生产环境,并推荐使用尘饥历。
流程说明:
支持以下功能:
补充:
dubbo的协议使用什么序列化框架?
dubbo有多种协议,不同的协议默认使用不同的序列化框架。比如dubbo协议默认使用 Hessian2 序列化(说明:Hessian2 是阿里在 Hessian 基础上进派搜行的二次开发,起名为Hessian2)。rmi协议默认为 java 原生序列化,http协议默认为为 json。
dubbo的通信方式?
采用单一长连接和NIO异步通信,基于Hessian2作为序列化协议。适合于小数据量(每次请求在100kb以内)大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。具体实现是消费者使用 NettyClient,提供者使用 NettyServer,Provider 启动的时候,会开启端口监听,使用我们平时启动 Netty 一样的方式。而 Client 在 Spring getBean 的时候,会创建 Client,调用远程方法的时候,将数据通过DubboCodec编码发送到 NettyServer,然后 NettServer 收到数据后解码,并调用本地方法,并返回数据,完成一次完美的 RPC 调用。
zookeeper选举机制?
zookeeper选举算法默认的是FastLeaderElection,选举机制的概念:
1.服务器ID:比如有三台服务器,编号分别是1、2、3,编号越大在选择算法中的权重越大。
2.事务ID:服务器中存放的最大数据ID(致使ZooKeeper节点状态改变的每一个操作都将更新事务id,即时间戳),值越大说明数据越新,在选举算法中数据越新权重越大。
3.逻辑时钟,或者叫投票的次数,同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加,然后与接收到的其它服务器返回的投票信息中的数值相比,根据不同的值做出不同的判断。
选举状态:LOOKING:竞选状态;FOLLOWING:随从状态,同步leader状态,参与投票;OBSERVING:观察状态,同步leader状态,不参与投票;LEADING:领导者状态。
初次选举简述:
目前有5台服务器,每台服务器均没有数据,它们的编号分别是1,2,3,4,5,按编号依次启动,它们的选择举过程如下:
1.服务器1启动,给自己投票,然后发投票信息,由于其它机器还没有启动所以它收不到反馈信息,服务器1的状态一直属于Looking。
2.服务器2启动,给自己投票,同时与之前启动的服务器1交换结果,由于服务器2的编号大所以服务器2胜出,但此时投票数没有大于半数,所以两个服务器的状态依然是LOOKING。
3.服务器3启动,给自己投票,同时与之前启动的服务器1,2交换信息,由于服务器3的编号最大所以服务器3胜出,此时投票数为3正好大于半数,所以服务器3成为领导者,服务器1,2成为小弟。
4.服务器4启动,给自己投票,同时与之前启动的服务器1,2,3交换信息,尽管服务器4的编号大,但之前服务器3已经胜出,所以服务器4只能成为小弟。
5.服务器5启动,后面的逻辑同服务器4成为小弟。
如果中间有节点挂掉,只要有半数以上节点存活,就可以正常服务,如果leader挂掉,则所有节点处于Looking状态 ,各自依次发起投票,投票包含自己的服务器ID和最新事务ID,如果发现别人的事务id比自己大,也就是数据比自己新,那么就重新发起投票,投票给目前已知最大的事务id所属节点(事务id一样,则数据id大的胜出)。每次投票后,服务器都会统计投票数量,判断是否有某个节点得到半数以上的投票。如果存在这样的节点,该节点将会成为准Leader,状态变为Leading。其他节点的状态变为Following。
引用:
zookeeper在Dubbo中扮演了一个什么角色,起到了什么作用
zookeeper是Dubbo服务的注册中心,provider提供服务后注册在zookeeper上, consumer可以接口和版本信息从zookeeper中烂丛获取相应的服务,服务对于consumer来说完全透明,根本感知不到该接口是来自本地和provider,就像引用本地的一个bean一样。饥侍樱 zookeeper可以实现服务的分布式,同时可以监控每谈核个服务的状态以及调用次数情况等。 希望可以帮助到您!
dubbo中为什么要用zookeeper
本笑历文内容并非原创,使用资料均来自互联网雀升汪。 dubbo使用了zkClient而不是使用zookeeper本身顷仔的客户端与zookeeper进行交互,为什么呢? 先看看zookeeper本身自带的客户端的问题。 1 ) ZooKeeper的Watcher是一次性的,用过了需要再注册; 2 ) sessi
关于dubbozookeeper和dubbozookeeper配置的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。