目录
注意:本文参考 堂妹问我:Dubbo的服务暴露过程
URL
不过在进行服务暴露流程分析之前有必要先谈一谈 URL,有人说这 URL 和 Dubbo 啥关系?有关系,有很大的关系!
一般而言我们说的 URL 指的就是统一资源定位符,在网络上一般指代地址,本质上看其实就是一串包含特殊格式的字符串,标准格式如下:
protocol://username:password@host:port/path?key=value&key=value
Dubbo 就是采用 URL 的方式来作为约定的参数类型,被称为公共契约,就是我们都通过 URL 来交互,来交流。
你想一下如果没有一个约束,没有指定一个都公共的契约那么不同的接口就会以不同的参数来传递信息,一会儿用 Map、一会儿用特定分隔的字符串,这就是导致整体很乱,并且解析不能统一。
而用了一个统一的契约之后,那么代码就更加的规范化、形成一种统一的格式,所有人对参数就一目了然,不用去揣测一些参数的格式等等。
而且用 URL 作为一个公共约束充分的利用了我们对已有概念的印象,通俗易懂并且容易扩展,我们知道 URL 要加参数只管往后面拼接就完事儿了。
因此 Dubbo 用 URL 作为配置总线,贯穿整个体系,源码中 URL 的身影无处不在。
URL 具体的参数如下:
protocol:指的是 dubbo 中的各种协议,如:dubbo thrift http
username/password:用户名/密码
host/port:主机/端口
path:接口的名称
parameters:参数键值对
配置解析
一般常用 XML 或者注解来进行 Dubbo 的配置,我稍微说一下 XML 的,这块其实是属于 Spring 的内容,我不做过多的分析,就稍微讲一下大概的原理。
Dubbo 利用了 Spring 配置文件扩展了自定义的解析,像 dubbo.xsd 就是用来约束 XML 配置时候的标签和对应的属性用的,然后 Spring 在解析到自定义的标签的时候会查找 spring.schemas 和 spring.handlers。
spring.schemas 就是指明了约束文件的路径,而 spring.handlers 指明了利用该 handler 来解析标签,你看好的框架都是会预留扩展点的,讲白了就是去固定路径的固定文件名去找你扩展的东西,这样才能让用户灵活的使用。
我们再来看一下 DubboNamespaceHandler 都干了啥。
讲白了就是将标签对应的解析类关联起来,这样在解析到标签的时候就知道委托给对应的解析类解析,本质就是为了生成 Spring 的 BeanDefinition,然后利用 Spring 最终创建对应的对象。
服务暴露全流程
我们在深入源码之前来看下总的流程,有个大致的印象看起来比较不容易晕。
从代码的流程来看大致可以分为三个步骤(本文默认都需要暴露服务到注册中心)。
第一步是检测配置,如果有些配置空的话会默认创建,并且组装成 URL 。
第二步是暴露服务,包括暴露到本地的服务和远程的服务。
第三步是注册服务至注册中心。
从对象构建转换的角度看可以分为两个步骤。
第一步是将服务实现类转成 Invoker。
第二部是将 Invoker 通过具体的协议转换成 Exporter。
<