dubbo 源码之启动过程分析

阅读数:73 2019 年 9 月 25 日 00:00

dubbo源码之启动过程分析

Apache Dubbo™ (incubating) 是一款高性能 Java RPC 框架。在平常业务开发过程中使用的越来越频繁, 同时也会遇到更多的问题。这就需要我们更多的了解一下 dubbo 源码,以便更好的处理问题。

看源码的话就会直面一个棘手的问题:不知道从哪下手,找不到切入点。所以,本文准备就 dubbo 的启动过程做一下宏观的流程分析,希望对大家有所帮助。

问题引入

用过 dubbo 的同学都知道,我们只需要在 xml 文件中配置 zk、协议、要暴露的服务等信息,发布 jar 包、然后启动 spring。我们的服务就可以被调用了。如下,我们暴露了 HelloService。启动 spring 就可以被远程调用了:

复制代码
1<dubbo:service interface="com.alibaba.dubbo.demo.hello.HelloService" ref="helloService" timeout="300" ></dubbo:service>

直入主题

那么在 spring 容器启动的过程中,都做了什么操作才使我们的服务可以暴露出去呢?为什么 dubbo 是透明化接入应用,对应用没有任何 API 侵入的呢?

Spring 可扩展 Schema 的支持

Spring 框架从 2.0 版本开始,提供了基于 Schema 风格的 XML 扩展机制,允许开发者扩展最基本的 spring 配置文件,这样我们就可以编写自定义的 xml bean 解析器然后集成到 Spring IoC 容器中。

也就是说利用这个机制就可以把我们在 xml 文件中配置的东西实例化成对象。
使用这种机制需要通过以下几步:

  • 设计配置属性和 JavaBean
  • 编写 XSD 文件
  • 编写 NamespaceHandler 和 BeanDefinitionParser 完成解析工作
  • 编写 spring.handlers 和 spring.schemas 串联起所有部件

接着我们以 dubbo 的 provider 为例开始分析:

复制代码
1<dubbo:provider registry="test_zk" version="1.0.0" iothreads="300" retries="0"/>
spring 启动过程中会去扫描 META-INF/spring.schemas,拿到 dubbo 的扩展配置,然后根据配置找到 META-INF/dubbo.xsd 文件。

1http://dubbo.apache.org/schema/dubbo/dubbo.xsd=META-INF/dubbo.xsd
至于 spring 为什么会扫面 META-INF/spring.schemas 目录呢?答案在 PluggableSchemaResolver.java 中。

复制代码
1public class PluggableSchemaResolver implements EntityResolver {
2 public static final String DEFAULT_SCHEMA_MAPPINGS_LOCATION = "META-INF/spring.schemas";
3 private static final Log logger = LogFactory.getLog(PluggableSchemaResolver.class);
4 private final ClassLoader classLoader;
5 private final String schemaMappingsLocation;
6 private volatile Map<String, String> schemaMappings;
7
8 public PluggableSchemaResolver(ClassLoader classLoader) {
9 this.classLoader = classLoader;
10 this.schemaMappingsLocation = "META-INF/spring.schemas";
11 }
12}

dubbo.xsd 文件中定义了我们 Bean 的标签,和 Bean 中定义的字段一一对应的;
这一步 spring 会把 dubbo.xsd 文件解析成 Dom 树,在解析的自定义标签的时候, spring 会根据标签的命名空间和标签名找到一个解析器。

dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析dubbo源码之启动过程分析

provider

这个命名空间就是 targetNamespace。拿到这个参数去扫面 META-INF/spring.handlers。拿到 dubbo 配置的 handler 路径:

复制代码
1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
2<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
3 xmlns:beans="http://www.springframework.org/schema/beans"
4 xmlns:tool="http://www.springframework.org/schema/tool"
5 xmlns="http://dubbo.apache.org/schema/dubbo"
6 targetNamespace="http://dubbo.apache.org/schema/dubbo">
复制代码
1 http\://dubbo.apache.org/schema/dubbo=com.alibaba.dubbo.config.spring.schema.DubboNamespaceHandler

这样就找到了 DubboNamespaceHandler, 由该解析器来完成对该标签内容的解析,并返回一个 BeanDefinition 。

