1.Dubbo源码解析：网络通信
2.Dubbo源码：跟着Demo学习基本使用
3.偷偷跟我学这个看源码的源验小技巧，早日解放双手
4.Dubbo调用超时那些事儿
5.我找到了Dubbo源码的码阅BUG，同事纷纷说我有点东西
6.Java教程：dubbo源码解析-网络通信

Dubbo源码解析：网络通信

       <dubbo源码解析：深入理解网络通信

       在之前的读经章节中，我们已经了解了消费者如何通过服务发现和负载均衡机制找到提供者并进行远程调用。源验本章将重点解析网络通信的码阅实现细节。

       网络通信主要在Dubbo的读经逆水寒 辅助 源码Remoting模块中进行，涉及多种通信协议，源验包括dubbo协议、码阅RMI、读经Hessian、源验HTTP、码阅WebService、读经Thrift、源验REST、码阅gRPC、读经Memcached和Redis等。每个协议都有其特定的优缺点，如Dubbo协议适用于高并发场景，而RMI则使用标准JDK序列化。

       Dubbo的序列化机制支持多种方式，如Hessian2、Kryo、FST等。近年来，高效序列化技术如Kryo和FST的出现，可提升性能，只需在配置中简单添加即可优化。

       关于数据格式和粘包拆包问题，Dubbo采用私有RPC协议，消息头存储元信息，如魔法数和数据类型，消息体则包含调用信息。消费者发送请求时，会通过MockClusterInvoker封装服务降级逻辑，然后通过序列化转换为网络可传输的数据格式。

       服务提供方接收请求时，ao动量指标源码首先对数据包进行解码，确认其格式正确性，然后调用服务逻辑。提供方返回调用结果时，同样经过序列化和编码，最后通过NettyChannel发送给消费者。

       在心跳检测方面，Dubbo采用双向心跳机制，客户端和服务端定期发送心跳请求以维持连接。此外，还通过定时任务处理重连和断连，确保连接的稳定性和可靠性。

       总的来说，Dubbo的网络通信模块精细且灵活，通过多种协议和优化技术确保服务调用的高效和可靠性。

Dubbo源码：跟着Demo学习基本使用

       Dubbo 是一款由阿里开源的高性能轻量级RPC框架，因其在各大企业如阿里、京东、小米、携程等的广泛应用而备受瞩目。本文将通过一个基础Demo，带你了解Dubbo的基本使用步骤。

       首先，你需要设置一个ZooKeeper服务器作为服务注册中心。ZooKeeper是Dubbo生产环境中的常见选择。下载并解压zookeeper-3.4..tar.gz包，然后修改conf/zoo.cfg配置，启动ZooKeeper服务。

       接下来，定义业务接口，即Dubbo Provider和Consumer之间的约定，如dubbo-demo-interface模块中的DemoService接口。它包含sayHello()和sayHelloAsync()方法。

       在dubbo-demo-xml模块中，提供了基于Spring XML的dll破译成源码Provider和Consumer实现。在Provider端的dubbo-provider.xml中，配置DemoServiceImpl为Spring Bean，并暴露到ZooKeeper。在Consumer端的dubbo-consumer.xml中，配置ZooKeeper地址，并使用dubbo:reference引入DemoService，以便远程调用其提供的服务。

       启动Consumer端的Application，通过ClassPathXmlApplicationContext加载配置文件，即可实现服务的调用。如果你有任何问题或需求，欢迎留言互动，共同探讨。

       本文摘自公众号“勾勾的Java宇宙”，关注的朋友们可以分享你的学习需求和建议。

