2024年9月dubbo注册中心(Dubbo服务注册与发现的流程)

 更新时间:2024-09-21 06:27:39

  ⑴dubbo注册中心(Dubbo服务注册与发现的流程

  ⑵Dubbo服务注册与发现的流程

  ⑶●??Provider(提供者)绑定指定端口并启动服务。●??提供者连接注册中心,并发本机IP、端口、应用信息和提供服务信息发送至注册中心存储。●??Consumer(消费者),连接注册中心,并发送应用信息、所求服务信息至注册中心。●??注册中心根据消费者所求服务信息匹配对应的提供者列表发送至Consumer应用缓存。●??Consumer在发起远程调用时基于缓存的消费者列表择其一发起调用。●??Provider状态变更会实时通知注册中心、在由注册中心实时推送至Consumer。

  ⑷Dubbo的注册中心承担着Dubbo服务的注册与发现的功能。

  ⑸Dubbo支持的注册中心主要包括:

  ⑹其中dubbo官方推荐用Zookeeper作为注册中心,下面介绍ZookeeperRegistry。

  ⑺Dubbo在Registry层实现服务的注册于发现,主要包括如下几个类:

  ⑻RegistryProtocol是对需要暴露服务到注册中心的一层封装,通过RegistryProtocol实现将暴露的服务信息注册到注册中心。

  ⑼ZookeeperRegistry是通过ZookeeperRegistryFactory创建。

  ⑽上面是AbstractRegistryFactory#getRegistry方法根据URL获取对应注册中心,真正的创建在子类的createRegistry方法中实现。

  ⑾ZookeeperTransporter才是真正与Zookeeper通信的对象。默认的Zookeeper客户端是curator。

  ⑿ZookeeperRegistry在创建时便和Zookeeper创建了连接。

  ⒀Zookeeper的服务注册就是创建Zookeeper的节点。

  ⒁根据url对象构建一个URL的Path,然后在Zookeeper上创建一个节点,节点是否是持久化的根据dynamic参数决定,true表示创建一个持久化节点,当注册方下线时,持久化节点仍然在Zookeeper上。false表示创建临时节点,当注册方下线时,会删除节点,同时通知监听节点的消费方。

  ⒂Zookeeper中的服务节点路径如Group/ServiceInterface/category/URL:

  ⒃服务下线就是把注册的节点进行删除。

  ⒄订阅有两种方式pull、push,pull是客户端定时轮询注册中心拉取配置,push是注册中心主动推送数据给客户端。dubbo是两者结合的方式进行配置的拉取,当第一次启动的时候通过客户端pull拉取所有数据方式,在订阅的节点上进行注册watcher,然后客户端与注册中心保持长连接,而后每个节点有任何数据变化,注册中心就会更新watcher情况进行回调通知到客户端,客户端就接收到这个通知了。

  ⒅服务在进行注册的时候,服务端会订阅configurators用来监听动态配置的变更。

  ⒆在消费者启动的时候,消费者会监听providers、routers、configurators来监听服务提供者、路由规则、配置变更的通知。

  ⒇取消订阅就是删除监听器。

  ⒈当与zookeeper重新连接时,需要刷新本机生产者列表,这个方法就是干这个的,它把的已订阅的列表都加入订阅失败的容器。

  ⒉addFailedSubscribed方法是FailbackRegistry将订阅失败的连接放入失败容器,FailbackRegistry有定时器会定时的处理这些失败的订阅。

  ⒊通知事件是调用的AbstractRegistry#notify方法完成。

  ⒋RegistryDirectory#notify就是更新本地缓存。

  ⒌file在AbstractRegistry对象创建的时候初始化。

  ⒍这使用了文件锁的方式保证只有一个在读写文件。

  ⒎消费者从注册中心获取注册信息后会做本地缓存。内存中也有一份,保存在Properties对象里,磁盘上也持久化一份,通过file对象进行引用。

  ⒏微服务初体验(二:使用Nacos作为配置中心并集成Dubbo

  ⒐首先启动Nacos,按照上篇文章的步骤,启动Nacos服务和项目,访问Nacos的web页面。确保项目中的服务都注册到注册中心当中了。在application.yml同级目录下添加bootstrap.yml,在Springboot项目中bootstrap.yml会比application.yml优先初始化,所以我们需要在bootstrap.yml中引入Nacos官方指定的配置文件即可(上篇文章中已经把Nacos作为配置中心的配置写入了application.yml,现在只需要把它从applicaiton.yml中剪切出来即可,其中的spring:application:name会作为Nacos中新增配置时的DataID,需要留意,再新增属性gorup进行分组测试,如下图

  ⒑接着打开Nacos的服务的web页面,打开配置管理-》配置列表,点击右侧新增按钮,进行新增。DataID:bootstrap.yml配置文件中spring:application:name对应的名称;Group:指定分组(便于不同环境下的项目配置管理,因为笔者这里属于测试,所以填写的是和上文中的配置文件中group对应的test一致;描述:针对于该配置的描述;配置格式:配置文件的格式,要和DataID中的后缀格式一致(这里笔者用的是yml,那么下面就选择yaml,注意该位置也可以选择properties,但是必须和上面bootstrap.yml文件中的file-extension的值相匹配;配置内容:具体的配置内容(这里笔者将项目中的application.yml中的配置全部拷贝至其中;

  ⒒测试启动consumer服务,在application.yml中为空的时候,项目启动端口还是如Nacos配置中的,说明项目依赖Nacos的配置中心成功,其他服务如法炮制即可:

  ⒓新增一个测试Controller,然后加上RefreshScope注解,表明该Controller中的配置数据为自动刷新。

  ⒔Nacos中的配置文件consumer新增相关参数type:test,访问Controller,返回test。效果如下图:

  ⒕将Nacos中consumer.yml文件的type:test修改为type:prod,在不重启项目的情况下重新访问对应的controller,效果如下图:

  ⒖因为Dubbo是属于各个服务之间都要公用的依赖,所以将其引入cloud-mon当中,详细的版本可以去mvnrepository搜索合适自己项目的

  ⒗引入依赖后需要编写消费者服务中的配置文件,将Dubbo服务注册至Nacos,新增如下内容,其中subscribed-services指的是生产者服务,prot:-指的是端口随机,registry:address:指的是Dubbo对应的注册中心那这里就应该设置为Nacos

  ⒘接下来新增接口服务,项目类型为Maven项目,在项目中新增一个接口。并在cloud-provider(生产者和cloud-consumer(消费者pom.xml文件中都引入该模块

  ⒙在生产者实际服务中实现该接口对应的方法

  ⒚在服务消费者的Controller中引入该Service,并在该Service上加入Reference注解,注意在引入jar包的时候选择带有Dubbo的,不要使用Jdk原生的

  ⒛编写消费者服务中测试Dubbo调用的接口,进行测试,测试结果如下图:

  Dubbo服务注册与动态发现机制的原理与实现细节

  总结一下服务注册与发现机制:基于注册中心的事件通知(订阅与发布,一切支持事件订阅与发布的框架都可以作为Dubbo注册中心的选型。、服务提供者在暴露服务时,会向注册中心注册自己,具体就是在${serviceinterface}/providers目录下添加一个节点(临时,服务提供者需要与注册中心保持长连接,一旦连接断掉(重试连接会话信息失效后,注册中心会认为该服务提供者不可用(提供者节点会被删除。、消费者在启动时,首先也会向注册中心注册自己,具体在${interfaceinterface}/consumers目录下创建一个节点。、消费者订阅${serviceinterface}/三个目录,这些目录下的节点删除、新增事件都胡通知消费者,根据通知,重构服务调用器(Invoker)。以上就是Dubbo服务注册与动态发现机制的原理与实现细节。

  springboot.x集成dubbo(支持不同group不同注册中心

  简单配置()消费者和提供者group、注册中心不同的配置dubbo的过滤器配置最后面会讲dubboServiceFilter?service注解用的是.alibaba.dubbo.config.annotation.Servicereference注解用的是.alibaba.dubbo.config.annotation.Reference

  说一下Dubbo的工作原理注册中心挂了可以继续通信吗

  答案是肯定可以的,我将从下面几点进行说明:

  dubbo的调用流程

  从源码上说明注册中心挂了还是可以继续通信的

  Provider(提供者)绑定指定端口并启动服务

  提供者连接注册中心,并发本机IP、端口、应用信息和提供服务信息发送至注册中心存储

  Consumer(消费者,连接注册中心,并发送应用信息、所求服务信息至注册中心

  注册中心根据消费者所求服务信息匹配对应的提供者列表发送至Consumer应用缓存。

  Consumer在发起远程调用时基于缓存的消费者列表择其一发起调用。

  Provider状态变更会实时通知注册中心、在由注册中心实时推送至Consumer

  这么设计的意义:Dubbo整体设计

  其协作流程如下:从源码上说明注册中心挂了还是可以继续通信的

  首先要把消费者注册到Zookeeper注册中心

  然后使用RegistryDirectory监听一下几个目录(会自动触发一次去获取这些目录上的当前数据)

  当前所引入的服务的动态配置目录:/dubbo/config/dubbo/.apache.dubbo.demo.DemoService:..:g.configurators

  比如监控providers目录:

  当有服务提供者注册,zookeeper会自动推动给订阅的消费者,然后转换为invoker存储到缓存中

  我们在看调用时的代码:

  我们看到FailoverClusterInvoker的doInvoke方法

  Invokerinvoker=select(loadbalance,invocation,copyInvokers,invoked);

  此方法根据负载均衡器去缓存中获取一个invoker,

  上面的copyInvokers就是上面我们缓存进去的List

  invokers=routerChain.route(getConsumerUrl(),invocation);

  在我们系统启动时,已经缓存了注册中心上的所有服务,后续的注册中心挂了只会影响到后续则注册,不会影响调用!

  Dubbo分布式的RPC,微服务框架,

  包括三个关键功能:基于接口的远程调用,容错与负载均衡,服务自动注册与发现。

  Dubbo使得调用远程服务就像调用本地java服务一样简单。

  参考Dubbo官方文档:包括实现细节,远程调用细节,服务提供者暴露服务。

  provider向注册中心去注册

  consumer从注册中心订阅服务,注册中心会通知consumer注册好的服务

  consumer调用provider

  consumer和provider都异步的通知监控中心

  基于zk作为注册中心:

  【提供者】在【启动】时,向注册中心zk【注册】自己提供的服务。

  【消费者】在【启动】时,向注册中心zk【订阅】自己所需的服务。

  所以是可以的,消费者在启动时,消费者会从zk拉取注册的生产者的地址接口等数据,缓存在本地。每次调用时,按照本地存储的地址进行调用,消费者本地有一个生产者的列表,他会按照列表继续工作,倒是无法从注册中心去同步最新的服务列表,短期的注册中心挂掉是不要紧的,但一定要尽快修复,挂掉是不要紧的,但前提是你没有增加新的服务,如果你要调用新的服务,则是不能办到的

  Dubbo的多注册中心配置

  最近项目中用到了Dubbo,Zookeeper,因为底层不同服务之间的调用,涉及到了不同的注册中心。由此写一下关于多注册中心的配置。SpringBoot框架:使用yml配置:dubbo:????registry:????????protocol:zookeeper????????address:****.****:|****.****:注意:|竖线分割线就是表示不同的注册中心dubbo:????registry:????????protocol:zookeeper????????address:****.****:,****.****:注意:,逗号表示同一注册中心不同的集群Springxml配置注册到不同的服务中心《dubbo:registryid=“dubbo“address=“****.****:“/》《dubbo:registryid=“dubbo“address=“****.****:“/》个人公号:【排骨肉段】,可以关注一下。

  dubbo和zookeeper

  dubbo是一个远程调用服务的分布式框架,可以实现远程通讯、动态配置、地址路由等等功能。比如在入门demo里的暴露服务,使得远程调用的协议可以使用dobbo协议()或者其它协议,可以配置zookeeper集群地址,实现软负载均衡并配置均衡方式等。在不搭配注册中心的时候,它也是可以实现服务端和调用端的通信的,这种方式是点对点通信的,所谓“没有中间商”。但是如果配置服务发布和调用端过多特别是集群的方式提供服务的时候,就会暴露许多的问题:增加节点需要修改配置文件、服务端机器宕机后不能被感知等。它可以通过集成注册中心,来动态地治理服务发布和服务调用。相当于把服务注册和发布推送的功能分摊给了(zookeeper)注册中心。

  Dubbo实现服务调用是通过RPC的方式,即客户端和服务端共用一个接口(将接口打成一个jar包,在客户端和服务端引入这个jar包),客户端面向接口写调用,服务端面向接口写实现,中间的网络通信交给框架去实现。

  咱们来看下Spring配置声明暴露服务,provider.xml文件

  再来看服务消费者,consumer.xml文件

  这就是典型的点对点的服务调用。当然我们为了高可用,可以在consumer.xml中配置多个服务提供者,并配置响应的负载均衡策略。

  配置多个服务调用者在sumer.xml的dubbo:reference标签的url属性中加入多个地址,中间用分号隔开即可;配置负载均衡策略在sumer.xml的dubbo:reference标签中增加loadbalance属性即可,值可以为如下四种类型:

  那么目前的架构有什么问题呢?.当服务提供者增加节点时,需要修改配置文件。.当其中一个服务提供者宕机时,服务消费者不能及时感知到,还会往宕机的服务发送请求。

  这个时候就需要引入注册中心了,Dubbo目前支持种注册中心(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是ApacaheHadoop的子项目,是一个树型的目录服务,支持变更推送,适合作为Dubbo服务的注册中心,工业强度较高,可用于生产环境,并推荐使用。

  补充:dubbo的协议使用什么序列化框架?dubbo有多种协议,不同的协议默认使用不同的序列化框架。比如dubbo协议默认使用Hessian序列化(说明:Hessian是阿里在Hessian基础上进行的二次开发,起名为Hessian)。rmi协议默认为java

  Dubbo的简要执行流程

  服务器启动,运行服务提供者。.服务提供者在启动时,向注册中心(zookeeper)注册自己提供的服务。.服务消费者在启动时,向注册中心订阅自己所需的服务。.注册中心返回服务提供者地址列表给消费者,(若有变更,注册中心将基于长连接推送变更数据给消费者).服务的消费者,从地址列表中,基于负载均衡,选一台提供者的服务器进行调用,若是失败,在从地址列表中,选择另一台调用..期间Dubbo的监控中心,会记录定时消费者和提供者,的调用次数和时间.

您可能感兴趣的文章:

相关文章