复制代码
1public class DubboNamespaceHandler extends NamespaceHandlerSupport {
2 public DubboNamespaceHandler() {
3 }
4
5 public void init() {
6 this.registerBeanDefinitionParser("application", new DubboBeanDefinitionParser(ApplicationConfig.class, true));
7 this.registerBeanDefinitionParser("module", new DubboBeanDefinitionParser(ModuleConfig.class, true));
8 this.registerBeanDefinitionParser("registry", new DubboBeanDefinitionParser(RegistryConfig.class, true));
9 this.registerBeanDefinitionParser("monitor", new DubboBeanDefinitionParser(MonitorConfig.class, true));
10 this.registerBeanDefinitionParser("provider", new DubboBeanDefinitionParser(ProviderConfig.class, true));
11 this.registerBeanDefinitionParser("consumer", new DubboBeanDefinitionParser(ConsumerConfig.class, true));
12 this.registerBeanDefinitionParser("protocol", new DubboBeanDefinitionParser(ProtocolConfig.class, true));
13 this.registerBeanDefinitionParser("service", new DubboBeanDefinitionParser(ServiceBean.class, true));
14 this.registerBeanDefinitionParser("reference", new DubboBeanDefinitionParser(ReferenceBean.class, false));
15 this.registerBeanDefinitionParser("annotation", new AnnotationBeanDefinitionParser());
16 }
17
18 static {
19 Version.checkDuplicate(DubboNamespaceHandler.class);
20 }

在这个过程中就会把 dubbo 自定义的 schema 配置初始化成 Bean 对象,并维护在 spring 容器中。
(深入了解 schema 机制,可参考: https://docs.spring.io/spring/docs/4.2.x/spring-framework-reference/html/xsd-configuration.html)

spring 事件机制

dubbo 使用到的配置信息都已经托管在 spring 容器中了,服务又是怎么暴露的呢?万事俱别,只欠东风,此时就需要一个触发 dubbo 服务启动的事件。

因为是和 spring 整合的,我们就直接定位到 dubbo-config-spring 目录下,定位发现一个类 ServiceBean。其实如果仔细留意一下 dubbo 的启动日志, 通过文本搜索也是可以快速定位到这个类的。

dubbo源码之启动过程分析
dubbo源码之启动过程分析

日志

看一下它的继承体系, 它继承了 ApplicationListener. 这个就是 spring 的事件机制,spring 容器初始化完成之后就会触发 ServiceBean 的 onApplicationEvent 方法。这个就是整个 dubbo 服务启动的入口了。

dubbo源码之启动过程分析

继承体系
``` 1public void onApplicationEvent(ApplicationEvent event) { 2 if (ContextRefreshedEvent.class.getName().equals(event.getClass().getName())) { 3 if (isDelay() && ! isExported() && ! isUnexported()) { 4 if (logger.isInfoEnabled()) { 5 logger.info("The service ready on spring started. service: " + getInterface()); 6 } 7 export(); 8 } 9 } 10 } ``` ### 服务暴露 从 export() 方法开始,才真正进入了 dubbo 的服务暴露流程,在这个过程中就会涉及到多协议暴露服务、注册 zk、暴露本地和远程服务,获取 invoker,将 invoker 转化成 exporter 等一系列操作。如同官方提供的那样:

dubbo源码之启动过程分析

服务暴露

接着会到 ServiceConfig.export() 方法,这里面涉及到 dubbo 服务延迟暴露的一个点,delay 这个参数可以配置在或者中,目的是为了延迟注册服务时间 (毫秒) ,设为 -1 时,表示延迟到 Spring 容器初始化完成时暴露服务。一些特殊的场景,可以通过修改该参数来解决服务刚启动接口响应较慢的案例。

dubbo源码之启动过程分析

delay

ServiceConfig.doExport() 主要是做一些合法性的校验工作:

  • application&registry&protocol 等有效性检查;
  • 中配置的 interface 合法性检查: 接口不能为空, 检查接口类型必需为接口,检查方法是否在接口中存在(checkInterfaceAndMethods);
  • 检查 xml 配置中 interface 和 ref 是否匹配(interfaceClass.isInstance(ref));
  • 有效性检查通过后,调用 doExportUrls() 发布 dubbo 服务。

在 ServiceConfig.doExportUrls() 方法,这里会进行多协议暴露服务,由于 dubbo 不仅支持 dubbo 协议同时还支持 http、webservice、thrift 等协议。如果我们配置的 service 需要同时提供多种服务,那么会根据不同的协议进行循环暴露。

复制代码
1<dubbo:service interface="com.alibaba.dubbo.demo.hello.HelloService" ref="helloService" timeout="300" protocol="dubbo"></dubbo:service>
2<dubbo:service interface="com.alibaba.dubbo.demo.hello.HelloService" ref="helloService" timeout="300" protocol="http"></dubbo:service>

dubbo源码之启动过程分析

protocol

在 doExportUrlsFor1Protocol 中会把所有的相关属性封装到 Map 中,构造 dubbo 定义的统一数据模型 URL, 这个 url 会贯穿服务暴露和调用的整个流程。

复制代码
1 URL url = new URL(name, host, port, (contextPath == null || contextPath.length() == 0 ? "" : contextPath + "/") + path, map);

接着是根据参数 scope 判断服务的发布范围。服务的发布范围分为不暴露、本地暴露、远程暴露。

scope 的配置规则如下:

  • 如果配置 scope=none, 不发布这个 dubbo 服务;
  • 如果配置 scope=local,只本地暴露这个 dubbo 服务;
  • 如果配置 remote,只远程暴露这个 dubbo 服务;
  • 如果不配置或者不为以上三种,既暴露本地服务,又暴露远程服务;
复制代码
1 // 配置为 none 不暴露
2 if (! Constants.SCOPE_NONE.toString().equalsIgnoreCase(scope)) {
3 if (!Constants.SCOPE_REMOTE.toString().equalsIgnoreCase(scope)) {
4 exportLocal(url);
5 }
6 if (! Constants.SCOPE_LOCAL.toString().equalsIgnoreCase(scope) ){
7 if (logger.isInfoEnabled()) {
8 logger.info("Export dubbo service " + interfaceClass.getName() + " to url " + url);
9 }
10 if (registryURLs != null && registryURLs.size() > 0
11 && url.getParameter("register", true)) {
12 for (URL registryURL : registryURLs) {
13 url = url.addParameterIfAbsent("dynamic", registryURL.getParameter("dynamic"));
14 URL monitorUrl = loadMonitor(registryURL);
15 if (monitorUrl != null) {
16 url = url.addParameterAndEncoded(Constants.MONITOR_KEY, monitorUrl.toFullString());
17 }
18 if (logger.isInfoEnabled()) {
19 logger.info("Register dubbo service " + interfaceClass.getName() + " url " + url + " to registry " + registryURL);
20 }
21 Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.toFullString()));
22
23 Exporter<?> exporter = protocol.export(invoker);
24 exporters.add(exporter);
25 }
26 } else {
27 Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, url);
28
29 Exporter<?> exporter = protocol.export(invoker);
30 exporters.add(exporter);
31 }
32 }
33 }