偷偷跟我学这个看源码的小技巧，早日解放双手

       大家好！

       在看源码的过程中，查看 Git 提交记录是了解文件演变过程的有效途径。对于如何在 IDEA 中查看这些记录，可能有些同学感到困惑。这篇文章将分享一些实用的小技巧，帮助大家更直观地进行源码学习。

       首先，确保你的本地环境配置了 Git。如果还没有安装 Git，强烈建议你先完成安装并熟悉基本操作。

       接下来，使用 Git 克隆一个感兴趣的开源项目，例如 Redssion。在 IDEA 中导入项目并查看文件右键菜单，确认是否能找到“Git”选项。如果找不到，可能是 Git 配置问题，进入 IDEA 设置中进行相应的easyui后台登录源码调整。

       在 IDEA 的“Version Control”标签页中，你可以看到项目的提交历史。通过这个界面，你可以快速浏览文件的变更情况，了解代码的演变过程。

       在日常工作中或撰写文章时，使用 IDEA 的 Git 功能主要关注提交记录，而不是直接在 IDEA 中进行代码提交。这种方式提供了可视化的代码历史，有助于理解代码的变更轨迹。

       以 Redssion 为例，通过在 GitHub 的 issues 页面搜索关键词（如“死锁”），可以找到相关的问题讨论和代码修复。关注这些信息能帮助你更快定位问题和学习关键代码变更。

       使用 IDEA 的 Git 插件，可以方便地查看特定日期的提交记录。在“Version Control”标签页中，通过过滤功能找到目标日期的提交，这样可以快速定位到关键变更。

       通过查看提交记录，你可以了解代码的具体修改内容，这对于深入理解代码实现和调试问题非常有帮助。例如，在 Redssion 中，可以追踪到特定类的修改历史，了解其功能演进。

       此外，通过查看项目的首次提交记录，可以了解项目的起源和发展历程。例如，Dubbo 的首次提交记录反映了项目早期的状态和开发团队的辛勤工作。这些历史记录不仅展示了技术演变，也蕴含了项目发展的故事。

       总的来说，利用 IDEA 的xnova-one 源码 Git 功能探索代码历史，不仅可以帮助你更高效地学习和理解源码，还能深入了解项目的开发背景和演进过程。通过这种方式，源码阅读将变得更具趣味性和实用性。

Dubbo调用超时那些事儿

       其实之前很早就看过Dubbo源码中关于超时这部分的处理逻辑，但是没有记录下来，最近在某脉上看到有人问了这个问题，想着再回顾一下。

开始

       从dubbo的请求开始，看看dubbo（2.6.6）在超时这块是怎么处理的：

com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeChannel#request(java.lang.Object, int)@Overridepublic ResponseFuture request(Object request, int timeout) throws RemotingException { if (closed) { throw new RemotingException(this.getLocalAddress(), null, "Failed to send request " + request + ", cause: The channel " + this + " is closed!");}// create request.Request req = new Request();req.setVersion(Version.getProtocolVersion());req.setTwoWay(true);req.setData(request);DefaultFuture future = new DefaultFuture(channel, req, timeout);try { channel.send(req);} catch (RemotingException e) { future.cancel();throw e;}return future;}DefaultFuture

       从返回值ResponseFuture类型可以看出，这是一个异步方法（不等同于Dubbo的异步调用）。那么调用超时的关键可以从ResponseFuture来看：

public interface ResponseFuture { Object get() throws RemotingException;Object get(int timeoutInMillis) throws RemotingException;void setCallback(ResponseCallback callback);boolean isDone();}

       可以看到这是一个接口，从request方法可以得知实现类是DefaultFuture，从构造函数入手：

