一、整体设计
dubbo整体设计以及调用用链路参照官网  1、注册中心参照官网   2、zk注册中心详解
2.1、目录结构
+- dubbo
+- com.demo.service.HelloService+- consumers
+- consumer://192.168.1.102/com.demo.service.HelloService?application=dubbo-demo-annotation-consumer&category=consumers&check=false&dubbo=2.0.2&init=false&interface=com.lagou.service.HelloService***
+- providers
+- dubbo://192.168.1.102:20880/com.demo.service.HelloService?anyhost=true&application=dubbo-demo-annotation-provider&deprecated=false&dubbo=2.0.2*** +- configuration +- routers解释: (1)、在服务启动的时候dubbo会在zk的根目录下创建一个dubbo的目录 (2)、dubbo跟节点下面是当前所拥有的接口名称,如果有多个接口,则会以多个子节点的形式展开 (3)、每个服务下面又分别有四个配置项 1)、consumers: 当前服务下面所有的消费者列表(URL) 2)、providers: 当前服务下面所有的提供者列表(URL) 3)、confifiguration: 当前服务下面的配置信息信息,provider或者consumer会通过读取这里的配置信息来获取配置 4)、routers: 当消费者在进行获取提供者的时,会通过这里配置好的路由来进行适配匹配规则 2.2、dubbo中的url 从2.1中咱们不难发现,无论是服务提供者还是服务消费者,在注册中心zk中都是以url的形式进行保存以便进行资源定位,所以咱们来具体看一下dubbo中的url 规则:protocol://host:port/path?key=value&key=value 例子:参考2.1中的目录结构中的consumer或者producer (1)、对应源码(构造方法)
(2)、主要组成部分
1)、protocol: 协议,一般像我们的 provider 或者 consumer 在这里都是人为具体的协议
2)、host: 当前 provider 或者其他协议所具体针对的地址,比较特殊的像 override 协议所指定的host就是 0.0.0.0 代表所有的机器都生效
3)、port: 和上面相同,代表所处理的端口号 4)、path: 服务路径,在 provider 或者 consumer 等其他中代表着我们真实的业务接口 5)、key=value: 这些则代表具体的参数,这里我们可以理解为对这个地址的配置。比如我们 provider中需要具体机器的服务应用名,就可以是一个配置的方式设置上去 (3)、dubbo中的URL与JAVA中的URL的区别 1)、dubbo中的URL支持参数的动态增减
2.3、服务本地缓存
从上面两张图我们可以看到,服务提供者在启动的时候会主动将自己提供的服务注册到注册中心中,而服务消费者在启动的时候也会去注册中心中获取自己引用的服务列表到本地并保存到文件中,而且需要订阅对应的服务提供者节点。当服务提供者有信息变更的时候消费者会收到节点变更通知,进而获取最新服务列表跟新本地缓存文件。
Dubbo在服务引用过程中会创建registry对象并加载本地缓存文件,会优先订阅注册中心,订阅注册中心失败后会访问本地缓存文件内容获取服务提供信息 下面我们来看一下具体的源码 1)、顶级接口 org.apache.dubbo.registry.Registry可以看到其中就提供了两个方法1、注册;2、注销。
org.apache.dubbo.registry.RegistryService 这个类主要是对指定的路径进行注册,注销,监听和取消监听,查询操作。也是注册中心中最为基础的类
AbstractRegistry 是对注册中心的封装,其主要会对本地注册地址的封装,主要功能在于远程注册中心不可用的时候,可以采用本地的注册中心来使用
FailbackRegistry 失败自动恢复,后台记录失败请求,定时重发功能接下来我们来看一下他的实现类org.apache.dubbo.registry.support.AbstractRegistry#AbstractRegistry的构造方法的具体实现
其实这里主要做的就是把url缓存到本地文件中
2.4、服务注册过程分析
1、服务注册时序图
2、服务注册过程
说明:服务注册过程大致可以分为两个过程1、具体某个服务转换为Invoker,2、invoker转换成exporter
从上面两张图可以看出dubbo先从 ServiceConfig 类拿到对外提供服务的实际类 ref(如:HelloServiceImpl),然后通过ProxyFactory 接口实现类中的 getInvoker 方法使用 ref 生成一个 AbstractProxyInvoker 实例,到这一步就完成具体服务到 Invoker 的转化。接下来就是 Invoker 转换到 Exporter 的过程接下来我们重点看一下ServiceConfig中的ProxyFactory 和 Protocol 以及 ref 属性
接下来我们再看一下协议接口
可以看到协议顶级接口中提供了暴露和引用服务的接口它有很多实现类,而我们注册使用的是org.apache.dubbo.registry.integration.RegistryProtocol
接下来我们看一下如何将一个ServiceConfig转换成invoker由于方法较长就不详细截图了
org.apache.dubbo.config.ServiceConfig#export
org.apache.dubbo.config.ServiceConfig#doExport
org.apache.dubbo.config.ServiceConfig#doExportUrls
org.apache.dubbo.config.ServiceConfig#doExportUrlsFor1Protocol
接下来我们再回头看看org.apache.dubbo.registry.integration.RegistryProtocol#export这个方法
这个方法呢主要做了5件事
1、获取注册中心的url:zookeeper://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=***
2、获取服务提供者的url: dubbo://192.168.1.102:20880/com.demo.service.HelloService?anyhost=**
3、获取注册中心
4、将服务提供者注册到注册中心中
5、返回暴露的对象
接下来我们再看一下org.apache.dubbo.registry.integration.RegistryProtocol.DestroyableExporter类
他主要提供了一个获取invoker的方法
我们再看一下注册方法
可以看到这里使用的是工厂模式获取的具体工厂,接下来我们再看一下注册中心的工厂接口
org.apache.dubbo.registry.RegistryFactory 是注册中心工厂,通过这种方式,也可以保证一个应用中可以使用多个注册中心。可以看到这里也是通过不同的protocol参数,来选择不同的协议
接下来我们看一下org.apache.dubbo.registry.support.FailbackRegistry#register
这里主要做了三件事情
1、把当前url放入到已经注册的列表中
2、处理注册失败的url
3、真正处理当前url的注册
我们再看看真正处理当前url的注册方法就会发现这是一个模板方法,需要子类去提供具体实现
既然dubbo默认使用zk为注册中心,那咱们就再看看zk的实现
看到这里,服务注册的流程就ok了。
原文转载:http://www.shaoqun.com/a/480927.html
易麦:https://www.ikjzd.com/w/2048
贝恩:https://www.ikjzd.com/w/1336
imgur:https://www.ikjzd.com/w/156
一、整体设计 dubbo整体设计以及调用用链路参照官网  1、注册中心参照官网  2、zk注册中心详解 2.1、目录结构 +-dubbo +-com.demo.service.HelloService +-consumers +-consumer://192.168.1.102/com.demo.service.Hello
美森:https://www.ikjzd.com/w/1693
rfq:https://www.ikjzd.com/w/251
从关键词起步爆单难不难?Amazon的流量来源根据分析:https://www.ikjzd.com/tl/4444
美股狂跌500点!特朗普又不高兴了!:https://www.ikjzd.com/home/103039
从选品到供应商的选择,卖家需要考虑哪些维度?:https://www.ikjzd.com/home/112588
No comments:
Post a Comment