那么为什么会有本地暴露呢?因为在 dubbo 中我们一个服务可能既是 Provider,又是 Consumer,因此就存在他自己调用自己服务的情况,如果再通过网络去访问,就会白白增加一层网络开销。所以本地暴露和远程暴露的区别如下:

  • 本地暴露是暴露在 JVM 中,不需要网络通信;
  • 远程暴露是将 ip、端口等信息暴露给远程客户端, 调用时需要网络通信。

本地暴露服务的时候 url 是以 injvm 开头的,而远程服务是以 registry 开头的,如图示:

dubbo源码之启动过程分析

injvm

dubbo源码之启动过程分析

registry

上面代码也可以看出来,本地暴露和远程暴露的本质都是是通过把拼装好的 url 转换成 invoker,然后把 invoker 转换为 exporter。

点开 getInvoker 方法:

复制代码
1 /**
2 * create invoker.
3 *
4 * @param <T>
5 * @param proxy
6 * @param type
7 * @param url
8 * @return invoker
9 */
10 @Adaptive({Constants.PROXY_KEY})
11 <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) throws RpcException;

这里用到了 Adaptive,就会生成动态编译的 Adaptive 类。这个类就是 getInvoker 方法的具体实现。
拿到 invoker 之后,调用 protocol.export(invoker) 把 invoker 转换成 exporter。

复制代码
1 /**
2 * 暴露远程服务:<br>
3 * 1. 协议在接收请求时,应记录请求来源方地址信息:RpcContext.getContext().setRemoteAddress();<br>
4 * 2. export() 必须是幂等的,也就是暴露同一个 URL 的 Invoker 两次,和暴露一次没有区别。<br>
5 * 3. export() 传入的 Invoker 由框架实现并传入,协议不需要关心。<br>
6 *
7 * @param <T> 服务的类型
8 * @param invoker 服务的执行体
9 * @return exporter 暴露服务的引用,用于取消暴露
10 * @throws RpcException 当暴露服务出错时抛出,比如端口已占用
11 */
12 @Adaptive
13 <T> Exporter<T> export(Invoker<T> invoker) throws RpcException;

到这里就是服务暴露的总流程。

netty 服务启动

在 invoker->exporter 转换的过程中又涉及到了 dubbo 连接池的创建和 netty 的初始化。

定位到了 DubboProtocol.export() 方法,接着会调用 openServer(url) -> reateServer(url)

dubbo源码之启动过程分析

DubboProtocol

下图 openServer 的 key 就是 ip:port

dubbo源码之启动过程分析

OpenServer

dubbo源码之启动过程分析

createServer