public DefaultFuture(Channel channel, Request request, int timeout) { this.channel = channel;this.request = request;this.id = request.getId();this.timeout = timeout > 0 ? timeout : channel.getUrl().getPositiveParameter(Constants.TIMEOUT_KEY, Constants.DEFAULT_TIMEOUT);// put into waiting map.FUTURES.put(id, this);CHANNELS.put(id, channel);}

       可以得知每一个DefaultFuture都有一个id，并且等于requestId，timeout是从url中获取的配置，没有时默认ms。

       从代码的注释可以看到FUTURES这个map应该就是关键，是一个waiting map。

       DefaultFuture中还有一个方法：

public static void received(Channel channel, Response response) { try { DefaultFuture future = FUTURES.remove(response.getId());if (future != null) { future.doReceived(response);} else { logger.warn("The timeout response finally returned at "+ (new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS").format(new Date()))+ ", response " + response+ (channel == null ? "" : ", channel: " + channel.getLocalAddress()+ " -> " + channel.getRemoteAddress()));}} finally { CHANNELS.remove(response.getId());}}

       可以看到调用的地方为：

       com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeHandler#received

@Overridepublic void received(Channel channel, Object message) throws RemotingException { //省略一些代码} else if (message instanceof Response) { handleResponse(channel, (Response) message);//省略一些代码}}

       com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeHandler#handleResponse

static void handleResponse(Channel channel, Response response) throws RemotingException { if (response != null && !response.isHeartbeat()) { DefaultFuture.received(channel, response);}}

       回到DefaultFuture.received，可以看到通过Response id从FUTURES中拿了一个DefaultFuture出来，然后调用了doReceived方法，也就是说Response id和Request id 相同。结下来看看doReceived做了什么：

private void doReceived(Response res) { lock.lock();try { response = res;if (done != null) { done.signal();}} finally { lock.unlock();}if (callback != null) { invokeCallback(callback);}}

       首先是加锁，然后通过唤醒了阻塞在Condition上的线程。看看什么地方会阻塞在done这个条件上：

@Overridepublic Object get(int timeout) throws RemotingException { if (timeout <= 0) { timeout = Constants.DEFAULT_TIMEOUT;}if (!isDone()) { long start = System.currentTimeMillis();lock.lock();try { while (!isDone()) { done.await(timeout, TimeUnit.MILLISECONDS);if (isDone() || System.currentTimeMillis() - start > timeout) { break;}}} catch (InterruptedException e) { throw new RuntimeException(e);} finally { lock.unlock();}if (!isDone()) { throw new TimeoutException(sent > 0, channel, getTimeoutMessage(false));}}return returnFromResponse();}

       是get方法，get方法确实在request请求后被调用：

(Result) currentClient.request(inv, timeout).get()

       可以看到get方法的大致逻辑为，先获取锁，然后循环判断isDone，并阻塞等到条件，当条件超时，如果任务完成，或者超过timeout结束循环，接着判断isDone，如果超时抛出TimeoutException。并且通过sent（request请求时间）是否>0（）来判断是clientSide还是serverSide超时。

       isDone逻辑如下：

@Overridepublic boolean isDone() { return response != null;}

       如果是正常Response，也有可能是超时的现象，可以看到get方法最后调用了一个函数：

public interface ResponseFuture { Object get() throws RemotingException;Object get(int timeoutInMillis) throws RemotingException;void setCallback(ResponseCallback callback);boolean isDone();}0TIMEOUT SIDE

       SERVER_TIMEOUT（服务端超时）： 这个就是正常的我们消费端请求一个RPC接口，服务端由于性能等一些原因处理时间超过了timeout配置时间。

       CLIENT_TIMEOUT：我们可以看到是通过sent(上面有说sent>0)这个来判断是否clientTimeout，那么这个sent什么时候改变呢？就在发送请求的地方：

public interface ResponseFuture { Object get() throws RemotingException;Object get(int timeoutInMillis) throws RemotingException;void setCallback(ResponseCallback callback);boolean isDone();}1

       也就是说handler.sent一旦调用成功返回，那么就不算clientSide Timeout了。那么CLIENT_TIMEOUT大概率就是由于client端网络，系统等原因超时。

原文：/post/

我找到了Dubbo源码的BUG，同事纷纷说我有点东西

       某天，运营反馈称，执行一次保存操作后，后台出现3条数据，我立刻怀疑可能存在代码问题。为了确保不会误判，我要求暂停操作，保留现场，以便我进行排查。

       查看新增代码，发现是同事三歪进行的改动，他将原有的dubbo XML配置方式改为了注解方式。我询问其改动详情，得知他是更改了模块的配置方式。于是，我决定深入研究，找出问题所在。

       dubbo配置方式多样，最常见的为XML配置与注解配置。我已初步推测原因，接下来将进行详细的调试过程。

       我使用dubbo版本2.6.2进行调试。首先，针对采用@Reference注解条件下的重试次数配置，我发现调用接口时，会跳转到InvokerInvocationHandler的invoke方法。继续跟踪，最终定位到FailoverClusterInvoker的doInvoke方法。在该方法中，我关注到获取配置的retries值，发现其默认值为null，导致最终计算出的重试次数为3。

       采用dubbo:reference标签配置重试次数时，同样在获取属性值后，发现其默认值为0，与注解配置一致，最终计算出的重试次数为1。对比两种配置方式，我总结了以下原因：

       在@Reference注解形式下，dubbo会在注入代理对象时，通过自定义驱动器ReferenceAnnotationBeanPostProcessor来注入属性。在标签形式下，虽然也使用了Autowired注解，但dubbo会使用自定义名称空间解析器DubboNamespaceHandler进行解析。

       在注解形式下，当配置retries为0时，属性值在注入过程中并未被解析为null，但进入buildReferenceBean时，因nullSafeEquals方法的处理，导致默认值和实际值不一致，最终未保存到map中。而标签形式下，解析器能够正确解析出retries的值为0，避免了后续的问题。

       总结发现，采用@Reference注解配置重试次数时，dubbo在注入属性过程中存在逻辑处理上的问题，导致默认值与实际值不一致。此为dubbo的一个逻辑bug。建议在不需要重试时，设置retries为-1，以确保接口的幂等性。需要重试时，设置为1或更大值。

       问题解决后，我优化了文件操作，将其改为异步处理，从而缩短了主流程的时间。最终，数据出现3条的状况得以解决。

       此问题已得到解决，并在后续dubbo版本2.7.3中修复，确保了在注解配置方式下，nullSafeEquals方法能够正确处理默认值与实际值一致的情况。

Java教程：dubbo源码解析-网络通信

       在之前的内容中，我们探讨了消费者端服务发现与提供者端服务暴露的相关内容，同时了解到消费者端通过内置的负载均衡算法获取合适的调用invoker进行远程调用。接下来，我们聚焦于远程调用过程，即网络通信的细节。

       网络通信位于Remoting模块中，支持多种通信协议，包括但不限于：dubbo协议、rmi协议、hessian协议、ty进行网络通讯，NettyClient.doOpen()方法中可以看到Netty的相关类。序列化接口包括但不限于：Serialization接口、Hessian2Serialization接口、Kryo接口、FST接口等。

       序列化方式如Kryo和FST，性能往往优于hessian2，能够显著提高序列化性能。这些高效Java序列化方式的引入，可以优化Dubbo的序列化过程。

       在配置Dubbo RPC时，引入Kryo和FST非常简单，只需在RPC的XML配置中添加相应的属性即可。

       关于服务消费方发送请求，Dubbo框架定义了私有的RPC协议，消息头和消息体分别用于存储元信息和具体调用消息。消息头包括魔数、数据包类型、消息体长度等。消息体包含调用消息，如方法名称、参数列表等。请求编码和解码过程涉及编解码器的使用，编码过程包括消息头的写入、序列化数据的存储以及长度的写入。解码过程则涉及消息头的读取、序列化数据的解析以及调用方法名、参数等信息的提取。

       提供方接收请求后，服务调用过程包含请求解码、调用服务以及返回结果。解码过程在NettyHandler中完成，通过ChannelEventRunnable和DecodeHandler进一步处理请求。服务调用完成后，通过Invoker的invoke方法调用服务逻辑。响应数据的编码与请求数据编码过程类似，涉及数据包的构造与发送。

       服务消费方接收调用结果后，首先进行响应数据解码，获得Response对象，并传递给下一个处理器NettyHandler。处理后，响应数据被派发到线程池中，此过程与服务提供方接收请求的过程类似。

       在异步通信场景中，Dubbo在通信层面为异步操作，通信线程不会等待结果返回。默认情况下，RPC调用被视为同步操作。Dubbo通过CompletableFuture实现了异步转同步操作，通过设置异步返回结果并使用CompletableFuture的get()方法等待完成。

       对于异步多线程数据一致性问题，Dubbo使用编号将响应对象与Future对象关联，确保每个响应对象被正确传递到相应的Future对象。通过在创建Future时传入Request对象，可以获取调用编号并建立映射关系。线程池中的线程根据Response对象中的调用编号找到对应的Future对象，将响应结果设置到Future对象中，供用户线程获取。

       为了检测Client端与Server端的连通性，Dubbo采用双向心跳机制。HeaderExchangeClient初始化时，开启两个定时任务：发送心跳请求和处理重连与断连。心跳检测定时任务HeartbeatTimerTask确保连接空闲时向对端发送心跳包，而ReconnectTimerTask则负责检测连接状态，当判定为超时后，客户端选择重连，服务端采取断开连接的措施。