在 createServer 方法中利用 dubbo SPI 机制找到 NettyTransporter,new NettyServer()->doOpen(). 最终我们就看到 boss 线程,worker 线程,和 ServerBootstrap。

dubbo源码之启动过程分析

NettyTransporter

dubbo源码之启动过程分析

doOpen

dubbo源码之启动过程分析

netty

到此,netty 开始进行初始化,并指定了 handler 为 nettyHandler,然后调用 bind 方法,完成端口的绑定,开启端口监听;

而 Client 在 Spring getBean 的时候,会创建 Client. 当调用远程方法的时候,将数据通过 dubbo 协议编码发送到 NettyServer,然后 NettServer 收到数据后解码,并调用本地方法,并返回数据,完成一次 RPC 调用。

1final NettyHandler nettyHandler = new NettyHandler(getUrl(), this);
NettyHandler 类它继承了 netty 框架的 SimpleChannelHandler 类,重写了 messageReceived 方法。接收到客户端请求的入口就是 messageReceived 方法。

复制代码
1 @Override
2 public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) throws Exception {
3 NettyChannel channel = NettyChannel.getOrAddChannel(ctx.getChannel(), url, handler);
4 try {
5 handler.received(channel, e.getMessage());
6 } finally {
7 NettyChannel.removeChannelIfDisconnected(ctx.getChannel());
8 }
9 }

执行了 handler 的 received 方法,这个 handler 其实就是 DubboProtocol 中的 requestHandler,因为在启动 netty 服务的时候,就将 requestHandler 对象一直传递到了 NettyServer,再通过 NettyServer 类的构造函数将它保存到了 NettyServer 类的终极父类 AbstractPeer 的 handler 属性上,AbstractPeer 类又实现了 ChannelHandler 接口,重写了 received 方法。

所以当 netty 框架接收到请求时执行 messageReceived 方法里面的 handler.received(channel, e.getMessage()); ,其实执行的是 AbstractPeer 类的 received 方法,received 然后里面又执行了 handler.received(ch, msg); ,然后 received 中又调用了 reply 方法。

在 reply 方法中,完成了数据的解码,和合法性校验。最终调用本地方法,返回数据,完成一次 RPC 调用。

复制代码
1private ExchangeHandler requestHandler = new ExchangeHandlerAdapter() {
2
3 public Object reply(ExchangeChannel channel, Object message) throws RemotingException {
4 if (message instanceof Invocation) {
5 Invocation inv = (Invocation) message;
6 Invoker<?> invoker = getInvoker(channel, inv);
7 // 如果是 callback 需要处理高版本调用低版本的问题
8 if (Boolean.TRUE.toString().equals(inv.getAttachments().get(IS_CALLBACK_SERVICE_INVOKE))){
9 String methodsStr = invoker.getUrl().getParameters().get("methods");
10 boolean hasMethod = false;
11 if (methodsStr == null || methodsStr.indexOf(",") == -1){
12 hasMethod = inv.getMethodName().equals(methodsStr);
13 } else {
14 String[] methods = methodsStr.split(",");
15 for (String method : methods){
16 if (inv.getMethodName().equals(method)){
17 hasMethod = true;
18 break;
19 }
20 }
21 }
22 if (!hasMethod){
23 logger.warn(new IllegalStateException("The methodName "+inv.getMethodName()+" not found in callback service interface ,invoke will be ignored. please update the api interface. url is:" + invoker.getUrl()) +" ,invocation is :"+inv );
24 return null;
25 }
26 }
27 RpcContext.getContext().setRemoteAddress(channel.getRemoteAddress());
28 return invoker.invoke(inv);
29 }
30 throw new RemotingException(channel, "Unsupported request: " + message == null ? null : (message.getClass().getName() + ": " + message) + ", channel: consumer: " + channel.getRemoteAddress() + " --> provider: " + channel.getLocalAddress());
31 }
32
33 @Override
34 public void received(Channel channel, Object message) throws RemotingException {
35 if (message instanceof Invocation) {
36 reply((ExchangeChannel) channel, message);
37 } else {
38 super.received(channel, message);
39 }
40 }

4 最后

如图,dubbo 的的模型十分易懂,但涉及到的东西确实很多。以上只是对第一步:0.start 做了一个简单的流水账分析。

所以,本文只是想做个引子,更多的细节还需要靠大家去挖掘。剩下的只有去 debug the universe 了。

dubbo源码之启动过程分析dubbo源码之启动过程分析

作者介绍:
江白圭(企业代号名),目前负责贝壳找房 java 后台研发工作。

本文转载自公众号贝壳产品技术(ID:gh_9afeb423f390)。

原文链接:

https://mp.weixin.qq.com/s/Vn2tErPWn2Fs52Igd0R5Qw

评论

发布